Critical PHP vulnerability PHP2Shell, what UAE businesses must do now

On 21 October 2026 the PHP project released emergency patches for two critical flaws in PHP itself, together named PHP2Shell, which allow an attacker with no login to run code on a web server and to read memory that may contain passwords, session tokens, API keys and certificates. Both are rated 9.2 Critical. The vulnerable code has been in PHP since version 5.4.0 in 2012, default configurations are affected, and PHP runs an estimated 69.3% of websites whose server-side language is known, which means most business websites in the UAE are built on it.

Two things make this different from the usual patch notice, and both matter more than the score.

First, the flaw is in the engine, not in your website. It fires before any of your application code runs. Your WordPress security plugin, your admin password, your firewall rules inside the application, even WordPress or Magento maintenance mode, are all downstream of the point where the attack happens. A site with perfectly clean code on a vulnerable PHP version is still exposed.

Second, exploitation attempts began before anyone outside the disclosure process knew. Amazon Threat Intelligence recorded an attempt against its honeypot network on 17 October, four days before public disclosure, and recommends that organisations start any investigation from at least that date rather than from the day the patch appeared.

This article sets out what happened, who should worry and how much, exactly what to do, what to do if you cannot patch immediately, and how to check whether you were already hit. It is written for business owners and marketing managers as much as for developers, so the technical sections say plainly who needs to act on them.

What happened, in order

The timeline matters because it explains why the patch arrived in a hurry and why your investigation window starts earlier than the patch date.

The flaws were found by Ryan Austin of Calif, by Wiz Research, specifically Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz, and by OpenAI's Codex Security team, with the PHP security team coordinating the fix. Google stated that its Gemini 4 Argon model contributed to finding the vulnerability, to exploit development, to attack detection and to validating the patch, and both Calif and Wiz confirmed they used AI models in their research. A decade-old bug found by three independent teams within a month of each other, all using AI assistance, is a pattern worth noting separately from this incident.

What the two vulnerabilities actually are

Both are memory safety bugs in how PHP handles a request that runs out of memory. In plain terms: PHP is interrupted mid-setup, does not finish cleaning up properly, and then treats leftover rubbish as though it were valid data. Here is the official description of each, from PHP's own advisory.

Both are rated CVSS v4.0 9.2 by the PHP security team. The 10.0 figure that circulated with the leaked identifiers was not PHP's and is wrong.

One technical detail decides how worried you should be. According to PHP, every known trigger is a multipart/form-data request, the format a browser uses to upload a file. PHP parses that request body before handing control to your application. That is why your application's defences are irrelevant to this bug, and it is also why the temporary mitigations below focus on request bodies and upload handling.

Sansec, whose forensics team published the clearest operational analysis, describes the second impact in terms that should concentrate the mind. PHP's upload progress handler can return freed worker memory to the attacker inside a PHPSESSID response cookie, and that memory can contain passwords, session tokens, API keys and TLS private keys belonging to other people's requests. It works even when your application never starts a session. The Hacker News reported that researchers demonstrated this reading of live worker memory against applications they did not control.

The practical consequence is that patching is not the whole job. If your server was exposed, you have to assume credentials may have leaked and rotate them. That is covered further down and it is the step most businesses will skip.

Who is affected, and who should actually worry

PHP's advisory states that all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is not evenly distributed, though, and it is worth knowing where you sit before you panic or relax.

The forgotten systems are the real problem. In our experience the server everybody patches is the main website. The ones that get missed are the old staging site on a subdomain, the microsite built for a campaign three years ago, the phpMyAdmin install somebody left reachable, a legacy intranet tool, and a developer's test environment that was never taken offline. Every one of those is a PHP server with a public address, and an attacker scanning for this does not care which of your sites is commercially important.

What to update to, and four traps on the way

The fix is a PHP update on the server. These are the fixed versions released on 21 October 2026.

