CodeIgniter 4.7.4

CodeIgniter 4.7.4 is out, and if you're responsible for a production app built on this framework, you'll want to pay close attention. This isn't a feature drop — it's a security-first patch release that fixes three distinct vulnerabilities, one of which could let an attacker write arbitrary files to your server.

The Security Fixes You Can't Ignore

Let's start with the serious stuff. Three security advisories were published alongside this release, and they're the real reason to upgrade today rather than next week.

IncomingRequest HTTPS detection. The isSecure() method was trusting client-supplied X-Forwarded-Proto and Front-End-Https headers without verifying the source. If your app sits behind a reverse proxy and you hadn't explicitly configured Config\App::$proxyIPs, an attacker could craft requests that bypass HTTPS detection. The fix: those headers are now only honored when the request originates from a trusted proxy.

SQL injection in deleteBatch(). The deleteBatch() method has a genuine SQLi — when used together with where() conditions, bound values from the WHERE clause were substituted into the generated SQL with their escape flag ignored. That means anything you passed to where() was never escaped or quoted. The WHERE binds now get the same escaping treatment as a regular delete(), but you should audit any code paths that chain deleteBatch() with user-supplied condition values.

UploadedFile::move() path traversal. This is the one that keeps me up at night. When move() was called without a second argument, the unsanitized client-provided filename was used as the destination. An attacker could supply a filename like ../../public/shell.php and write the uploaded file outside the intended directory. The fix sanitizes the filename now, but if you've been relying on the raw client filename anywhere else in your upload logic, you've got more work to do.

Bug Fixes — The Good, the Annoying, and the Ones You Didn't Know About

Beyond the security patches, there are about a dozen bug fixes worth noting. The esc() helper now propagates encoding correctly and won't leak references. env() no longer throws a TypeError on unexpected input. The InvalidChars filter was crashing on array keys containing control characters. IncomingRequest::getPostGet() was returning inconsistent results in certain edge cases.

The User Agent library was reporting Safari's WebKit version instead of the actual browser version — a niche issue, but it could break analytics or feature-detection code. Model::objectToRawArray() had a bug that affected custom casting logic. The required_without validation rule broke when using array dot notation inside the rule parameters, which is a common pattern in complex form validation.

On the Redis session handler side, the configured prefix wasn't being applied consistently. And if you're using spark lang:find, it was treating translation keys that were already excluded as though they still needed scanning.

Should You Upgrade?

The answer depends on your risk tolerance and deployment cadence. If you're running CodeIgniter 4.7.3 in production behind a properly configured reverse proxy with no file upload endpoints exposed to unauthenticated users, you could probably wait for the next scheduled maintenance window.

But the deleteBatch() SQLi alone is reason enough to fast-track this. Database-layer vulnerabilities are the kind that get exploited silently — you won't know you've been hit until the damage is done. And the file upload path traversal? That's the sort of bug that makes the OWASP Top 10 list year after year for a reason.

The upgrade path from 4.7.3 to 4.7.4 is straightforward — update via Composer, run your test suite, and you're done. No new configuration keys, no deprecations, nothing to migrate. Just be thorough with your test coverage around database queries and file uploads, because those are the areas where this release actually matters.