PHP2Shell: What the PHP Vulnerability Means for ISO 27001 and NIS2

Key takeaways

• PHP2Shell is the name for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. They let attackers run code on web servers without logging in.
• The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For PHP 7.4 to 8.1, the PHP project only published source backports, and older versions get no fix at all.
• Germany's BSI issued a cybersecurity warning at alert level "3 / Orange" on October 21, 2026. Amazon observed the first exploitation attempt on October 17, four days before the patches.
• Under NIS2, the vulnerability alone is not a reportable incident. If it leads to a significant incident, an early warning to the national authority is due within 24 hours.
• In an ISO 27001 ISMS, your response falls under control A.8.8 (management of technical vulnerabilities). At your next audit, you should be able to show which systems you checked and when you patched them.

On October 21, 2026, the PHP project released emergency updates for two critical flaws now known as PHP2Shell. This PHP vulnerability sits not in a plugin or framework but in the interpreter itself. That means every application running on PHP is affected: WordPress, Drupal, Typo3, Joomla, Magento, Shopware, Moodle, and many in-house applications. According to the BSI, the flaw affects not only websites but also firewalls, load balancers, and other network devices that have a PHP-based web interface.

Germany's Federal Office for Information Security (BSI) described the threat potential as "outstanding". Universities, city administrations, and hospitals took their websites offline as a precaution, and most were back online the following day.

This article is for IT leads, CISOs, and compliance teams. It explains what happened technically, what you should do now, and what PHP2Shell means for companies that are ISO 27001 certified or fall under NIS2.

What is PHP2Shell?

PHP2Shell is the collective name for two vulnerabilities in the PHP interpreter that let attackers run their own code on a web server remotely, without credentials. This is known as remote code execution. An attacker who gets that far can steal data and passwords, deface websites, plant malware, or use the server for further attacks.

The two vulnerabilities

CVE-2026-109618 occurs when PHP runs out of memory during a request. The request is interrupted while internal data is only partly built. The cleanup routine that follows treats this incomplete data as valid, and that is where the attack comes in.

CVE-2026-109619 concerns the state between two requests. Internal data from one request survives after its memory has been freed. When the same worker handles the next request, it can use this stale state before it is reset.

Why your application can't stop the attack

The attack runs before your application even starts. Security researchers at Datadog reproduced both flaws: a single unauthenticated HTTP POST request to any PHP script is enough, even if that script only prints a page.

A login, a security plugin, or carefully audited application code therefore offers no protection. All common setups are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team rates the risk highest for mod_php.

How the situation unfolded

According to Amazon Threat Intelligence, the first exploitation attempt hit Amazon's honeypot network on October 17, 2026, while the flaws were still under embargo. On October 20, the PHP project announced the patches after technical details had leaked. The fixed versions were released on the afternoon of October 21 (CEST).

Cloudflare CEO Matthew Prince reported that exploitation attempts rose to hundreds of thousands within two hours of disclosure and to millions shortly after. Security experts expect automated attacks to continue for weeks or months. As of October 22, the BSI said it had no reports of successfully compromised systems in regulated industries or the German federal administration, but it explicitly does not rule out successful attacks.

Which PHP versions are affected

All PHP versions released before the emergency updates of October 21, 2026 are affected, going back to PHP 5. Whether a server is protected depends on its version branch and where it gets its updates from.

A common misconception: the version number alone doesn't tell you whether a server is safe. Linux distributions often apply security fixes as backports without changing the displayed PHP version. Check your distribution's security advisories, or ask your hosting provider to confirm in writing that both CVEs are fixed.

Before the patches, a widely shared tip was to disable session.upload_progress. Datadog showed that this does not stop the attack. New WAF rules, such as those Cloudflare rolled out to all plans, only bridge the time until you update. Only the patch protects you.

What to do now

The most important task is a complete picture of where PHP runs in your company. In practice, that is usually more systems than IT can name off the top of their heads.

1. Build an inventory (day 1, IT operations). List every server, container image, and hosting package that runs PHP. Include staging environments, old campaign sites, the intranet, and websites an agency manages for you. This also covers firewalls, load balancers, NAS devices, and other hardware with a PHP-based admin interface. For these devices, the fix comes as a firmware update from the manufacturer, not as a PHP update.
2. Patch or get confirmation (days 1 to 2, IT operations or hosting provider). Install the fixed versions on your own servers. Large hosting providers such as Ionos have already updated their systems. Still, get confirmation for every website.
3. Isolate outdated systems (days 1 to 2, head of IT). Anything on PHP 8.1 or older that can't be updated quickly should be taken offline or isolated. The UK's NCSC, among others, recommends this. Until they are updated, keep the admin interfaces of firewalls, NAS devices, and other network hardware unreachable from the internet.
4. Review logs (days 2 to 3, security). Analyze logs from October 17 onward. Watch for very large form uploads, memory errors at the start of a request, shell processes spawned by PHP, new admin accounts, and unexpected file changes.
5. Trigger your incident process (immediately if you suspect compromise, information security officer or CISO). If there are signs of a compromise, your incident response process applies, including a check of possible reporting obligations.
6. Document (ongoing, information security officer). Record when you learned of the vulnerability, which systems were affected, when you patched, and what the log review found.