PHP 8.6.0 RC4 also contains the fixes, though release candidates should not be in production. Now the traps, each of which we have seen catch somebody already.

1. Updating WordPress, Magento or Laravel does not update PHP. This is the single most common misunderstanding of this incident. The PHP runtime comes from your server package, your host or your container image. Your application can be completely up to date and still be running a vulnerable PHP. Check the PHP version, not the CMS version.
2. A distribution package can carry the fix under an old looking version number. If you run Debian, Ubuntu, Red Hat or similar, your package may still report something like 8.2.7 while containing the backported fix, because Linux distributions and LTS vendors received the patches in advance. Debian's advice is to check the package changelog for the CVE identifiers rather than trusting the version string. Equally, do not assume you are safe because the number looks recent.
3. PHP 8.2 reaches end of life on 31 December 2026. Updating to 8.2.35 is correct today and buys you about ten weeks. If you are making a change anyway, go to 8.3 or 8.4 and save yourself a second migration. Treat 8.2.35 as emergency triage rather than a destination.
4. Third-party repositories lagged, and PHP said so itself. PHP's advisory carries an unusually direct instruction: if you rely on the volunteer-maintained rpms.remirepo.net, common on Red Hat based servers, switch to distribution packages or build from source, because the repository would not have updates that day. A project telling its own users to stop using a popular third-party repository is not a sentence you see often. If you install PHP from any third-party repository, verify the fix is actually present rather than assuming an update command did the job.

Then restart everything. Updating the package is not enough on its own. Restart Apache, restart PHP-FPM, restart any long-running PHP workers, queue workers and daemons, and redeploy containers. A patched PHP binary on disk with an unpatched worker still in memory is still vulnerable.

If you cannot patch immediately, what the real options are

PHP is unambiguous on this point, and so are we. Every one of the four release announcements published on 21 October carries the same sentence: "There are no complete mitigations, updating is the only safe choice." Everything else reduces exposure to specific attack paths without making a server safe, which is PHP's own wording in its security advisory. A PHP core developer, Gina Peter Banyard, put it more bluntly still before the release: "the only mitigation is patching or upgrading PHP."

That said, there are four categories of temporary measure, and it is worth understanding what each one actually costs you before anyone touches a configuration file.

The full technical detail, including the exact values PHP recommends, is published in PHP's own advisory and summarised by the NCSC, and the operational analysis from Sansec and Tenable is the best available. We have deliberately not reproduced the configuration here, for the reason in the next section.

Why this is not a do it yourself job

We have seen each of the following go wrong this week, on real sites, in the hands of competent people working quickly under pressure.

• The settings are applied where they have no effect. PHP-FPM reads its own pool configuration rather than the command-line configuration file, and PHP explicitly says not to rely on in-script settings or per-directory overrides for these mitigations. A change made in the obvious place frequently does nothing, and the server looks protected while it is not.
• The workers are never restarted. A patched or reconfigured PHP on disk with an old worker still resident in memory is still vulnerable. This single omission accounts for more false confidence than any other.
• Nobody verifies the result. The values have to be confirmed in a request actually served by the web stack, not on the command line, because the two read different configuration. Without that check you have a belief rather than a fix.
• One mitigation is mistaken for both. The setting that circulated widely as a workaround before the patch covers one confirmed path of one of the two flaws. Applying it and standing down is a common and serious error.
• A substitute is used that makes things worse. PHP specifically warns against two common memory limiting mechanisms as substitutes, because they can themselves cause the allocation failure the attack depends on.
• The side effects are discovered by customers. Uploads stop working, checkout fails on certain carts, large imports break. If nobody tests the commercial paths after applying a mitigation, the business finds out from a complaint.
• The temporary measures are never removed. Months later the site is patched, uploads are still blocked, and the memory limit is still off, which is its own availability risk.

None of that is a reason to do nothing. It is a reason to have it done by people who will apply the change in the right place, restart the right processes, verify it in a real request, test your checkout and your uploads afterwards, and reverse it deliberately once PHP is patched.

