In short: The PHP vulnerability PHP2Shell consists of two critical flaws in PHP, the foundation of most websites and online shops. Through them, attackers can execute malicious code on web servers without a password. The BSI (German Federal Office for Information Security) warns at level orange and advises: update immediately, otherwise take affected servers offline temporarily. For management, this means today: clarify responsibility, demand the update and proof of it, decide on a shutdown and document everything.
The situation in three sentences
On 21 October 2026, the PHP project released updates for two critical security vulnerabilities known as PHP2Shell. PHP itself is affected, not a specific product, so potentially every website, shop and portal that runs on PHP. The BSI has declared warning level 3 / orange, security companies report attack attempts, and confirmed successful attacks on a broad scale were initially not known according to the BSI.
According to media reports, authorities such as the BKA (German Federal Criminal Police Office) and several cities took their websites offline as a precaution. That was caution, not a sign of an attack.
What the PHP vulnerability means for management and companies
The question is not whether you use PHP. Almost every company does so somewhere: website, shop, applicant portal, customer area, intranet, ticketing system, agency microsite. The question is whether these systems are up to date and who is responsible for them.
If an attack succeeds, in the worst case the attacker can take over the server. Possible consequences are data leakage, manipulated content, redirects to fraud sites, a shop outage or misuse of the server for further attacks. If personal data may be affected, reporting obligations are added; the deadline under Art. 33 GDPR is generally 72 hours. Details are under GDPR reporting obligation. This is not legal advice.
What costs typically arise in a worst case is put into context by the article Cost items of a hack.
Where PHP is often overlooked in companies
Most people keep the main website in view. Systems at the edge are more likely to be overlooked: the applicant portal from an external provider, the landing page from a past campaign, a partner area for resellers, the support ticketing system, a file cloud on your own server or the web interface of a network storage device. Test systems run by agencies are also often publicly reachable and run on the same server as the real website.
For management the lesson is simple: the question to IT is not "Is our website patched?" but "Are all our systems with PHP patched, including those of service providers?" The difference between the two questions is often exactly the spot where an attack succeeds.
What the situation is not
An assessment in the other direction is just as important. PHP2Shell is no reason for actionism that disrupts operations more than necessary. Anyone who has patched with proof, restarted all PHP processes and finds nothing unusual in the check can return to normal operations. A temporary shutdown is an option for unresolved cases, not an obligation for all.
Five questions for your IT team or service provider
You can ask these questions today. The answers should come in writing.
- Which of our systems run on PHP? A list with address, purpose and operator.
- Is every system patched? Fixed version 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a backport confirmed by the vendor.
- Were all PHP processes restarted? Without a restart the update has no effect.
- What about systems on PHP 8.1 or older? There are no official updates for them. What is the plan?
- Has anyone checked whether anything happened before the update? Logs from 20 October preserved, traces searched for?
If your website is with a hosting provider, a formal request helps. A template is offered by the guide Requesting hosting provider PHP update confirmation.
The decisions that should be made today
| Decision | Options | Basis |
|---|---|---|
| Who leads? | one responsible person internally, an external partner | responsibility must be unambiguous |
| Unpatched systems | patch immediately, interim measures, shut down temporarily | BSI recommendation, data situation, revenue relevance |
| Check for traces | internal, external, only if anomalies appear | protection needs of the data on the server |
| Communication | inform internally, prepare customers, wait | situation after the check |
| Legacy systems | plan migration, isolate, shut down | PHP 8.1 and older without official updates |
Record who decided what and when, and on what information. A short, dated note is enough. Afterwards, it is often worth more to insurers, customers or supervisory bodies than any explanation after the fact.
Why this documentation matters for the management is explained on the page Management liability for IT security vulnerabilities. This is general information and not legal advice.
What you should not believe
Managing directors often hear three statements at the moment, and all three are wrong:
- "We updated WordPress, so we are safe." The vulnerability is in PHP, not in the CMS. A CMS update does not close it.
- "We are too small, nobody will attack us." Attacks run automatically. They look for vulnerable servers, not for known names.
- "The update is installed, so the matter is settled." A patch does not remove malware that was planted beforehand and does not prove that nothing happened.
How does PHP SOS help?
- Situation overview for management: We prepare a short overview of your PHP systems with status and recommendation for each system.
- Implementation: We patch, restart or apply interim measures where an update is not yet possible.
- Check: We preserve logs and check for traces of an attack.
- Proof: You receive documentation that you can use internally and towards third parties.
The process is described on the page PHP2Shell immediate help.
Conclusion
PHP2Shell is a technical vulnerability with a management task attached. Specialists take care of the technology. Management makes sure that someone is responsible, that the five questions are answered and that decisions are made deliberately and documented. That fits into one morning if it starts today.
Frequently asked questions
Does management have to deal with PHP2Shell itself?
Not the technical implementation, but the steering, yes. Management should ensure that responsibilities are clear, that the BSI recommendation is implemented and that decisions such as a temporary shutdown are made deliberately and documented.
How do I explain the vulnerability in one sentence?
In PHP, the software on which most websites and shops run, there are two critical flaws through which strangers can start programs on the server without a password; an update is available and must be installed.
What does it cost to do nothing?
That cannot be put into a flat figure. Possible consequences of a successful attack are downtime, data leakage, reporting obligations, effort for cleanup and forensics, and loss of customer trust. An update with a check is generally far less effort.
Is it enough if the hosting provider takes care of it?
With shared hosting, the hosting provider generally installs the update. Have this confirmed in writing, including the restart of the PHP processes. The confirmation does not answer whether anything happened before the update; that requires a check of the website.