Summary
Thelia contains an unrestricted file upload vulnerability that can allow an authenticated back-office user to upload a PHP file despite filename validation. A trailing space creates a mismatch between validation and storage-time sanitization, potentially allowing the file to be placed in a web-accessible directory and executed by the web server.
Thelia contains an unrestricted file upload vulnerability that can allow an authenticated back-office user to upload a PHP file despite filename validation. A trailing space creates a mismatch between validation and storage-time sanitization, potentially allowing the file to be placed in a web-accessible directory and executed by the web server.
Affected context
The issue affects Thelia deployments where authenticated back-office users can upload documents and uploaded files are stored under a web-accessible path such as public/cache/documents/. Risk increases when the application server treats files in that location as executable and filename validation occurs before a later sanitization step changes the filename.
The issue affects Thelia deployments where authenticated back-office users can upload documents and uploaded files are stored under a web-accessible path such as public/cache/documents/. Risk increases when the application server treats files in that location as executable and filename validation occurs before a later sanitization step changes the filename.
Exploit preconditions
- Attack surface: Authenticated back-office file upload functionality
- Required access: A valid account with permission to upload files
- Trigger point: File validation and subsequent storage of an uploaded document
- Why exploitation is possible: Validation evaluates the submitted filename before trailing-space normalization, while storage removes the space and can leave a PHP extension
- Additional deployment condition: The resulting file must be reachable through the web server and interpreted as executable PHP
- Attack surface: Authenticated back-office file upload functionality
- Required access: A valid account with permission to upload files
- Trigger point: File validation and subsequent storage of an uploaded document
- Why exploitation is possible: Validation evaluates the submitted filename before trailing-space normalization, while storage removes the space and can leave a PHP extension
- Additional deployment condition: The resulting file must be reachable through the web server and interpreted as executable PHP
Why this happens
The vulnerability results from inconsistent handling of filenames across validation and storage. The upload validator evaluates the raw filename, while a later sanitization routine removes a trailing space before saving the file. This canonicalization mismatch can bypass extension restrictions and cause an executable script to be stored in a public directory, mapping to CWE-434: Unrestricted Upload of File with Dangerous Type.
The vulnerability results from inconsistent handling of filenames across validation and storage. The upload validator evaluates the raw filename, while a later sanitization routine removes a trailing space before saving the file. This canonicalization mismatch can bypass extension restrictions and cause an executable script to be stored in a public directory, mapping to CWE-434: Unrestricted Upload of File with Dangerous Type.
Potential impact
- An attacker may execute arbitrary PHP code as the web server user
- The application and its accessible data could be compromised
- Credentials, configuration values, or customer data could be exposed
- The affected server could be used for persistence or lateral movement
- Website content or application behavior could be modified
- An attacker may execute arbitrary PHP code as the web server user
- The application and its accessible data could be compromised
- Credentials, configuration values, or customer data could be exposed
- The affected server could be used for persistence or lateral movement
- Website content or application behavior could be modified
General mitigation guidance
Mitigation generally focuses on enforcing one consistent, secure filename and content-validation process from intake through storage.
Common defensive patterns include:
- Canonicalize filenames before applying extension and policy checks
- Prefer allowlists of permitted file types and reject executable formats
- Validate file content and detected type rather than trusting the client-provided filename
- Store user-uploaded content outside the web root when possible
- Disable script execution in upload and cache directories
- Generate server-side filenames and avoid preserving user-controlled extensions
- Apply least-privilege permissions to the web server and uploaded-file directories
- Restrict upload functionality to the minimum required authenticated roles
Mitigation generally focuses on enforcing one consistent, secure filename and content-validation process from intake through storage.
Common defensive patterns include:
- Canonicalize filenames before applying extension and policy checks
- Prefer allowlists of permitted file types and reject executable formats
- Validate file content and detected type rather than trusting the client-provided filename
- Store user-uploaded content outside the web root when possible
- Disable script execution in upload and cache directories
- Generate server-side filenames and avoid preserving user-controlled extensions
- Apply least-privilege permissions to the web server and uploaded-file directories
- Restrict upload functionality to the minimum required authenticated roles
How teams detect issues like this
Organizations can look for:
- Static-analysis findings where filename validation precedes normalization or sanitization
- Code review signals involving extension checks on raw user-controlled names
- Upload paths located beneath publicly served directories
- Web-server policies that permit script execution in document, cache, or media directories
- Logs showing unusual upload filenames, trailing whitespace, unexpected script extensions, or requests for newly uploaded files
- Automated security tests that compare validation behavior before and after filename canonicalization
Organizations can look for:
- Static-analysis findings where filename validation precedes normalization or sanitization
- Code review signals involving extension checks on raw user-controlled names
- Upload paths located beneath publicly served directories
- Web-server policies that permit script execution in document, cache, or media directories
- Logs showing unusual upload filenames, trailing whitespace, unexpected script extensions, or requests for newly uploaded files
- Automated security tests that compare validation behavior before and after filename canonicalization
