- As of October 21, 2026, 17:00 CEST. Two critical flaws in PHP (CVE-2026-109618 and CVE-2026-109619, severity 9.2 out of 10) let attackers run malicious code on web servers without logging in.
- Updates have been available since October 21, 2026, 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get a fix from the PHP project itself.
- An up-to-date WordPress or up-to-date plugins do not protect you. What matters is the PHP version on the server.
- Websites where the server only delivers finished HTML, CSS and image files offer this flaw no attack surface.
What happened? PHP2Shell in brief
On October 20, 2026, a post appeared on the Hacker News forum announcing two critical flaws in PHP. The post disappeared quickly, but screenshots were already circulating. The security company watchTowr confirmed that the flaws are real and was able to reproduce one of them. The details were actually meant to be published later, together with the updates.
The PHP team reacted the same evening and brought its security updates forward to Wednesday, October 21, 2026, 14:00 UTC. The two flaws carry the identifiers CVE-2026-109618 and CVE-2026-109619, each with a severity of 9.2 on a scale up to 10. Security researchers call them “PHP2Shell”, a nod to the notorious Log4Shell flaw from 2021.
Germany’s Federal Office for Information Security (BSI) issued a warning at level 3 (orange) and expects attackers to exploit the flaws on a large scale within a few hours of the updates being released. BSI Vice President Thomas Caspers put it plainly: there is an immediate need to act. The EU’s computer emergency response team CERT-EU and the UK’s National Cyber Security Centre also advise taking systems offline that cannot be updated right away. According to the German press agency dpa, the city of Mainz took its portal mainz.de and other online services offline as a precaution.
Simply explained: what does PHP have to do with your website?
If you do not work with technology every day, you are right to ask: what actually is PHP, and why does this affect me? A picture from everyday life helps.
Imagine your website as a restaurant. Your visitors sit in the dining room and only see what ends up on the plate: texts, images, your contact form. On most websites, however, each page is only prepared at the moment someone requests it. That happens in the kitchen, and on a great many websites the cook in that kitchen is called PHP. If you use WordPress, Shopware or a similar system, you have this cook in-house, often without knowing it.
PHP2Shell is a flaw in this cook’s training. With a specially crafted order, a stranger can get the cook to hand over control of the kitchen, without any key and without anyone in the dining room noticing. Whoever controls the kitchen can help themselves to everything stored there, or serve the guests something other than planned.
In practical terms, this means: neither you nor your content did anything wrong. The problem lies in the technology your website runs on. That is why a new password will not help. Only an update of that technology will, and in most cases your host or your agency takes care of it.
This is exactly why I build websites as static HTML and CSS pages as a matter of principle. To stay with the picture: every page is prepared in advance and is ready like a buffet that has already been laid out. There is no PHP system, no CMS and no database behind the pages, so there is no cook anyone could trick. That is not only safer, it is also up to date and much faster, because nothing has to be prepared when a page is requested. You can see how I do this under web design & support.
Why this flaw is so serious
Security flaws in websites happen all the time. Most of them sit in a single plugin or theme and only affect the sites that use exactly that extension. PHP2Shell is different: the bugs are in the core of PHP itself, in the technology the website runs on.
According to the official security advisory from the PHP project, all PHP installations that handle web requests are affected, whether via PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The most dangerous setup is mod_php: here it was shown that a single request without any login can trigger the attack, before the website’s own code even runs.
Remote code execution, or RCE, means that an attacker can run their own commands on someone else’s server from a distance. They need neither a password nor access to the admin area. In the worst case, they gain full control over the website and everything stored on the server.
What attackers can do with a hijacked website is well known: steal customer data, spread malware to visitors or quietly create hundreds of spam pages that link to other offers. That last one hits visibility hard. Google flags hacked websites in its search results and reports security issues in Search Console. It can take a while until trust and rankings are back.
Then there is the speed. The BSI expects attackers to analyze the published updates with AI-assisted tools and build working attacks from them very quickly. The gap between update and attack wave is no longer weeks, but hours.
Is your website affected?
The short answer: if your website runs on WordPress, Joomla, Drupal, TYPO3, Shopware, Magento or another PHP-based system, it is affected in principle, as long as the server does not run an updated PHP version. The same applies to contact forms, booking tools or customer areas that work with PHP.
One important point that is often misunderstood: an up-to-date WordPress, up-to-date plugins or a security plugin do not protect you here. The flaw sits one level deeper. The only thing that matters is which PHP version runs on your server.
These versions are patched: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you still use PHP 8.1 or older, you will no longer get an official update from the PHP project itself. For PHP 7.4, 8.0 and 8.1, there are only code fixes for specialists who compile PHP themselves, plus updates from some Linux distributions and commercial vendors. For anything older, the only option is moving to a current version.
If your website is hosted with a provider, the provider usually installs the updates. But you should not assume this has already happened. Check it.
What you should do right now
The good news: for most businesses, the fix is not a major project. These steps take priority today:
1. Check and update your PHP version. Look in your hosting control panel to see which PHP version your website uses and switch to a current one. If you cannot find it there, ask your host directly whether the updates from October 21 have been installed. The PHP project is clear: only the update fully solves the problem.
2. Do not keep outdated versions running. If your site still runs PHP 7 or older, now is the time to move on. Keep in mind that PHP 8.2 will only receive security updates until December 31, 2026.
3. Create a backup. A current backup of your files and database, stored separately from the server, is your life insurance if something goes wrong.
4. Watch for anything unusual. Unknown files, new user accounts, foreign-language pages suddenly appearing in Google or warnings under “Security issues” in Search Console are red flags. Bring in specialists immediately if you see them.
5. If necessary, go offline temporarily. If the update cannot be installed quickly, the BSI and CERT-EU recommend taking affected systems offline until protection is in place. An additional protective layer such as a web application firewall, for example the rules Cloudflare has published for this, can help, but it does not replace the update.
The real problem: every technology needs maintenance
The updates are out, and many hosts are installing them right now. But the real question remains: how much technology does your website actually need?
A classic website with a content management system builds each page only at the moment someone requests it. To do that, PHP, a database, the system itself, a theme and usually a whole series of plugins work in the background. Each of these layers is software, and any software can have flaws. This time it was not a plugin but the foundation. Next time it will be an extension, a form or the system itself again.
For many businesses, this means updates, security warnings and emergency appointments are part of everyday life, even though the content of their own website only changes a few times a month. In my experience, this is exactly where many company websites are out of balance: a lot of moving technology for a website that, at its core, presents information and is meant to win inquiries.
A website with a CMS is like a shop with a main entrance, a delivery door, a basement window and a back door. Every door is useful, but every one has to be locked and checked regularly. A static website is more like a well-lit shop window: everyone sees everything they are meant to see, but there is no door anyone could get in through.
Static websites: where nothing runs, nothing can be attacked
With a static website, each page is built carefully once and then placed on the server as a finished file: HTML for the content, CSS for the design, plus images and fonts. When someone visits the page, the server simply delivers these files. No PHP runs, there is no database and no login area anyone could attack.
For a flaw like PHP2Shell, this means: if no request is passed to PHP, there is nothing an attacker could trigger. The same applies to the typical flaws in plugins, themes and databases. They simply do not exist on a purely static website. If a static site does need a function on the server, such as a contact form, I use a single, lean script instead of a whole system. In that case, the PHP version at the host must of course be current as well, but the attack surface and the maintenance effort are many times smaller.
The security gain is only part of the equation. Static pages are also noticeably faster, because the server no longer has to compute anything. That pays directly into the Core Web Vitals, the metrics Google uses to assess loading speed and usability. You can see how fast a static website can be on my own site:
ctseo.de scores 100 % on Google
Speed is not a nice-to-have. Google treats loading time and Core Web Vitals as a ranking factor, and fast sites keep visitors and win more enquiries. What I deliver for my clients you can see right on this page, measured officially with Google PageSpeed Insights. Even AI agents read and use this page flawlessly, a direct advantage for your visibility in AI systems.
Top scores in Google PageSpeed Insights. Values can vary slightly between measurements, feel free to check for yourself.
On top of that, static pages can be built especially cleanly for search engines and AI systems. A clear structure, structured data and fast response times make it easy for Google, ChatGPT and others to read and understand your content. That is exactly how I build every website for my clients: as a static HTML and CSS site with no PHP system behind it. For company websites, this is the up-to-date approach today: shorter loading times, far less attack surface, hardly any maintenance and designed for search and AI from the very start.
Who the switch is worth it for, and who it is not
A static website is not a cure-all, and I do not recommend it across the board. It is an excellent fit if your website mainly informs and is meant to win inquiries. That applies to most company websites: law firms, medical practices, trades businesses, service providers and consultants.
It is less suitable if your website is essentially an application: a large online shop with a cart and customer accounts, a members’ area or a portal where many people post content every day. These need server-side technology, and consistent maintenance is the right approach there.
When switching, it is important that your existing visibility is preserved. Addresses, content and redirects must be planned carefully, otherwise you will lose rankings you have built up over years. I describe what matters in detail in my article on a website relaunch. A welcome side effect: if you are rebuilding anyway, you can also do without plugins for analytics and cookie banners. I show how that works in my article on cookieless tracking.
Conclusion: patch today, ask the bigger question tomorrow
PHP2Shell is one of the most serious flaws in recent years because it affects the foundation of millions of websites. If your website runs on PHP, only one thing takes priority today: check the PHP version, have the update installed and keep an eye on your site over the next few days.
After that, it is worth taking an honest look at the bigger question: does your website really need this much technology? For many businesses, a lean, static website is the safer, faster and lower-maintenance solution. If you would like to know which technology your site runs on today and whether a switch makes sense for you, I am happy to take a look with you, free of charge.
Frequently asked questions
The easiest way is your hosting control panel, where the PHP version can usually be set per website. In WordPress, the “Site Health” section under “Tools” also shows the version in use. If you are unsure, ask your host or your agency directly.
With classic web hosting, the host usually installs the PHP updates. Often, however, you choose yourself which PHP version your website uses. If an old version is still selected there, your site remains vulnerable, even if the host has long offered newer versions.
No. According to the PHP project, the attack can be triggered before the website’s code even runs. A plugin that is part of this code comes too late. Only an updated PHP version protects you.
The value comes from the Common Vulnerability Scoring System, or CVSS, an international standard for rating security flaws. The scale goes up to 10. Values of 9 and above are considered critical, meaning flaws that should be closed immediately.
Typical signs are unknown files or user accounts, foreign pages appearing in Google under your domain, sudden redirects and warnings in the browser or in Google Search Console. If you suspect something, secure the logs and bring in specialists instead of deleting files yourself.
It can. Google can flag hacked websites in its search results, and injected spam pages dilute the picture of your website. After the cleanup, you can request a review in Search Console. It often takes time, though, until trust and rankings are fully restored.
There is never absolute security. With a static website, access to hosting, the domain and email accounts must also be well protected. But the typical attacks on systems, plugins and databases come to nothing on a purely static site, because that technology does not exist there.
That depends on the solution. On most company websites, content only changes occasionally. For the static websites I build, I take care of changes as part of ongoing support if you wish. That saves you maintaining a system of your own. We clarify together beforehand what fits your day-to-day work.
Yes, if they are based on PHP, for example with WooCommerce, Shopware or Magento. Shops also process customer data and payments, so speed is especially important here. A large shop usually cannot be built as a static site, so fast updates and consistent maintenance are the right approach.
The PHP project maintains each version for a limited time only. After that, there are no more security updates, not even for severe flaws like PHP2Shell. This currently applies to PHP 8.1 and all older versions. PHP 8.2 will receive security updates until December 31, 2026.