Since 21 October 2026, PHP2Shell has been the topic in every security channel. We briefly summarise what it is, then focus on what actually matters to our customers: how Goldoak Spectacles automatically defended against the attacks, and how we determined for every monitored system whether PHP2Shell was exploited or not.
PHP2Shell in Brief: CVE-2026-109618 and CVE-2026-109619
PHP2Shell is the name for two vulnerabilities in PHP that were fixed on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both are memory bugs in how PHP handles out-of-memory conditions during a request. An attacker needs no login: a single crafted HTTP request is enough to run their own code on an unpatched server or to read memory contents such as passwords and API keys.
Every PHP application reachable from the internet is affected, meaning WordPress, Typo3, Nextcloud, Laravel, e-commerce systems and anything running on PHP-FPM, PHP-CGI or Apache with PHP. PHP 8.1 and older will not receive a fix. Exploitation attempts have been reported since the day of disclosure.
Sources:
The only real fix is updating to a patched version. But the question every company is asking is: what happened in the window between disclosure and patch?
How Goldoak Spectacles Automatically Defended Our Customers Against PHP2Shell
Goldoak Spectacles monitors our customers' servers around the clock with an agent that sees every process start, every file change and every network connection. For PHP2Shell, we rolled out targeted detection rules to all customer systems on the day of disclosure. They trigger as soon as a PHP process does something it never does in normal operation: open a shell, download tools, drop a new PHP file in the webroot, create a cron job or a user account.
Detection alone is not enough. On a hit, Spectacles automatically isolates the affected system from the network. The server stays on and stays connected to our platform, but the attacker cannot go any further: no spread to other systems, no data exfiltration, no ransomware. Minutes pass between detection and isolation, with no human intervention required.
For our customers, this meant that even servers that had not been patched yet did not become an entry point into the company. The patch could be applied calmly instead of in a race against the attacker. And all of this works without an in-house security team, because the rules, the monitoring and the response come from us.
In short: Goldoak Spectacles protects against PHP2Shell by detecting the attack traces on the server and automatically isolating the affected system before a PHP bug becomes a security incident.
How We Determined Whether Our Customers Were Affected by PHP2Shell
Patching closes the door. It says nothing about whether someone was already inside. That is exactly what our customers wanted to know, and exactly what we could answer.
Because Spectacles continuously records all process, file and network events, we retroactively checked every monitored system for the typical traces of exploitation since the vulnerability became public:
- Did a PHP process start a shell or a download tool?
- Were PHP files created or modified in the webroot outside of a deployment?
- Were there unusual outbound connections from the PHP process?
- Were new cron jobs or accounts created?
The result is a clear statement per system: not affected or affected. For unaffected systems, our customers have solid evidence for management, auditors and their own customers. For affected systems, the full chain is available, from request to process to file to connection, as the basis for remediation and, if needed, notification of affected parties and authorities.
Without such a record, all that is left is guesswork. Web server logs might show a suspicious request, but not what happened on the system afterwards. And most logs rotate after a few days.
In short: with Goldoak Spectacles, it can be proven for every server whether PHP2Shell was exploited, because all relevant events since the day of disclosure are searchable.
Frequently Asked Questions About PHP2Shell
Is PHP2Shell dangerous? Yes. The vulnerability is exploitable from the internet without a login, allows code execution on the server and can expose passwords and API keys from memory. It is one of the most critical PHP vulnerabilities in years.
Which PHP versions are safe? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or newer. Anything below is vulnerable, and PHP 8.1 and older will not be fixed.
What do I need to do right now? Patch, then rotate database passwords, API keys and tokens on publicly reachable PHP systems, and check whether an attack already took place in the days before the patch.
How do I find out whether I was affected? Only through a record of what happened on the server: process starts, file changes, network connections. Goldoak Spectacles provides exactly that record and answers the question per system.
Does a WAF protect against PHP2Shell? It helps, but it does not replace the patch. Bypasses of WAF rules have already been observed.
Conclusion
PHP2Shell shows what matters with a critical vulnerability: not just patching fast, but knowing what happened in the meantime, and being certain that a single vulnerable server does not put the whole company at risk. Goldoak Spectacles delivered both for our customers.
Do you run PHP systems and do not know whether they were affected? Get in touch and we will check your systems for traces of PHP2Shell. For an active incident, our incident response team is available around the clock.