Taking the site offline, and the trap almost everyone hits

Going offline is a legitimate response and serious organisations chose it this week. BambooHR took its service offline across the United States, Canada and Ireland and warned that payroll would be interrupted. In the Netherlands, MijnOverheid, DigiD, the lower house of parliament's website, the national cyber security centre and several education systems went offline as a precaution, as did the technology site Tweakers and Security.NL. None of those outages were reported as a response to a confirmed break-in.

Here is the trap. The maintenance modes built into WordPress and Magento do not protect you at all, because PHP parses every incoming request before the application ever checks the maintenance flag. A business that switches on maintenance mode and believes it is now safe is in exactly the same position as before, with the added disadvantage of having stopped trading. Taking a PHP site genuinely offline, or restricting it so visitors can still browse while logins and orders are disabled, is a server-level change rather than an application setting.

Whether that trade is worth making depends on how long you will be exposed and what the site earns in that time. It is a commercial decision that needs a technical answer underneath it, and it is the kind of call we make with clients rather than for them.

Your WAF and Cloudflare will not save you

Cloudflare deployed firewall rules for the known exploit vectors on 21 October, available to all customers including the free tier, and Google Cloud Armor issued managed rules. Both are worth having switched on. Neither is a fix, and the vendors say so themselves.

Cloudflare's own chief technology officer, Dane Knecht, described the rules as "a STOPGAP only" and told administrators to patch. Sansec went further and told its own paying customers not to wait for a rule from its commercial security product, because the attack paths run inside PHP, before store code and before any of it. When two security vendors tell you their products will not protect you, that is worth believing.

There is also a gap that catches people out. Rules only cover traffic that actually routes through them. A server reachable directly by its IP address, an origin that was never restricted to the proxy's address ranges, a staging subdomain outside the configuration, or an old campaign microsite on separate hosting are all unprotected regardless of what you enabled this morning. Finding those is part of the work.

The after effects, and the part most businesses will skip

Patching closes the hole. It does not undo anything that happened before you patched, and because the memory disclosure path leaks secrets without needing code execution first, the clean-up is wider than usual. This is the sequence we would run for any client whose server was internet facing and unpatched.

1. Assume credentials may have leaked, and rotate them. Memory disclosure is a confirmed impact of this pair, and the memory in question can hold passwords, session tokens, API keys and TLS private keys belonging to other requests. Rotate database passwords, application and admin credentials, API keys and tokens for payment gateways, email services, CRMs and any integration, session secrets and salts, and seriously consider reissuing TLS certificates. Force a logout of all sessions.
2. Investigate from 17 October, not from the patch date. This is Amazon Threat Intelligence's explicit recommendation, based on its own observation of an attempt four days before disclosure. An investigation window that starts on 21 October is the wrong window.
3. Hunt for the specific indicators. Researchers suggest watching for unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, oddly large PHPSESSID response cookies, and unexplained restarts of PHP workers. Those three together are a strong signal.
4. Look for persistence, not just for the attack. NCSC's guidance is explicit that if you could not patch immediately you should assess the system for evidence of compromise and look for backdoors before upgrading. That means new or modified PHP files, unfamiliar scheduled tasks and cron entries, new admin users, modified core files, unexpected outbound connections and suspicious plugins or extensions. A patched server with a web shell on it is still an owned server.
5. Check your backups before you trust them. If a backdoor was planted on 18 October, a restore from 20 October reinstalls it. Identify a known-good restore point from before 17 October, and verify rather than assume.
6. Review memory settings after patching. This is a genuine post-patch regression risk that almost nobody is talking about. The fix introduces a new hard memory limit, and reaching it ends the process and stops shutdown handlers from running. Check memory_limit and post_max_size against what your application actually needs, particularly for large imports, report generation and bulk uploads.
7. Remove the temporary mitigations once patched. The multipart block breaks uploads and memory_limit = -1 leaves a server one bad request away from exhausting its memory. Both should be reversed deliberately, not forgotten.
8. Write down what you found and when. If you handle personal data, a plain internal record of exposure window, actions taken, evidence reviewed and credentials rotated is what you will need later. Decide, with advice if necessary, whether any notification obligation applies to you. We are not lawyers and this is not legal advice.

