Summary
- Researchers documented 35 successful shell sessions across three controlled honeypots.
- The observations concern a specific vulnerable Apache and PHP configuration.
- The evidence does not establish 35 compromised businesses or widespread production exploitation.
Attackers have successfully executed shell commands against vulnerable PHP servers monitored by security researchers, providing evidence that the critical PHP2Shell vulnerabilities are being exploited beyond unsuccessful probing and service disruption.
The findings concern CVE-2026-109618 and CVE-2026-109619, vulnerabilities in the widely deployed PHP runtime that can permit unauthenticated remote code execution under affected conditions. Earlier reports had documented scanning, crashes and attempted exploitation, but the evidence of completed command execution was more limited.
Security researcher Adel Karimi, identified in contemporary reporting as Detection and Response Lead at Perplexity, monitored honeypots running Apache mod_php with an affected PHP 8.4 release. Initial activity produced memory exhaustion and worker failures without proving that the attacker obtained a working shell.
On 24 October, the monitoring environment recorded 35 shell sessions across three honeypots. The recorded activity involved two originating IP addresses, with one accounting for most of the sessions. The findings concerned research infrastructure configured specifically to observe attempts against vulnerable systems.
The evidence included memory disclosure followed by command execution, allowing the researcher to distinguish a completed attack sequence from requests that merely resembled exploitation. The result changes the evidential assessment of the campaign, but its scope remains constrained.
Thirty-five shell sessions do not equal 35 compromised companies, and the reported tests do not establish equivalent results across unrelated configurations. The honeypots employed a particular Apache and PHP combination, with a deliberately limited worker arrangement intended to expose the underlying behaviour.
PHP vulnerabilities can behave differently depending on request handling, memory layout, protective settings and the surrounding application. A request that crashes one server may fail against another or require substantially different conditions to achieve execution.
The PHP project released emergency security updates on 21 October after the coordinated disclosure schedule was accelerated. The affected flaws involve memory management and exceptional control flow, creating conditions that may allow an attacker to interfere with internal process state.
They have implications beyond standalone websites because PHP is also incorporated into management portals, supplier-maintained applications and services embedded within infrastructure equipment. The reach of an attack depends on whether the vulnerable component can process attacker-controlled requests.
UK organisations have already experienced operational disruption while responding to the PHP2Shell warnings. Cyber Insider reported that government services were taken offline as a precaution, and separately covered the regulator's warning to communications operators.
Those earlier interruptions should not be reinterpreted as confirmation that the named government systems were compromised. The latest observation concerns successful attacks recorded by a researcher against controlled honeypots, not confirmed intrusions into UK public services.
The distinction affects incident reporting and risk assessment. Large volumes of malicious traffic show attacker interest, but a successful compromise requires stronger technical evidence, such as execution traces, subsequent authenticated activity or changes on the affected host.
Operators investigating their exposure need an accurate inventory of installed runtimes, supplier-managed components and reachable application interfaces. A central operating-system update does not necessarily replace PHP bundled within independently maintained software or equipment.
Where applications are supplied by vendors, the availability of supported builds and backported fixes may be more important than the release of the upstream runtime update. Older applications may also require careful testing before a newer PHP branch can be deployed.
The distinction also changes what investigators can infer from network telemetry. An outbound connection, a scanner signature and a process crash may each indicate malicious activity, but only a trace of the completed execution chain establishes that attackers achieved the claimed capability in the observed environment. Consequently, the most reliable new finding is the existence of working shell access in the research deployment, not a global estimate of affected businesses.
The published honeypot investigation did not report downstream malware installation during the recorded sessions. It demonstrates a working attack against a known vulnerable environment, while the identity of any additional victims and the extent of subsequent compromise remain unconfirmed.
