CISA has added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog. Federal civilian agencies have been directed to remediate the vulnerabilities by October 29.

There is an important correction to earlier reporting. Palo Alto Networks Unit 42 retracted its claim that PHP2Shell caused a European government agency compromise.

Researchers confirmed that an attack occurred against a vulnerable PHP application, but could not establish that either PHP2Shell CVE provided initial access.

This directly relates to our discussion yesterday about honeypots versus production compromises. CISA recognizes active exploitation, but the specific government intrusion should not be presented as confirmed PHP2Shell exploitation.

On 10/25/26 22:47, Michael Orlitzky wrote: On 2026-10-25 10:33:37, Demi Marie Obenour wrote: On 10/24/26 15:56, Roman Kuligin wrote: Hello, I have developed a backported .patch for EOL versions of PHP (specifically PHP 5.4, 5.5, and 5.6) to mitigate the critical PHP2Shell Out-of-Memory (OOM) vulnerability (CVE-2026-109618 / CVE-2026-109619). Since these legacy versions are no longer supported by the upstream PHP team, this patch updates the internal memory allocation model to prevent memory exhaustion and crashes during file upload progress tracking. The patch and instructions are publicly available on GitHub: https://github.com/akamor2800/php-5.4-cve-2026-php2shell-patch Best regards. In light of the size of the upstream patch, would it be better to handle out of memory by crashing the process instead? Considering that PHP 5.x has been out of security support for ~8 years and out of active support for ~10, best of all would be to crash the process when it starts.

For many of those years, there existed no AI marketing departments to publicize individual vulnerabilities. No one knows how, but hundreds of vulnerabilities were nevertheless fixed during that time. Anyone willing to do that would have uninstalled old PHP long ago.

Of course, the real problem is that such an old version of PHP is installed in the first place. If one can't get rid of it, (a) ensure that nothing can connect to it that one wouldn't trust with shell access on the server and (b) consider modernizing it. -- Sincerely, Demi Marie Obenour (she/her/hers)

The PPA we use https://launchpad.net/~ondrej/+archive/ubuntu/php had a PHP 5.6 back port the same day. Have you compared your patch to other patches?

Peter

On Mon, Oct 26, 2026, 13:27 Michael Orlitzky <michael () orlitzky com> wrote: On 2026-10-25 10:33:37, Demi Marie Obenour wrote: On 10/24/26 15:56, Roman Kuligin wrote: Hello, I have developed a backported .patch for EOL versions of PHP (specifically PHP 5.4, 5.5, and 5.6) to mitigate the critical PHP2Shell Out-of-Memory (OOM) vulnerability (CVE-2026-109618 / CVE-2026-109619). Since these legacy versions are no longer supported by the upstream PHP team, this patch updates the internal memory allocation model to prevent memory exhaustion and crashes during file upload progress tracking. The patch and instructions are publicly available on GitHub: https://github.com/akamor2800/php-5.4-cve-2026-php2shell-patch Best regards. In light of the size of the upstream patch, would it be better to handle out of memory by crashing the process instead?

Considering that PHP 5.x has been out of security support for ~8 years and out of active support for ~10, best of all would be to crash the process when it starts.

For many of those years, there existed no AI marketing departments to publicize individual vulnerabilities. No one knows how, but hundreds of vulnerabilities were nevertheless fixed during that time.

Here's a lighweight, background service & temporary shield for Linux and Windows. Prevents, detects, logs, and mitigates php2shell pre-auth RCE exploits across PHP 5.4–8.5 without requiring application code changes.

There is an important development in the PHP2Shell story we've been discussing.

Until recently, researchers had observed scanning and exploitation attempts, but convincing evidence of successful attacks was limited. That changed today.

Security researcher Adel Karimi reported evidence from honeypots showing successful exploitation against an Apache installation running PHP 8.4.26.

The evidence included memory disclosure followed by remote command execution.

Security researcher Marcus Hutchins independently reviewed the findings and described them as particularly convincing evidence of real-world exploitation.

The affected vulnerabilities are:

CVE-2026-109618 and CVE-2026-109619.

These are the same vulnerabilities addressed by the October 21 PHP security updates.

This is more significant than Google's earlier reminder to restart services after patching.

Researchers now have evidence that attackers can successfully execute commands against vulnerable PHP installations.

