【攻击检测规则与迹象排查】PHP 远程代码执行漏洞(CVE-2026-109618、CVE-2026-109619)安全风险通告

06

攻击检测规则与迹象排查

适用场景：nginx + PHP-FPM、Apache mod_php、Apache + proxy_fcgi 等常见部署。  

影响版本：PHP < 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。

检测规则参考链接如下：

• https://gist.github.com/Blevene/472692937d05145d29d17dc3c6edc2a0

攻击针对同一个 PHP worker，通常分两步：

1.ARM（武装）：发送畸形 multipart/form-data POST（超长内容、大量文件字段、超长重复字符文件名），在解析阶段触发内存耗尽（OOM）。错误表现为 in Unknown on line 0 的 fatal，导致 session 等全局状态残留。

2.FIRE（触发）：同源再发一次 multipart POST，利用残留状态造成 UAF，可能导致 worker SIGSEGV，或在成功时返回干净 200 并执行代码。

关键结论：

•不看请求体也能检出（长度 + 状态码 + 错误日志）。

•成功与否必须下沉到进程层判断，HTTP 2xx 不等于成功。

1.确认错误日志位置

php-fpm -i | grep -E 'log_errors|^error_log|fastcgi.logging'
grep catch_workers_output /etc/php/*/fpm/pool.d/*.conf

•nginx + FPM：fastcgi.logging=On → nginx error log；catch_workers_output=yes → FPM 主日志。

•官方 PHP-FPM 镜像默认 log_errors=Off，错误可能只出现在容器 stderr，需额外关注进程层与 access log。

2.确认 PHP worker 运行用户（进程层规则必须用 uid）

ps -o user= -C php-fpm | sort -u
# 常见：33=www-data，48=apache

后续 auditd / Falco 规则请按实际 uid 配置，不要按 pid（worker 会轮转）。

R1·ARM：脚本外内存耗尽 fatal（最高精度，全栈通用）

采集点：PHP error log / nginx error log / Apache ErrorLog / FPM 主日志。

匹配逻辑（token 组合，避免整句匹配，因 display_errors=1 可能被 HTML 包裹）：

"Allowed memory size of" AND "exhausted"
AND ("in Unknown on line 0" OR "in <b>Unknown</b> on line <b>0</b>")

•in Unknown on line 0 是关键判据：正常业务 OOM 会指向具体脚本路径与行号。

•无大文件上传业务的站点可直接视为 critical；有上传业务的站点视为 high。

R2·FIRE：FPM worker 段错误 / 崩溃

采集点：FPM 主日志、kern.log、journalctl -k。

匹配示例：

•FPM：exited on signal 11 (SIGSEGV) 或 exited with code 70

•内核：segfault at ... in php-fpm[pid:

•nginx 伴随现象：upstream prematurely closed connection while reading response header 或 upstream sent unexpected FastCGI record: 3，状态码多为 502（而非 500）。

R3·Access log 关联（无需解密 HTTPS，生产环境最强信号）

仅用请求长度 + 状态码即可。nginx 示例（$request_length 含 body）：

同一 $remote_addr、10 分钟内出现：

•(a) POST multipart 且 $request_length ≥ 2 × memory_limit，返回 5xx → ARM

•(b) POST multipart 返回 502 → FIRE

•(a) 后紧跟 (b) → 高度可疑武装攻击，立即深入排查

单次超长 POST 可能是扫描；AB 成对且多轮重复通常为真人调参攻击。

建议日志格式增加 SID 便于后续关联：

log_format php_sid '$remote_addr [$time_local] "$request" $status$request_length sid=$cookie_PHPSESSID';

Apache（需 mod_logio）：

LogFormat "%a%t \"%r\" %>s %I sid=%{PHPSESSID}C" php_sid

R4·结构指纹（能查看 body 时精度极高）

一次请求中出现数百个文件名由同一字符重复构成、且同名字段数组化的 file part → 几乎可判定为攻击（正常表单不会出现）。

R5·官方缓解项反用作检测（零误报，前提是已加固配置）

ModSecurity 示例（注意：multipart 下 REQUEST_BODY 为空，旧规则永远不触发）：

SecRule ARGS_POST_NAMES|FILES_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" \
  "id:2026106183,phase:2,deny,status:403,log,msg:'PHP2Shell probe'"

R6·post_max_size / max_file_uploads 绕过检测（补丁前视同恶意）

•绕过一：multipart + (Transfer-Encoding: chunked | 无 Content-Length | 代理解码后大小不符)

•绕过二：单 body 内 filename="" 的 part ≥ 10

SecRule MULTIPART_PART_HEADERS "@rx (?i)^content-disposition:.*;\s*filename=\"\"" \
  "id:2026106186,phase:2,pass,nolog,setvar:tx.php_cve_empty_fn=+1"
SecRule TX:php_cve_empty_fn "@ge 10" \
  "id:2026106185,phase:2,deny,status:403,log,msg:'PHP2Shell max_file_uploads bypass'"

R7·PHPSESSID 内存泄露（响应侧）

正常 PHPSESSID 应为 32 位小写 hex（若修改过 session.sid_length / sid_bits_per_character 需同步调整）：

SecRule RESPONSE_HEADERS:Set-Cookie "@beginsWith PHPSESSID=" \
  "id:2026106184,phase:3,deny,status:403,log,msg:'PHP2Shell stale PS(id) leak',chain"
  SecRule MATCHED_VAR "!@rx ^PHPSESSID=[0-9a-f]{32}(?:;|$)"

成功的 FIRE 往往返回干净 200，失败也可能返回 200。因此需结合以下内核/进程痕迹：

1.worker 产生 shell 类子进程（php-fpm 正常几乎从不 exec）

2.无文件执行：memfd_create + execveat(AT_EMPTY_PATH)，表现为 /proc/<pid>/exe -> /memfd:xxx (deleted)

3.worker 向非常规端口/地址外连（C2/stager）

4.延迟崩溃：污染请求返回 200，崩溃落在同一 worker 的后续请求（需按 worker 关联，而非单请求）

5.会话污染：同一 PHPSESSID 反复出现 “Failed to decode session object” + 段错误；或 sess_<sid> 文件体积异常/含非 UTF-8 垃圾。

判定建议：单 SID 24 小时内 ≥3 次 decode 失败 + 一次段错误 → 按已被攻陷处理（删除会话、轮换、进入 IR）

进程层检测示例

Falco（需支持 proc.is_exe_from_memfd 与 memfd_create）：

- macro: php_worker
  condition: (proc.pname startswith php-fpm or proc.pname startswith lsphp or proc.pname in (php, php-cgi))
- rule: PHP worker spawned shell or downloader
  condition: >
    spawned_process and php_worker and
    (proc.name in (sh, bash, dash, zsh, curl, wget, perl, nc, ncat, socat, base64, chmod, chown)
     or proc.name startswith python)
  priority: CRITICAL
- rule: PHP worker fileless exec from memfd
  condition: spawned_process and php_worker and proc.is_exe_from_memfd=true
  priority: CRITICAL
- rule: PHP worker called memfd_create
  condition: evt.type=memfd_create and evt.dir=< and
             (proc.name startswith php-fpm or proc.name in (php, php-cgi))
  priority: CRITICAL

auditd（按池用户 uid，示例为 33）：

-a always,exit -F arch=b64 -S execve,execveat -F euid=33 -k php-child
-a always,exit -F arch=b32 -S execve,execveat -F euid=33 -k php-child
-a always,exit -F arch=b64 -S memfd_create -F euid=33 -k php-memfd
-a always,exit -F arch=b32 -S memfd_create -F euid=33 -k php-memfd

先建立基线：部分环境会合法调用 sendmail、图像处理工具等。

1.错误日志：grep 'Unknown on line 0' + grep 'exited on signal 11'，按源 IP / 时间窗对齐，确认 ARM/FIRE 是否成对。

2.Access log：查找同 IP 的异常长度 multipart POST 与 5xx/502，观察是否多轮重复。

3.进程：ps -ef | grep -E 'php-fpm' 检查是否有 shell/curl/wget 子进程；ls -l /proc/*/exe 查找 memfd:。