How worried should a normal business in the UAE be

Honestly, it depends on one answer: who controls your PHP version. We would rather give you a calibrated view than add to the noise.

• If you are on reputable managed hosting on a current PHP branch, you are probably already patched or will be within days, and your job is to confirm it in writing rather than to act. Ask your host three questions: which PHP version serves my site, is it patched against CVE-2026-109618 and CVE-2026-109619, and have the workers been restarted. A host that cannot answer those quickly is telling you something useful.
• If you run your own server or VPS, or your developer does, this is a today job. The window between public exploit code and automated mass scanning is measured in hours, not weeks.
• If you are on PHP 8.1 or older, this is the week the deferred upgrade stops being deferrable. There is no official patch for you, and no mitigation makes an unpatched installation safe.
• If you run an ecommerce store, treat it as the priority regardless of platform. Magento, Shopware and WooCommerce stores are all exposed when the engine beneath them is vulnerable, and a store holds payment integrations, customer data and credentials that make memory disclosure genuinely expensive.
• If nobody in your organisation can tell you what PHP version your site runs, that is the actual finding, and it will be true again at the next one of these. The answer is a maintenance arrangement where somebody is accountable for knowing, not a one-off scramble.

And some proportion. As at the time of writing, multiple honeypot networks had observed exploitation attempts, but no source had publicly confirmed a successful break-in at a named organisation, and neither CVE had been added to the CISA Known Exploited Vulnerabilities catalog. Amazon said it was unclear whether the attempts it saw on 21 October would have succeeded against real-world systems. That is not a reason to relax, because PHP flaws have a track record here. The CISA catalogue already lists three, and two of them, a PHP-CGI flaw from 2024 and a PHP-FPM flaw added in 2022, are known to have been used in ransomware campaigns. The pattern is that mass exploitation of PHP bugs arrives after the patch, not before it, and it arrives against whoever has not moved.

Why this is the argument for a maintenance arrangement

The businesses that had a calm week were not the ones with the best firewalls. They were the ones where somebody already knew what every server was running and had a route to change it the same day. That is the whole difference, and it is not something you can buy on the morning of an incident.

Consider what this particular event asked of a business in the space of a few hours. Know every system you own that runs PHP, including the forgotten ones. Know the exact PHP version and how it is running on each. Judge whether a distribution package carries the fix despite an old looking version number. Decide between patching, mitigating and going offline, commercially as well as technically. Apply changes in the place they take effect, restart the right processes and verify the outcome. Test that checkout and uploads still work. Review logs back to a date four days before the patch existed. Look for backdoors rather than only for the attack. Work out which credentials to rotate and rotate them. Then undo the temporary measures and re-check memory settings for a post-patch regression. Finally, write down what was found and done.

That is not a task. That is a function, and it has to exist before it is needed.

