What it is about
On 21 October 2026, the PHP project released out-of-band security updates. They fix two serious flaws that have become known as PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both allow attackers to run code on a web server without logging in, with the privileges of the web server process. Each is rated 9.2 out of 10 (CVSS v4) (php.net).
PHP powers a large share of the web – from WordPress and online shops to bespoke customer portals. That is why the flaws also affect many businesses that are not even aware they run PHP.
The situation on 28 October 2026
- Exploitation: According to Datadog, AWS reported exploitation attempts from 17 October – before the flaws were made public. Since then, attackers have been scanning widely for vulnerable servers (Datadog Security Labs).
- CISA: The US Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities (KEV) catalogue on 26 October (CISA). US federal agencies must patch by 29 October.
- Exploits: Rapid7 reports that public proof-of-concept exploits so far work only for specific combinations of operating system, PHP version and web server (Rapid7). You should not rely on that.
Affected versions and set-ups
The flaws are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. All earlier versions of these branches are affected.
- PHP 8.1 and older no longer receive official releases. For 7.4, 8.0 and 8.1, only source-code patches are available; whether your Linux distribution or hosting provider applies them has to be checked case by case. How far back the flaws go is not yet settled – some sources mention versions as old as PHP 5.4. Anything older than 7.4 gets no fix at all: the only option is to upgrade.
- Server set-ups: Every PHP installation that handles web requests is affected – Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest risk, as the attack works there before any application code runs.
- A note on PHP 8.2: this branch reaches end of life on 31 December 2026. If you update to 8.2.35 now, plan the move to 8.3 or later at the same time.
Workarounds do not cover everything
The setting session.upload_progress.enabled=0 is often recommended as a quick fix. However, it only blocks known attack paths for CVE-2026-109619, not CVE-2026-109618. Conversely, memory_limit=-1 only blocks the known path for CVE-2026-109618 without removing the root cause. The PHP team is clear: these measures reduce the risk but do not make an installation safe. The only complete fix is to update (php.net).
On 23 October, the PHP project also announced a further flaw, CVE-2026-115560. It requires an unusual configuration and is considerably less urgent. Here too, session.upload_progress.enabled=0 is recommended for now; the full fix is due with the next regular release.
Where PHP runs in your business
- your company website, for example on WordPress, TYPO3, Joomla or Drupal
- online shops such as WooCommerce, Shopware or Magento
- an intranet, wiki or ticketing system on your own server
- customer portals, booking and appointment systems
- hosted industry solutions and web applications run by external providers
If your website is hosted, your provider is usually responsible for the PHP version. Still, ask whether the updated version is already in place – and check whether you have selected an older PHP version yourself in your hosting control panel.
Checklist: what to check now
- List every system running PHP, including test and legacy systems
- Check the PHP version the web server actually uses, not just the command-line version
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart all PHP processes
- Ask hosting and software providers to confirm their patch status in writing
- Review logs back to 17 October: unusual multipart uploads with
PHP_SESSION_UPLOAD_PROGRESS, “Allowed memory size … exhausted” errors in “Unknown on line 0”, crashing web server processes - Check file integrity: new or modified PHP files in the web root, unknown user accounts, scheduled tasks
- If you suspect a compromise: isolate the system, rotate credentials (database, API keys, admin accounts) and restore from a clean backup
Bear in mind that clean logs do not prove nothing happened: according to Datadog, a successful attack can return a normal response and leave the process running.
How IT United can help
We work with you to find out where PHP runs in your environment, install updates or coordinate with your hosting provider, and review logs for signs of an attack where needed. In the long run, updates like these belong in structured managed IT with patch management and monitoring – see also IT security.
Not sure whether your website or portal is affected? Get in touch for a free initial consultation – we will clarify it quickly and without fuss.
