PHP Radar HU EN
ALERT · 21 OCTOBER 2026 · CVSS 9.2 · UNAUTHENTICATED REMOTE CODE EXECUTION

PHP ARMAGEDDON

Two critical flaws opened in the language that runs the web. An attacker needs no password and no login to run code on your server. This is not panic: in the PHP Foundation's own words, you "must update now".

69.3%of websites run on PHP (W3Techs, cited by Tenable)
2 CVEsCVE-2026-109618 and CVE-2026-109619, both critical
9.2CVSS v4.0 severity (per the PHP security team)
0 passwordsunauthenticated, remotely exploitable (php.net advisory)

Researchers say that on unpatched PHP the big platforms are affected too: WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin, Nextcloud, Roundcube, MediaWiki, WHMCS. Not a flaw in those – a flaw in the PHP beneath them.

Domain name only: letters, digits, hyphen, dot. Internationalised (IDN) names are fine too.

Free, passive check: we only read what your server serves to anyone without authentication (response headers, the home page). No intrusion, no path guessing, no exploitation attempt of any kind.

What happened on 20–21 October 2026?

This is not another "update WordPress" story. The PHP runtime itself is affected, so every PHP application is in scope, from the simplest page to a webshop. The PHP Foundation calls updating "imperative".

  1. Calif (Ryan Austin) and OpenAI – independently, on the same day – report the first flaw to the PHP security team. Wiz reports further cases on 24 August, OpenAI on 18 September.

    → PHP Foundation – background on the release

  2. The CVE identifiers leak early to Hacker News and social media – with a wrong 10.0 CVSS score and a wrong release time. No technical detail yet.

    → PHP Foundation – background on the release

  3. On the php.announce list Jakub Zelenka posts the pre-announcement: "Upcoming Critical PHP Security Release" – two critical (CVSS v4.0 9.2) flaws, release on 21 October at 14:00 UTC. The original date was 22 October; the leak pulled it forward.

    → php.net – pre-announcement (php.announce #509)

  4. Patchstack hosting partners report the first suspicious traffic; Cloudflare's CTO reports early probing and ships WAF rules to every customer, free tier included – stressing it is only a stopgap, not a substitute for updating.

    → Patchstack – live status and WordPress guidance

  5. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship. The php.net advisory: "All PHP users are strongly encouraged to update immediately." The already end-of-life 7.4, 8.0 and 8.1 branches get only a minimal source backport.

    → php.net – official security advisory (2026-10-21)

  6. CERT-EU issues advisory 2026-018 (update now, or isolate internet-facing systems). Hungary's National Cyber Defence Institute issues a Hungarian alert: "update without delay". As a precaution, Dutch government services (DigiD, MijnOverheid) also go offline temporarily.

    → Hungarian National Cyber Defence Institute – alert

  7. watchTowr and Huntress do not yet confirm mass successful exploitation; Rapid7 expects a working public exploit "soon". Researchers say working code execution was built during the research against both mod_php and PHP-FPM.

    → Rapid7 – analysis and mitigation

What are these two flaws? – in plain terms

We give no exploitation recipe, and none is needed. It is enough to understand which two edge cases PHP got wrong, to see why a firewall or a password alone will not save you. The attacker reaches PHP through your application, but the flaw is in PHP.

CVSS v4.0 9.2 · critical

CVE-2026-109618 – memory handling flaw (OOM)

When PHP runs out of memory while handling a request, a half-built internal structure can be left behind. During request shutdown PHP treats it as valid, and from that corrupted memory state an attacker can reach code execution on the server. PHP considers Apache mod_php the highest risk, because there this can happen even before the application's code runs.

→ GitHub Advisory – CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
CVSS v4.0 9.2 · critical

CVE-2026-109619 – stale state (use-after-free)

PHP holds internal state (error, session, object data) that belongs to one request but is kept by the worker process. If it is not cleared in time, the next request on the same worker can reference already-freed memory. This can lead to memory disclosure (reading passwords, tokens, keys) and to code execution.

→ GitHub Advisory – CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

The flaws were reported by Calif, OpenAI and Wiz; the research is collectively named "php2shell". Wiz also showed that the PHP process memory can be read without code execution – so rotating the passwords and keys stored on the server is advised if an unpatched version was running.

Status by version – what got fixed on 21 October 2026?

This table is built from PHP's official data (php.net/supported-versions, php.net/eol and the 2026-10-21 advisory). Dates are UTC. We do not guess: a branch that is end of life received no official release.

BranchFixed release (2026-10-21)Previous releaseSecurity support endsStatus
8.58.5.128.5.11 (2026-09-24)2029-12-31 Active branch. Update to 8.5.12.
8.48.4.278.4.26 (2026-09-24)2028-12-31 Active branch. Update to 8.4.27.
8.38.3.368.3.35 (2026-09-24)2027-12-31 Security fixes only now. Update to 8.3.36.
8.28.2.358.2.34 (2026-09-24)2026-12-31 Got the fix (8.2.35), BUT the branch ends on 31 Dec 2026. Plan a move to 8.3+.
8.1— (no official release)8.1.34 (2025-12-18)2025-12-31 (ended) End of life. Only a minimal source backport (self-compiled). Needs an upgrade.
8.0— (no official release)8.0.30 (2023-08-03)2023-11-26 (ended) End of life. Only a source backport exists. Urgent upgrade.
7.4— (no official release)7.4.33 (2022-11-03)2022-11-28 (ended) End of life. Only a source backport exists. Urgent upgrade, with a compatibility review.
7.3 and older— (no fix)—long ended No fix and no backport. Must be replaced.

PHP 8.6 is planned for 19 November 2026 (php.net wiki); this radar judges only today's officially released branches and does not guess about future versions.

The PHP security team published a minimal source backport for the 7.4, 8.0 and 8.1 branches (php.net advisory). This is not an official release: it must be built from source. The reliable path is to move to a supported branch rather than patch in place.

WARNING – the upgrade alone can break your site

This is the most important sentence on this page, so we box it:

Raising the PHP version is one thing. But if the code running on your website (theme, plugin, custom work) is not PHP 8.x compatible, the moment you update the site WILL COLLAPSE: white screen, 500 error, unreachable admin, sometimes data loss.

Old code (many PHP 5.x / 7.x era themes and plugins) relies on language features that PHP 8 removed or tightened. What was a "warning" on 7.4 is a fatal error on 8.x.

An abandoned plugin that has not been updated for years is the most common point of failure. Everything must be surveyed before the upgrade.

So the correct order is: 1) backup, 2) make a staging copy, 3) compatibility review of the code, 4) fix the issues on the copy, 5) only then the live upgrade. Updating live and blind is reckless.

