Where can I safely download the October 2026 PHP security fix?

From four places only: php.net, your Linux distribution's security tracker and package repositories, your hosting or software vendor's own release channel, and github.com/php/php-src. Anything else, including blog posts offering a direct download, a "patcher" or a scanner binary, should be treated as untrusted.

How do I verify that a PHP release is genuine?

Official PHP release tarballs are signed. The release managers' public keys are published at php.net/gpg-keys.php, so you import the relevant key, download the signature file alongside the tarball and verify it before unpacking. If a download has no matching signature from a key listed on php.net, do not build or install it.

Is php2shell.com an official source for this vulnerability?

No. PHP2Shell is the nickname researchers gave CVE-2026-109618 and CVE-2026-109619, and php2shell.com appears to be part of legitimate coordination around the disclosure. It is still not an official PHP project property, so it must not be treated as one. Take version numbers and fixes from php.net or php-src.

Why are "free vulnerability scanner" downloads risky right now?

Because a scanner is an executable you run with your own privileges on the machine you are worried about, usually in a hurry. After a widely covered critical CVE that is an unusually effective delivery route for malware. Prefer a script you can read in full, a package from your distribution, or simply checking the version number yourself.

What should I do with an urgent email containing a PHP patch attachment?

Do not open the attachment and do not follow its links. No legitimate PHP security update is distributed as an email attachment. Verify independently by checking php.net and your distribution's security notice, then patch through your normal package manager or deployment process.

Fake PHP Patches: How to Spot a Scam After a Critical CVE

October 22, 2026 7 min read

Dark banner reading 'The fake patch arrives faster than the real one', advising to trust only php.net, your distro and your vendor

The Second Wave Is Not the Exploit, It Is the “Fix”

Every critical vulnerability has two phases. The first is technical and brief: a patch lands, maintainers ship packages, administrators update. The second is social, lasts for weeks, and is aimed at the people who are anxious, busy or new to this — a flood of urgent emails, helpful-looking blog posts, “emergency patchers” and free scanner downloads.

The October 2026 PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are an ideal setup for that second wave. They are rated CVSS v3.1 9.8 CRITICAL, they allow remote code execution, proof-of-concept code is public, and they were covered everywhere under the nickname PHP2Shell. Enormous audience, high anxiety, lots of people searching for a download. That combination is the bait.

In 60 seconds

Trust four sources only: php.net, your distribution’s security tracker, your vendor’s own channel, and github.com/php/php-src.
Verify signatures. Release tarballs are signed; keys are listed at php.net/gpg-keys.php.
Never run an unread binary offered as a “scanner” or “patcher”.
No real PHP patch arrives as an email attachment. Ever.
Patch to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 through your package manager.

The only numbers that matter

Scams work by introducing a version number or a download you cannot check. So pin the facts first, from the vendor:

Branch	Fixed release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Those four numbers are stated in the official PHP release announcement for 21 October 2026. Anything claiming a different “emergency” version is wrong, confused or hostile.

Branches 7.4, 8.0 and 8.1 are end-of-life and receive no release at all. The PHP project made a one-off exception and published source-only backports in php/php-src, on branches named like PHP-8.1-CVE-2026-109618-109619, which you compile yourself. There is no tarball, no distribution package and no ongoing support. Remember that shape, because “here is the PHP 8.1 patched binary, download it” is a claim no honest source can make.

Our main article explains the mechanics of both bugs and the per-stack remediation, if you want the engineering context: what the two PHP CVEs actually do and how to remediate them.

Source list: who gets to tell you what to install

Source	Trust	Why
`php.net`	Yes	The project’s own site; releases and signing keys
`github.com/php/php-src`	Yes	Upstream repository, advisories and EOL backport branches
Your distro’s security tracker	Yes	Packages built and signed by your vendor
Your host’s or product vendor’s channel	Yes	They know their own build
A blog with a download button	No	Even the well-meaning ones repackage
A “free scanner” executable	No	An unread binary run with your privileges
An emailed attachment	No	Not a distribution method for security updates

