Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN727 _____________________________________________________________________ DATE : 07/07/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running codeigniter4 versions prior to 4.7.4. ===================================================================== https://github.com/codeigniter4/CodeIgniter4/security/advisories/GHSA-mmj4-63m4-r6h5 https://github.com/codeigniter4/CodeIgniter4/security/advisories/GHSA-c9w5-rwh3-7pm9 https://github.com/codeigniter4/CodeIgniter4/security/advisories/GHSA-hhmc-q9hp-r662 https://github.com/codeigniter4/CodeIgniter4/security/advisories/GHSA-7wmf-pw8j-mc78 _____________________________________________________________________ Uploaded file extension validation bypass in `is_image` and `mime_in` rules Critical paulbalandan published GHSA-mmj4-63m4-r6h5 Package codeigniter4/framework (Composer) Affected versions < 4.7.4 Patched versions 4.7.4 Description Impact This is an unsafe file upload validation vulnerability that can lead to remote code execution in vulnerable application configurations. Applications are impacted when they: validate uploads using is_image or mime_in without an independent safe extension check, such as ext_in on patched versions save uploaded files using the client-supplied filename place uploads in a web-accessible directory where PHP files can execute Patches Upgrade to v4.7.4 or later. Workarounds Save uploads outside the public web root, preferably under writable/uploads. Use $file->store() or $file->move($path, $file->getRandomName()) instead of preserving the original client filename. Disable script execution in any public upload directory. Manually verify the client filename extension before moving the file. For image uploads, reject files when $file->getClientExtension() is not an allowed image extension. For exact MIME-type validation, reject files when $file->getClientExtension() does not match $file->guessExtension(). References GHSA-2gr4-ppc7-7mhx: Uploaded file extension validation bypass in ext_in CodeIgniter4 uploaded files documentation CodeIgniter4 file upload validation documentation CWE-434: Unrestricted Upload of File with Dangerous Type OWASP File Upload Cheat Sheet Severity Critical 9.8/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality High Integrity High Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H CVE ID No known CVE Weaknesses Weakness CWE-434 Credits @wnsgurd90-keke wnsgurd90-keke Reporter _____________________________________________________________________ SQL injection in Query Builder deleteBatch() when used with where() conditions Critical paulbalandan published GHSA-c9w5-rwh3-7pm9 Package codeigniter4/framework (Composer) Affected versions >= 4.3.0, < 4.7.4 Patched versions 4.7.4 Description Impact A SQL injection vulnerability exists in the Query Builder's deleteBatch() method. When deleteBatch() is used together with where() conditions, the bound values from the WHERE clause are substituted directly into the generated SQL with their escape flag ignored, so they are never escaped or quoted. If an application passes user-controlled input to where() before calling deleteBatch(), that input is interpreted as SQL rather than as a value, allowing SQL injection. This affects only the deleteBatch() code path. Regular delete() operations escape where() binds correctly. Patches Upgrade to v4.7.4 or later. Workarounds If you cannot upgrade immediately: Strictly validate and cast values (e.g. numeric IDs) before using them in conditions - though this does not fully protect string conditions. Do not pass user-controlled input to where() when using deleteBatch(). For user-controlled conditions, use a normal delete() with Query Builder binds instead of deleteBatch(). Where possible, express required matching values through the batch data and onConstraint() rather than as separate user-controlled where() clauses. References OWASP - SQL Injection (attack reference): https://owasp.org/www-community/attacks/SQL_Injection deleteBatch() documentation: https://codeigniter.com/user_guide/database/query_builder.html#builder-deletebatch Severity Critical 9.4/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality Low Integrity High Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H CVE ID No known CVE Weaknesses Weakness CWE-89 Credits @gr8man gr8man Reporter _____________________________________________________________________ Path traversal in UploadedFile::move() when using client-provided filenames High paulbalandan published GHSA-hhmc-q9hp-r662 Package codeigniter4/framework (Composer) Affected versions < 4.7.4 Patched versions 4.7.4 Description Impact In affected versions, calling UploadedFile::move() without a second argument uses the client-provided filename without sanitization. Depending on the destination path and server configuration, an attacker can supply a filename containing path traversal sequences (e.g. ../../public/shell.php) to write uploaded content outside the intended upload directory. The patch sanitizes this default (no-argument) path. Note: The patch only sanitizes the filename when no second argument is passed. If your application explicitly passes a client-provided name as the second argument, you remain responsible for sanitizing it - the patch does not (and cannot) sanitize a caller-supplied filename: // Unsafe - even after upgrading: $file->move(WRITEPATH . 'uploads', $file->getName()); $file->move(WRITEPATH . 'uploads', $file->getClientName()); Patches Upgrade to v4.7.4 or later. Workarounds If you cannot upgrade immediately, use a generated filename or sanitize the client filename before passing it to move(). Use a generated filename: $file->move(WRITEPATH . 'uploads', $file->getRandomName()); Or sanitize the client filename before passing it to move(): helper('security'); $name = sanitize_filename($file->getClientName()); $file->move(WRITEPATH . 'uploads', $name); References OWASP: Path Traversal: https://owasp.org/www-community/attacks/Path_Traversal Uploaded Files documentation: https://codeigniter.com/user_guide/libraries/uploaded_files.html Security Helper sanitize_filename(): https://codeigniter.com/user_guide/helpers/security_helper.html Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity High Availability None CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N CVE ID No known CVE Weaknesses Weakness CWE-22 Credits @gr8man gr8man Reporter _____________________________________________________________________ Spoofable forwarded HTTPS headers in IncomingRequest::isSecure() Moderate paulbalandan published GHSA-7wmf-pw8j-mc78 Package codeigniter4/framework (Composer) Affected versions < 4.7.4 Patched versions 4.7.4 Description Impact IncomingRequest::isSecure() trusted the X-Forwarded-Proto and Front-End-Https headers from any incoming request. In affected deployments, an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure. This may impact applications that rely on isSecure(), force_https(), forceGlobalSecureRequests, or similar logic to enforce HTTPS-only access or make security-sensitive decisions. Exploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them. Patches Upgrade to v4.7.4 or later. Workarounds Users who cannot upgrade immediately should enforce HTTP-to-HTTPS redirects outside CodeIgniter, for example with Apache .htaccess/virtual host rules, nginx server blocks, Caddy site config, or load balancer redirect rules. Users should also ensure that reverse proxies strip or overwrite client-supplied X-Forwarded-Proto and Front-End-Https headers before forwarding requests to the application. References CWE-348: Use of Less Trusted Source: https://cwe.mitre.org/data/definitions/348.html MDN: X-Forwarded-Proto: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto Severity Moderate 4.8/ 10 CVSS v3 base metrics Attack vector Network Attack complexity High Privileges required None User interaction None Scope Unchanged Confidentiality Low Integrity Low Availability None CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N CVE ID No known CVE Weaknesses Weakness CWE-348 ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================