CVE-2026-109162 in TYPO3
Summary
by MITRE • 10/13/2026
Forms using FileUpload or ImageUpload elements with a custom saveToFileMount configured stored uploaded files in the default storage folder 1:/user_upload/ instead of the configured destination. This could cause uploaded files to end up in a publicly accessible storage even though a restricted, non-public storage had been configured. Files stored this way are served directly, without the access checks applied to non-public storages. Forms that use the default value for saveToFileMount are not affected. This issue affects TYPO3 CMS versions 14.0.0-14.3.8.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability described constitutes a critical misconfiguration handling flaw within the file upload mechanisms of specific versions of TYPO3 CMS, specifically affecting releases from 14.0.0 through 14.3.8. The core issue arises when developers configure forms utilizing FileUpload or ImageUpload elements with a custom saveToFileMount parameter intended to direct uploaded assets to a restricted, non-public storage location. Instead of adhering to this explicit configuration directive, the system erroneously defaults to storing these files in the standard public directory located at 1:/user_upload/. This deviation from expected behavior creates a significant security gap because it bypasses the access control mechanisms that are typically enforced for private or protected storage mounts.
From a technical perspective, the flaw lies in the logic governing file persistence during form submission processes. When a custom saveToFileMount is specified, the application fails to validate or enforce this path constraint correctly, resulting in files being written to a location with broader web server exposure. Unlike public storage areas where direct access is permitted without authentication checks, non-public storages are designed to serve content only after verifying user permissions and session validity. By placing files in the default public folder despite instructions otherwise, the system effectively neutralizes these protective layers. Consequently, any file uploaded through such a form becomes immediately accessible via its URL without requiring valid credentials or authorization tokens.
The operational impact of this vulnerability is severe, particularly for applications handling sensitive data or proprietary content. Attackers can exploit this misconfiguration to retrieve restricted files simply by constructing the appropriate direct link to the stored asset in the public directory. This leads directly to unauthorized information disclosure, as confidential documents, images, or other user-uploaded materials become viewable to any internet user. In scenarios where uploaded files contain personally identifiable information or intellectual property, this exposure can result in regulatory compliance violations and substantial reputational damage. The risk is further compounded if the stored files are executable scripts that could be leveraged for remote code execution attacks, although the primary immediate threat remains data leakage through unrestricted file access.
This vulnerability aligns with CWE-200, which categorizes issues related to exposure of sensitive information to unauthorized actors, and specifically reflects weaknesses in input validation and configuration management often associated with improper resource control. In terms of attack vectors, it facilitates exploitation without the need for complex injection techniques or privilege escalation, relying instead on predictable file paths resulting from a logic error. It also relates to CWE-59, Improper Link Resolution Before File Access, as the system fails to correctly resolve and enforce the intended secure storage path before committing the data.
To mitigate this risk, administrators must upgrade their TYPO3 CMS instances to version 14.3.8 or later, where the logic for handling custom saveToFileMount configurations has been corrected to respect the designated non-public storage paths. For environments that cannot immediately patch due to dependency constraints, temporary workarounds should include auditing all forms using FileUpload or ImageUpload elements with custom mount points and ensuring they are not processing sensitive data until an upgrade is feasible. Additionally, implementing strict web server configuration rules can provide a secondary layer of defense by restricting direct access to the user_upload directory for specific file types that should remain private, although this does not address the root cause within the application logic itself.