• A current inventory is the thing that saves you. Under a maintenance arrangement we already know your PHP version, your server configuration, your platform and which of your properties are internet facing, including the staging site and the old campaign microsite. On the day of an incident that question is already answered.
• Patching happens in hours, not after an approval cycle. The window between a public exploit and automated mass scanning is measured in hours. A maintenance arrangement is partly a technical service and mostly a pre-agreed permission to act quickly.
• Somebody is watching when you are not. This advisory landed at 14:00 UTC, which is 18:00 in Dubai, on a Wednesday. Monitoring, update management and a named person who answers are what turn that into a handled event rather than a Thursday morning discovery.
• Tested backups are what make recovery possible. If a backdoor was planted before the patch, a restore from after it reinstalls the problem. Knowing you have a verified restore point from before 17 October is a maintenance outcome, not a lucky one.
• Routine patching is the thing that was already being skipped. PHP's own news archive for 2026 records 33 point releases across its supported branches in the first ten months of the year, on eleven separate release dates, which is a release date roughly every four weeks. Most of those were routine maintenance and some carried security fixes. The businesses scrambling this week are overwhelmingly the ones that applied none of them, because nobody owned the job. An emergency is just a routine task that was deferred until it became one.
• Version currency is a security control. Businesses on PHP 8.1 or older had no official patch available to them this week. That was decided months earlier by whoever let the version drift, and PHP 8.2 reaches end of life on 31 December 2026, so the same decision is in front of a lot of businesses right now.
• You get a written record. What was exposed, for how long, what was checked, what was changed and what was rotated. If you handle customer data you will want that document to exist, and it is much harder to assemble afterwards.

Our website maintenance and AMC service covers updates, security patching, backups with tested restores, uptime and form delivery monitoring, performance work and a defined turnaround for changes, delivered by the same in house team that builds and hosts the sites. Our note on what should be in a website AMC sets out the scope in detail. Tomsher has operated in Dubai since 2011, with more than 15 years of delivery experience and a 4.9 out of 5 rating from 201 Google reviews.

What this says about the next one

Two observations worth taking away once the patching is done, because there will be another of these.

The disclosure process failed on timing, and the defenders lost the gap. A coordinated disclosure that began in August was pulled forward by a day because the CVE identifiers leaked on social media, and attack attempts were recorded six hours before the patch was publicly available. Amazon saw an attempt four days earlier still. The practical lesson for anyone running infrastructure is that the window to prepare is not the window between patch and exploit, because that window can be negative. The preparation that helps is the boring kind done in advance: knowing every server you own, knowing what runs on it, and having a route to patch it in hours rather than weeks.

A decade-old bug was found by three independent teams within a month, all using AI assistance. Calif found it on 1 August, Wiz reported independently on 24 August, OpenAI's Codex Security team was credited, and Google says its Gemini 4 Argon model contributed to discovery, exploit development, detection and patch validation. That code had been in PHP since 2012. The honest reading is that AI-assisted vulnerability research is now finding things that went unnoticed for thirteen years, and that it works for both sides of the fence. The defensive consequence is not philosophical: patch cycles that assumed a quiet discovery rate need to get faster, because the discovery rate changed.

Neither point is comfortable, and neither is a reason to avoid PHP, which runs most of the web and is maintained by a security team that turned around two critical fixes under pressure and published unusually detailed mitigation guidance while doing it. The point is simply that the speed expected of you has gone up.

PHP2Shell FAQs

Common questions about CVE-2026-109618 and CVE-2026-109619 for business owners, marketing managers and developers.

What is PHP2Shell in plain English?

PHP2Shell is the name given to two critical flaws in PHP, the software that runs most websites on the server side. Together they let an attacker who has no account and no password run their own code on a web server, and separately read chunks of the server's memory that can contain passwords, session tokens, API keys and certificates. They are tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 and classed as Critical. PHP released fixes on 21 October 2026 and says that updating is the only complete solution.

Is my website affected?

If your website runs on PHP and the PHP version on the server has not been updated, yes. That covers WordPress, Magento, Drupal, Joomla, Laravel, Symfony, WooCommerce, Shopware, phpMyAdmin, Nextcloud, WHMCS and most custom-built sites in the region. The vulnerable code has been in PHP since 2012 and default configurations are affected, so there is no version old enough or new enough to have escaped before the patch. If your site is fully static, or hosted on a platform such as Shopify, Wix or Squarespace, this particular issue does not apply to you.

We keep WordPress and our plugins fully updated. Are we protected?

