CVE-2026-109618 · CVE-2026-109619
Two flaws in PHP itself let an attacker run code on a web server or read its memory without logging in. They are in the language runtime, not in your application, so a fully updated WordPress, Drupal or Laravel site is still exposed until the PHP underneath it is updated and restarted. The fix shipped on 21 October 2026.
php2shell.eu is an independent guide maintained by the OffSeq security team in Riga. It is not affiliated with the PHP project or the researchers who found the flaws.
Paste the output of php -v, a phpinfo() heading or an X-Powered-By header. The verdict comes from the PHP project's fixed-version table and is worked out in your browser: what you paste is not sent anywhere, and your server is never contacted.
Verdict
Paste a version above to see the verdict and what to do next.
Do next
A version check is a starting point, not an assessment. It cannot see distribution backports, which server interface you run, or whether the server was compromised before it was patched.
Find every exposed PHP runtime with OffSeqThe interactive checker needs JavaScript. Compare your version with the table below instead: on each branch, any release lower than the one in the last column is affected. PHP 8.1 and older are affected and get no official fixed release.
8.3.6-0ubuntu0.24.04.13 may carry a backported fix with the old number. Compare the package version with your distribution's security notice.| Branch | Vulnerable | First fixed release |
|---|---|---|
| PHP 8.5 | < 8.5.12 | 8.5.12 |
| PHP 8.4 | < 8.4.27 | 8.4.27 |
| PHP 8.3 | < 8.3.36 | 8.3.36 |
| PHP 8.2 | < 8.2.35 | 8.2.35 |
PHP2Shell is the name the researchers gave to a family of memory-safety bugs in how PHP handles fatal errors, out-of-memory errors above all. A request that ends abruptly can leave corrupted or stale internal state behind, and a later request handled by the same worker can trip over it. The PHP project tracks them as two CVEs.
CVE-2026-109618
When an allocation fails, PHP aborts the request. If that happens while internal request data is only partly set up, the clean-up that follows treats the half-built data as valid and corrupts memory.
GHSA-w8hw-w9fx-j79wCVE-2026-109619
Some internal state survives after the request that owned its memory has finished. A later request on the same worker can use that state before PHP resets it, which is a use-after-free.
GHSA-6wmf-4rv5-p3rp| Who | Scope | Result |
|---|---|---|
| Wiz Research | WordPress, Drupal and Joomla, latest container images at the time of testing | Unauthenticated remote code execution; memory disclosure that does not depend on the application |
| Calif | WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony, WHMCS | Unauthenticated remote code execution, including against Nginx with PHP-FPM |
| OpenAI Codex Security | Reported the same root cause independently, and further attack vectors later | Published a defensive version checker, not an exploit |
Field data
OffSeq, which maintains this site, runs a fleet of decoy servers called Mirage. Here is what PHP2Shell looked like on it in the first 48 hours.
The traffic is automated: nine sources, the five using the session route each with its own variant, and the lead tool repeating its run overnight and labelling itself with the string p2shell. The guide lists the indicators and log signals to search for.
Decoys cannot be exploited, so they show attempts, not whether an attack succeeds against a real server.
Response plan
This is the order of work the PHP advisories, the researchers and CERT.LV point to. Do not wait for a complete inventory: start step 2 on your most exposed servers straight away and run the rest in parallel.
First hour
The flaws are in PHP, so the inventory is of PHP runtimes, not of websites. One server can run several PHP versions side by side, and the command-line version is often not the one serving web requests.
php-fpm -v, the Apache module, or a temporary phpinfo() page that you delete afterwards.php -v
php-fpm -v # or php-fpm8.3 -v, php-fpm83 -v
apachectl -M | grep -i php
dpkg -l 'php*' | grep ^ii # Debian, Ubuntu
rpm -qa 'php*' # RHEL, Alma, Rocky, Fedora
Today
Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package. The PHP project gave Linux distributions and long-term support vendors the patches in advance. Updating WordPress, Drupal or your framework does not update the PHP runtime beneath it.
Fixed versions: php.net security advisory, 21 Oct 2026
Straight after
Installing a package does not replace code that is already running. PHP-FPM pools, Apache processes and long-running workers keep the vulnerable binary in memory until they are restarted.
ps -eo pid,lstart,cmd | grep -i '[p]hp' shows when each worker started.memory_limit, or memory_limit plus 1 GB for limits above 1 GB, that kills a worker outright with exit code 137, without running shutdown handlers or destructors. A few regressions are being tracked in php-src; see the platform guide.sudo systemctl restart php8.3-fpm # unit name varies by distribution
sudo systemctl restart apache2 # or httpd
ps -eo pid,lstart,cmd | grep -i '[p]hp'
If you cannot patch
Where an update is impossible today, the PHP project lists configuration changes that reduce exposure to specific attack paths but do not make an installation safe. CERT.LV goes further: a system that cannot be updated to a safe version should not be publicly reachable until the risk is removed.
This week
Patching closes the hole; it does not tell you whether someone came through it first. Amazon recorded an exploitation attempt on 17 October, four days before disclosure, and advises investigating from at least that date. Anything exposed before you patched deserves a look.
in Unknown on line 0, and for bursts of worker crashes.As you go
Write down what you found, what you patched and when. If you find a compromise, regulatory clocks may already be running. Under NIS2, the early warning to your CSIRT is due within 24 hours of becoming aware of a significant incident. Under the GDPR, a personal data breach must be notified to the supervisory authority within 72 hours where feasible.
These are the measures the PHP project published for systems that cannot be updated immediately. Each one blocks particular attack paths, some affect availability, and none of them makes an installation safe. Apply them in configuration that takes effect before PHP parses the request, then restart every worker.
| Measure | Against | What it does | Watch out for |
|---|---|---|---|
session.upload_progress.enabled=0 | CVE-2026-109619 | Blocks the confirmed session upload progress paths. Set it in php.ini, the FPM pool or the server configuration. | Do not rely on ini_set() or FPM .user.ini: they apply too late. Breaks upload progress bars, if you use them. |
fatal_error_backtraces=0 | CVE-2026-109619, PHP 8.5 only | Blocks the confirmed fatal error backtrace path. | Covers that one path only. |
memory_limit=-1, enforced with php_admin_value | CVE-2026-109618 | Removes the controllable PHP memory-limit failure. | An underlying allocation failure can still reach the vulnerable path, and a runaway request can now exhaust the machine. Contain each worker with a cgroup or container limit. Check that no pool or application restores a finite limit. |
Low post_max_size | CVE-2026-109618 | 8M where no uploads are needed, 32M where they are, with upload_max_filesize below it. | Breaks larger legitimate uploads. |
| Request limits at the web server or proxy | CVE-2026-109618 | Cap decoded request size, field count, multipart part count, header count and nesting depth. | The limits must also cover requests without a usable Content-Length. |
| Fix fatal errors and timeouts attackers can reach | CVE-2026-109619 | Removes ways to end a request abruptly, including in callbacks, upload or import handling and clean-up. | Application work; not a quick switch. |
GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. The PHP advisory for CVE-2026-109619 also suggests leaving session.upload_progress.enabled=0 after patching if you do not need the feature.RLIMIT_AS or RLIMIT_DATA as a memory cap. The PHP project warns they can trigger the very allocation failure the attack needs.display_errors, lowering error_reporting or using @ does not protect against CVE-2026-109619; the stale state is touched before PHP decides whether to show anything.No single signal proves an attack, and the absence of one proves nothing: the vulnerable code runs below your application, often before it has logged anything. Treat these as leads for an investigation, and look at everything exposed before you patched.
A PHP Fatal error: Allowed memory size of … exhausted that names Unknown on line 0 instead of a file means the limit was hit before any script ran, during request parsing. An out-of-memory error from your own code names a real file and line.
PHP error log · web server error log
Clusters of segmentation faults or PHP-FPM children exiting on a signal within a short window, followed by a slow successful response. A few isolated crashes are normal; dozens in minutes are not.
Apache error log · php-fpm log · systemd journal
OffSeq's decoy fleet saw the lead attack tool put the literal string p2shell in the multipart boundary of its requests. OffSeq reports that no legitimate traffic contains it, so a match in a Content-Type header is worth investigating at once. Tools change, so its absence proves nothing.
Access logs with headers · WAF · CDN analytics
Multipart uploads carrying a PHP_SESSION_UPLOAD_PROGRESS field on pages with no upload progress bar, very long field names, deeply nested [ brackets, or URL-encoded POST bodies above one or two megabytes. The field is a legitimate PHP feature, so context matters.
Access logs with request bodies · WAF · IDS
A Set-Cookie: PHPSESSID response value far longer than your normal session IDs. Wiz and Imperva describe memory being returned to the attacker this way.
Response logs · WAF · CDN analytics
A PHP-FPM, php-cgi, Apache or LiteSpeed process launching sh, bash, curl, wget, python or nc. Baseline first: PHP's own mail() starts sendmail through /bin/sh. An unexplained shell from a PHP worker is post-exploitation, and one of the strongest signals available.
EDR · auditd · process accounting
New .php files in upload, cache or temporary directories, new cron jobs or accounts, and outbound connections from the web server shortly after inbound POST requests.
File integrity monitoring · netflow · cron and account audit
Early signs surfaced in 2024; the exploitable paths were reported in August 2026 and fixed in October. Exploitation attempts began before the fix: the earliest known is from 17 October.
2024
A PHP core developer working on findings from a funded security audit spots the first signs of the out-of-memory problem. An exploit is theorised, but no concrete attack vector is found, and the problem is left unfixed.
11 Aug 2026
Calif and OpenAI independently report an unauthenticated remote code execution flaw with the same root cause.
24 Aug 2026
Wiz Research, which found the issues independently, reports them to the PHP security team. OpenAI reports further attack vectors on 18 September.
17 Oct 2026
Amazon's MadPot honeypots record a PHP2Shell exploitation attempt from an anonymisation network, four days before disclosure. Amazon reports it on 21 October and advises investigating from at least 17 October.
20 Oct, around 15:00 UTC
The two CVE numbers start circulating online, with a wrong release time and a wrong score of 10.0. No technical detail leaks.
20 Oct, 19:30 UTC
The PHP project pre-announces the release and moves it forward by a day, to 21 October at 14:00 UTC.
20 Oct, evening
One of the research firms mistakenly publishes a demonstration video, then deletes it. Copies circulate and speed up the development of proof-of-concept code.
20 Oct, 21:57 UTC
OffSeq's Mirage decoy fleet records its first PHP2Shell-shaped request, about sixteen hours before the fix ships.
21 Oct, 02:00 to 08:00 UTC
Amazon identifies the first proof-of-concept exploits, and sees further attempts against its honeypots from what it judges to be multiple actors.
21 Oct, 07:41 UTC
A container image vendor publishes fixed images more than six hours before the coordinated release, letting anyone study the fix early.
21 Oct, 13:30 to 14:00 UTC
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, with minimal source backports for PHP 7.4, 8.0 and 8.1. Full advisories are published.
21 Oct, from mid-morning
Governments across Europe start taking sites offline as a precaution, many before the fix is out. After the release, the EU institutions and national CSIRTs issue a joint statement urging immediate action.
21 Oct, evening
Latvia's National Cyber Security Centre restricts access to affected state systems to Latvian IP addresses, possibly until Monday 26 October. CERT.LV reports isolated, unsuccessful exploitation attempts.
22 Oct
CERT.LV says about 95% of important Latvian state digital resources have been updated. Cloudflare's chief executive reports millions of attempts across its network. No vendor or CERT has publicly confirmed a successful compromise, and neither CVE is in CISA's Known Exploited Vulnerabilities catalogue. The PHP project's issue tracker lists the first regressions in the fixed releases.
Many public bodies did not wait for the release. Across the EU, websites were taken offline as a precaution, and the national CERTs that published advice said much the same: patch now, and isolate what you cannot patch.
Latvia · state services
On 21 October the Ministry of Defence's National Cyber Security Centre limited access to state information systems running the affected PHP to Latvian IP addresses until they are fixed. The shared state and municipal website platform was switched off for about three and a half hours that evening, in Latvia as well, and the public broadcaster's portal LSM.lv for about five hours; both were back for users in Latvia by 23:00. On 22 October CERT.LV said about 95% of important state digital resources had been updated and were fully reachable from Latvia, and that access from abroad should return for most of them by Monday 26 October.
Latvia · CERT.LV
CERT.LV's deputy head said on 21 and 22 October that mostly automated attempts, by bots and small groups, had been seen against private and state systems in Latvia and that none was known to have succeeded, though he expects some poorly protected sites to fall. CERT.LV estimates that about 6,000 digital resources in Latvia could be affected, several hundred of them in the public sector. CERT.LV calls on companies to check their systems and install the updates immediately, starting with public websites, online shops and customer portals.
EU · joint statement
The European Commission, ENISA, CERT-EU, Europol's cybercrime centre and the network of national CSIRTs issued a joint statement urging immediate action and, where remediation is not feasible, consideration of isolating exposed applications from public networks until fixes are applied. It also reminded manufacturers that actively exploited vulnerabilities in their products must now be reported under the Cyber Resilience Act.
National CERTs, and beyond Europe
Germany's BSI rated the situation orange, meaning act without delay. It advises considering disconnection from the internet where patches cannot be installed, and rebuilding Docker images. CERT-FR advises isolating end-of-life PHP and migrating. The UK NCSC asks organisations that cannot update to check for compromise and backdoors first. CISA advises taking PHP systems offline if they cannot be updated immediately or run PHP 8.1 or earlier.
Across Europe
Reported closures on 21 October included Dutch government portals and the Port of Rotterdam, all Flemish government websites, Finland's central government public internet services and French prefecture websites. Many were back within hours, including the Dutch NCSC's own website. Recovery was slower elsewhere: on 22 October Finland's state IT provider said full restoration could take days or even weeks, and a UK minister said 32 government services were unavailable and four partially, as a precaution. None of the closures was attributed to a breach, and Germany's digital minister said there was no sign that federal systems had been compromised.
Beyond websites
The Dutch NCSC notes that PHP is also embedded in appliances, network devices, management interfaces and other vendor products where administrators may not be able to update PHP directly. It maintains a public, admittedly incomplete list of potentially affected third-party products, which CERT-EU and the UK NCSC both point to. On 21 October Palo Alto Networks said the management interface of every PAN-OS and Panorama version is affected, with no fixed version yet; restrict management interfaces to trusted networks. Ask your vendors directly.
Each guide takes one part of the response and goes through it in full, with sources.
Where the fixed PHP packages are for Debian, Ubuntu, RHEL and its rebuilds, Fedora, SUSE, Alpine, Amazon Linux, Docker, control panels and managed hosts, and how to make sure the new binary is the one running.
Read the guideThere is no official fixed release below PHP 8.2. What the PHP project provided for 7.4, 8.0 and 8.1, where distribution fixes come from, and what to do with anything older.
Read the guideThe configuration changes the PHP project published for systems that cannot be updated today, what each one blocks, what it breaks, and the two settings that make things worse.
Read the guideWhere to look, what each signal means and does not mean, and what to do if a server shows signs of compromise, including preserving evidence before you rebuild.
Read the guideField data from OffSeq's Mirage decoy fleet: when PHP2Shell traffic started, how many sources sent it, and the indicators defenders can hunt for in their own logs.
Read the guideWhich security and cloud vendors published PHP2Shell rules, which are on by default and which you must switch on, and the limits every one of them states.
Read the guideWhat the EU institutions and national CERTs advised, and when a PHP2Shell incident triggers NIS2, GDPR, DORA, Cyber Resilience Act or Latvian reporting duties.
Read the guideShort answers, drawn from the sources listed at the foot of this page.
memory_limit, or memory_limit plus 1 GB for limits above 1 GB, above which PHP now ends the process instead of raising the usual catchable out-of-memory error; a php-src issue reports some functions hitting it where 8.5.11 raised a normal error. Other open or fixed issues report session upload progress destroying a session that stores certain objects, and a SimpleXML memory error that broke some test suites, fixed in the source code on 22 October but not yet in a release. Test your application after upgrading and watch for workers exiting with code 137.Prefer to call? +371 2256 5353 Monday to Friday, 09:00 to 18:00 Riga time
After the emergency
PHP2Shell will not be the last critical flaw in software that organisations forget they run. These OffSeq services help you know what you expose before the next one.