Do not leave it to chance. One wrong click on the update button and the site can be down for days. Leave it to a professional.

Request expert help →

What should you do NOW? – practical order

  1. 1

    Find out which PHP version runs

    Use the radar above, or check the hosting panel. The exact patch level (e.g. 8.3.36) is what matters, not just the branch.

  2. 2

    Make a full backup

    Files and database together, BEFORE the upgrade. If something breaks, this is the way back.

  3. 3

    Update to the fixed release

    To your branch's fixed release (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35). On an end-of-life branch: move to a supported branch.

  4. 4

    Test on a copy (staging) first

    Check that the theme, plugins and custom code tolerate the new PHP. Go live only after a working copy.

  5. 5

    Rotate the secrets

    If an unpatched version was running, memory could be read. Passwords, API keys, sessions – rotate all of them.

  6. 6

    If you cannot solve it in time

    Temporary stopgaps exist (php.net lists them), but none is complete protection. The sure fix is the update – with an expert if needed.

Temporary mitigation if you cannot update now (per php.net – NOT complete protection):
  • Against CVE-2026-109618: set memory_limit=-1 so the application cannot override it (e.g. php_admin_value in the FPM pool or Apache config); keep post_max_size low (8M without uploads, 32M with uploads).
  • Against CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini / the FPM pool (NOT ini_set() or .user.ini), then restart every worker; on PHP 8.5 also fatal_error_backtraces=0.
  • Hiding errors (error_reporting, display_errors, @) does NOT help. A container/cgroup memory limit can act as an availability boundary but is not complete; RLIMIT_AS / RLIMIT_DATA should specifically be avoided.

