Today's PHP security release, and how we're strengthening security
- ID
- 38011
- Status
- summarized
- Published
- 21 Oct 2026, 11:48 PM
- Fetched
- 22 Oct 2026, 5:17 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 22 Oct 2026, 5:18 AM
- Tags
- Audience
- developersvibe_coderssaas_founders
What happened
The PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 Oct 2026 to fix two critical unauthenticated RCEs: CVE-2026-109618 (memory corruption when a request hits memory_limit at the wrong moment, demonstrable on Apache with mod_php before any application code runs, and reachable on PHP-FPM through app-level paths) and CVE-2026-109619 (a fatal error leaving stale state so a later request on the same worker reuses freed memory). The Foundation traces the OOM bug partly to its first external audit in years, funded by the Sovereign Tech Agency and run through OSTIF by Quarkslab, and notes a 2024 exploit theory that was never pursued because other issues took priority. The post's real ask is funding and organisational support from companies that depend on PHP, not just patching.
Why it matters
If you run PHP — WordPress, Laravel, Magento, or an agency-maintained site — check the actual PHP version your host serves, not what your composer.json says: on shared or managed hosting the patch only lands when the provider updates it, and CVE-2026-109618 needs no application bug to trigger on mod_php. Builders who assumed a 2024-era theory was harmless now have a confirmed RCE from exactly that class of bug.
Discussion angle
The OOM exploit was theorised in 2024 and only fixed after an externally funded audit found it again — so who in the room actually knows which PHP version their host or PaaS is running today, and how would they find out without SSH access?