Summary
CodeIgniter's upload validation rules is_image and mime_in can allow dangerous files to be uploaded when only MIME type or image checks are enforced without validating file extensions.
If an application preserves the client-supplied filename and stores uploads in a web-accessible, script-enabled directory, a remote attacker could upload executable content and potentially achieve remote code execution.
Affected context
This vulnerability manifests in CodeIgniter-based applications that rely solely on is_image or mime_in for upload validation while:
- Accepting and trusting the client-supplied filename
- Storing uploaded files under their original names
- Writing uploads into web-accessible directories where PHP or other scripts can execute
It becomes particularly risky when no independent safe extension check (such as ext_in) is enforced and the web server is configured to execute files based on their extensions.
Exploit preconditions
- Attack surface: Public or authenticated file upload endpoints built with CodeIgniter.
- Required access: Ability to submit file uploads to an affected endpoint (no need for direct server access).
- Trigger point: Upload handlers that validate files with
is_imageormime_inonly, then save the file using the client's filename into a script-executable directory. - Why exploitation is possible: MIME-type or content-based checks alone do not constrain the final file extension, so an attacker can supply a file with executable extension (e.g.,
.php) that passes validation and is later interpreted as code by the server.
Why this happens
The core issue is an unrestricted file upload pattern where trust is placed in MIME or image checks without enforcing a safe, whitelisted file extension.
The is_image and mime_in rules validate content characteristics but do not constrain or sanitize the resulting filename on disk, allowing client-controlled extensions to remain intact.
This maps to CWE-434: Unrestricted Upload of File with Dangerous Type, where user-controlled uploads can result in files being stored and executed in contexts that treat them as server-side code.
Potential impact
- Remote code execution on the web server through uploaded scripts
- Complete compromise of the affected application and its data
- Use of the server as a pivot point for lateral movement in the network
- Defacement or manipulation of served content via malicious uploads
- Deployment of web shells or backdoors for persistent access
General mitigation guidance
Effective mitigation focuses on restricting what gets uploaded, where it is stored, and how the server interprets it:
- Enforce strict whitelists of allowed file extensions independent of MIME checks, and reject any unexpected or executable types.
- Normalize and regenerate filenames on the server side instead of using client-supplied names; avoid carrying over user-controlled extensions.
- Store uploads in non-executable directories or on storage backends that are not mapped to script-capable web roots.
- Configure the web server to treat upload locations as static-only, disabling PHP or other scripting engines there.
- Apply least-privilege file and directory permissions so uploaded content cannot escalate its impact if mishandled.
How teams detect issues like this
Organizations can detect this class of issue through a combination of code and configuration review:
- Static analysis: Look for upload handlers that rely on
is_imageormime_inwithout additional extension whitelisting or filename normalization. - Code review signals: Patterns where
$file->getClientName()or similar constructs are used directly when saving files, especially into web-accessible paths. - Configuration checks: Validate that upload directories are not configured as script-executable roots and that web server directives do not enable code execution there.
- Security testing: Incorporate upload fuzzing in penetration tests to attempt uploading benign scripts with allowed MIME types to see if they are accepted and executable.
