Two critical PHP holes: the fixes are out. Here are the version numbers and why waiting until morning is a bad idea

This morning the Slovak national cyber security authority posted a warning about two critical PHP vulnerabilities. Under the authority’s name sits an AI content label.

On a security warning from a state body, that is the sort of thing that sends you to the source. So we went, and the numbers and the timing hold up.

Updated 22 October. The fixes are out: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on your branch, with source patches for the unsupported 7.4, 8.0 and 8.1. Since then it has emerged that exploitation attempts were already running on 17 October, four days before disclosure, and the NSA advises taking systems that cannot be updated immediately off the network. We have also clarified the section on temporary mitigations.

What is actually happening

The PHP security team published an advance notice of an emergency release. In full, it says:

It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2. We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.

The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and the name that has stuck in the community is php2shell.

SK-CERT issued its own advisory the same day, describing the impact in one blunt sentence: successful exploitation may enable a remote unauthenticated attacker to execute arbitrary code on the affected system. Unauthenticated means no login is involved. It is enough that the attacker can reach your site.

With the fixes out, what the flaws actually are is public too. Both are memory-handling bugs:

• CVE-2026-109618 is remote code execution through out-of-memory corruption. When PHP hits its memory limit, the handling of that situation interrupts it while the internal data for the request is only half built, and the cleanup that follows goes wrong.
• CVE-2026-109619 is remote code execution through stale internal state. Data belonging to one request survives after the memory under it has been freed, and the next request handled by the same worker can use it before it gets reset.

The second one is particularly unpleasant because it links two unrelated requests through a single worker process.

According to PHP, anything serving web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, across every release older than today’s fixed ones.

PHP also says it considers the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. That is awkward news for cheaper shared hosting, where mod_php is still common.

The dangerous moment is right after the fix

Details of the vulnerabilities leaked on 20 October, a day ahead of the planned disclosure, along with a screenshot of a tool called php2shell. That is why PHP accelerated the whole process.

As of this morning nobody had confirmed exploitation in the wild. watchTowr told BleepingComputer it was seeing no attacks, and Huntress added that it saw none in its partner environments and had not managed to reproduce the flaw.

Then it changed, and one figure moves the whole story backwards. Amazon reported exploitation attempts as early as 17 October, four days before public disclosure. Attacks were already running while only a narrow circle knew about the flaw and nobody else had a chance to defend against it.

Broad untargeted scanning followed, along with several reports of actual breaches. Patchstack’s own telemetry on 21 October at 13:57 UTC showed only probing, but it also said hosting partners had reported exploitation incidents to it. What is certain is what PHP itself says: a working exploit exists, and on mod_php it needs a single unauthenticated request that lands before your application code runs.

The same day the US NSA issued guidance that is unusually blunt for such an institution: update, and if you cannot do it immediately, take the system off the network until it is resolved. Other national authorities followed, including the Czech NÚKIB.

The reason it turned at exactly that point is the patch itself. A patch is a public diff of the source code, and from it the location of the bug can be worked backwards. For a vulnerability of this kind that amounts to a set of instructions. Before the release, Sansec put it in one sentence:

We expect mass attacks to start within 15 minutes of the release.

So there is little point leaving the update until morning. The fixes are out, and attackers have had the same head start as you.

Who gets no proper release

For small businesses this is probably the most uncomfortable part of the whole thing.

PHP supports four branches and only those got a proper release. Today’s fixed numbers are 8.5.12, 8.4.27, 8.3.36 and 8.2.35:

So if your site runs on PHP 8.1, 8.0, 7.4 or older, no proper release is coming your way. And 7.4 and 8.0 in particular are still common on cheaper hosting and in older WordPress installations.

You are not entirely without help, though. For these two flaws PHP published source patches for the 7.4, 8.0 and 8.1 branches. That is not an installable package, it is a source code change for those who build PHP themselves or have no vendor to do it for them.

So there are three routes, and the first two are worth a phone call today.