No, and this is the most common misunderstanding of this incident. The flaw is in PHP itself, which sits underneath WordPress, so an entirely up-to-date WordPress on a vulnerable PHP version is still exposed. The attack happens before any of your application code runs, which also means your security plugins, your firewall settings inside WordPress, your admin password and even WordPress maintenance mode are all downstream of where the problem occurs. The PHP runtime is updated by your server package, your host or your container image, not by your CMS updater.

What should I ask my hosting provider?

Three questions, and get the answers in writing. Which PHP version is serving my site right now. Is that version patched against CVE-2026-109618 and CVE-2026-109619, meaning 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a distribution package carrying the backported fix. And have Apache or PHP-FPM workers been restarted since the update, because a patched file on disk with an old worker still in memory is still vulnerable. If you are on PHP 8.1 or older, add a fourth question about moving to a supported branch, because no official patch exists for those versions.

Which PHP versions are safe?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later within those branches. PHP 8.6.0 RC4 also contains the fixes but release candidates do not belong in production. PHP 8.1 and older receive no official release, although the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people building from source, and there is nothing for PHP 5. One caveat worth knowing: a Linux distribution package can contain the fix while still showing an older looking version number, so Debian's advice is to check the package changelog for the CVE identifiers rather than reading the version string alone.

Has anyone actually been attacked, or is this theoretical?

Attempts are real and were under way before the patch existed. Amazon Threat Intelligence recorded an exploitation attempt against its honeypot network on 17 October, four days before public disclosure, saw further attempts on 21 October with payloads and infrastructure suggesting multiple actors, and says PHP2Shell is now being broadly exploited. Cloudflare reported early attacks at 07:43 UTC on 21 October, before the patch was released, and watchTowr observed exploitation through its own honeypot network. What has not happened, as at the time of writing, is a publicly confirmed successful break-in at a named organisation, and neither CVE has been added to the CISA Known Exploited Vulnerabilities catalog. Treat that as a reason to move quickly rather than a reason to relax.

We patched. Is that the end of it?

Not quite, and the remaining steps are the ones most businesses skip. Because one impact is memory disclosure that does not require code execution first, you should assume secrets may have leaked from an exposed server and rotate them: database passwords, admin and application credentials, API keys for payment gateways and integrations, session secrets, and ideally your TLS certificates. You should also review logs from 17 October onwards rather than from the patch date, look for backdoors rather than just for the attack, verify that your chosen restore point predates 17 October, and re-check your memory settings, because the fix introduces a new hard memory limit that ends the process when reached.

How do I tell if we were already compromised?

Look for three indicators together: unusual multipart form requests followed by memory limit errors or repeated HTTP 500 responses, unusually large PHPSESSID response cookies in your logs, and unexplained restarts of PHP worker processes. Beyond that, check for new or modified PHP files, unfamiliar cron jobs or scheduled tasks, new administrator accounts, changed core files, unexpected outbound network connections and unfamiliar plugins or extensions. NCSC's guidance is that if you could not patch immediately you should assess for compromise and look for backdoors before upgrading, and that if you are not confident doing that yourselves you should get specialist help.

Can a firewall or Cloudflare protect us instead of patching?

No. Cloudflare deployed WAF rules on 21 October, available to all customers including the free tier, and Google Cloud Armor issued managed rules, and both are worth enabling as defence in depth. But Cloudflare's own CTO described the rules as a stopgap only and told administrators to patch, and Sansec told its own customers not to wait for a rule from its commercial product because the attack paths run inside PHP before any of it. Rules also only cover traffic that routes through them, so a server reachable directly by IP address, or a staging subdomain outside the proxy, is unprotected regardless.

Should we take our website offline?

It is a legitimate option and serious organisations chose it this week, including BambooHR across three countries and several Dutch government services. The decision comes down to how long you need before you can patch and what the site is worth while exposed. If you can patch within the hour, patch. If patching will take days and the server is internet facing and unpatched, going offline or read only is defensible. One technical point if you do: the maintenance modes in WordPress and Magento do not help, because PHP parses the request before the application checks the flag, so you need to stop PHP-FPM and serve a static page from the web server instead.