The test is run by Gábor Vidovics

Security incident expert · website security (WordPress / PHP) · senior full-stack developer

I have worked in IT for nearly thirty years, over twenty of them as a developer and technical lead. Today I investigate and restore hacked, slowed or oddly behaving websites, and make sure nothing goes wrong again on the sites I have put right.

I measure, I do not guess; I quarantine, I do not delete – your data survives the investigation and every step is reversible. I do not promise 100% protection: I can tell you how far an intruder gets, and I can increase that distance.

I have worked on everything from native PHP to the large frameworks, so I am at home with PHP version upgrades and with the "nobody dares touch this any more" sites. The pre-upgrade compatibility review and the safe go-live are part of one process for me.

  • 21 documented, anonymised incident cases
  • 164,457 log lines reviewed in a single case
  • 0 files deleted – everything quarantined, evidence preserved
  • Own tools: DomainCheck, domain analyser, incident analyser
Contact
Phone
+36 30 9688 854
Location
Szentes, Hungary · remote / hybrid
LinkedIn
linkedin.com/in/vidovicsgabor

I take requests through the form below. In an acute situation (Google flagged you, your host warned you, or you see something odd on the site) write URGENT in the message.

Request expert help with the upgrade

The radar is free. If your website runs a vulnerable version, or it cannot be told from outside, and you do not want to leave the upgrade to chance, write to me – I reply on working days, and out of turn in acute cases.

Security code (CAPTCHA image)

Our own check with no third-party service – no Google, no cookies.

I use your data solely to answer your request. The message is sent over authenticated SMTP on an encrypted channel.

Quick facts

The key, self-contained facts about the 21 October 2026 PHP security release.

  • The two critical PHP flaws are CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2 (critical).
  • The fix shipped on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • The flaws are unauthenticated and remotely exploitable, and affect every web-facing PHP install (mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed).
  • PHP 8.1 and older have no official fix, only a minimal source backport – you must move to a supported branch.
  • Raising the PHP version alone is not safe: if the code is not PHP 8.x compatible the site can collapse, so a backup, a copy and a compatibility review come first.
  • The free PHP Radar (dinorr.hu/php-radar) shows which PHP version is visible on a domain and whether, by version number, it is affected.
  • The test is run by Gábor Vidovics, security incident expert; the radar is free and the first reply is free.

Frequently asked questions

What exactly does this radar do?

It looks at what PHP-version signal your server gives out from the outside (HTTP response headers, the home page content) and classifies it against PHP's official data: patched, vulnerable, end-of-life branch or hidden. It is a passive check: it never attempts exploitation, never guesses paths, it only reads the publicly served response.

Is the result reliable?

We measure what the server prints. Many servers hide the version for security (which is correct), or the distribution patches without raising the version number – then nothing certain can be said from outside, and the radar says so honestly. The exact state is revealed inside the server, with a single command.

Is it free? What is the catch?

The radar is genuinely free, and there is no catch. The expert upgrade (survey, staging, compatibility fixes, safe go-live) is the paid service – but only if you ask for it.

Is updating PHP enough?

Against the security flaw, yes, that is the complete fix. BUT if your code is not PHP 8.x compatible, the update can break the site. That is why you first need a backup, a copy and a compatibility review.

My host says they "handle it". Can I relax?

Many hosts really do update or backport – but it is worth verifying, not assuming. A "hidden" or "distribution" result from the radar signals exactly this: it is not visible from outside, it has to be checked from inside.

What are CVE-2026-109618 and 109619?

The official identifiers of the two flaws. Both are critical (CVSS v4.0 9.2), unauthenticated and remotely exploitable, and fixed by PHP's 21 October 2026 security release. Details are in the GitHub advisories and the php.net advisory – see the Sources section.

Sources

Every statement rests on these public, citable sources. This page is informational; the authority is always php.net's official announcement.