The advisories themselves are worth bookmarking so you can compare claims against the source: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. Distribution users should read their own notice instead of a summary — Ubuntu’s is USN-8948-1.

Verifying a release rather than believing it

If you compile PHP, or download a tarball for any reason, signature verification is the step that makes the rest of this article unnecessary. PHP release tarballs are signed by release managers whose public keys are published at php.net/gpg-keys.php, which is live and current.

The logic is simple: import the release manager’s key from php.net, download the .asc signature next to the tarball, verify, and only then unpack. A mirror can be compromised; a signature made with a key you fetched from the project’s own site cannot be forged by whoever controls the mirror. If a download has no signature, or the signature is made by a key that is not listed on php.net, stop there.

Two specific things to avoid this week

Pages that hand out “checking tools”. One current example is jackalsyn.com/posts/php-up-2026.html, which offers checking tools and contradicts itself within the same page. Internal inconsistency is a strong signal: a page that cannot keep its own version claims straight is not a page whose binaries you should execute.

Treating php2shell.com as official. PHP2Shell is the researchers’ nickname for this CVE pair, and the site appears to be part of legitimate coordination around the disclosure. That is not the same as being an official PHP project property, and it must not be described as one. Use it as context if you like; take your version numbers and your code from php.net and php-src.

How to read our script before you run it — including ours

We publish a free exposure-check script, and the honest position is that you should apply the same scepticism to it that we are asking you to apply to everyone else. That is why it is distributed as a readable text file rather than a binary, and why the usage is deliberately two steps:

curl -fsSL https://blog.limewire.com/content/files/2026/10/php-exposure-check.txt -o php-exposure-check.sh
less php-exposure-check.sh
sh php-exposure-check.sh

SHA-256: c13cd5690c9d352c6a95e854602be2f330a0799435c05a8261037401fcf50255

Because this article is about fakes, here is where the real file lives: on LimeWire, published by our verified account @limewireofficial — php-exposure-check.sh. Two copies, one checksum; if a third copy appears somewhere else with a different hash, that is your answer about it.

What to look for while reading it, in this order:

Any outbound network call — curl, wget, nc, a hostname. There are none. The script makes no network calls and collects nothing.
Any write outside the current directory, especially to system paths. It needs no root.
Anything that evaluates downloaded data. The pattern to fear is fetch-then-execute.
What it actually inspects: PHP binaries on disk including cPanel, Plesk, Remi and LiteSpeed paths, running PHP-FPM workers and whether a restart is still pending, Docker containers, and WordPress or Laravel installs.
The exit codes: 0 everything found is patched, 1 something vulnerable or end-of-life, 2 no PHP found.

It is POSIX sh and a careful read takes a few minutes. If anything in it does not match this description, do not run it — and that instruction applies to any future copy of it you find somewhere other than the link above, which is also what the SHA-256 is for.

Red flags worth memorising for the next CVE

Urgency plus a download. Real advisories tell you to update; they do not ship you the update.
A version number that appears nowhere on php.net.
“Our patch works on PHP 8.0.” No packaged fix exists for end-of-life branches.
A support call offering to log in and fix it. Verify through the number on your invoice, not the one in the message.
A page that is vague about who wrote it but very specific about what you should run.

Why we are twitchy about this particular pattern

A brief and genuinely self-deprecating note: LimeWire spent the 2000s as the canonical example of how a trusting user and a confidently mislabelled file end badly together. We were the delivery mechanism. We did not find this PHP bug, we had nothing to do with it, and we are not selling you a scanner — but we do recognise “helpful download, urgent framing, unverified source” faster than most, for reasons our own history explains.

The boring conclusion that keeps working

Check your version. Patch from your package manager or php.net. Verify signatures if you compile. Ignore everything that arrives by email with an attachment. The people exploiting this week are counting on you skipping exactly one of those four steps.