Executive Summary
CVE-2026-14635 is a high-severity unrestricted file upload vulnerability affecting the open-source kirilkirkov/Ecommerce-CodeIgniter-Bootstrap project. The flaw exists in the vendor product management endpoint (AddProduct.php) and allows an authenticated vendor user to upload a PHP webshell disguised as an image, achieving remote code execution on the web server.
CVSS Score: 7.3 (High)
Operators running this ecommerce framework should treat this as urgent — vendor account registration is often publicly accessible, meaning an attacker can self-register before exploiting the flaw.
Vulnerability Overview
Root Cause
The multi-image upload endpoint in application/modules/vendor/controllers/AddProduct.php accepts file uploads without validating the true MIME type or enforcing a safe allowlist of extensions. The application relies on client-supplied Content-Type headers and filename extensions, both of which can be trivially spoofed.
Attack Surface
| Component | Detail |
|---|---|
| Endpoint | POST /vendor/addproduct (multi-image parameter) |
| Auth Required | Vendor account (self-registrable in most deployments) |
| File Stored | Publicly accessible upload directory |
| Impact | RCE as the web server process (www-data or equivalent) |
Attack Chain
1. Attacker registers or compromises a vendor account
2. Navigates to Add Product and uploads PHP webshell as "image"
3. Server accepts file — no MIME validation performed
4. Attacker requests the uploaded file URL directly
5. PHP interpreter executes the shell on the server
6. Full remote code execution achievedTechnical Details
Affected Code Path
The vulnerability is in the multi-image handling logic:
application/modules/vendor/controllers/AddProduct.php
The upload helper accepts any file matching basic image extension patterns but does not:
- Validate actual file content / magic bytes
- Strip or reject PHP-interpretable extensions (
.php,.php5,.phtml, etc.) - Restrict execution of files in the upload directory
Proof of Concept (Redacted)
A minimal exploit involves:
- Crafting a POST request with
Content-Type: multipart/form-data - Including a file field with extension
.php(or a double extension like.php.jpgif filtered) - File content: minimal PHP webshell
Actual exploit payloads are available on public exploit databases; patch immediately.
Affected Versions
| Commit | Status |
|---|---|
Up to 222ff31c06687b1c6d0e1ab63953f82c3674c52b | Vulnerable |
| No patched release published at time of disclosure | Check upstream |
Remediation
Immediate Steps
1. Validate file type server-side using magic bytes (not extension or Content-Type):
// Use PHP's finfo to validate real MIME type
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($_FILES['image']['tmp_name']);
$allowed = ['image/jpeg', 'image/png', 'image/gif', 'image/webp'];
if (!in_array($mime, $allowed)) {
show_error('Invalid file type.');
}2. Enforce safe extension allowlist and rename on save:
// Rename uploaded file to UUID + safe extension
$ext = 'jpg'; // determined from validated MIME only
$newname = bin2hex(random_bytes(16)) . '.' . $ext;3. Disable PHP execution in upload directories (.htaccess):
<Directory /path/to/uploads>
php_flag engine off
Options -ExecCGI
AddType text/plain .php .php5 .phtml .phar
</Directory>4. Move upload storage out of the web root if possible.
Detection
Log Analysis
Look for POST requests to vendor product upload endpoints followed by GET requests to upload directories with .php extensions:
grep -E "POST.*addproduct" /var/log/apache2/access.log
grep -E "GET.*/uploads/.*\.php" /var/log/apache2/access.logFile System Audit
# Find PHP files in upload directories
find /var/www/html/uploads -name "*.php" -o -name "*.phtml" -o -name "*.phar" 2>/dev/null