Shipped two days early
PHP 8.6.0 Beta 2 was tagged on August 25, 2026, two days ahead of its planned slot of August 27 on the official release schedule tracked by PHP.Watch. Release manager Matteo Beccati is steering this cycle. The build follows the usual path: alpha 1 on July 2, alpha 2 on July 16, alpha 3 on July 30, and beta 1 on August 13, all in 2026. Beta 3 is next, due September 10, followed by a hard feature freeze on September 22 and a first release candidate targeted for September 24. General availability is aimed at November 19, 2026.
Separately, and unrelated to the 8.6 beta cycle, the current stable line also saw a routine point release this week: PHP 8.5.10 shipped August 27.
A cluster of memory-safety fixes
The most consequential part of this beta isn't a new feature, it's a batch of fixes for use-after-free bugs, a class of memory-handling error where code keeps using a piece of memory after it has already been freed, which can crash a process or, in the wrong circumstances, be exploited. This beta closes several of them in the DOM (Document Object Model) extension, covering DOMDocument::xinclude(), cloned namespace nodes, and live wrapper objects. It also fixes a crash in Opcache's tracing JIT (just-in-time) compiler that occurred when compiling side traces for certain classes, and a bug where nested "yield from" chains misbehaved after calling valid() or next() on a generator.
Other correctness fixes in this beta touch the internationalization (Intl) extension, including grapheme_strrev(), UTF-16 (Unicode Transformation Format, 16-bit) offset handling, and a double-free in IntlGregorianCalendar; the PDO_PGSQL (PHP Data Objects, PostgreSQL driver) lazy-fetch mode; and ZipArchive's stream lifecycle handling.
None of these are the kind of change that shows up in a release announcement's headline, but taken together they are a heavier-than-usual correctness pass for a second beta. Use-after-free bugs in particular tend to surface only under specific, hard-to-reproduce conditions, which is exactly why wide beta testing across the extensions that changed matters more than usual for this cycle.
What's new for developers
The SNMP (Simple Network Management Protocol) extension got the largest feature overhaul in this beta. It now supports AES (Advanced Encryption Standard) -192 and AES-256 security protocols wherever the underlying system library allows it, can load the MIB (Management Information Base) tree dynamically through a new snmp_read_mib() function, and gains six new output format controls.
Elsewhere, pack() and unpack() now accept < and > endianness modifiers on integer and float format codes, letting a script specify byte order explicitly rather than relying on the platform default. That matters most for code that reads or writes binary formats meant to be portable across machines with different native byte orders, where relying on the platform default has historically been a source of subtle, hard-to-test bugs. Class constants can now reference mutated object properties. And SessionHandler::validateId() is now implemented and enforces session.use_strict_mode, closing a gap where custom session handlers could silently ignore that setting and accept session identifiers they should have rejected.
Two deprecations to plan around
Beta 2 flags two behaviors for removal in a future version: return statements inside finally blocks, and the CSV-related methods on SplFileObject. Neither breaks anything yet, both will emit deprecation warnings, and code that relies on them should be migrated before those warnings turn into errors down the line. A return inside finally is a pattern that already behaves confusingly, since it silently overrides any return value or exception from the try block it wraps, so the deprecation is as much a nudge toward clearer code as it is a cleanup.
Why the schedule slipped forward, not back
It's worth noting the direction of the schedule change here: this beta shipped two days ahead of its planned slot, not behind it. Betas landing early is unusual enough to be worth flagging, since PHP's release process more commonly runs into last-minute fixes that push a tag back rather than pull it forward. Combined with the size of the memory-safety fix list, it suggests the team had a clear backlog of fixes ready to go rather than a light beta padded out to hit a date.
What it means in practice
None of this belongs in production yet; PHP 8.6 is still pre-release, and the currently supported stable release for production use is PHP 8.5.10. What this beta is useful for is testing, particularly for anyone maintaining code that touches SNMP tooling, custom session handlers, or DOM manipulation, since those are the areas that changed the most. Running an existing test suite against Beta 2 now, while there's still time before the September 22 feature freeze, is the best way to catch anything that breaks before it becomes a release-day surprise. With beta 3 due September 10 and the feature set locking down twelve days after that, this is close to the last comfortable window to report a compatibility problem and have it addressed before general availability in November.
