PHP 8.5.10 and 8.4.25 Patch Critical CVEs and Stack Overflow Bugs

PHP dropped two security releases this week, PHP 8.4.25 and PHP 8.5.10, and the practical question for most teams isn’t “which one is more secure” – it’s “how fast can I get one of these into production without breaking anything.” Both branches ship the identical set of CVE fixes. The difference is what happens after you patch.

Patch now: what’s actually fixed

Image: Warp2Search.net

Four issues land in both releases, and none of them are theoretical.

CVE-2026-17544 is an out-of-bounds write in BCMath’s bccomp() function, the arbitrary-precision comparison routine commonly used in financial and billing code where floating-point rounding isn’t acceptable. An out-of-bounds write means the function can write data past the memory it’s allocated – in the worst case, that’s a route to memory corruption, not just a crash. If your app does precision math on user-supplied strings anywhere near bccomp(), that’s your first thing to check.

There’s also a SQL injection vulnerability in the pgsql extension, where a crafted E'...' backslash-escaped string literal can break out of its quoting context. So what does that mean in practice? If your code builds queries using PostgreSQL’s escape-string syntax and touches user input near an E'' literal, you have a genuine injection vector, not a hardening nicety. Worth a direct search through your codebase for E' usage today.

Both branches also gain stack overflow hardening against crashes from deeply nested data structures – nested arrays or DOM documents parsed from untrusted input. You might expect a stack overflow from nesting to be a corner case nobody hits by accident. Actually, it’s a cheap denial-of-service vector: feed an API malformed, deeply nested JSON or XML, and a naive parser crashes the worker before it ever validates the payload.

Rounding out the list: a libgd fix for CVE-2026-9672 affecting image processing, a fix for CVE-2026-7260 (a Phar extension crash triggered by recursive symlinks), and a memory leak fix in repeated DatePeriod::__construct() calls – the kind of leak that gets misdiagnosed as “the server just needs a restart every few days” until someone traces it with a profiler.

Full details, affected versions, and official changelogs: PHP 8.4.25 release notes and PHP 8.5.10 release notes.

PHP 8.4.25: security-only, nothing else moves

PHP 8.4 is now in security-only maintenance. The 8.4.25 announcement is explicit about that status – no new features, no engine changes, just the CVE and stability fixes above. That’s the entire point of this release: if you’re on 8.4, upgrading to 8.4.25 changes nothing about your application’s behaviour except closing these specific holes.

Announced by Calvin Buckley, Saki Takamachi, and Eric Mann, it ships as tar.bz2, tar.gz, and tar.xz tarballs with SHA256 hashes and PGP signatures, so you can verify the download before it touches a production box.

PHP 8.5.10: same fixes, plus engine work you should test for

PHP 8.5.10 carries every fix above, plus targeted adjustments to the JIT compiler – the just-in-time engine that compiles frequently executed code paths to machine code – and general engine functionality improvements. Here’s the honest caveat: “JIT adjustments” in a point release are typically correctness and stability tuning, not a headline performance uplift. Don’t budget for a speed win you haven’t measured on your own workload. Treat it as engine hardening that happens to be riding alongside the security patches, and verify any performance claim yourself before you put it in a sprint report.

Decision tree

You’re on 8.4.x and staying: upgrade to 8.4.25. No behavioural change beyond the security fixes, so this is close to a drop-in patch.

You’re on 8.5.x already: upgrade to 8.5.10. Same logic applies – you’re just closing the same holes on your current branch.

You’re deciding whether to move from 8.4 to 8.5 for the first time: don’t bundle that decision with this patch cycle. Apply 8.4.25 now to close the CVEs, then evaluate the 8.4-to-8.5 migration separately, with its own regression pass, since a minor version bump can still touch deprecations and edge-case behaviour beyond what a security release covers.

Upgrading safely

Before you touch production:

1. Verify the download. Check the SHA256 hash and PGP signature against the values published on php.net for the tarball you pulled – don’t trust a mirror blindly.
2. Check your extensions. Confirm BCMath, pgsql, GD, Phar, and DateTime-related extensions load cleanly against the new version in a staging environment before rollout – these are exactly the extensions this release touches.
3. Run your full test suite against staging, not just a smoke test. Pay particular attention to any code path touching precision arithmetic, PostgreSQL query construction, or deeply nested input parsing, since those are the areas the patches change.
4. Confirm Opcache and JIT status post-upgrade if you’re on 8.5 – a version bump can require an Opcache cache clear, and you want to confirm JIT is still enabled and behaving as expected rather than assuming it carried over.
5. Have a rollback path ready. Keep the previous version’s tarball or container image available, and confirm your deployment process can revert in one step if the test suite or staging traffic surfaces a regression. Don’t patch production without a tested way back.

If you handle untrusted nested data or run anything touching pgsql string interpolation, prioritise this patch this week. If neither applies to your stack, it’s still worth doing on your next maintenance window – these are the kind of fixes you don’t want to be the one still missing when someone else’s incident report explains what CVE-2026-17544 actually does.

Frequently Asked Questions

Q: What’s the single most urgent thing to check before patching?
A: Search your codebase for bccomp() usage and any PostgreSQL query building near E'' string literals – those are the two vulnerabilities with the clearest direct-exploitation path, covering CVE-2026-17544 and the pgsql SQL injection fix respectively.

Q: Does upgrading to PHP 8.5.10 give me a performance boost over 8.4.25?
A: Not automatically. The JIT and engine adjustments in 8.5.10 are primarily correctness and stability improvements; treat any speed gain as something to measure on your own workload, not assume from the changelog.

Q: What extensions should I specifically regression-test after upgrading?
A: BCMath, pgsql, GD (via libgd), Phar, and DateTime – each has a fix in this release, so each is worth a targeted pass beyond your general test suite.

Q: What’s my rollback plan if the upgrade breaks something in staging?
A: Keep the prior version’s verified tarball or container image on hand and confirm your deployment tooling can revert in a single step before you attempt the upgrade in production.

Source: https://www.warp2search.net/story/php-8510-and-8425-released-critical-cve-patches-and-stack-overflow-fixes