This week, two critical flaws in the core of PHP forced websites around the world offline. Link11 assesses what is known about the attacks and the role of web application firewalls, explaining why only the update closes the gaps.
On October 21, the PHP project released security updates for the two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, also known as “PHP2Shell.” Both vulnerabilities have been rated with a CVSS score of 9.2. Under certain conditions, these vulnerabilities allow attackers to run code on web servers without logging in and read memory contents, such as passwords or API keys.
Germany’s Federal Office for Information Security (BSI) has rated the situation as a warning level 3/Orange. Where the update could not be applied quickly, BSI recommended taking servers offline temporarily. Authorities, universities, hospitals, and hosting providers followed this advice on an unprecedented scale.
From scans to widespread attacks
Link11’s honeypots, which are distributed worldwide, have detected scanners systematically searching the internet for vulnerable websites. Security researchers across the industry are now reporting widespread exploitation attempts against these vulnerabilities. According to these reports, the first attempts occurred as early as October 17, four days before the vulnerabilities were disclosed (Infosecurity Magazine). So far, no successful compromise has been publicly confirmed.
“We’re seeing attackers specifically scouting the web,” says Karsten Desler, CTO at Link11. “No one can reliably rule out whether vulnerabilities have already been exploited. A sophisticated attack often goes unnoticed, even by the victim.” Therefore, operators should review their logs from at least October 17, not just the day of disclosure.
How Link11 responded
Link11 took immediate and proactive action. On the day of disclosure, our team developed protection rules against known PHP2Shell attack patterns and deployed them to all Link11 WAAP customers. The platform combines a web application firewall (WAF), web DDoS protection, bot management, and API security.
One rule targets the session upload progress path in PHP. According to security researchers, this is the route that most current attacks are taking. The team continuously adapts the rules to new attack variants.
Thus, the Link11 WAAP provides an additional layer of protection while the PHP update is being prepared and deployed. Patching remains an essential step.
Why only the update helps
There are numerous workarounds for PHP2Shell circulating, such as disabling individual PHP features. While these reduce the risk, they do not fully eliminate the vulnerabilities. Therefore, the PHP project explicitly states that the update is the only complete fix (PHP Foundation).
“Workarounds and configuration changes can help, but they are no substitute for an update,” says Desler. “Anyone who merely tweaks settings remains vulnerable.”
Furthermore, the PHP runtime itself is affected. Therefore, updating WordPress, Typo3, or other applications is not enough. Older, unsupported versions, including PHP 5, are also vulnerable.
How many websites are affected?
The commonly cited figure of 70 percent describes the percentage of websites that use PHP, according to W3Techs. The number of vulnerable websites depends on the version used, the server setup, and the patch status. Desler considers a range of 30 to 40 percent to be more realistic. This number is currently falling because most major hosting providers have updated their systems. However, self-managed servers, containers, appliances, and legacy systems remain critical.
What operators should do now
The key point first: the flaws are in PHP itself. Updating your CMS or application alone will not fix them.
- Identify all PHP systems. PHP often runs in more places than expected, such as containers, appliances, internal tools, and admin panels. For Linux distributions, check the package changelog to see if the CVE numbers have been fixed. However, the version number alone can be misleading because distributions often backport fixes to older versions.
- Patch immediately. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or to your vendor’s patched package. Then, restart all PHP processes so that the update takes effect. PHP 8.1 and older versions no longer receive official updates. These systems should quickly be moved to a supported version.
- If patching is delayed, reduce your attack surface. Restrict access to affected systems, for example, by using allowlists. A WAAP blocks known attack patterns and buys time. Although configuration changes lower the risk further, they do not replace the update. Systems that cannot be patched or secured must be taken offline temporarily.
- After patching, strengthen your defenses. The update introduces a fixed memory limit. Check that your memory settings suit your applications to avoid outages. Also, review your logs from at least October 17 because a patch does not undo an existing compromise. Warning signs include repeated memory errors, unexplained server errors, and restarts of PHP processes.
If you use a hosting provider, check whether the fix has been installed or is only scheduled. With managed hosting, the provider is usually responsible for the update. For self-managed servers, virtual machines, and containers, responsibility lies with the operator.
AI is changing the pace
PHP2Shell was discovered with the help of AI. The bug had gone undetected in the code for over ten years. Since July, the PHP security team has published 15 CVEs.
“PHP2Shell won’t be the last vulnerability of this kind,” says Desler. “AI tools are now finding bugs that have lain undetected in the code for years – and that applies to defenders and attackers alike.”
For companies, this means the time between disclosure and a working exploit will continue to shrink. This makes an up-to-date software inventory, short patch cycles, and a protection layer that responds to attacks in real time all the more important.