Move to PHP 8.2 or newer. On a standard WordPress site or shop that is usually a switch in the hosting panel and a matter of minutes; on an old bespoke application it can be a project of weeks.

Check with your host or your distribution whether they will ship a backported patch. Large providers do this, and distributions such as Debian or RHEL maintain their own packages well past upstream end of life. Ask about these two CVEs specifically.

And if neither applies, take the application off the internet until it is sorted. Unpleasant, but less unpleasant than somebody else’s code on your server.

Temporary mitigations: what actually holds

In the morning, when only the timing and the severity were known, the advice on mitigations was a mess and we were wary of it. With the details public it is clearer, and part of that mess explains itself: these are not contradictory recommendations but two different mitigations for two different bugs.

• Against CVE-2026-109618 (the out-of-memory flaw) PHP recommends setting memory_limit=-1.
• Against CVE-2026-109619 (the stale state flaw), session.upload_progress.enabled=0, plus fatal_error_backtraces=0 on PHP 8.5, and restarting all workers.

So both are needed at once, otherwise you close only one of the two doors. And even then what PHP stated plainly still applies: no complete mitigation exists, only the update actually fixes it.

One practical note on memory_limit=-1, because it sounds alarming and rightly so. Unlimited memory on a production server is a route to one process eating the machine. If you reach for it, pair it with request size limits at the web server and a memory cap on the container, never on its own.

Blocking multipart POST requests before they reach PHP still makes sense as a further brake where the site does not need file uploads. But it is a brake, not a fix.

What to do now

1. Find every place PHP is running. Not just websites. That includes admin interfaces on network appliances, NAS boxes, camera systems, internal tools and containers deployed once and untouched since.
2. Check the version. On a server, php -v and separately php-fpm -v, because the command line and the web may run different builds. On hosting, in the control panel; in WordPress, under Tools and Site Health.
3. Separate what is reachable from the internet from what only runs internally. The first group goes first.
4. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, whichever branch you run. Do not skip the php-fpm restart, without it the old code keeps serving.
5. Verify the version afterwards, rather than assuming the command worked because it threw no error.
6. Look back through your logs, at least to 17 October. Not to the disclosure date, but to the day the first attempts were recorded. Watch for unusual POST requests and new files in upload directories.
7. If you find anything suspicious, do not treat updating as the end of it. The update closes the door; it does not remove whatever may already have come through.

These are the commands worth having ready:

php -v
php-fpm -v
systemctl restart php8.3-fpm   # version number as appropriate

Fifteen minutes at the source

That AI content label is exactly the moment to open php.net and the SK-CERT page and see whether the figures hold. It took fifteen minutes. They do.

Along the way it also became clear what a short post had no room for: that the dangerous moment comes after the fix, and that older PHP versions get no proper release. That is not a complaint about the authority, a short Facebook post cannot carry everything. It is the reason to check a warning before you start acting on it.

Added after the release. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and source patches came out for the unsupported 7.4, 8.0 and 8.1. What we said cautiously above about temporary mitigations, PHP has since confirmed: there is no complete one, only the update helps.

Verification and sources. The timing, the number of vulnerabilities and the CVSS v4.0 9.2 rating were verified directly in the security team’s announcement on php.net, which also lists the currently supported branches. The CVE identifiers and the impact wording come from the SK-CERT advisory of 21 October 2026. The range of vulnerable versions and the expectation of mass attacks after release come from Sansec. The fact that nobody had confirmed exploitation in the wild that morning was reported by SecurityWeek, citing watchTowr and Huntress. That exploitation attempts were running from 17 October was reported by Amazon and summarised by Datadog Security Labs, which is also where the per-CVE mitigation breakdown comes from. National advisories were issued by the Czech NÚKIB and the US NSA. Full details of both flaws are in the GitHub security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. We updated the article at 16:35 after the fixes shipped: we added the patched version numbers, what both flaws are, the source patches for 7.4, 8.0 and 8.1, and the current exploitation picture per Patchstack telemetry and the Help Net Security summary.

This article is part of the Cybersecurity overview.