php cat

• CodeIgniter4 system/Validation/StrictRules/FileRules.php (develop, post GHSA-mmj4-63m4-r6h5): ext_in, mime_in and is_image now each check two more things. First, the client extension must equal finfo's guessExtension(), or for is_image map to an image/* type. Second, hasUnsafeClientFilename() runs sanitize_filename(getClientName()), the same name move() uses. It rejects trailing-dot names and any middle extension of php\d*, pht, phtml, phar or phps, which covers Apache multi-extension handler mapping. max_dims/min_dims only call getimagesize() and add no name checks, so they are not upload-safety rules.
• Laravel 12.x ValidatesAttributes.php has two file rules. validateMimes checks the finfo-guessed extension against the allowlist. validateMimetypes checks getMimeType(). Both call shouldBlockPhpUpload(), which tests only the client's last extension against php, php3–php8, phtml and phar. It skips middle extensions (CI4's post-fix check covers those) and leaves out pht and phps. This is a design gap that is safe by default, because store() renames via hashName(). It only matters when an app saves with storeAs(..., getClientOriginalName()) on a server that maps multi-extension handlers. Unverified, a comparison only.
• More on Laravel 12.x validateMimes: it only checks in_array(guessExtension(), allowlist) and never compares that with getClientOriginalExtension(). That is the same content-vs-name gap CI4 fixed in GHSA-mmj4-63m4-r6h5. Laravel's only name-based guard is shouldBlockPhpUpload(), and it turns itself off when the rule list contains 'php'. So any Laravel app that keeps the client's original filename has to supply its own extension allowlist. To confirm risk in a given app, look for storeAs/move with getClientOriginalName() next to a 'mimes:' rule.

• GHSA-mmj4-63m4-r6h5 / CVE-2026-63223 (codeigniter4/framework < 4.7.4, CWE-434): is_image and mime_in in system/Validation/StrictRules/FileRules.php only checked the content MIME from finfo. They never checked the client filename extension, and UploadedFile::move() keeps that extension by default. So a valid image with an executable extension passed validation. Fix b6e9a4fa adds hasInvalidImageClientExtension (is_image: client ext must map to an image/* type) and hasMismatchedClientExtension (mime_in: client ext must equal guessExtension()).
• Edge cases in the CI4 4.7.4 fix (from its own tests, not tested by me): is_image still accepts an extensionless filename ('blob') and SVG (image/svg+xml). It also accepts an image extension that doesn't match the content (gif bytes named .jpg). SVG passing is_image is a stored-XSS concern, separate from code execution. The client extension comes from the last path segment only, so how double extensions behave depends on the web server. Unverified; worth a human look at whether the docs warn about SVG.
• Contrast with Laravel (src/Illuminate/Http/FileHelpers.php, 12.x): UploadedFile::extension() and hashName() both use guessExtension() from the content and a Str::random(40) name. So the default store() never writes the client extension, and the content-vs-extension gap in CI4's CVE-2026-63223 can't happen with Laravel's defaults. The risk moves to apps that call storeAs() with getClientOriginalName() or getClientOriginalExtension(). That's a good grep target when auditing Laravel apps for CWE-434 (pattern only, unverified in any app).

Now look at `images.php` and `files.php`: Let's look at `data/inc/images.php` lines 38-42 again: ```php /* fix issue 44. Thanks to Klaus. */ $imagewhitelist = array('jfif', '.png', '.jpg', '.gif', 'jpeg'); if (!in_array(strtolower(substr($_FILES['imagefile']['name'], -4)), $imagewhitelist)){ show_error($lang['general']['upload_failed'], 1); }else{ /* end of fix issue 44. Thanks to Klaus. */ if (!copy($_FILES['imagefile']['tmp_name'], 'images/'.latinOnlyInput($_FILES['imagefile']['name']))) show_error($lang['general']['upload_failed'], 1); else { chmod('images/'.$_FILES['imagefile']['name'], 0666); ``` Wait! Look at `substr($_FILES['imagefile']['name'], -4)`. What if a file is named `test.jfif`? The last 4 characters are `jfif`. Is `'jfif'` in `$imagewhitelist`? Yes (`'jfif'`). What if a file is named `test.png`? The last 4 characters are `.png`. Is `'.png'` in `$imagewhitelist`? Yes (`'.png'`). What if a file is named `test.jpg`? The last 4 characters are `.jpg`. Is `'.jpg'` in `$imagewhitelist`? Yes (`'.jpg'`). What if a file is named `test.gif`? The last 4 characters are `.gif`. Is `'.gif'` in `$imagewhitelist`? Yes (`'.gif'`). What if a file is named `test.jpeg`? The last 4 characters are `jpeg` (NOT `.jpeg`!). Is `'jpeg'` in `$imagewhitelist`? Yes (`'jpeg'`). BUT what if a file is named `anythingjpeg` with NO dot, or `evil.php.jpeg`? Wait! What if a file is named `test.phpjpeg`?! Let's calculate: `substr('test.phpjpeg', -4)` is `jpeg`! Because it's just the last 4 characters! Does it check for the dot? For `jpeg`, NO! It checks if the last 4 characters are `'jpeg'`! And what is `latinOnlyInput('test.phpjpeg')`? It is `'test.phpjpeg'`. Wait, does Apache run `.phpjpeg`? Normally not, unless configured. BUT what about: What if a file has an extension like `.phar` or `.php`? Can any executable extension end in `jfif`, `jpeg`, `.png`, `.jpg`, `.gif`? Wait, what if Apache has multiple extensions enabled, e.g. `evil.php.jpg`? In Apache configurations where `AddHandler application/x-httpd-php .php` is used without `FilesMatch`, Apache evaluates MIME types by examining all extensions: `evil.php.jpg` has extensions `.php` and `.jpg`. If Apache's handler handles `.php`, it will execute the file as PHP! Wait! Even more important: Does pluck-cms have an `.htaccess` file in `images/` or `files/`? Let's check `images/.htaccess` and `files/.htaccess` in pluck-cms! Let's see what commit `8f6541e` added to `images/.htaccess` and `files/.htaccess`!