Last updated: July 29, 2026

Good, I have enough context. Writing the expanded article now.

Image: LinuxCompatible.org (Philipp Esselbach)

Before 28 July 2026, a call to bccomp() – PHP’s arbitrary-precision comparison function – looked like harmless maths plumbing. After this release, it’s the first thing to audit: under the right conditions, a caller-supplied scale value could trigger a stack-based memory corruption and potentially hand an attacker a remote code execution primitive. The immediate move is patch now, then search your codebase for any path where user-controlled input reaches bccomp() or its siblings.

That’s the shape of the PHP security update 2026 picture: three coordinated releases, one serious vulnerability, and a clear triage order for every team still running PHP 8.2.

What got patched: the case for updating immediately

Image: LinuxCompatible.org (Philipp Esselbach)

The PHP team tagged PHP 8.6.0alpha3, PHP 8.5.9, and PHP 8.2.33 within roughly a three-hour window, all sharing an identical security patch set. That synchronisation signals the team considers these vulnerabilities serious enough to fix across every supported line simultaneously.

The headliner is GHSA-x692-q9x7-8c3f, a stack-based out-of-bounds write in PHP’s ext/bcmath extension. The trigger is bccomp() when it truncates fractional digits at a caller-supplied scale. You might think arbitrary-precision maths is niche, but bcmath ships enabled by default in most PHP distributions. OOB writes have a nasty history of enabling remote code execution. Treat this one seriously.

The vulnerable pattern is more common than it sounds. A typical exposure looks like this:

// Dangerous: $scale comes from user input
$precision = (int) $_GET['decimals'];
$result    = bccomp($userValueA, $userValueB, $precision);

Any route that passes an HTTP parameter, a database-stored preference, or a parsed API field as the third argument to bccomp(), bcadd(), bcsub(), bcmul(), or bcdiv() shares the same attack surface. Audit for the pattern bccomp($a, $b, $someExternalValue) before you do anything else. In most codebases a grep -rn 'bccomp\|bcadd\|bcsub\|bcmul\|bcdiv' across your source tree takes under a minute.

Three more fixes round out a thorough security pass: a PostgreSQL SQL injection path exploiting E'...' backslash escape sequences, a Phar archive circular-symlink crash, and a backport for CVE-2026-9672 in the bundled libgd image library. Four CVEs across four different subsystems in a single coordinated drop – that’s not routine maintenance, that’s a meaningful hardening pass.

The 8.6 alpha: the case for watching closely

Alpha 3 is not for production – full stop. But the features landing now will define how PHP development feels for the next several years.

Partial function application is the headline. Built on the first-class callable cache from alpha 1, it lets you curry functions – fix some arguments, leaving others open – without writing wrapper closures. A pipeline that today reads array_map(fn($x) => clamp(0, 100, $x), $values) becomes cleaner once you can partially apply clamp directly. There’s also a new clamp() function replacing the tedious max($min, min($max, $value)) idiom, and TAILCALL VM support on Windows with Clang 19+ on x86-64, which matters for recursive algorithms that would otherwise overflow the stack.

The alpha also patches a JIT-tracing crash triggered by hitting the memory limit mid-execution, a heap buffer over-read in PDO_ODBC, restored Opcache JIT for ZTS builds on Apple Silicon, and GMP extension hardening. A fast-copy API using sendfile or splice is a low-level but genuinely impactful performance primitive for file-serving workloads. Alpha 4 is expected around 30 July, with an RC targeting August – though treat those dates as provisional until the PHP project confirms them in its official releases feed.

Head-to-head: where the branches diverge

PHP 8.2 is now in maintenance mode – security-only updates, no new features. The 8.2.33 tag also carries a complication: an expired GPG key that triggers GitHub signature-verification warnings. The patch is legitimate, but that warning is the branch waving goodbye. According to endoflife.date, PHP 8.2 reaches end of support on 31 December 2026 [citation needed] – five months away. That’s not a long runway. PHP 8.5, released November 2025, is supported through 31 December 2027 per the same source.

The synchronised three-branch drop on 28 July is also worth noting: PHP has sometimes been criticised for delayed cross-branch security coordination. This release is a direct refutation of that reputation.

If you’re on PHP 8.5: patch to 8.5.9 today – straightforward security point release, no breaking changes.

If you’re on 8.2: apply 8.2.33 as an immediate stop-gap, then treat the migration as a time-boxed project, not a background task. Here’s what a cautious upgrade looks like in practice for real teams:

1. Pin the target. PHP 8.4 or 8.5 are both reasonable. 8.5 gives you more runway (end of 2027) and the same July patches without expired-key noise.
2. Run the compatibility pass first. Add "php": "^8.4" to composer.json and run composer check-platform-reqs locally. Follow up with a static analyser (Rector’s SetList::PHP_84 ruleset catches most breaking changes automatically).
3. Shadow-test in CI. Add a PHP 8.4 or 8.5 matrix job to your CI pipeline before touching production. Treat any failure as a blocker, not a warning.
4. Stage the rollout. Deploy to a staging environment first, run your smoke tests and integration suite, then promote to production. If you use containers, swapping the base image tag from php:8.2-fpm to php:8.5-fpm is the mechanical part – the testing is where the time goes.

Most modern Laravel and Symfony applications upgrade cleanly. The friction usually comes from older extensions, abandoned packages with hardcoded version constraints, or custom C extensions. Finding those early – in CI, not in production – is the point of the exercise.

If you’re evaluating 8.6: spin up alpha 3 in an isolated dev environment and explore partial function application – just keep it well away from anything serving real users.

Frequently Asked Questions

Q: What is the bcmath out-of-bounds write and does it affect my app?
A: GHSA-x692-q9x7-8c3f is a stack-based memory corruption flaw triggered by bccomp() when truncating fractions at a caller-supplied scale. Because bcmath ships enabled by default, any application passing user-controlled input to bccomp() or related functions should treat this as high-priority and update immediately. Run grep -rn 'bccomp\|bcadd\|bcsub\|bcmul\|bcdiv' across your source and audit each call site.

Q: Is PHP 8.2.33 safe despite the expired GPG key warning?
A: Yes – the expired key causes a signature-verification warning on GitHub but does not invalidate the release. The patches are legitimate. However, treat the warning as a prompt to migrate: PHP 8.2 reaches end of support on 31 December 2026, so the clock is running regardless.

Q: Can I deploy PHP 8.6.0alpha3 to production?
A: No. Alpha releases are preview builds for testing and bug reporting only. Run alpha 3 in isolated development environments; the stable production options are PHP 8.5.9 or PHP 8.4.

Q: Which version should I migrate to from 8.2?
A: PHP 8.5 is the stronger choice – it is supported through December 2027 (per endoflife.date) and carries the same July 2026 security patches without the expired-key friction of 8.2. PHP 8.4 is also viable if your team is already partway through that migration.

Q: What is partial function application in PHP 8.6?
A: It lets you fix some arguments of a function and defer the rest, creating a new callable without a wrapper closure. It builds on the first-class callable syntax from PHP 8.1 and makes functional-style pipelines considerably more concise. Available in alpha 3 for testing – not yet stable.

Source: https://www.linuxcompatible.org/story/php-859-and-8233-security-updates-drop-alongside-86-alpha-3