PHP released emergency fixes on October 21, 2026 for CVE-2026-109618 and CVE-2026-109619. Both are critical memory vulnerabilities with a CVSS v4.0 score of 9.2. The flaws allow unauthenticated remote code execution on PHP installations that handle web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is greatest with mod_php because exploitation occurs before application code runs.

<agent_config>
  <localfile>
    <log_format>full_command</log_format>
    <command>ps -u www-data -o comm=,args= 2>/dev/null | grep -Ev '^(php-fpm|php-fpm[0-9.]+|apache2|htcacheclean|nginx) ' | grep -Ev 'front/cron\.php' || true</command>
    <alias>web-children</alias>
    <frequency>60</frequency>
  </localfile>
  <syscheck>
    <directories realtime="yes" check_all="yes" restrict=".php$|.php5$|.php7$|.phtml$|.phar$|.inc$">/var/www</directories>
    <ignore type="sregex">/cache/|/_cache/|/sessions/|/_sessions/|/_tmp/|/_log/|/wp-content/upgrade/</ignore>
  </syscheck>
</agent_config>

Fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions published packages on the same day. PHP 8.1 and older versions have no official fix. Running workers must still be restarted after patching, including php-fpm and the web server.

The community contribution describes three Wazuh local rules and one agent group for the period between disclosure and full patch deployment. The setup was tested in production. It does not reliably detect the exploit itself because both vulnerabilities operate before the application and leave no dependable application-log trace. Instead, it watches for processes launched by the web user and for PHP-related files created or changed afterward. The method is intended to cover any remote-code-execution incident on a PHP web server, not only these CVEs.

On October 21, Wazuh CTI did not yet list either CVE, so Vulnerability Detection would not flag an affected agent. NVD had published both entries that day. Ubuntu listed USN-8948 for php8.3 version 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04. Debian listed DSA-6574-1 and DLA-4848-1 for trixie and bookworm. Bullseye, which carries PHP 7.4, had no fix. Neither CVE was in CISA KEV. No indicators of compromise had been confirmed, although an unverified proof of concept was circulating and might contain malware.

The proposed Wazuh setup places only PHP-serving machines in an agent group such as web_php. Central command execution must be enabled with logcollector.remote_commands=1, followed by an agent restart. The group configuration samples processes owned by www-data every 60 seconds. It filters out normal php-fpm, Apache, htcacheclean and nginx processes, as well as the example front/cron.php job. File-integrity monitoring watches /var/www in real time for .php, .php5, .php7, .phtml, .phar and .inc files. Cache, session, temporary, log and WordPress upgrade directories are excluded.

The paths and account names need local adjustments. Debian and Ubuntu commonly use www-data, whereas RHEL derivatives may use apache or nginx. Legitimate jobs running as the web account must be excluded. Applications can keep PHP outside /var/www, such as the Zabbix frontend under /usr/share/zabbix. Wazuh does not follow symbolic links for this monitoring, so the target directory must be added directly.

The local rules use deployment-specific IDs 100972, 100973 and 100976. New IDs should come from the free local range 100000 to 120000. Rule 100972, at level 12, looks for shells, downloaders, network tools, scripting runtimes and similar commands in the web-children process output. It maps the activity to MITRE ATT&CK T1190, T1059.004 and T1505.003. Rule 100973, also at level 12, reports a new PHP-family file below /var/www and maps it to T1505.003. Rule 100976, at level 8, reports a modified file of the same types and asks operators to check whether an update explains it.

The configuration should be tested with GET /cluster/configuration/validation or wazuh-analysisd -t before a restart. The directories in the rules must match the paths in agent.conf. Five operational details matter. The restrict attribute and the sregex ignore pattern are not PCRE, so grouped expressions can fail silently; alternatives must be separated with |. $(agent.name) is not expanded inside a rule description. A first scan establishes the baseline, so files created before real-time monitoring starts do not alert. The agent ignores the command unless remote commands are enabled. In an unprivileged LXC container, inotify-based real-time FIM works, but auditd does not; host-level execve auditing must use the mapped UID, such as 100033 instead of 33.

Alerts 100972 and 100973 should be treated as likely incidents until explained. Operators should inspect full_log for the process and arguments, including patterns such as curl piped to bash, /dev/tcp, nc -e and mkfifo. An unknown process warrants isolating the site through the WAF or firewall. Evidence should be collected before a restart, including web-server and PHP logs, ps -ef, ss -tnp and a VM or container snapshot. Persistence checks should cover new PHP files, the web user’s crontab, new accounts and SSH keys. A confirmed compromise should be reported to the relevant national cybersecurity authority.

For a new PHP file, the application owner should confirm whether an update created it. If not, the file should be checked for eval, base64_decode, system, shell_exec and execution fed by $_POST, without opening it through a browser. Expected false positives include application cron jobs under the web account, PHP mail(), which invokes sh -c sendmail, and CMS or plugin updates that produce many 100976 alerts.

Validation requires group_config_status = synced and an ossec.log entry showing real-time monitoring of the target directory. In logtest, an event using log_format = full_command and location = web-children should match 100972 when it contains a shell, whereas an empty process list should remain at level 0. An end-to-end test can run a harmless command as the web user for longer than the 60-second sampling interval and create an empty .php file in the web root. The team should verify delivery to its dashboard, email or SOAR system and record the test time.

The process check samples only once per minute, so commands that finish within seconds can escape it. Host-level auditd is needed for broader coverage. On IIS, the corresponding signal is w3wp.exe or php-cgi.exe starting cmd.exe or powershell.exe, which requires Sysmon or Windows event 4688 with command-line logging.

Patching and restarting remain the primary response. A newly installed package does not repair workers that are already running. For PHP 7.4 through 8.1, where no official fix is available, affected services should be removed from the Internet and PHP’s partial mitigations should be applied, including session.upload_progress.enabled=0 and memory_limit=-1 through php_admin_* settings. The article also recommends checking WAF routing and SNI filtering because a public-site SNI combined with an internal-site Host header can reach an internal site. Requests from outside the internal network for non-public names should be blocked at the WAF.

The cited material includes the PHP News Archive 2026, the GitHub advisory GHSA-w8hw-w9fx-j79w for CVE-2026-109618, Ubuntu’s CVE-2026-109618 page, the Debian security tracker, and response material from Huntress and Tenable. The rules are an independent community contribution. Wazuh Inc. has not reviewed, validated or endorsed them, and they are not part of the official Wazuh ruleset. They should be tested in each environment before production use.