PHP remains one of the most widely used server-side programming languages, powering websites, content management systems, e-commerce platforms, and business applications. However, October 2026 has brought renewed attention to PHP security after the discovery of two critical vulnerabilities that could allow unauthenticated attackers to execute malicious code on vulnerable servers.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell. Both received a CVSS v4.0 severity score of 9.2 out of 10. The PHP development team released security updates on October 21, 2026, while security researchers subsequently reported exploit attempts and the circulation of proof-of-concept code.
A third issue, CVE-2026-115560, was disclosed on October 23. It concerns a more unusual PHP session configuration and requires separate mitigation.
These developments raise an important question for website owners and IT administrators: are PHP-based websites currently being attacked, and what should organizations do to protect their infrastructure?
1. The latest critical PHP vulnerabilities
CVE-2026-109618: Remote code execution through memory corruption
This vulnerability involves PHP's handling of memory allocation failures during request processing.
Under certain conditions, PHP may encounter an out-of-memory error while internal request data is only partially initialized. Subsequent cleanup operations can then interact with invalid or improperly initialized memory.
If successfully exploited, this memory corruption could allow a remote attacker to execute arbitrary code on the affected server.
Potential impact:
Unauthorized execution of server-side commands.
Compromise of website files and application data.
Exposure of credentials and sensitive configuration.
Further compromise of systems accessible from the affected server.
CVE-2026-109619: Remote code execution through stale global state
The second vulnerability involves internal request state that can remain accessible after the associated memory has been released.
In certain circumstances, a later operation may reuse this stale state before PHP has properly reset it. This can create an opportunity for memory corruption and potentially remote code execution.
The PHP project has identified Apache deployments using mod_php as a particularly concerning configuration because a demonstrated exploit can trigger the issue before application-level code executes.
Potential impact:
Remote compromise of vulnerable PHP services.
Unauthorized modification of website content.
Theft of application secrets and customer information.
Installation of malicious files or persistence mechanisms.
Both vulnerabilities can affect PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
CVE-2026-115560: An additional PHP session-related issue
On October 23, 2026, another potential remote code execution issue was disclosed.
Unlike PHP2Shell's two critical vulnerabilities, this issue requires an uncommon combination of application behavior and PHP configuration. The application must change its session serialization handler at runtime in a particular way, and session upload progress must remain enabled.
The recommended temporary mitigation is to disable session upload progress until the PHP project provides the appropriate fix:
session.upload_progress.enabled=0
Administrators should apply this setting through the appropriate PHP configuration, restart the relevant workers, and verify that the setting is effective. Applications should also be assessed for compatibility before configuration changes are deployed.
2. Are attackers actively exploiting PHP vulnerabilities?
Yes, exploitation attempts have been observed in security researchers' telemetry. However, an attempted attack is not the same as a confirmed successful compromise.
Amazon Threat Intelligence reported detecting a PHP2Shell exploitation attempt on October 17, four days before the vulnerabilities were publicly disclosed. Amazon subsequently observed additional attempts and proof-of-concept exploits targeting its honeypot infrastructure.
F5 Labs also reported PHP2Shell scanning activity before the official public disclosure.
These findings indicate that attackers were attempting to exploit the vulnerabilities around the disclosure period. However, the available reports do not establish that every attempt succeeded or that all vulnerable PHP websites have been compromised.
The Dutch National Cyber Security Centre reported on October 23 that it knew of a possible exploitation incident but had not confirmed that the attack had succeeded. Palo Alto Networks' Unit 42 also clarified on October 25 that it could not confirm that a previously investigated intrusion was caused by these specific PHP vulnerabilities.
The practical conclusion is that PHP2Shell exploitation attempts are occurring, but confirmed successful compromises specifically attributable to these CVEs remain a separate question.
Organizations should not wait for proof of a successful attack before patching.
3. What is currently at risk?
The primary concern is not a single PHP application but the underlying PHP runtime and the infrastructure that depends on it.
WordPress and other content management systems
Websites built on WordPress, Drupal, Joomla, and other PHP-based platforms may be exposed when their underlying PHP runtime is vulnerable.
Updating a CMS or installing a security plugin does not automatically fix a vulnerability in the PHP runtime. Administrators must verify the PHP version used by the actual website.
E-commerce platforms
PHP-based online stores may process customer details, account credentials, orders, and payment-related information. A successful server compromise could expose this data or enable unauthorized changes to checkout pages.
The presence of a vulnerable PHP version does not itself prove that customer data has been stolen.
Custom PHP applications and APIs
Business portals, internal dashboards, customer-facing APIs, and custom applications may also be affected, even if they do not use a popular CMS.
Internet-facing applications deserve particular attention because they can receive malicious requests directly from external attackers.
Hosting providers and shared servers
Hosting environments may run many websites on a common infrastructure. The impact of a compromise depends on isolation, account permissions, PHP execution architecture, and the privileges available to the affected process.
Poorly isolated environments could increase the potential for an attacker to move beyond one compromised website.
4. What could happen after a successful compromise?
A successful remote code execution attack may give an attacker the ability to execute code with the privileges of the vulnerable service. The exact outcome depends on server permissions, isolation controls, and the environment.
Possible consequences include:
Website defacement: Unauthorized changes to pages, images, or website content.
Data theft: Access to customer records, application databases, and configuration files.
Credential theft: Exposure of database passwords, API keys, and other secrets available to the application.
Malware deployment: Installation of malicious scripts or other unauthorized software.
Web-shell installation: Creation of a persistent remote administration mechanism controlled by an attacker.
Cryptocurrency mining: Unauthorized use of server CPU and memory resources.
Further network intrusion: Attempts to access other systems using credentials or network access available to the compromised server.
Business disruption: Website downtime, incident response costs, reputational damage, and possible regulatory consequences.
These are potential attack outcomes, not a claim that every PHP2Shell attack has produced all or any of them.
5. Which PHP versions are affected, and which versions fix PHP2Shell?
The PHP security team released the following fixed versions on October 21, 2026.
| PHP branch | Vulnerable versions | Fixed release |
|---|---|---|
| PHP 8.5 | Earlier than 8.5.12 | 8.5.12 |
| PHP 8.4 | Earlier than 8.4.27 | 8.4.27 |
| PHP 8.3 | Earlier than 8.3.36 | 8.3.36 |
| PHP 8.2 | Earlier than 8.2.35 | 8.2.35 |
These releases address CVE-2026-109618 and CVE-2026-109619. Organizations using older, end-of-life PHP branches should consult their operating-system or hosting vendor for supported security fixes and upgrade guidance.
The additional CVE-2026-115560 requires separate attention because it was not addressed by the October 21 releases.
6. How to protect a PHP-based website
Step 1: Identify the actual PHP runtime
Check the PHP version used by every production website, application, container, and server. A command such as php -v can identify the command-line PHP version, but that version may differ from the runtime used by a web server.
Confirm the version through the hosting control panel, PHP-FPM configuration, container image, or server-management tooling.
Step 2: Apply the appropriate security update
Upgrade to the appropriate fixed PHP release or a newer supported security release. Test the application in a staging environment where practical, then deploy the update and confirm that the production web-serving process uses the patched runtime.
Patching the command-line PHP binary alone is insufficient if the website continues to run an older PHP-FPM pool or Apache module.
Step 3: Mitigate CVE-2026-115560
Review whether the application changes session.serialize_handler at runtime and whether session upload progress is enabled.
Where the relevant configuration and application behavior are present, disable session upload progress as recommended by the PHP project. This is a temporary mitigation for the additional issue, not a replacement for patching PHP2Shell.
Step 4: Review web server and application logs
Investigate unusual POST requests, unexpected upload activity, abnormal HTTP error patterns, and suspicious requests involving PHP session upload progress.
Correlate web logs with PHP-FPM logs, operating-system events, endpoint detection alerts, and process execution records. No single log signature reliably proves or rules out exploitation.
Step 5: Check for evidence of compromise
Look for unexpected PHP files, recently modified application code, unfamiliar scheduled tasks, suspicious child processes spawned by web-server workers, and unusual outbound network connections.
Also review database access, privileged account activity, and changes to application credentials.
If compromise is suspected, preserve relevant logs and evidence, isolate the affected system where necessary, and follow an incident response process. Patching alone does not remove an attacker's existing persistence.
Step 6: Strengthen the hosting environment
Use least-privilege service accounts, isolate websites and containers, restrict unnecessary outbound connections, protect secrets, and maintain tested backups.
A web application firewall may provide an additional layer of defense, but it should not be treated as a substitute for a PHP security update.
7. What should organizations prioritize now?
Organizations should prioritize systems according to exposure and potential impact:
Critical priority: Internet-facing PHP servers running vulnerable versions, particularly environments with higher-risk execution configurations.
High priority: E-commerce systems, customer portals, and applications processing sensitive data.
High priority: Unsupported PHP branches without a verified security backport.
Follow-up priority: Internal applications, test systems, and other assets that may still be reachable from compromised network segments.
Security teams should maintain an inventory of affected assets, record the installed and fixed versions, identify the owner of each application, and verify remediation rather than relying solely on change tickets.
Conclusion
The October 2026 PHP vulnerabilities demonstrate how a flaw in a widely deployed programming-language runtime can affect many different types of websites and business applications simultaneously.
PHP2Shell, comprising CVE-2026-109618 and CVE-2026-109619, creates a serious remote code execution risk for unpatched PHP servers. Public reporting confirms that exploitation attempts and proof-of-concept activity have occurred, while the extent of successful real-world compromise remains uncertain.
The additional CVE-2026-115560 highlights the importance of reviewing application-specific configuration as well as applying core security updates.
For organizations operating PHP-based infrastructure, the priorities are clear: inventory exposed systems, apply the correct security releases, investigate suspicious activity, and verify that vulnerable runtimes are no longer serving production requests.
In cybersecurity, a vulnerability announcement is not merely a development-team concern. It is an operational risk that requires coordinated action from developers, system administrators, hosting providers, and security teams.
