# PHP2Shell: Critical PHP vulnerabilities – has your website been updated yet?

> Two critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619) can allow code execution on web servers. Here is how to check your website’s patch status with your hosting provider.

- Quelle: https://bezahlbare-webseite.de/en/ratgeber/php2shell-kritische-php-luecke-was-tun/
- Datum: 2026-10-22
- Sprache: en
- Thema: Technik & Sicherheit

On 21 October 2026, the PHP project released security updates for two critical vulnerabilities. Every website running unpatched PHP is affected – including WordPress, Joomla, TYPO3 and Shopware sites. Under certain conditions, attackers can execute code on the server without logging in; with Apache and mod_php, they can do so before your website even loads. Attack attempts are already under way. Check with your hosting provider today whether the update has been installed. As of: 22 October 2026.

## What is PHP2Shell?

PHP runs website code on the server, for example for WordPress and Joomla. Wiz, OpenAI and Calif were among those involved in the PHP2Shell reports. The identifiers are CVE-2026-109618 and CVE-2026-109619. The PHP advisories rate both as critical, with a CVSS v4.0 score of 9.2 out of 10. This describes their severity, not the likelihood of your website being compromised.

The flaws concern memory handling and aborted requests: PHP can continue using data that has not been fully initialised or access memory that has already been freed. Crafted requests can therefore trigger code execution, data leakage or crashes. Up-to-date plugins and strong passwords remain important, but they do not fix these flaws in PHP itself.

PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as deployment types that need checking. With mod_php, an attack before website code executes has been demonstrated. For FPM, the PHP Foundation reports code execution through application paths; the OOM advisory does not yet document a complete exploit for this. For the second flaw, an FPM path has been confirmed under certain application conditions. FPM therefore does not provide a blanket assurance of safety.

According to Wiz, affected versions go back as far as PHP 5.4: at least one vulnerability is relevant in each case. Not every attack works in every configuration. What matters is fixing the PHP runtime actually in use.

## How serious is the risk?

A successful attack can execute code with the permissions of the PHP worker process. Which files or databases it can access depends on those permissions; this does not automatically grant full administrator rights over the server. Wiz also demonstrated the extraction of sensitive process data such as passwords, tokens and API keys. This can put login credentials and customer data at risk, for example.

Cloudflare reports attack traffic linked to the premature disclosure of the vulnerabilities, as well as changes in attack patterns. watchTowr reports active exploitation attempts. CERT-EU recommends immediate updates and, where that is not possible, considering the isolation of publicly accessible applications. The Dutch NCSC has published similar recommendations. The BSI has issued a warning; advisory WID-SEC-2026-4055 is documented at CERT-Bund.

Attack attempts do not yet prove successful breaches. The sources do not provide a reliable total number of compromised systems. The reported attempts make the update urgent; they do not tell us how much time you have before your website is attacked.

## Which PHP versions fix these vulnerabilities?

For unmodified PHP releases, the following minimum versions apply to each branch. Providers can incorporate fixes into older packages: these backports require evidence from the vendor. These details concern the two vulnerabilities, not your website’s overall security.

- PHP 8.5: from 8.5.12.
- PHP 8.4: from 8.4.27.
- PHP 8.3: from 8.3.36.
- PHP 8.2: from 8.2.35. Regular security support ends on 31 December 2026; plan your move to a supported branch.
- PHP 8.1, 8.0 and 7.4 no longer receive regular updates from the PHP project. As an exception, source-code patches and vendor packages are available for these versions. For Linux, Plesk lists corrected builds dated 21 October for 8.1.34, 8.0.30 and 7.4.33. The visible PHP version may stay the same. For cPanel and Ubuntu, the full package identifiers are what matters.
- Some providers also offer backports for older branches: Hetzner reports corrected PHP 5.6 and 7.3 for its web hosting and managed servers. This does not apply to all installations. Without a confirmed fix, you need to arrange an update, a version change or a temporary block on access.

## How do I check whether my website is affected?

With shared hosting, several customers share the server infrastructure; the hosting provider manages the PHP packages. You can often choose the version branch, but cannot install the security update yourself. Ask for confirmation of the status for every domain, subdomain and additional PHP application. A website built by an agency may also be hosted by a different provider.

- WordPress: Tools → Site Health → Info → Server shows the PHP version. A version number lower than those listed above may still have been fixed through a backport. Ask for the package identifier and the corresponding security advisory.
- Plesk: Domains → your domain → PHP Settings → “View the phpinfo() page”. Compare the version and “Build Date” with the Plesk advisory for the specific package. A recent build date on its own does not prove a fix is present. If you do not have access, ask your hosting provider.
- cPanel: Software → MultiPHP Manager shows the version for each domain, provided your hosting provider enables this feature. Check all relevant domains; they may use different PHP versions.
- Hostinger: hPanel → Websites → Dashboard → PHP Info. Hostinger states that a build date of 21 October 2026 or later is sufficient only for its own updated packages. The completion notice for managed hosting is dated 22 October, 06:44 UTC, or 08:44 CEST. VPS customers manage PHP themselves.
- Hetzner reports completion for PHP 7.4 and 8.0–8.5 on its web hosting and managed servers on 21 October at 19:50 CEST, and for 5.6 and 7.3 on 22 October at 06:32 CEST. These provider statements do not automatically confirm the status of self-managed dedicated or cloud servers.
- Other providers: Ask for confirmation for your domain. Not finding a public announcement does not prove that a patch is missing. If you have SSH access, `php -v` shows the command-line version; your website may use a different PHP process.

## What should I write to my hosting provider?

