Php Severe Vulnerability

Does anyone have detailed knowledge of the two recently disclosed critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619?

I’m looking for technical details on how these vulnerabilities can be exploited, a step-by-step guide to reproducing them in a controlled lab environment, any temporary mitigations or workarounds that are currently effective, and confirmation of whether official patches have been released.

Any technical documentation, proof-of-concept references, or practical remediation guidance would be greatly appreciated.

I’m also hoping this discussion can serve as a helpful resource for others who may not yet be aware of these vulnerabilities and need guidance on assessing their exposure and securing their systems.

Thanks in advance to everyone who shares their knowledge and insights!

:police_car_light: PHP2Shell — 9.8, RCE, patched 21 Oct

@Afro_Guru — both CVEs are real, and the chain is short enough to see in one picture.

digraph G { rankdir=TB; bgcolor="transparent"; nodesep=0.35; ranksep=0.45; node [shape=box style="rounded,filled" fontname="Helvetica" fontsize=12 color="#8C3B3B" fillcolor="#FBEDED" penwidth=1.4]; edge [color="#8A9A8F" penwidth=1.4 arrowsize=0.8]; A [label="🐘 PHP core\n109618 · 9.8\n109619 · 8.1" fillcolor="#F6DADA"]; B [label="🌍 every site\nrunning PHP"]; C [label="⚡ one request\nno login"]; D [label="💥 code runs\nor memory leaks"]; E [label="✅ patched\n8.2.35 to 8.5.12" color="#2F6B4A" fillcolor="#EAF3EC"]; A -> B; B -> C; C -> D; D -> E [style=dashed label="fix" fontsize=10]; }
  • CVE-2026-109618 — 9.8 CRITICAL, RCE, no login needed
  • CVE-2026-109619 — 8.1 HIGH, memory disclosure, Heartbleed-shaped
  • affected — PHP 5.4 → 8.5, a decade of releases
  • fixed — 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12, on 21 Oct 2026

70% of the web runs PHP. WordPress, Wikipedia, Joomla, Drupal, every cPanel host. The flaw is in PHP itself, so the fix is the engine underneath everything, not a plugin update. Two days after disclosure, most of the internet has not done it.

The memory bug leaks other requests’ passwords, session cookies, API keys and TLS private keys — silently, nothing in the logs. It sat in the codebase for a decade; humans could not chain it. Frontier AI models did — Wiz Research found it.


:bullseye: Check your own site in 30 seconds

node phpcheck.js "https://your-site.com"

openai/php2shell-checker ★816 · Apache-2.0 — reads the PHP your site advertises and tells you if it is inside the vulnerable range. OpenAI shipped it the day after its models helped find the bug.

On the server itself:

php -v && php-fpm -v

:wrench: Patch the engine

Branch Fixed release End of life
8.5 8.5.12 2029
8.4 8.4.27 2028
8.3 8.3.36 2027
8.2 8.2.35 Dec 2026
≤ 8.1 upgrade to 8.3+ past
# Debian / Ubuntu
apt install --only-upgrade php8.4-fpm php8.4-cli

# RHEL family
dnf upgrade php-fpm php-cli

# containers
docker pull php:8.4.27-fpm-alpine

# always, afterwards
systemctl restart php8.4-fpm

The restart is the fix. An old FPM master keeps serving the vulnerable binary until it is replaced. :date: endoflife.date/php tracks the current release per branch, so the next one never surprises you.


:toolbox: Tools that appeared within 48 hours

  • ikow/php2shell-poc ★1,521 · MIT — five pre-auth RCE chains on the heap use-after-free, plus Suricata, Sigma and ModSecurity rules in the same repo. Attack and defence, one download
  • 9bie/php2shell-bypass-aslr-exp ★956 — bypasses ASLR without touching the patched binary. This is the repo that answers “how bad is it really”
  • NCSC-NL/php2shell ★226 · EUPL — the Dutch government’s operational note, updated today
  • CISA KEV catalog — 1,754 KEV entries in machine-readable JSON, refreshed daily. The list to watch this week
The mechanics, the lab, and what to do if you cannot patch today

109618 — the out-of-memory path. PHP aborts an OOM request with longjmp, and some contexts skip the cleanup. The next request finds memory uninitialised, and cleanup reads and branches on it. Chain it reliably and you steer execution → RCE. CWE-416, CWE-824, CWE-755, CWE-1325.

109619 — stale global state. Some globals point into request memory. When they are not reset, or get repopulated afterwards, they still reference freed memory. The next request reads or branches on that stale pointer: same family, different key.

Lab, your own box only:

services:
  vuln:
    image: php:8.4.26-fpm-alpine
    ports: ["127.0.0.1:9000:9000"]

Drive the OOM paths from the advisories against 127.0.0.1:9000, watch the FPM logs, then pull php:8.4.27-fpm-alpine and repeat the same sequence. That difference is your proof the patch works.

No patch window in the next hour? Isolate tenants — one FPM pool per user, open_basedir set, no shared pools. Cross-request disclosure is the lever attackers pull first. Then rotate every secret that lived on the host during the exposure.


:books: CVE-2026-109618 · CVE-2026-109619 · php-src advisories · openwall thread · PHP release archive

On a shared host, check today. :police_car_light:

WhiteHat’s writeup is genuinely scary in the best way. The memory disclosure part is what got me — silent leaks with nothing in the logs is the stuff of nightmares.

I checked my own VPS right after reading this: php -v showed I was sitting on a vulnerable 8.3 build, so I upgraded and restarted php-fpm within the hour. The bit about the old FPM master keeping the vulnerable binary alive until a restart is such a classic gotcha, glad it was called out explicitly.

Anyone on shared hosting though — you’re basically at your provider’s mercy here. If you can’t check the version yourself, it’s worth opening a ticket and asking what they’re running. They should already know about this one.

Really solid breakdown, thanks for sharing this. The one thing I’d add on top of patching is secret rotation: upgrading PHP stops the leak, but it doesn’t invalidate anything that already bled out. If your site was on a vulnerable build before this week, treat session tokens, API keys and database credentials as compromised and rotate them, since the memory disclosure was completely silent and nothing in your logs will tell you what escaped.

Also worth a reminder for anyone running containers or long-lived workers (queues, daemons): upgrading the package isn’t enough until those processes actually restart, because the old FPM master keeps the vulnerable binary in memory. A rebuild plus a full restart is the only way to be sure.