For administrators operating web applications or onion services using PHP, that raises the urgency of patching and checking for compromise.

The finding confirms successful exploitation against a honeypot. It does not establish how many production servers have been compromised.

Recommended action: Install the appropriate patched PHP release, ensure the patched runtime is actually running, and review suspicious requests and server activity.

Update the existing PHP2Shell announcement to distinguish confirmed successful exploitation from the earlier unsuccessful attempts.

On 2026-10-25 10:33:37, Demi Marie Obenour wrote: On 10/24/26 15:56, Roman Kuligin wrote: Hello, I have developed a backported .patch for EOL versions of PHP (specifically PHP 5.4, 5.5, and 5.6) to mitigate the critical PHP2Shell Out-of-Memory (OOM) vulnerability (CVE-2026-109618 / CVE-2026-109619). Since these legacy versions are no longer supported by the upstream PHP team, this patch updates the internal memory allocation model to prevent memory exhaustion and crashes during file upload progress tracking. The patch and instructions are publicly available on GitHub: https://github.com/akamor2800/php-5.4-cve-2026-php2shell-patch Best regards. In light of the size of the upstream patch, would it be better to handle out of memory by crashing the process instead? Considering that PHP 5.x has been out of security support for ~8 years and out of active support for ~10, best of all would be to crash the process when it starts.

For many of those years, there existed no AI marketing departments to publicize individual vulnerabilities. No one knows how, but hundreds of vulnerabilities were nevertheless fixed during that time.

On 10/24/26 15:56, Roman Kuligin wrote: Hello, I have developed a backported .patch for EOL versions of PHP (specifically PHP 5.4, 5.5, and 5.6) to mitigate the critical PHP2Shell Out-of-Memory (OOM) vulnerability (CVE-2026-109618 / CVE-2026-109619). Since these legacy versions are no longer supported by the upstream PHP team, this patch updates the internal memory allocation model to prevent memory exhaustion and crashes during file upload progress tracking. The patch and instructions are publicly available on GitHub: https://github.com/akamor2800/php-5.4-cve-2026-php2shell-patch Best regards. In light of the size of the upstream patch, would it be better to handle out of memory by crashing the process instead? -- Sincerely, Demi Marie Obenour (she/her/hers)

Google cloud updated its PHP2Shell security advisory on October 23 with additional guidance from Mandiant Consulting.

CVE-2026-109618 and CVE-2026-109619

Both are critical remote-code-execution vulnerabilities affecting PHP.

The updated guidance emphasizes that installing patched packages does not necessarily mean the running web application is protected.

Older PHP processes may remain active in memory until the relevant web-serving services are restarted.

Researchers also recommend preserving volatile forensic evidence before restarting servers suspected of compromise.

Google additionally announced new detection capabilities for identifying potentially vulnerable systems and suspicious activity.

Why onion-service administrators should care

An onion service running PHP can remain vulnerable even when Tor successfully hides its hosting infrastructure.

Administrators should verify that the web server actually uses a patched PHP runtime.

For supported upstream branches, the initial fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Distribution-specific security backports may use different version numbers.

Review logs dating back to October 17, when Amazon Threat Intelligence observed early exploitation attempts.

Confirmed exploitation attempts do not automatically establish successful server compromise.

Recommended action: Patch, restart the appropriate services, verify the running version, and investigate suspicious activity. Preserve evidence first if compromise is suspected.

Hello, I have developed a backported .patch for EOL versions of PHP (specifically PHP 5.4, 5.5, and 5.6) to mitigate the critical PHP2Shell Out-of-Memory (OOM) vulnerability (CVE-2026-109618 / CVE-2026-109619). Since these legacy versions are no longer supported by the upstream PHP team, this patch updates the internal memory allocation model to prevent memory exhaustion and crashes during file upload progress tracking. The patch and instructions are publicly available on GitHub: https://github.com/akamor2800/php-5.4-cve-2026-php2shell-patch Best regards.

[MEGATHREAD] PHP2Shell (CVE-2026-109618/109619), LiteLLM, eMudhra, GitLab & Other October Security Incidents AKA Black October

We've been getting hammered with posts and questions about the wave of vulnerabilities, compromises, and other security incidents over the past week. A lot are duplicative, and there is a wave of vibe coded crap getting shared that doesn't really do much in this situation. Rather than having a 3 dozen threads covering the same thing, we're going to consolidate the general discussion.

