Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 isimage or mimein without an independent safe extension check, such as extin 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…
Recommended action: Upgrade to 4.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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: Or sanitize the client filename before passing it to move():
Recommended action: Upgrade to 4.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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(), forcehttps(), 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…
Recommended action: Upgrade to 4.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability affects applications that: Use the ImageMagick handler for image processing (imagick as the image library) AND either: Allow file uploads with user-controlled filenames and process uploaded images using the resize() method OR use the text() method with user-controlled text content or options An attacker can: Upload a file with a malicious filename containing shell metacharacters that get executed when the image is processed OR provide malicious text content or options that get executed when adding text to images Patches Upgrade to v4.6.2 or later. Workarounds Switch to the GD image handler (gd, the default handler), which is not affected by either vulnerability For file upload scenarios: Instead of using user-provided filenames, generate random names to eliminate the attack vector with getRandomName() when using the move() method, or use the store() method, which automatically generates safe filenames For text operations: If you must use ImageMagick with…
Recommended action: Upgrade to 4.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Lack of proper header validation for its name and value. The potential attacker can construct deliberately malformed headers with Header class. This could disrupt application functionality, potentially causing errors or generating invalid HTTP requests. In some cases, these malformed requests might lead to a DoS scenario if a remote service’s web application firewall interprets them as malicious and blocks further communication with the application. Patches Upgrade to v4.5.8 or later. Workarounds Validate HTTP header keys and/or values if using user-supplied values before passing them to Header class. Differences from CVE-2023-29197 1. Affected Software: CVE-2023-29197 specifically addresses a vulnerability in the guzzlehttp/psr7 library. The reported issue in this Security Advisory is within the CodeIgniter4 framework and does not depend on or use the guzzlehttp/psr7 library. 2. Root Cause and Implementation: The vulnerability reported arises from an issue in the Header class…
Recommended action: Upgrade to 4.5.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability was found in the Language class that allowed DoS attacks. This vulnerability can be exploited by an attacker to consume a large amount of memory on the server. Patches Upgrade to v4.4.7 or later. See upgrading guide. Workarounds - Disabling Auto Routing prevents a known attack vector in the framework. - Do not pass invalid values to the lang() function or Language class. References - https://codeigniter4.github.io/userguide/outgoing/localization.html#language-localization - https://codeigniter4.github.io/userguide/general/commonfunctions.html#lang
Recommended action: Upgrade to 4.4.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an error or exception occurs in CodeIgniter4 v4.4.2 and earlier, a detailed error report is displayed even if in the production environment. As a result, confidential information may be leaked. Patches Upgrade to v4.4.3 or later. See upgrading guide. Workarounds Replace iniset('displayerrors', '0') with iniset('displayerrors', 'Off') in app/Config/Boot/production.php. For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability allows attackers to execute arbitrary code when you use Validation Placeholders. The vulnerability exists in the Validation library, and validation methods in the controller and in-model validation are also vulnerable because they use the Validation library internally. Patches Upgrade to v4.3.5 or later. Workarounds Setting validation rules with an array. E.g.: References - https://codeigniter4.github.io/userguide/libraries/validation.html#validation-placeholders - https://codeigniter4.github.io/userguide/incoming/controllers.html#validating-data - https://codeigniter4.github.io/userguide/models/model.html#in-model-validation For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When an application uses (1) multiple session cookies (e.g., one for user pages and one for admin pages) and (2) a session handler is set to DatabaseHandler, MemcachedHandler, or RedisHandler, then if an attacker gets one session cookie (e.g., one for user pages), they may be able to access pages that require another session cookie (e.g., for admin pages). Patches Upgrade to version 4.2.11 or later. Workarounds - Use only one session cookie. References - https://codeigniter4.github.io/userguide/libraries/sessions.html#session-drivers For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability may allow attackers to spoof their IP address when your server is behind a reverse proxy. Patches Upgrade to v4.2.11 or later, and configure Config\App::$proxyIPs. Workarounds Do not use $request-getIPAddress(). References - https://codeigniter4.github.io/userguide/incoming/request.html#CodeIgniter\HTTP\Request::getIPAddress For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Setting $secure or $httponly value to true in Config\Cookie is not reflected in setcookie() or Response::setCookie(). Note This vulnerability does not affect session cookies. The following code does not issue a cookie with the secure flag even if you set $secure = true in Config\Cookie. Patches Upgrade to v4.2.7 or later. Workarounds 1. Specify the options explicitly. 2. Use Cookie object. References - https://codeigniter4.github.io/userguide/helpers/cookiehelper.html#setcookie - https://codeigniter4.github.io/userguide/outgoing/response.html#CodeIgniter\HTTP\Response::setCookie For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.2.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
British Columbia Institute of Technology CodeIgniter 3.1.3 is vulnerable to HTTP Header Injection in the setstatusheader() common function under Apache resulting in HTTP Header Injection flaws.
Recommended action: Upgrade to 3.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability might allow remote attackers to bypass the CodeIgniter4 CSRF protection mechanism. Patches Upgrade to v4.1.9 or later. Workarounds These are workarounds for this vulnerability, but you will still need to code as these after upgrading to v4.1.9. Otherwise, the CSRF protection may be bypassed. When Auto-Routing is Enabled 1. Check the request method in the controller method before processing. E.g.: When Auto-Routing is Disabled Do one of the following: 1. Do not use $routes-add(), and use HTTP verbs in routes. 2. Check the request method in the controller method before processing. E.g.: References - CodeIgniter4 CSRF protection For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability allows attackers to execute CLI routes via HTTP request. Patches Upgrade to v4.1.9 or later. Workarounds None. For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Cross-Site Scripting (XSS) vulnerability was found in API\ResponseTrait in Codeigniter4. Attackers can do XSS attacks if you are using API\ResponseTrait. Patches Upgrade to v4.1.8 or later. Workarounds Do one of the following: 1. Do not use API\ResponseTrait nor ResourceController 2. Disable Auto Route and Use Defined Routes Only References - Cross Site Scripting (XSS) Software Attack | OWASP Foundation For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Deserialization of Untrusted Data was found in the old() function in CodeIgniter4. Remote attackers may inject auto-loadable arbitrary objects with this vulnerability, and possibly execute existing PHP code on the server. We are aware of a working exploit, which can lead to SQL injection. Patches Upgrade to v4.1.6 or later. Workarounds Do not use: - old() and formhelper - RedirectResponse::withInput() and redirect()-withInput() References - PHP Object Injection | OWASP For more information If you have any questions or comments about this advisory: Open an issue in codeigniter4/CodeIgniter4 Email us at SECURITY.md
Recommended action: Upgrade to 4.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.