PHP 8.4.25 and PHP 8.5.10 both landed on August 27, 2026, alongside the second beta of PHP 8.6. Neither stable release carries a single CVE, which makes both of them easy to leave in the backlog. That is the wrong call on a Magento stack, because the two versions map onto two different Magento lines with two very different expiry dates, and one of those dates is four months away.
What PHP shipped on August 27
Three PHP releases went out on the same day: 8.5.10, 8.4.25 and 8.6.0 beta 2. The PHP team announced both stable versions as bug fix releases and encouraged all 8.5 and all 8.4 users respectively to upgrade, per the PHP news archive. Beta 2 is not for production. It continues a cycle that reaches general availability on November 19, 2026, with beta 3 due September 10 and the hard feature freeze on September 22, per the PHP 8.6 release plan. Nothing in the beta changes what you should run today.
PHP 8.4.25 vs 8.5.10: the fix lists are nearly the same
The two releases fix largely the same bugs, and neither mentions a CVE. Counting entries in the PHP 8 changelog, 8.4.25 carries 33 fixes across 19 components and 8.5.10 carries 34 across 19. The overlap is the interesting part. Both lines got the same session defect, where broken session ID code can corrupt the Zend memory manager heap (GH-23043), the same use-after-free when a DOMDocument subclass keeps the stylesheet copy that XSLTProcessor::importStylesheet made, and the same pair of stack overflows when normalizing a deeply nested document (GH-23116 and GH-23117). Each line also got fixes the other did not. Only 8.4.25 repairs the build failure against libxml 2.15 (GH-22752) and an out-of-bounds write when shm_attach opens a segment larger than the segment really is. Only 8.5.10 gets four Opcache fixes and a PDO_PGSQL lazy fetch defect. If you were hoping one of these was optional, the honest answer is that they are the same release wearing two version numbers.
Why the XML fixes land harder on Magento than elsewhere
Magento parses XML on nearly every request, so DOM and libxml bugs sit inside its hot path rather than at its edges. Nine of the 33 entries in 8.4.25 are in DOM, SimpleXML, XSL and LibXML. On a typical framework that is a quiet corner of the standard library. On Magento it is layout XML merging, di.xml compilation and the config merge that assembles module configuration at runtime, which is exactly the machinery that produces deeply nested trees on a heavily customised theme. A stack overflow while normalizing a deep document is not an abstract risk when your layout graph is the deep document. The session fix deserves the same reading on a storefront holding live carts, because heap corruption in session handling is the class of bug that surfaces as an unreproducible 500 under load rather than as a clean error.
Read the absent CVEs precisely. Zero CVEs means nobody has demonstrated and scored an attacker-controlled path to these bugs. It does not mean the underlying use-after-free, out-of-bounds write and heap corruption defects are harmless, and it does not mean they will still be unscored in six months. Memory safety fixes that arrive with no severity label attached are the cheapest patches you will ever apply, precisely because there is no incident forcing the timeline.
The support clock is the real difference between the two
PHP 8.4 loses active support on December 31, 2026, and PHP 8.5 keeps it until December 31, 2027, per the PHP supported versions table. That single year is what separates the two releases, and it maps directly onto Magento. Adobe lists PHP 8.4 and 8.3 for every 2.4.8 patch release, and PHP 8.5 for 2.4.9, per the Adobe Commerce system requirements. So a 2.4.8 storefront is pinned to a PHP line that stops receiving bug fix releases in four months, then drops to security only patches until December 31, 2028. Releases like 8.4.25, with 33 fixes and no security pressure behind them, are the thing that goes away first. A 2.4.9 storefront on PHP 8.5 has another full year of them. Note also that PHP 8.3, which 2.4.8 still permits, left active support back on December 31, 2025, so a 2.4.8 install running 8.3 is already living on security only patches today.
What we would change this quarter
Roll the patch release now, then decide the 2.4.9 question before the peak season freeze rather than in January. Taking 8.4.25 or 8.5.10 is a within-line patch with no migration surface, so it belongs in this week's maintenance window, not a quarterly review. The harder decision is the line itself. If you are on 2.4.8, the December date turns the 2.4.9 upgrade from a 2027 item into a Q4 planning item, and it is not a small jump: it drops Laminas MVC, TinyMCE and PHP 8.2 while landing Symfony 7.4, which is why we called it the biggest framework jump since 2.0. Budget the third party module audit accordingly, because that is where the time actually goes.
Do not let 8.6 beta 2 pull your attention forward. General availability is November 19 and no Magento line certifies it, so the only sensible use of the betas is a throwaway CI job that surfaces deprecation warnings early, which is the same position we took on beta 1. Two smaller items are worth a ticket each. If you build PHP yourself rather than consuming distro packages, GH-22752 is the one that bites the day your base image moves to libxml 2.15, and it is fixed only on the 8.4 line. And if your PHP version is decided by whatever your host installed rather than by a pinned value in your own infrastructure, fix that before December, because the support clock is about to start mattering. We treat the runtime version as part of the deliverable on every Magento and Hyva build, since the teams for whom end of support dates are uneventful are the ones who chose their own upgrade date.