Description

Winter CMS is a content management system built on the Laravel PHP framework. In versions up to and including 1.2.12, the backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on, allowing an authenticated backend user to read and modify attachment records belonging to other users or records. The widget's getFileRecord() lookup resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session. Because all attachments share a single File model and table and attachment ids are sequential integers that are easily enumerated, a user reaching any form with a fileupload field, including the built-in My Account avatar field that requires no specific permission, could target arbitrary attachments to modify their title and description via onSaveAttachmentConfig and change their sort order via onSortAttachments, which passed posted ids straight to an unscoped update. CSRF tokens remain enforced, so exploitation requires a valid authenticated backend session with any level of access. This issue is fixed in version 1.2.13.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-26T18:16:40.780Z",
  "pubdate": "2026-08-26T18:16:40.780Z",
  "executiveSummary": "Winter CMS versions up to and including 1.2.12 contain a critical authorization vulnerability within the backend FileUpload form widget.\nThe vulnerability allows an authenticated backend user to perform unauthorized operations on arbitrary attachment records stored within the global system_files table.\nBy manipulating the file_id POST parameter, an attacker can modify metadata, such as titles and descriptions, or alter the sort order of attachments that do not belong to their own account or session context.\nThe root cause is a failure to enforce relationship scoping or ownership verification during the file lookup process in the getFileRecord() function.\nBecause attachment identifiers are sequential integers, the system is susceptible to enumeration attacks, enabling unauthorized manipulation of sensitive system or user-specific files.\nExploitation requires a valid, authenticated backend session, as CSRF protection remains enforced, limiting the attack surface to users with at least minimal backend access. The risk involves unauthorized data modification and potential integrity compromise of system resources.",
  "technicalDetails": "The vulnerability resides in the backend FileUpload form widget, specifically within the logic used to retrieve and interact with file attachments. The getFileRecord() function is responsible for resolving the requested attachment based on a user-supplied file_id POST parameter. In affected versions (up to 1.2.12), this function resolves the provided ID against the global system_files table without implementing necessary security checks to verify that the target file belongs to the current widget's relation, parent record, or an active deferred-binding session.\nBecause Winter CMS utilizes a unified File model and a singular database table for all attachments, the lack of relationship-based scoping allows any user with backend access to query any record in the table. Furthermore, because attachment IDs are implemented as sequential integers, an attacker can easily enumerate valid IDs to target arbitrary files, including those belonging to other users or sensitive system configurations.\nThe attack flow proceeds as follows: An authenticated user navigates to a backend form containing a FileUpload widget. Even if the user has minimal privileges (e.g., the 'My Account' profile page), they can intercept the request and modify the file_id parameter. Upon sending a crafted POST request, the application invokes onSaveAttachmentConfig or onSortAttachments. These methods utilize the unsanitized file_id to perform database operations. The server-side logic processes these commands directly on the requested object, unaware that the object resides outside the user's scope. Consequently, the attacker can update the title, description, or sort order of any file indexed in the database.\nThe vulnerability is primarily an Insecure Direct Object Reference (IDOR) combined with insufficient authorization controls. By failing to validate the relationship between the authenticated user and the specific attachment record, the application violates the principle of least privilege. The impact includes the ability to corrupt attachment metadata, potentially disrupting system functionality or altering user-uploaded content management. While the attacker cannot directly execute arbitrary code, the ability to manipulate file records can be a precursor to further exploitation or social engineering by altering file metadata to misrepresent system or user data."
}