We are on PHP 7.4 and an upgrade is a big project. What now?

You have a short-term option and no long-term one. The short-term option is the minimal source backport the PHP security team published for 7.4, which requires building from source, or a backported package if your distribution or LTS vendor provides one, so ask them. That keeps you running but leaves you on a branch that receives no routine security maintenance, which means you will be in exactly this position at the next PHP vulnerability, with fewer options. The honest answer is that the upgrade stopped being optional this week, and the sensible move is to apply the backport or a vendor package now to stop the bleeding and start the upgrade to a supported branch immediately after.

Does this affect email, databases or anything other than the website?

The vulnerability is in PHP, so the direct risk is to anything that runs PHP to serve requests. The indirect risk is wider, which is the point people miss. If an attacker achieved code execution on a web server, they were on a machine that typically holds database credentials, mail server credentials and API keys, and could reach whatever those credentials reach. If they achieved only memory disclosure, those same secrets may have been read without any code being run. So your database and your email are not vulnerable to PHP2Shell themselves, but they may well be reachable with credentials stolen through it, which is why rotation matters as much as patching.

Can Tomsher help with this?

Yes, and for sites we already maintain this work is part of the arrangement rather than an extra. For anyone else, we can identify the PHP version and configuration serving your site, tell you whether it is patched, apply the update or the official mitigations and restart workers properly, review logs from 17 October for the known indicators, check for backdoors and modified files, advise on which credentials to rotate, and give you a written record of what was done and when. If your site sits with a host we do not control, we will tell you exactly what to ask them and review their answer.

Sources

• PHP, official security advisory and release announcement, 21 October 2026, php.net. The source for the CVE descriptions, fixed versions, affected server configurations and the full mitigation list quoted above.
• PHP, news archive for 2026, php.net/archive/2026.php. The source for the 20 October advance notice, the four individual release announcements and their shared line that there are no complete mitigations, the instruction regarding the rpms.remirepo.net repository, and the count of point releases published across supported branches during 2026.
• National Cyber Security Centre (UK), "Critical security issue affecting PHP", alert published 21 October 2026, ncsc.gov.uk. The source for the priority actions, the instruction to assess for compromise and backdoors before upgrading, and the reference to the NCSC-NL inventory of products with a PHP dependency.
• Google Cloud, "Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619", Chris Betz, CISO Google Cloud, and Raluca Ada Popa, Head of Gemini Security, Google DeepMind, 21 October 2026, cloud.google.com. The source for the CVSS 9.2 rating, the Cloud Armor guidance, the per-service patching position and the Gemini 4 Argon contribution.
• Tenable Research Special Operations, "php2shell: Frequently asked questions", Satnam Narang, 21 October 2026, tenable.com. The source for the disclosure timeline, the Amazon Threat Intelligence findings, the W3Techs and exposed-host figures, and the CISA KEV history of earlier PHP flaws.
• Sansec Forensics Team, "PHP2Shell: Critical PHP RCE", 21 October 2026, sansec.io. The source for the multipart trigger, the web server mitigation snippets, the PHPSESSID memory leak description, the list of confirmed vulnerable applications, the Remi repository note and the detailed timeline.
• The Hacker News, "PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge", Swati Khandelwal, 21 October 2026, thehackernews.com. The source for the mod_php and PHP-FPM risk distinction, the distribution version-number caveat, the post-patch memory limit change, the indicators of compromise and the precautionary outages.
• watchTowr, "Frequently Asked Questions About PHP Remote Code Execution", published 20 October 2026 and updated 22 October 2026, watchtowr.com. Used for the exploitation status and the CISA KEV listing status as at 22 October 2026.

Research credit for the vulnerabilities belongs to Ryan Austin of Calif, to Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz) and to OpenAI's Codex Security team, with the PHP security team coordinating the fix. This article summarises their published work and adds no exploit detail of its own.