Another misconception concerns WordPress. Many site owners rely on automatic updates. These update WordPress, plugins, and themes, but not the PHP version on the server. The fix has to come from your hosting provider or server operations.

What PHP2Shell means for NIS2

Under NIS2, vulnerability handling is an explicit obligation. Article 21(2)(e) of the directive requires measures for security in the acquisition, development, and maintenance of systems, including vulnerability handling. In Germany, this duty sits in section 30 of the BSI Act, which the NIS2 implementation act revised with effect from December 6, 2025. For an overview of all obligations, see our guide to NIS2 requirements.

Reporting: when it applies and when it doesn't

Many companies assume they have to report PHP2Shell to their authority because their servers were affected. That isn't the case. A vulnerability alone is not a security incident. The reporting duty applies to a significant incident, for example if attackers used the flaw to steal data or disrupt a service.

If that happens, the deadlines in Article 23 NIS2 apply: an early warning within 24 hours of becoming aware of the significant incident, an incident notification within 72 hours, and a final report no later than one month after that notification. Review your logs promptly.

Management is accountable

NIS2 makes management bodies responsible for implementing cybersecurity risk management measures. For a vulnerability of this scale, your managing directors should know how many systems were affected and by when they will be patched. Our article on NIS2 obligations for managing directors explains what this means in practice.

What PHP2Shell means for ISO 27001

In an ISMS based on ISO 27001:2022, PHP2Shell is a test case for several Annex A controls. At the center is A.8.8, management of technical vulnerabilities: you need to get information about vulnerabilities in time, assess your exposure, and take appropriate action.

Other controls are involved too. A.5.9 requires an inventory of assets, without which you can't know everywhere PHP runs, including in network devices. A.5.7 covers threat intelligence, meaning how quickly you learned of the warning. A.8.16 governs the monitoring you need for log review, and A.5.24 to A.5.28 cover incident management. How these ISO 27001 controls fit together is covered in a separate article.

What auditors will want to see

At your next surveillance audit, expect the question of how your company responded to PHP2Shell. An auditor won't expect perfection, but a traceable process: When did you learn of the vulnerability? Who assessed the exposure? Which systems were patched, and by when? Where is that documented?

An example: a 60-person SaaS company runs its platform on PHP 8.3 across 14 container images, plus a marketing website with a hosting provider and an old customer portal on PHP 7.4. The containers are updated within six hours, and the hosting provider confirms the website fix the next morning. The team takes the customer portal offline and schedules its migration. With timestamped tickets for each step, the evidence for A.8.8 takes minutes to pull together. Without them, the team rebuilds the story weeks later from chat threads and memory.

GDPR: when personal data is involved

The GDPR applies regardless of NIS2. If attackers used PHP2Shell to access customer data, passwords, or contact details, that is a personal data breach. Under Article 33 GDPR, you must notify the competent data protection authority within 72 hours, unless the breach is unlikely to result in a risk to the people affected. Assess this in parallel with the technical analysis, not afterward.

Fixing and proving vulnerabilities without collecting screenshots

After a flaw like PHP2Shell, you don't just have to fix it, you also have to prove the fix at your audit. Kertos connects both steps through the Aikido and Kertos integration. Aikido Security detects vulnerable components in code, container images, and cloud environments. Kertos reads these findings and their remediation deadlines daily and records the result as evidence against the matching requirements in ISO 27001, NIS2, and SOC 2.

For your audit, that means the evidence of when a vulnerability was found and when it was fixed comes from where the work happens. Kertos's certified experts help you set up your vulnerability and incident processes so they hold up when the next critical flaw lands.

If you'd like to see how this works in your environment, book a demo.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. They let attackers run code on web servers without logging in. The PHP project released fixed versions on October 21, 2026.

Which PHP versions are affected by PHP2Shell?

All versions before the emergency releases of October 21, 2026 are affected, going back to PHP 5. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 or later are safe. PHP 7.4 to 8.1 only get backports through distributions and LTS vendors, and older versions get no fix.

Is my WordPress site affected by the PHP vulnerability?

Yes, if the server runs an unpatched PHP version. Automatic WordPress updates don't help, because they only update WordPress, plugins, and themes. You can see the PHP version under Tools, Site Health, Info, Server, and the fix has to come from your hosting provider or server operations.

Do I have to report PHP2Shell under NIS2?

Not just because your servers had the vulnerability. The reporting duty applies to a significant incident, such as a data breach or a disruption of your services. In that case, an early warning is due within 24 hours, a notification within 72 hours, and a final report no later than one month after that notification.

Does a web application firewall protect against PHP2Shell?

Only temporarily. Providers such as Cloudflare have rolled out rules for known attack patterns that bridge the time until you update. Variations of the attack can get around such rules, so only the PHP update protects you permanently.