There's a lot happening, and some of it more serious than others. There's also a fair amount of speculation and outright BS getting mixed in with legitimate reporting.

For anyone trying to catch up, here are the most significant incidents / vulns and links to official sources. We'll add more as needed.

What's going on?

PHP2Shell (CVE-2026-109618 / CVE-2026-109619)

Critical PHP vulnerabilities with reported exploitation attempts predating public disclosure. Emergency security updates were released October 21.

- PHP official releases - CISA advisory

LiteLLM supply chain compromise

Malicious packages published through PyPI and container registries. Potential credential theft and remote code execution.

- LiteLLM official incident report

eMudhra certificate authority compromise

Compromised certificate infrastructure created the potential for forged trusted certificates. Google and Mozilla have both published responses.

- Google security response - Mozilla security response

GitLab critical vulnerabilities

Emergency security updates for affected self-managed GitLab installations.

- GitLab security release

Railway and Zeabur security incidents

Both platforms have disclosed security incidents affecting their infrastructure and services.

- Railway security disclosure - Zeabur incident report

Other useful resources

- CISA Known Exploited Vulnerabilities Catalog - NIST National Vulnerability Database - CISA Cybersecurity Advisories

A few things worth mentioning

If you have new research, technical findings, or a significant development, feel free to create a separate post. Otherwise, please keep chatter and questions here.

Please link original sources when possible. We're particularly interested in technical findings, incident reports, and official advisories rather than another article summarizing someone else's reporting.

If we've missed something significant, drop it in the comments with a source and we'll update the thread.

Last updated: October 23, 2026.

Zabbix web server on RHEL 8.10 running PHP 8.0.30 (AppStream RPM), Apache + PHP-FPM, Zabbix 7.0.29. I started reviewing our environment two days after PHP2Shell (CVE-2026-109618 / 109619) was disclosed.

dnf check-update 'php' returned nothing. Before reading that as “up to date”, I checked the repos. Zabbix and MariaDB were enabled, but BaseOS and AppStream were both enabled=0 (as was a local install-media repo). So dnf had nothing that could offer a newer PHP. The empty list only told me what dnf could see.

I haven’t checked Red Hat’s advisories for the php:8.0 stream, so I can’t say whether a fix exists there. Upstream, PHP 8.0 is EOL and only got a minimal source backport, not a release.

EPEL and Remi were installable on this box, so I moved to the 8.3 stream. Zabbix 7.0.29 supports PHP 8.3:

dnf module list php dnf module reset php dnf module enable php:remi-8.3 dnf module list php # expecting remi-8.3 [e] dnf list --showduplicates php php-cli php-fpm dnf update 'php' --assumeno # dry run first dnf update 'php'

In the dry run I was checking that 8.3.36 was selected, dependency resolution succeeded, and no Zabbix package or other core package was being removed.

Verification beyond php -v: php-fpm -t, php -m (bcmath, mbstring, mysqlnd, PDO, xml, gd all loaded), PHP-FPM and Apache status, then a real request:

curl -k -I https://localhost/zabbix/ HTTP/1.1 200 OK X-Powered-By: PHP/8.3.36

I also read the PHP-FPM and Apache logs (normal restart, no fatal errors) and clicked through login, dashboard, Problems, Hosts and Latest data.

Two things I’m unsure about, and I’d like to hear from others:

Has anyone confirmed whether RHEL 8’s php:8.0 stream got an erratum for PHP2Shell, or are people moving to Remi like I did? For those on Apache + PHP-FPM: how are you confirming the frontend really runs on the new PHP, beyond the header?

