Date: October 21, 2026
Severity: Critical | CVSS 4.0: 9.2
Vulnerabilities: CVE-2026-109618 and CVE-2026-109619
Summary
The PHP development team has released emergency security updates for two critical vulnerabilities that could allow unauthenticated attackers to execute code on vulnerable web servers.
Known collectively as PHP2Shell, the vulnerabilities affect PHP installations serving web requests and could lead to server compromise, sensitive data exposure, or service disruption. Security researchers have reported active exploitation attempts.
Organizations running PHP should prioritize remediation immediately rather than waiting for their next routine maintenance window.
PHP powers a wide range of websites, content management systems, e-commerce platforms, and business applications, including WordPress, Drupal, and Joomla. If your organization operates or hosts websites and applications using PHP, assess your exposure now.
What you need to know
| Item | Details |
| Vulnerabilities | CVE-2026-109618 and CVE-2026-109619 |
| Impact | Unauthenticated remote code execution, potentially resulting in server compromise, data exposure, or service disruption |
| Severity | CVSS 4.0 score of 9.2 for both vulnerabilities |
| Affected environments | PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed |
| Fixed releases | PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 |
| Exploitation status | Active exploitation attempts reported by security researchers |
The vulnerabilities involve two distinct attack paths: out-of-memory corruption and stale internal state following memory deallocation. Apache deployments using mod_php have been identified as carrying particularly high demonstrated risk.
Who is affected?
Any organization operating vulnerable PHP installations should investigate, including those running:
- Public-facing websites, e-commerce platforms, and content management systems.
- Custom PHP applications, APIs, and business-critical web services.
- Third-party products, managed hosting environments, and devices that embed PHP.
PHP 8.1 and earlier no longer receive standard security updates directly from the PHP project. Some distributions and long-term support vendors may provide backported fixes. Confirm the status of your specific deployment with your vendor.
Recommended actions
1. Prioritize patching
PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix both critical vulnerabilities. All PHP users are strongly encouraged to update immediately.
We recognize that organizations may not be able to patch immediately because they need to test changes, validate application compatibility, and assess dependencies. Establish an expedited remediation process, prioritize internet-facing systems, and avoid unnecessary delays.
2. Inventory and assess exposure
Identify PHP installations across production environments, prioritizing internet-facing servers and applications. Confirm the PHP version, deployment configuration, hosting provider, and availability of an approved security update.
3. Verify third-party remediation
Contact hosting providers, managed service vendors, and software suppliers to confirm that affected PHP components have been updated or that an appropriate vendor-supported fix is available.
4. Investigate potential compromise
Review relevant PHP and web server logs, processes, files, and outbound network traffic for suspicious activity. Prioritize systems that remained exposed after disclosure. Preserve relevant evidence if compromise is suspected.
5. Apply interim protections if immediate patching is not possible
Important: The following measures reduce exposure to specific attack paths but do not make an installation safe. Only applying the appropriate security update is a complete solution. Have qualified security and infrastructure teams assess these changes before implementation.
A. Remote code execution via out-of-memory (OOM) corruption — CVE-2026-109618
- Remove the controllable PHP memory limit failure: Set memory_limit=-1, preferably through configuration applications cannot override, such as php_admin_value in the PHP-FPM pool or Apache configuration. Verify that no pool, directory, or application setting reintroduces a finite limit. Underlying allocation failures can still reach the vulnerable code path.
- Limit request and upload sizes: Set a low post_max_size. For applications that do not require file uploads, use post_max_size = 8M. Where uploads are necessary, use post_max_size = 32M. Keep upload_max_filesize below post_max_size.
- Enforce additional request limits: Where practical, configure the web server or proxy to limit decoded request size, input field count, multipart part count, header count, and nesting depth. Ensure these controls also cover requests without a usable Content-Length.
- Set availability boundaries: Use container or cgroup limits, preferably with a policy that terminates only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
B. Remote code execution via stale global state — CVE-2026-109619
- Disable session upload progress: Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, PHP-FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks confirmed session-based paths but not other variants.
- For PHP 8.5, disable fatal error backtraces: Set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
- Remove problematic per-request settings: Correct invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics through error_reporting, display_errors, or the @ operator does not address the issue.
- Address attacker-reachable fatal errors and timeouts: Review and fix relevant failures in callbacks, upload or import processing, and cleanup routines.
These are interim risk-reduction measures, not substitutes for patching. Configuration changes must be validated against the application’s requirements and deployment architecture.
6. Review legacy systems and embedded PHP
For unsupported PHP versions, confirm whether the operating system or vendor provides a backported security fix. If no suitable fix is available, plan an upgrade or migration. Until remediation is possible, assess temporary isolation from the internet and restrict access to affected systems.
For IoT devices or products that embed PHP, contact the vendor about available updates and segment devices that cannot be patched.
How Accorian can help
Accorian helps organizations identify security gaps, assess exposure, validate remediation, and strengthen application security controls.
If your team needs support assessing PHP exposure, prioritizing remediation, or validating security controls, contact Accorian to discuss next steps.
Sources and further reading
This advisory is intended for security awareness and remediation planning. Organizations should consult the official PHP guidance and their software or hosting vendors for deployment-specific instructions.
