PHP Security Vulnerability Also Affects WordPress Websites

On October 21, 2026, a striking number of websites went offline. The city of Mainz shut down its portal, Berlin's Charité hospital took its website offline, and universities, the fire department and banks were also unreachable for a while. By October 23, almost all of the websites that had been shut down as a precaution were reachable again, including those of ministries, authorities and the Charité, according to the German news agency dpa (t-online). That does not mean the issue is over. Every website without the update remains vulnerable, and according to dpa, the wave of automated attacks is expected to continue for weeks and months (Tagesspiegel).

Behind it all is not a single hacker attack, but a security vulnerability in PHP. A large share of all websites runs on this technology, including every single WordPress website.

What happened with the PHP2Shell security vulnerability?

When a visitor opens a website, their browser sends a request to the web server where the PHP files are stored. The server recognizes the PHP code, runs the commands it contains and turns the result into plain HTML and CSS code. It sends this finished code back to the browser, which displays it as a page. The original PHP source code stays invisible to the visitor and protected on the server. From simple blogs to news portals and online shops, a large part of the internet works this way.

Two serious flaws were found in exactly this process. On October 21, 2026, the PHP project released an update that fixes both flaws, announced for 4 p.m. German time. All operators were urged to install it immediately (php.net).

Attackers can run their own commands on the server

The two vulnerabilities share the nickname PHP2Shell. Experts track them under the official identifiers CVE-2026-109618 and CVE-2026-109619. Both target exactly the moment when the server processes a request.

Put simply, it works like this. An attacker sends the server a specially prepared request with many nested fields. It is not particularly large, but PHP has to set aside extra memory for every level of nesting. This happens before the actual page even starts. With some server setups, a request to any PHP page is therefore enough, no form is needed. With others, it depends on how the website is programmed. PHP hits its memory limit, stops halfway through and mixes up its own data during the cleanup that follows (Calif). With the second vulnerability, leftovers of a request remain in memory and are picked up again by a later request (php.net).

That mix-up is where the danger lies. Instead of just delivering a page, the server then runs the attacker's commands, without any password and with the same permissions it normally uses to run the website. The area on the server that is supposed to be protected is then open to the attacker. In the worst case, they take over the website, gain access to customer data, forms or passwords, and use the server for further attacks.

Such an attack is not trivial. According to heise online, it often takes several thousand requests. For automated attack tools, however, that is no obstacle. In a video by Calif, foreign commands were running on a server with the PHP framework Laravel after just 38 seconds.

How the flaw came about

The problem is not entirely new. PHP already had a similar vulnerability in 2004 (Calif), and according to the BSI, all known PHP versions are affected, going back to at least PHP 5 (BSI). A developer on the PHP team noticed the flaw as early as 2024. Because no way to exploit it was found at the time and the small team could not agree on a fix, it was left as it was. The PHP Foundation itself now calls this a structural failure (The Next Web).

In 2026, the security company Calif examined PHP from the end of July, specifically with the help of AI, as part of a security program run by OpenAI. On August 11, it reported the vulnerability to the PHP team (Calif).

Why the attacks started exactly now

Until October, only a few parties knew about the vulnerability, such as the discoverers, the PHP team and providers preparing updates. Without a hint, hardly anyone can find a single flaw in PHP's huge codebase. Shortly before the update, this secrecy partly broke down. On October 20, at around 5 p.m. German time, the identifiers of the vulnerabilities began circulating online, but no technical details yet. The PHP team then brought its update forward by one day to October 21 (heise online). That same evening, Calif accidentally published a video of the attack. On October 21, a software provider then made fixed packages available more than six hours before the official date (The Next Web).

With the update, it then became fully visible which part of the code had been repaired. The BSI considered it likely that attackers would use AI tools to exploit the vulnerability on a large scale within a few hours of the update (BSI). Amazon even observed a first attack attempt on one of its own decoy servers on October 17. During the night before October 21, still before the update, the first sample attacks appeared, more followed a few hours after the update, and Amazon now sees broad attack attempts in the wild (AWS Security Blog). Anyone who updated only days later should therefore not assume that nothing happened.

What role AI plays

AI played a role on both sides. On August 19, a good week after Calif's report, the security company Wiz also came across the flaws independently. According to Wiz, it used AI models to track down the vulnerabilities and to test the update (Wiz). Flaws that used to be considered too complicated to exploit suddenly become attackable with the help of AI. But what helps security researchers helps attackers just as much.

For website operators, this mainly means that sometimes only hours pass between a vulnerability becoming known and the first attacks. Security updates should therefore never be put on the back burner.

Why did so many websites go offline?

Operators had taken their sites offline as a precaution until the update was installed. As long as a website is offline, no request from an attacker reaches the server. That was annoying for visitors, but the most sensible decision in this situation.

The BSI advised shutting down if in doubt