How the Planet Gets Hacked in Seconds (and Why Updating Isn't Optional)

You don't get a month to patch anymore. You get hours. Sometimes you don't even get that.

On October 21, 2026, PHP shipped emergency fixes for PHP2Shell, CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws in PHP itself, both rated CVSS 9.2. The fixed versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Every earlier 8.x is affected, and 8.1 and older have no official release at all.

Exploitation attempts were reported within hours of the patch, millions of them. That is not a typo, and it is not a future threat. It is the normal timeline now: patch drops, attackers reverse the fix, automation starts probing, and every unpatched server on the internet is on a list before most teams have finished reading the advisory.

The 2.6-second idea, cleaned up

Can someone actually hack the whole planet in 2.6 seconds? No, not in the full sense. But the reason the number feels plausible is worth understanding, because it explains why patching can't wait.

Scanning is a bandwidth problem, not a magic problem. There are 2^(32) IPv4 addresses, 4,294,967,296 of them. At 100% utilization, with no retries and no rate limits, the theoretical minimum time is:

time = addresses x bytes per host x 8 / bandwidth

At 1 Gbps, a single actor gets roughly:

SYN probe, \~60 bytes per host: \~34 minutes Headers only, \~500 bytes: \~4.8 hours A fingerprint with an 8 KiB body cap: \~3.3 days A full probe pass, \~64 KiB: \~26 days

At 10 Gbps, divide by 10. That full pass becomes \~2.6 days, not 2.6 seconds.

So where does 2.6 seconds come from? Parallelism. One machine at 1 Gbps needs 34 minutes just to send a SYN to every address. A thousand machines sharing that work, or a large botnet with \~800 Gbps of aggregate bandwidth, could in theory send those SYNs in about 2.6 seconds. That's discovery, not hacking. It finds open ports. It doesn't fingerprint every site, it doesn't check every PHP version, and it certainly doesn't exploit every vulnerable host in 2.6 seconds. Each of those steps costs more data, more handshakes, more latency, and more time.

But discovery is the step that matters for defenders, because once a host is discovered and fingerprinted as unpatched PHP, it stays on a list. Attackers don't need to hack the planet in one shot. They need to find your one unpatched server once, and then they have all the time in the world to come back to it.

To do a full 64 KiB fingerprint of every IPv4 address in 2.6 seconds would need about 866 terabits per second of aggregate bandwidth. No known botnet has that. The scary version isn't that fast. The scary version is fast enough: minutes to find you, hours to confirm you're vulnerable, days to work through the list. Your patch window is measured in the same units.

Why updating is the whole defense

PHP2Shell is a perfect example of why "update WordPress" is not the same as "update PHP." The flaw is in the runtime, not the app. Updating a CMS, a plugin, or a theme does not fix it. Updating the PHP version does, and only if you also restart the workers afterward. A patch on disk that never gets loaded by a running FPM pool or Apache worker is not a patch in practice.

The same rule applies everywhere else:

1. Update the runtime, not just the app. PHP, Node, Python, the OS packages underneath them. Node had its own emergency fixes the same week, with patched versions 22.23.4, 24.22.1, and 26.12.1. 2. Restart after you patch. Old processes keep running old code. 3. Re-check after you restart. Don't assume the version changed. Verify it. 4. Treat end-of-life as unpatched. If a branch has no official fix, a vendor backport is the only exception, and you need proof of it, not hope. 5. Automate the boring part. Inventory, version check, patch, restart, re-check. If that loop takes a human a week, the attackers' loop will beat it.

For your own systems, that loop is trivial compared to scanning the internet. One hundred hosts at 64 KiB each is 6.4 megabytes total. Checking your own fleet is seconds to minutes of work. Scanning the whole internet is weeks. There is no bandwidth excuse for not knowing the state of your own servers.

That is what Fuck Teh World is for. It's available on Windows, Mac, and Linux. Point it at ranges you own or have written permission to test, scan for open ports, fingerprint what you find, run an offline CVE check against the versions you actually see, patch the vulnerable ones, restart them, and check again. Kopimi covers the code. It does not cover your conduct. Only scan what is yours.

Grab it @ https://github.com/hoytnix/FTW

The bottom line

The planet doesn't get hacked in 2.6 seconds. It gets hacked one unpatched server at a time, found in minutes, confirmed in hours, exploited in days, while the owner meant to patch it next sprint.

Update religiously. Patch the runtime, restart the service, verify the version, and do it again next time. The attackers are already automating their side. Your side has to be automated too, or at least fast enough that you're not still on their list when they get back to it.

Might as well enjoy the chaos with some music 😂

Might as well enjoy the chaos with some music 😄

https://www.php.net/archive/2026.php#2026-10-23-1 advises: We suggest you set session.uploadprogress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serializehandler to phpbinary or phpserialize in its configuration and then switch it to php at runtime with iniset() before calling sessionstart(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

New technical findings make the PHP2Shell situation more serious than the original patch announcement alone suggested.

Amazon Threat Intelligence identified attempted exploitation dating to October 17, four days before the vulnerabilities were publicly disclosed.

The vulnerabilities are:

CVE-2026-109618 and CVE-2026-109619

Both carry critical CVSS v4.0 scores of 9.2.

Amazon observed additional attempts before the public release, followed by widespread exploitation attempts after the October 21 disclosure.

Researchers have not established that every observed attempt successfully compromised a real-world server.

Why onion-service administrators should care An onion service running vulnerable PHP may be exposed even when its real server IP address remains hidden.

Tor protects the network path; it does not fix vulnerabilities in the application running behind it.

Upgrade to patched PHP releases, including 8.2.35, 8.3.36, 8.4.27, or 8.5.12, as appropriate. Review server logs dating back to at least October 17.

Web application firewalls may reduce exposure but do not replace patching. Update the existing PHP security advisory to mention confirmed exploitation attempts and the earlier October 17 activity.

Quick recap for anyone catching up.

The leaked PHP RCEs (CVE-2026-109618 and CVE-2026-109619) were exploited before the fix landed. AWS's MadPot honeypots saw an attempt on 17 Oct, and the fixes shipped on 21 Oct. Public reporting documents attempts, not a confirmed scale of compromise.

Things I haven't seen discussed much:

1. Not every PHP version gets a real patch. Fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 7.4, 8.0 and 8.1 only have source backports, so you either build them or wait for your distro. PHP 5.4 through 7.3 have no upstream fix. 2. Updating the package isn't enough. Restart PHP-FPM and Apache workers and confirm the running processes use the new build. Otherwise the old runtime can keep serving requests. 3. Config tweaks aren't a fix. Lowering memory\limit, post\max\size or max\input\nesting\level might reduce the opportunity, but they don't remove the bug. 4. The risk is mostly the PHP you didn't install. Hosting control panels, appliance management consoles, legacy apps and forgotten campaign microsites often carry their own PHP runtime. A "we don't run PHP" answer from the web team won't cover them, and the fix has to come from the vendor.

What I'd hunt for, going back to 17 Oct:

Abnormal multipart POSTs and PHP\SESSION\UPLOAD\PROGRESS fields. Oversized PHPSESSID cookies after suspicious requests. Web server or PHP processes spawning shells, curl or wget. Memory-exhaustion errors near odd requests.

Exploitation doesn't always crash a worker or return a 500, so a clean error log doesn't prove much.

I'd worry about the vendor-embedded copies. A write-up on where PHP hides (control panels, appliance consoles, forgotten microsites) and how to record ownership is here: https://www.ctm360.com/blogs/php2shell-critical-php-flaws-put-websites-at-risk-of-server-takeover

How are you handling the PHP 7.x boxes that can't be upgraded?

Hi,

I have ported the official minimal fix for CVE-2026-109618 and CVE-2026-109619 (php-src commit 712e60f9ed, "Avoid state corruption via bailout", the PHP 7.4 backport) to the PHP 5 packages of Enterprise Linux 6 and 7, which will not get a vendor update:

php-5.4.16-48.el7 (RHEL / CentOS / Oracle Linux / Scientific Linux 7) -> php-5.4.16-48.el7.php2shell.1 php-5.3.3-50.el610 (RHEL / CentOS / Oracle Linux 6) -> php-5.3.3-50.el610.php2shell.1

The patches are made against the vendor source trees (after %prep, with all vendor patches applied) and are attached. The spec file changes, a container build and CI are in:

https://github.com/alvm/php2shell-eol-backport

This adds the EL6 / EL7 vendor packages to the unofficial backports that Leon Lai announced for Amazon Linux and for PHP 7.3 on EL7: https://www.openwall.com/lists/oss-security/2026/10/22/13

What the 7.4 fix maps to in the PHP 5 engine --------------------------------------------

Ported directly to 5.4.16 and 5.3.3:

- Allocation failures no longer bail out. zendmmsafeerror() and the "Possible integer overflow in memory allocation" check in the four safeaddress() variants print the error to stderr and call exit(1), through a new zendmmsafeerrorex(). zendmmpanic() uses exit() as well. - The same exit path is used for both Balloc() errors in zendstrtod.c and for the string size overflow in concatfunction(), the PHP 5 counterpart of the ZENDCONCAT / ZENDFASTCONCAT checks. The second branch of concatfunction() also gets the size check that was missing there. - Request state is reset: sapideactivate() sets authuser, authpassword, authdigest, contenttypedup and currentuser to NULL; zendllistdestroy() resets head and tail; shutdownexecutor() resets EG(errorhandling) and EG(exception); phprequestshutdown() clears PG(httpglobals) (PHP 5 otherwise clears them only at the next request startup) and resets PG(modulesactivated). - Multipart parsing keeps only the Content-Disposition and Content-Type part headers, ignores duplicates, and limits the number of parts with maxmultipartbodyparts (default: maxinputvars + maxfileuploads).

Session upload progress is disabled in code in 5.4, as in the 7.4 backport. PHP 5.3 does not have the feature.

Not applicable to PHP 5: the zendhash changes (the PHP 5 HashTable grows through pereallocrecoverable() and has no fatal error path there), the VM handler changes and the single-slot superglobal arrays.

Notes for anyone porting to other PHP 5 trees ---------------------------------------------

- Later PHP 5 releases have more fatal allocation paths than these vendor trees: php-5.4.45 has two "String size overflow" sites in zendoperators.c, and php-5.6.40 has six "Possible integer overflow" call sites in zendalloc.c instead of four. A port that converts only the call sites known from 5.4.16 misses them. - Compared with Leon Lai's independent port to the Amazon Linux 2 php-5.4.16 package (derived from the RHEL 7 one), the core changes are identical line for line. That port does not include the concat, Balloc(), zendmmpanic() and maxmultipartbodyparts parts; it also clears httpglobals in phprequestshutdownforhook(), which no SAPI of the RHEL build calls. Details: https://github.com/alvm/php2shell-eol-backport/blob/main/docs/ALTERNATIVES.md

Risk on PHP 5 -------------

As of 22 Oct, Red Hat's VEX lists the RHEL 6 and 7 php packages as "under investigation" for CVE-2026-109618 and as not affected by CVE-2026-109619 ("vulnerable code not present"). An independent analysis of PHP 5.3 [1] found that the out-of-memory fault can be reached, but the published memory corruption step relies on PHP 7 engine internals, so on PHP 5 the known attack ends in a denial of service; 5.4 to 5.6 were assessed by comparing the code only.

The backport applies the mitigation anyway, because it removes the unsafe error path itself, not only the known way to reach it.

[1] Analysis of php2shell on PHP 5.3.15: https://github.com/euriconicacio/blog/blob/main/allcollections/posts/2026-10-22-evaluating-php2shell-reachability-and-corruptibility-in-php-5-3-15.md

Behaviour changes -----------------

- Exceeding memorylimit ends the process. "Fatal error: ..." goes to stderr (the web server error log), shutdown functions do not run, and temporary files of uploads in that request stay in /tmp until tmpwatch / systemd-tmpfiles removes them. This follows the 7.4 fix. - Session upload progress does not work (5.4). - New php.ini directive maxmultipartbodyparts. - ABI: one new exported function (zendmmsafeerrorex); existing structures and functions are unchanged.

Testing -------

The packages were rebuilt from the vendor SRPMs (pinned SHA-256) in pinned Oracle Linux containers, and the test suite of the RPM %check was compared with an unmodified rebuild of the same SRPM:

EL7, 5.4.16: 12373 tests, failures 14 -> 23 (8 session upload progress tests and tests/lang/bug45392.phpt) EL6, 5.3.3: 11213 tests, failures 55 -> 56 (tests/lang/bug45392.phpt: the fatal error message now starts with an empty line, as with the 7.4 fix)

GitHub Actions rebuilds both packages on every push with the same results, apart from a few environment-dependent tests (SPL file owner tests, a timing test) that come and go between runners. No exploit code was written or used.

Packages --------

Signed RPMs and a yum repository, for those who prefer not to build the packages themselves:

https://github.com/alvm/php2shell-eol-backport/releases/tag/v1 https://alvm.github.io/php2shell-eol-backport/

Signing key: 2757 B60F D23D ED25 021B BE37 8079 7C97 A561 BC94

These are unofficial and come without support. TuxCare's commercial ELS also shipped fixed builds of these packages on 21 Oct. Moving to a supported PHP version remains the real fix.

Attached patches (SHA-256):

php-5.4.16-48.el7-cve-2026-109618.patch cefd460a8a3c73e4ccd42ae478e3cb944e19f713020983e0358878c3a0a7a33e php-5.3.3-50.el610-cve-2026-109618.patch 3f47e82abb08d2a84f945d7fe76eb59a2fbcff2305c2e415baedd26dab9f0eae

-- Oleksii Molchanov

The php2shell leak (CVE-2026-109618 / 109619, CVSS 9.2) had everyone scrambling. We mapped the exposure (hundreds of thousands of PHP hosts, mostly on end-of-life versions) and went looking at what attackers are doing with it. Short version: lots of staging and scanning, no confirmed compromise anywhere, and no public exploit that actually works on modern systems yet.

If you run PHP, patch to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 and watch for the attempt signatures. The full writeup has the numbers, the attacker infrastructure, and the detection indicators.

On Thu, 22 Oct 2026 08:45:47 +0200, Christian Fischer wrote: it might worth to mention that the subject as well as the text here could imply / be interpreted that only PHP 8.2-8.5 are affected (and older versions not).

But at least https://www.php.net/archive/2026.php#2026-10-21-5 mentions the availability for backports down to PHP 7.4 which implies that at least versions down to 7.4 are affected as well: affected is 5.4.0 and all newer ones.

-- R-A-C Götz T. Fischer CertIT&Comp +49(0)7225/98 98 79 g.fischer () r-a-c de r-a-c.de

Quick recap for anyone catching up. AWS says its honeypots saw a PHP2Shell (CVE-2026-109618/109619) exploit attempt on 17 Oct, four days before the embargo lifted, from anonymised infrastructure (AWS write-up). SecurityWeek reports the details leaked on 20 Oct and a PoC video went out early (SecurityWeek). Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source backports for 7.4 to 8.1. So patching alone may not be the end of it. A few things that seem worth doing: check web and PHP-FPM logs from 17 Oct onward, especially multipart and session upload-progress requests (Hadrian says most attacks it sees abuse that path). Rotate secrets that could sit in PHP process memory, since Wiz showed memory disclosure without RCE (Wiz). And find the PHP you forgot about: old vhosts, vendor appliances, staging boxes.

On that last point, this explainer on zero-day response makes the fair point that exploitation can start before public disclosure, so an up-to-date external asset inventory matters more than patch speed alone. How are you scoping the look-back window, and has anyone actually found hits from before the 21st?

On Thu, 2026-10-22 at 08:45 +0200, Christian Fischer wrote: Hello,

> On 21.10.2026 16:44 CEST Jakub Zelenka <bukka () php net> wrote:  >  > Affected versions are PHP 8.2 before 8.2.35, PHP 8.3 before 8.3.36, PHP 8.4  > before 8.4.27, and PHP 8.5 before 8.5.12.

it might worth to mention that the subject as well as the text here could imply / be interpreted that only PHP 8.2-8.5 are affected (and older versions not). ...

I'm wondering about the specific versions as well. Because following is written at https://www.wiz.io/blog/php2shell-php-rce#overview-2

"Nearly every PHP version is affected by at least one of these issues, including releases dating back to PHP 5.4. The vulnerabilities can allow unauthenticated attackers to execute code on affected servers or read sensitive process memory. That memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself."

Markus

CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, can allow unauthenticated remote code execution through memory corruption and request lifecycle issues in PHP.

For defenders, a key challenge is identifying the runtime actually serving each application. Checking php -v on a host may only identify the CLI binary. Web workers, containers, and deployment images can use different builds, while distribution packages may include backported fixes.

A practical response should cover:

Inventorying web-facing PHP runtimes, including replicas and rollback images. Checking vendor advisories for patched packages. Updating affected deployments and replacing workers still running old code. Reviewing direct origin access and other routes that bypass inspection. Investigating suspicious activity separately from patching when compromise is suspected.

Check Point released emergency IPS protections associated with these CVEs, and reported proactive WAF blocking in its testing. Credit to Matanya Moses and the IPS team for the quick response. For organizations using those controls, effective enforcement still depends on the applied policy, exceptions, and visibility into HTTPS traffic.

Virtual patching can reduce exposure during remediation, but it does not remove the vulnerable code or address an existing compromise.

I wrote a more detailed breakdown on CheckMates covering the vulnerability mechanisms, operational impact, protection validation, and patching considerations:

Full article in English

Artigo em português

What has been the biggest obstacle in your environment: finding embedded PHP installations, confirming backports, or getting applications patched without disrupting service?

→ CVE-2026-109618 and CVE-2026-109619, both rated 9.2 (CVSS v4.0) → PHP’s security release is scheduled for October 21 at 14:00 UTC → Fixes are coming for supported branches 8.2 through 8.5 → End-of-life versions will not receive patches

Hi,

For anyone still running PHP on platforms that will not receive a vendor fix for CVE-2026-109618 / CVE-2026-109619 (unauthenticated RCE, CVSS 4.0 9.2), I have published source backports of the upstream minimal mitigation (commit 712e60f9ed, "Avoid state corruption via bailout") for:

- PHP 7.3.33 on CentOS/RHEL 7 (Remi php73 7.3.33-22) - PHP 5.4.16 on Amazon Linux 2 (php-5.4.16-46.amzn2.0.7) - PHP 5.3.29 on Amazon Linux 1 (php-5.3.29-1.8.amzn1)

https://github.com/leonlai-tw/php-eol-cve-2026-109618-109619

Patches and Docker-based build scripts only, no binaries. The scripts verify the vendor SRPM signatures before patching. The 7.3 patch touches the same 17 files as Sury's independent port in php7.3 7.3.33-35, and the core changes are line-for-line identical.

Note for Debian/Ubuntu users of the Sury PPA: php7.3 7.3.33-35, php7.4 7.4.33-31, php8.0 8.0.30-25 and php8.1 8.1.34-9 already contain the fix, although their changelogs do not mention the CVEs.

These are unofficial and come with no support commitment. Upgrading to a supported PHP release remains the real fix.

Leon Lai

Hi,

On Wed, Oct 21, 2026 at 5:40 PM Aaron Rainbolt <arraybolt3 () gmail com> wrote: On Wed, Oct 21, 2026 at 10:11 AM Jakub Zelenka <bukka () php net> wrote: Hello,

The PHP security team announces a critical vulnerability in PHP core (php-src).

CVE: CVE-2026-109619 Severity: Critical (CVSS v4.0: 9.2)

Affected versions are PHP 8.2 before 8.2.35, PHP 8.3 before 8.3.36, PHP 8.4 before 8.4.27, and PHP 8.5 before 8.5.12.

PHP maintains global state that temporarily points into request memory. In some scenarios, this state is not correctly reset, or is repopulated after being reset. Once the request memory is freed, a subsequent request handled by the same worker may access the stale state before normal initialization replaces it, causing a use-after-free and potentially allowing remote code execution.

Unauthenticated RCE has been demonstrated against Apache modphp and PHP-FPM. Exploitability depends on the affected state, configuration, and application behavior.

Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or a later release in the corresponding branch. Updating is the only reliable mitigation; there is no complete generic configuration workaround. While not yet fully confirmed, the Fediverse is reporting that the fix to at least PHP 8.5.12 may be incomplete: https://fedi.katze.sh/@elise/117479383739450605 This is unrelated issue with minimal impact (crash in one component in slightly unlikely scenario). It has nothing to do with the RCE.

Kind regards,

Jakub

On 10/22/26 10:49, Emmanuel Fleury wrote:

Here is a technical description of the bugs and the finding process:

https://calif.io/php2shell/ Hint: skip the comics part (useless) and go directly to the written part at the end.

Regards -- Emmanuel Fleury

Univ. de Bordeaux, LaBRI, | Associate Professor, 351, Cours de la Libération | Email: emmanuel.fleury () u-bordeaux fr 33405 Talence Cedex, France | Web: http://www.labri.fr/~fleury

On Wed, 21 Oct 2026, Aaron Rainbolt wrote: On Wed, Oct 21, 2026 at 10:24 AM Aaron Rainbolt <arraybolt3 () gmail com> wrote:

...snip... While not yet fully confirmed, the Fediverse is reporting that the fix to at least PHP 8.5.12 may be incomplete: https://fedi.katze.sh/@elise/117479383739450605 According to a conversation in #security:ubuntu.com Matrix, Canonical asked php.org if the issue mentioned in this Mastodon thread was a real vulnerability or not, and was told that it's "unrelated and not a real issue". If someone from the PHP security team could reconfirm this here, that would be greatly appreciated. https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecomment-26090654

"The PHP team is aware of that report and there are no new plans as of now."