Summary
Laravel-Mediable contains an incomplete file-extension blocklist that allows files using the .pht extension to pass upload validation. On deployments where the web server treats .pht files as PHP, an attacker who can upload media may achieve remote code execution with the privileges of the web server process.
Affected context
The vulnerability occurs in Laravel-Mediable deployments that use the affected validation and sanitization logic and permit users or external systems to upload files. Risk is higher when the upload directory is web-accessible and the server configuration maps .pht files to the PHP interpreter, as can occur with certain Apache configurations on Debian- or Ubuntu-based systems.
Exploit preconditions
- Attack surface: Media or file upload functionality exposed by the Laravel-Mediable application
- Required access: Authorization to submit an upload, or another condition that permits an attacker to place a file through the application
- Trigger point: File validation followed by storage in a web-accessible location and subsequent HTTP access
- Why exploitation is possible: The extension blocklist omits
.pht, allowing the file to be stored; a compatible web-server handler may then process it as PHP rather than as inert content
Why this happens
The underlying issue is an incomplete denylist for executable file extensions. Although the validation logic blocks some PHP-related extensions, it does not account for .pht, creating a mismatch between application-level validation and web-server execution behavior. This maps to CWE-434: Unrestricted Upload of File with Dangerous Type, because a potentially executable file can cross the upload boundary and reach a location where it may be interpreted as server-side code.
Potential impact
- An attacker may execute arbitrary code with the privileges of the web server process
- The application and its hosted data could be compromised
- Credentials, environment variables, or connected services could be exposed
- Uploaded content could be altered or used to facilitate persistence
- The server may be used for lateral movement or further attacks
General mitigation guidance
Mitigation generally focuses on making uploaded content non-executable by design rather than relying solely on extension blocklists.
Common defensive patterns include:
- Store uploads outside the web document root or serve them through a controlled download handler
- Use an allowlist of expected file types and validate content independently of the filename
- Normalize filenames and reject ambiguous, executable, or server-interpreted extensions
- Configure the web server and runtime so user-uploaded files cannot be executed as scripts
- Apply least-privilege permissions to the web server and upload directories
- Use isolated storage, constrained filesystem permissions, and resource limits where practical
- Treat client-supplied filenames, MIME types, and extensions as untrusted metadata
How teams detect issues like this
Detection approaches may include:
- Static analysis rules that identify extension denylists without corresponding allowlists or server-side execution controls
- Code review checks for upload validation followed by writes into web-accessible directories
- Configuration reviews for handlers that associate uncommon extensions with PHP or other interpreters
- Monitoring for executable extensions, unexpected script content, or requests targeting uploaded files
- Policy enforcement requiring uploads to use non-executable storage and controlled download paths
- Automated security review tools that compare application upload behavior with web-server configuration
