入侵排查与响应

我被攻击了吗？

没有一条规则能覆盖所有变种，而且有漏洞的代码运行在你的应用之下，应用日志可能什么都看不到。这些信号用来确定排查优先级——不能用来证明系统安全。

最后核实 2026-10-22

没有信号不代表安全

内存泄露路径可以在服务器上不执行任何代码的情况下窃取机密。不管排查结果如何，都要打补丁。

值得调查的信号

信号	为什么重要	去哪里看
multipart POST 之后紧接着出现内存上限致命错误	内存耗尽是一种触发条件。CVE-2026-109619 还存在不依赖 OOM 的路径，缺少 OOM 错误不能排除该漏洞。	PHP / FPM 错误日志 + Web 访问日志
同一客户端短时间内大量 HTTP 500	利用需要多次尝试来适配目标的内存布局。	访问日志
worker 因 SIGSEGV / SIGABRT 崩溃，或 worker 异常频繁地重启	失败的释放后使用尝试往往会让 worker 崩溃。	FPM 日志、Apache 错误日志、dmesg / journal
响应中出现异常长或经过百分号编码的 PHPSESSID	内存泄露路径会把泄露的堆内存 URL 编码后写入会话 Cookie——即使网站从未调用 `session_start()`。	记录了 Set-Cookie 的反向代理 / CDN / WAF 日志（默认访问日志里没有）
Web 根目录出现新的 .php 文件，PHP 用户启动了意外的子进程	典型的入侵后行为：Webshell、curl / wget、由 www-data 发起的反弹 shell。	文件系统、EDR、进程审计

正常的 PHPSESSID 很短，由字母数字组成（默认 32 个字符）。出现几百个字符或 %xx 字节序列就不正常了。

搜索日志

路径为 Debian / Ubuntu 默认值，请按你的系统调整；至少覆盖 2026 年 10 月初以来的时间段。

shell

# 1. Memory-limit fatals (PHP's exact message)
sudo grep -rh "Allowed memory size of" /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ /var/log/nginx/ 2>/dev/null | tail -50

# 2. Workers killed by signals
sudo grep -rhE "exited on signal (6|11)|exit signal (Segmentation fault|Aborted)" \
  /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ 2>/dev/null | tail -50
sudo journalctl --since "2026-10-01" | grep -E "php.*segfault" | tail

# 3. Clients producing many 500s on POST (combined log format)
sudo awk '$6=="\"POST" && $9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | sort | uniq -c | sort -rn | head -20

打补丁后，新的硬内存限制也可能让 worker 突然退出。单个 worker 退出不能证明遭到攻击——要看是否集中出现在同一客户端或同一类请求上。

在代理层捕捉内存泄露

nginx + shell

# Temporary: log Set-Cookie on responses to spot oversized PHPSESSID values.
# This writes session IDs to disk — restrict the file and remove it afterwards.
# In the http {} block:
log_format php2shell '$remote_addr [$time_local] "$request" $status "$sent_http_set_cookie"';
# In the server {} block:
access_log /var/log/nginx/php2shell.log php2shell;

# Then, from a shell, look for long or percent-encoded session cookies
grep -E 'PHPSESSID=[^;"]{64,}|PHPSESSID=[^;"]*%' /var/log/nginx/php2shell.log

排查入侵后的痕迹

shell

# PHP files changed in the web root since the bugs became known (adjust path/date)
sudo find /var/www -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort | tail -100

# Processes the web user is running right now (shells and downloaders are red flags)
ps -u www-data -o pid,ppid,lstart,cmd | grep -vE 'php-fpm|apache2|httpd'

# Established connections owned by PHP / Apache — review every remote address
sudo ss -tpn state established | grep -E 'php|apache|httpd'

WAF 覆盖情况

托管规则只是打补丁期间的权宜之计。请查看你所用厂商的 PHP2Shell 指引。Cloudflare 已公布规则 ID——见 Cloudflare 页面。

安全厂商的检测规则

如果你在用以下产品，它们的文章介绍了已发布的检测签名和威胁狩猎查询。

AkamaiCritical RCE vulnerabilities in PHP core
ImpervaPHP2Shell vulnerability updates
CorelightPHP2Shell detection
CrowdStrikeProtecting customers from PHP RCE zero-days
Unit 42CVE-2026-109618 / CVE-2026-109619
Cisco TalosTwo critical RCEs in PHP core
watchTowrPHP RCE FAQ: CVE-2026-109618
SansecPHP2Shell: critical PHP RCE

不要在服务器上运行 GitHub 上的 “PoC” 脚本

应将利用工具和扫描器仓库视为不可信代码。公开发布不代表有效或安全；优先使用厂商检查方法，不要在生产系统运行未知脚本。

如果发现了可疑情况

先保全证据：在重建之前复制日志，条件允许的话做磁盘 / 内存快照。
打补丁或隔离主机。优先从干净镜像重建，而不是在原机上清理。
轮换 PHP 内存中可能出现的所有机密：数据库密码、API 密钥、OAuth 客户端密钥、SMTP 凭据、应用密钥（APP_KEY、WordPress salts），以及 PHP 能访问到的 TLS 私钥。
让所有会话失效，使被盗的 Cookie 无法再用，并要求管理员重新登录。
评估影响范围：这些凭据还能访问哪些系统（云账号、内部 API、其他数据库）。