Originally published at https://monstermegs.com/blog/php-security-patch/
Roughly 72 percent of every website with a known server side language still runs PHP, and a large share of those installs sit on a branch that stopped receiving patches months ago. On August 27, 2026, the PHP development team shipped 8.5.10 and 8.4.25, a PHP security patch that closes two tracked CVEs alongside a cluster of memory safety bugs in bundled libraries. For sites on a supported branch, this PHP security patch is a quiet background task your host handles. For everyone else, it is the clearest signal yet that a hard deadline is now three months away.
What the PHP Security Patch Actually Patches
The release notes on php.net describe both 8.5.10 and 8.4.25 as bug fix releases, which undersells them. Bundled into this PHP security patch are two assigned CVEs, four vulnerabilities inherited from the uriparser library, a memory safety flaw in GD, and additional corrections in Phar and OpenSSL. The 8.5 branch also picked up targeted adjustments to the JIT compiler. Nothing here is a remote code execution headline, and that is part of the problem. Quiet releases get postponed, and postponed releases are how sites end up years behind.
These two builds remain the current patch level in September, so anyone who skipped the late August window is still exposed to the same set of issues today. A PHP security patch does not expire politely while you wait for a convenient maintenance slot.
The Two CVEs Behind the Release
Both tracked flaws in this PHP security patch sit in code that ordinary applications touch without thinking about it, which is exactly why they are worth reading closely rather than skimming past the identifiers.
An Out of Bounds Write in bccomp
CVE-2026-17544 is an out of bounds write in bccomp, part of the BCMath extension used for arbitrary precision arithmetic. BCMath shows up in billing code, currency conversion, invoicing plugins, and anywhere floating point rounding errors would be unacceptable. An out of bounds write is a memory corruption class bug, and memory corruption in a function that accepts user supplied numeric strings is not a theoretical concern for an e-commerce site processing untrusted input at checkout.
SQL Injection Through a Backslash Breakout
CVE-2026-17543 patches a SQL injection path in the pgsql extension caused by a backslash breakout. Escaping bugs in database drivers are especially dangerous because developers reasonably assume the driver is doing its job. Code that looks correct, passes review, and uses the documented escaping function can still be exploitable when the escaping itself is flawed. If your stack pairs PostgreSQL with PHP, this single fix justifies the entire PHP security patch on its own.
Bundled Libraries Carried Their Own Flaws
The less discussed half of this PHP security patch is inherited risk. PHP bundles third party libraries, and when uriparser or GD ships a flaw, every PHP install carrying that copy inherits it. Four uriparser vulnerabilities and a GD memory safety bug landed in this cycle. GD matters for any site that resizes uploaded images, which covers most content management systems, and image parsing has been a reliable source of memory safety bugs across every language for two decades. Phar and OpenSSL corrections round out the set.
Inherited flaws are the strongest argument against pinning an old build. You can freeze your own application code and review every dependency you install, but you cannot freeze the vulnerability research happening upstream in the libraries PHP ships with. That research continues whether or not your branch is still receiving patches, and a PHP security patch is the only mechanism that carries those upstream fixes down to your server.
Stack Hardening Moves From Candidate to Production
The headline engineering change is not a CVE at all. Both branches gained stack overflow hardening against deeply nested arrays and DOM documents, work that first appeared in the release candidate builds earlier in the cycle. Deeply nested structures are a classic denial of service vector: feed a parser a JSON payload or XML document nested thousands of levels deep and the recursion exhausts the stack before any application logic runs. Hardening the interpreter against that pattern protects every site on the branch, including the ones whose developers never considered the attack surface.
The Deadline Sitting Behind This PHP Security Patch
Here is the context that makes this PHP security patch more than routine maintenance. PHP 8.2 reaches the end of its security support on December 31, 2026. After that date the branch closes, and no patch, exception, or backport arrives from the PHP project. Every flaw discovered from January 1, 2027 onward simply stays open on 8.2 forever.
PHP 8.3 is already in security fix only mode. PHP 8.4 remains in active support, PHP 8.5 is the current stable branch, and PHP 8.6 is scheduled for general availability on November 19, 2026. That timing is useful: the next feature release lands roughly six weeks before 8.2 goes dark, which means anyone planning a move has a clear window to test against a modern branch first.
Why So Many Sites Miss Every PHP Security Patch
The uncomfortable statistic is that roughly 55 percent of the top million PHP sites are still running an end of life version, months after PHP 8.1 closed on December 31, 2025. W3Techs data consistently shows the same lag: the language powers the majority of the web, but version adoption trails releases by years. A PHP security patch only protects the sites that actually apply it.
What happened after the 8.1 cutoff is instructive. WP Cloud automatically upgraded remaining 8.1 sites to the platform default on the deadline, and WP Engine, Kinsta, and SiteGround followed comparable policies, warning customers by email for months and then forcing the migration. Hosts increasingly make the version decision for you, because the alternative is operating a fleet of unpatchable servers.
The lesson is straightforward. If you do not schedule the move, someone else eventually schedules it for you, and forced migrations happen on the host's calendar rather than yours. Applying a PHP security patch on your own terms is always cheaper than discovering on a Tuesday morning that your site was upgraded overnight and a legacy plugin no longer loads.
What This PHP Security Patch Asks of Site Owners
This is not a drill that requires a rewrite. It is a version audit and a controlled upgrade, and the work is genuinely measured in hours rather than weeks for most sites.
Confirm the Version You Are Actually Running
Open your control panel and check the PHP version selector, or drop a file containing a phpinfo call in your web root and read the output. Do not trust the value you remember choosing at launch, because hosts move defaults and staging environments drift. At MonsterMegs the version selector sits in cPanel and switching branches takes a single click, so verifying and applying a PHP security patch is a two minute job rather than a support ticket.
Test on a Staging Copy First
Clone the site to staging, switch the branch, then exercise checkout, forms, email delivery, and any custom code. Deprecated function calls are the usual failure mode, and they surface immediately in error logs. Before you touch anything, confirm you have a restore tested backup, because the point of a backup is the restore, not the copy. With a working rollback in place, every PHP security patch becomes reversible rather than risky.
Where the Release Cycle Goes From Here
The cadence is predictable enough to plan around. PHP ships a feature release each November, gives it two years of active support, then two more years of security fixes. Apply that to the current calendar and PHP 8.4 carries you comfortably past 2027, while 8.5 buys another year on top. Choosing a branch with runway left is the difference between one migration and three. Every PHP security patch issued between now and then arrives on a branch that is still open to receive it.
Performance is the quiet bonus nobody budgets for. Each recent branch has narrowed execution time and trimmed memory use on typical workloads, so moving off an aging version usually shaves response times without a single code change. Pair that with an opcode cache and a server built for concurrency and the upgrade pays for itself in page speed long before the next PHP security patch arrives.
The Takeaway
Three things are worth carrying away from this release. The 8.5.10 and 8.4.25 builds close two real CVEs plus a set of inherited library flaws, and they remain the current patch level right now. The stack hardening work quietly removes an entire denial of service class for sites on supported branches. And PHP 8.2 loses security support on December 31, 2026, which turns a routine version check into something with a date attached.
If you are not certain which branch your site runs on, check this week, and if switching versions on your current host is harder than it should be, LiteSpeed powered NVMe hosting with one click PHP version control makes the next PHP security patch a non event.
Top comments (0)