Write to hosting support or the person looking after your website. If your site is hosted elsewhere, the agency should involve the server operator. Copy this enquiry:

“Have CVE-2026-109618 and CVE-2026-109619 been fixed for all PHP versions used by my domains [Domains]? Please confirm the web PHP versions actually in use, the full package/build identifiers, evidence of any backports where applicable, and the activation time and restart of all PHP worker processes. Have the administration interface and PHP webmail also been updated? If anything is outstanding, when will it be fixed, and how will public access be blocked outside PHP until then?”

Ask for evidence relating to the specific package. Running PHP processes must be restarted after the update so that they use the corrected code. A general status announcement does not replace this confirmation.

Website PHP and the panel’s internal PHP must be checked separately. For Plesk, the vendor lists 18.0.81 Update 4 or 18.0.80 Update 11 to fix sw-engine. For cPanel/WHM, the listed versions are 11.110.0.153, 11.134.0.66, 11.136.0.50 and 11.138.0.18. The websites’ PHP packages also need their own updates.

Remember email: cPanel’s internal PHP is also used for Roundcube webmail. An updated website does not confirm that webmail access has been patched. Have the webmail runtime checked separately, including with other panels. The PHP vulnerabilities prove neither that every mailbox has been breached nor that your mail services are secure.

After the update: Get confirmation of the PHP patch status and restart, and check key processes such as login, contact forms and ordering. Check what backups of files and databases are available and whether they can be restored. A backup does not replace the patch. If there are suspicious changes, the person looking after your website should preserve files and logs before cleaning up, investigate the incident and replace affected credentials after the clean-up. A patch alone does not remove malicious code that has already been planted.

## What if an immediate update is not possible?

Discuss temporary isolation with the operator. CERT-EU recommends considering shielding publicly accessible applications until the fix has been applied and verified. A block at the web server or firewall must take effect before PHP; a WordPress maintenance page is not enough. Restricting access to explicitly allowed IP addresses can limit access, but does not fix the vulnerabilities.

For administrators, PHP lists limited interim measures: set `memory_limit=-1` and prevent changes where possible; actual memory exhaustion remains dangerous. Set `post_max_size=8M` if uploads are not needed, or `32M` if they are, and keep `upload_max_filesize` below that. Also limit request size and complexity at the web server or proxy, even without a usable Content-Length. Container/cgroup limits can help maintain availability; `RLIMIT_AS` and `RLIMIT_DATA` are not substitutes. This is not a guide to making unchecked changes in your customer panel.

For additional attack paths: configure `session.upload_progress.enabled=0` before the request is read, for example in php.ini or the FPM pool; `ini_set()` and FPM `.user.ini` are not sufficient. On PHP 8.5, also set `fatal_error_backtraces=0`, then restart all worker processes. The person responsible for maintenance must check incorrect settings, fatal errors that can be triggered, and timeouts. Hiding error messages does not help. These measures do not close every attack path.

Since 21 October at 03:02 UTC, or 05:02 CEST, Cloudflare has offered additional rules even on its Free plan, provided the website uses WAF protection. On paid plans, have the Cloudflare Managed Ruleset checked with “Generic Rules – Anomalous Execution” in Block mode. In the Free Ruleset, the rules are active automatically. The PHP update is still necessary.

## What have we done for our customers?

During our checks on 22 October, we found Plesk PHP 8.0 to 8.5 on our hosting servers with builds dated 21 October, matching the Plesk security advisory. The PHP-FPM processes had been restarted on all servers by the morning of 22 October. We check the administration interface separately.

For websites on our hosting, you do not need to install anything yourself. This explicitly does not apply to websites hosted elsewhere, even if we built or maintain them: the respective operator must confirm the patch status. Please continue to report anything unusual on your website to us.

## Frequently asked questions about PHP2Shell

### WordPress and all my plugins are up to date. Is that enough?

No. Those updates do not fix the flaws in PHP. Some attack paths take effect before WordPress even runs. Ask your hosting provider to update the PHP runtime actually in use and restart the processes. CMS and plugin updates remain important as well.

### My website shows PHP 8.1.34. Have the vulnerabilities been fixed?

The number alone does not answer that. With Plesk on Linux, the corrected build dated 21 October is what matters; with cPanel, for example, it is the EasyApache package 8.1.34-5 for ea-php81. Ask for the corresponding vendor evidence. Regardless of the emergency patch, plan a move to a supported PHP branch.

### How can I tell whether my website has already been hacked?

Unknown users, modified files, unexpected redirects or malware warnings are reasons to investigate, but are not specific evidence of PHP2Shell. Have the person looking after your website check the files and server logs. The absence of anything unusual does not prove that no breach has occurred. This also applies after the update.

### Is my website safe with Cloudflare?

A configured Web Application Firewall can intercept known attack patterns. However, Cloudflare also reports changes in patterns and continues to require the PHP update. A Cloudflare account alone confirms neither your website’s protection nor its patch status.

### I have a static website without PHP. Does this affect me?

If PHP really does not process any web requests, this attack path does not affect the website. However, check PHP contact forms, additional blogs, administration interfaces and webmail separately. The name of a website system or the home page’s file extension is not sufficient evidence.

### Why have such old flaws only been fixed now?

According to the PHP Foundation, the first indications of the OOM problem emerged in 2024. Difficult fixes and organisational bottlenecks delayed remediation. The Foundation now also describes changes to its security work. What matters for you is using corrected packages and replacing outdated PHP branches.

---
Veröffentlicht von bezahlbare-webseite.de — Website im Abo ab 79 €/Monat. https://bezahlbare-webseite.de/