Germany's Federal Office for Information Security (BSI) rated the situation as extraordinarily serious with warning level "3 / Orange". Anyone who could not install the update immediately should consider temporarily disconnecting the website from the internet, according to the BSI (Tagesspiegel). Marc Henrichmann, chair of the German parliamentary committee overseeing the intelligence services, called it one of the most serious security vulnerabilities of recent years (Tagesspiegel).

Many organizations followed this advice. According to the German news agency dpa, the websites of the Charité, the Berlin fire department, the Berliner Tafel food bank, the University of Potsdam and the Ernst von Bergmann hospital, among others, were unreachable. The city of Mainz shut down several online services, including its portal mainz.de (Tagesspiegel). According to ZDFheute, the websites of banks and savings banks were also partly offline for a few hours. Online banking itself was not affected because it is built with entirely different technical components.

Shutting down is a precaution, not a sign of an attack

For authorities and hospitals, the trade-off is simple. A website that is missing for a few hours annoys visitors. If attackers get hold of patient data or citizen applications, however, real damage is done. In those days, a site that had been shut down was therefore more a sign of responsibility. Up to October 22, the BSI had not found any cases in which the vulnerability had been exploited. However, the authority could not rule out successful attacks (Tagesspiegel). Sites that simply keep running without the update therefore remain critical.

Which websites are affected by the PHP security vulnerability?

Every website whose server processes requests with PHP and has not yet received the update is affected. That is a great many. According to W3Techs, 69.3 percent of all websites with a known technology use PHP.

Every single WordPress website without a PHP update

The vulnerability sits in PHP itself, not in a particular content management system. A content management system like WordPress is essentially a large collection of PHP files that the server runs every time a page is opened. That is why every system built on PHP is affected. These include WordPress, Typo3, Joomla, Drupal, the learning platform Moodle and many shop systems. According to an expert estimate, WordPress alone powers 400 to 500 million websites worldwide (Tagesspiegel). According to Wiz, every PHP version released in the past ten years is affected by at least one of the vulnerabilities, with PHP 5.4 being the oldest affected version (Wiz).

For WordPress operators, this is already the second critical vulnerability within a few months, even though PHP2Shell is not in WordPress itself. In July 2026, WordPress had to close a vulnerability with version 7.0.2 that also allowed attackers to run foreign code (WordPress.org). It became known as wp2shell, and back then the BSI also rated the situation as Orange (IT-Administrator). The difference matters. wp2shell was in WordPress's own PHP files, so a WordPress update helped. PHP2Shell sits one level deeper, in the technology that runs these files. That is why PHP itself has to be updated this time.

Devices at home and in the office, too

PHP also runs in devices you might not think of at first. Many routers, firewalls and network storage devices (NAS) have a settings page that you open in your browser. Behind this page, PHP is often at work as well, as heise online reports for devices from various manufacturers. If you use such devices, you should turn on automatic updates (ZDFheute).

If you only browse the internet, you do not need to do anything on your own computer or phone. The browser only receives finished HTML and CSS from the server, and the PHP code runs exclusively on the server. The vulnerability therefore affects servers, not visitors' devices.

How do you check and protect your website now?

You do not need any technical knowledge for a first website security check. The following three steps show whether your website is affected and what needs to be done.

Step 1: Find out what your website runs on

If your website runs on WordPress, Typo3, Joomla or a shop system such as Shopware or WooCommerce, it almost certainly uses PHP. With WordPress, you can check this yourself. Under "Tools" you will find "Site Health". The "Info" tab shows the exact PHP version in the "Server" section. The "Status" tab does warn about outdated technology (WordPress.org), but according to the documentation it does not specifically warn about missing security updates like the one for PHP2Shell. So compare the version number yourself.

PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or newer are protected against PHP2Shell. If an older number appears there, contact your host or your agency right away. On some Linux servers, the number may look older even though the host has already installed the fix, so ask if in doubt. If you do not know what technology your website runs on, ask them as well.

Step 2: Have the update installed

PHP is installed on the server, not in your website. That is why, with a standard hosting package, the host usually takes care of the update. According to ZDFheute, large providers such as IONOS have already installed it. If your website runs on its own server, your IT service provider or your agency is responsible.

There are interim solutions, such as certain PHP settings or protective filters that intercept suspicious requests. However, the PHP project stresses that there is no complete protection other than the update (php.net). Separately, since October 23 the PHP project has recommended temporarily disabling the setting "session.upload_progress.enabled", even on servers that are already updated. The reason is an additional, separate vulnerability that can only be exploited with an unusual combination of settings and will only be closed with the next regular PHP update. Your host or agency can take care of this too. If the update is not possible right away, the BSI's advice remains to take the website offline for a short time. For PHP 8.1 and older, the PHP project no longer provides regular updates, and some Linux providers ship their own fixes. In the long run, the only solution is switching to a current version.