4.网络与崩溃：ss -tp | grep php-fpm 查外连；journalctl -k | grep segfault；coredumpctl list php-fpm。

5.会话：定位单个 SID 的重复 decode 失败。

6.任一出现 exec / memfd / 异常外连 → 按已入侵响应（worker 进程内存是现场，不要只删 webshell）。

7.无论结论，立即升级到 PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 并重启所有 worker。

•依赖 payload 字节签名或单请求字节偏移：填充无意义且偏移随编译变化。

•仅做限速：一发即可完成 ARM，FIRE 紧随其后。

•使用 REQUEST_BODY "@contains PHP_SESSION_UPLOAD_PROGRESS"：multipart 下 REQUEST_BODY 为空，永不触发。

•不要使用 RLIMIT_AS / RLIMIT_DATA（ulimit）作为缓解：官方明确会诱发分配失败，反而助攻；可用性边界应使用 cgroup/容器限额。

0.打补丁 + 重启 worker（唯一根治）；

1.未打补丁时：设置 session.upload_progress.enabled=Off + 启用 R5 检测规则；

2.部署 R1 + R2（错误日志 + FPM 崩溃）——精度最高、无需 body；

3.部署 R3 access log AB 关联（并给日志加 SID）；

4.补充 R6 绕过检测 + R7 cookie 泄露检测；

5.部署进程层监控（Falco / auditd）——唯一能确认“成功”的一层；

6.边界 Suricata 结构规则（需 TLS 终结点）。