Wazuh Walkthrough Detects PHP2Shell Exploitation Attempts and Guides Patching

Summary

A Wazuh walkthrough shows how to identify vulnerable PHP packages, check partial mitigations, and alert on PHP2Shell indicators. It recommends fixed PHP releases as the only complete fix for CVE-2026-109618 and CVE-2026-109619.

Key points

PHP advisories describe two critical memory-corruption vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can enable unauthenticated remote code execution; each has a CVSS 4.0 score of 9.2.
PHP lists fixed releases 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The article says updating to a fixed release is the only complete fix.
The Wazuh walkthrough monitors Apache error logs, auditd events, and web-root file changes, and adds rules for memory-exhaustion errors, worker crashes, commands run by www-data, and new or modified PHP files.
Wazuh vulnerability detection identifies affected PHP packages, while a custom Security Configuration Assessment policy checks selected temporary mitigations.
The article says the vulnerabilities have reportedly been exploited in the wild since October 21, 2026; it cautions that missing relevant log entries do not prove a server is safe.
Disabling session upload progress and, on PHP 8.5, fatal error backtraces can partially mitigate CVE-2026-109619. These settings do not address CVE-2026-109618.

Article Details

Defense Focus: Detect PHP2Shell exposure and exploitation attempts by assessing vulnerable PHP packages and mitigations, monitoring error and audit logs, and identifying suspicious web-root file changes.
Detection Methods: Use Wazuh vulnerability detection to identify vulnerable PHP packages.
Use a custom Security Configuration Assessment policy to check PHP mitigation settings.
Alert on PHP memory-exhaustion and maximum-execution-time errors in Apache logs, and correlate repeated memory-exhaustion errors from the same source IP.
Monitor commands executed with effective UID 33, used by the www-data account.
Use real-time file integrity monitoring to detect new or modified PHP-related files in the web root.
Monitor Apache worker segmentation-fault alerts as possible exploitation indicators.
Data Sources: Apache HTTP Server error logs
Linux auditd logs, including execve events
File integrity monitoring events for the web root
PHP package inventory and vulnerability data
PHP configuration files checked by the SCA policy
Rule Types: Custom Wazuh XML rules with PCRE2 regular expressions and event correlation
Linux auditd syscall rules for execve events by effective UID 33
Wazuh Security Configuration Assessment YAML policy
File integrity monitoring rules for new or modified PHP-related files
Platforms: Ubuntu 24.04 Linux endpoint running Apache HTTP Server with mod_php
Defensive Actions: Update PHP to a fixed release; the article identifies PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, or use the fixed package version specified by the distribution.
Until updating, disable session.upload_progress.enabled; on PHP 8.5, also disable fatal_error_backtraces.
Limit request-body size and multipart structure at a reverse proxy or web application firewall; treat memory_limit=-1 as a partial mitigation with denial-of-service tradeoffs.
For PHP-FPM, consider pm.max_requests = 1 as a partial risk-reduction measure, accounting for the added worker-startup overhead.
Review adjacent conf.d configuration and Apache php_flag directives because they can override the main php.ini settings.
Inspect web-root directories for newly created web shells after suspected exploitation.
Tune detection rules to account for legitimate applications that exhaust memory or run programs as www-data.