Step 3: Have someone check whether anyone got in beforehand

The update closes the vulnerability, but it does not remove anything an attacker has already left on the server. Because the first attacks started before the update, Amazon recommends checking for traces from October 17 onward, not just from the day of the update (AWS Security Blog). Servers usually record which requests have reached them. Ask your host or your agency to check these logs for anything unusual. With WordPress, you can also check yourself whether there are any administrator accounts you do not recognize.

We explain how a thorough, professional website security check works in our article How to Close the Biggest Security Gaps on Your Website.

What makes a website secure in the long run?

PHP2Shell will not be the last major vulnerability. Secure websites are therefore not the result of a single update, but of the right technology and clear processes.

Four principles for secure websites

First, as little software as possible should run on the server. Every program and every plugin involved when a page is opened processes the visitor's request and is therefore a potential weak spot. Second, security updates have to arrive within hours, not weeks. With PHP2Shell, the first attacks even started before the update was released.

Third, clear responsibility is needed. In those days, many organizations first had to find out who looked after their website and what technology it ran on. That time is missing in an emergency. Fourth, current backups are part of it, so a website can be restored quickly after an attack. You can read what to look for in a partner for ongoing support in How to Choose the Right Agency for Website Maintenance.

What makes Evelan websites secure

The websites we build at Evelan today follow these principles. This does not just protect against a single vulnerability like PHP2Shell, it makes the whole website less vulnerable:

• No traditional backend on the server: The website runs on Next.js. Content, logins and data are kept separately with the cloud service Sanity. There is no WordPress backend and there are no plugins that attackers could exploit on the web server. Vulnerabilities like PHP2Shell or wp2shell do not affect these websites because neither PHP nor WordPress runs there.
• Ready-made pages from a global server network: The pages are usually converted into finished HTML and CSS in advance and delivered by Vercel, including our own website evelan.de. When a visitor opens a page, the server only sends this finished file. Hardly any code runs in the process that could be attacked. Next.js is not free of vulnerabilities either, though. At the end of 2025, for example, the React2Shell vulnerability had to be closed (Vercel).
• Updates without maintenance stress: At the infrastructure level, Vercel installs important security updates automatically, according to its own documentation (Vercel). Nobody has to update a server in the middle of the night. We also keep the building blocks the website itself is made of up to date.
• Protected content: According to Sanity, it is SOC 2 Type 2 certified for security and GDPR compliant. Access can be controlled precisely via roles, and depending on the plan, Sanity records a version history of changes. In addition, Sanity backs up the database continuously and can restore it to any point within the last 30 days (Sanity).
• Support from a single source: On request, we take care of hosting, operations and updates so that you do not have to deal with them yourself.

Secure technology needs updates too

Still, no technology is invulnerable. On the same October 21, Node.js, the runtime environment of Next.js, also received security updates (Aikido). The difference is who installs it and how quickly. According to its documentation, Vercel installs such Node.js updates automatically when needed, and we keep the other building blocks of the website up to date and republish them as needed. Our comparison Headless CMS vs. Traditional CMS shows how the two approaches differ.

Related Evelan articles

• How to Close the Biggest Security Gaps on Your Website
• Headless CMS vs. Traditional CMS: Which Fits You?
• Website Relaunch as an Investment in the Future

Sources

• https://www.php.net/archive/2026.php
• https://www.heise.de/en/news/php2shell-Critical-flaws-allow-code-injection-in-PHP-11494897.html
• https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html
• https://www.tagesspiegel.de/wirtschaft/dpa-bsi-warnt-und-rat-im-zweifel-zum-trennen-der-server-vom-netz-16184490.html
• https://www.tagesspiegel.de/gesellschaft/medien/dpa-viele-webseiten-wieder-online--aber-noch-keine-entwarnungwas-sie-zur-php-sicherheitslucke-wissen-mussen-16186542.html
• https://www.t-online.de/digital/aktuelles/id_101494558/php-sicherheitsluecke-viele-betroffenen-webseiten-wieder-online.html
• https://www.zdfheute.de/politik/php-sicherheitsluecke-faq-websites-internet-100.html
• https://w3techs.com/technologies/details/pl-php
• https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak
• https://calif.io/php2shell/
• https://www.wiz.io/blog/php2shell-php-rce
• https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• https://wordpress.org/documentation/wordpress-version/version-7-0-2/
• https://wordpress.org/documentation/article/site-health-screen/
• https://www.it-administrator.de/wordpress-bsi-alarmstufe-orange-schwachstelle-websites
• https://www.aikido.dev/blog/node2shell-nodejs-brotli-rce-cve-2026-111497
• https://www.sanity.io/security
• https://vercel.com/blog/resources-for-protecting-against-react2shell
• https://vercel.com/docs/functions/runtimes/node-js/node-js-versions