提前缓解 PHP2SHELL

从感觉这次 PHP 漏洞影响会很广继续讨论：

虽然 Cloudflare 大善人贴心地为所有托管在CF上网站都添加了安全规则

今天 PHP2Shell(CVE-2026-109618, CVE-2026-109619) 可以说是安全核弹了。现在谁懂 zhile.io 宕机的含金量了

大家不用太慌，大善人 cloudflare 早就有所动作了：

他们早就为所有使用 Cloudflare CDN 的用户（免费收费都有）提供了紧急托管规则，分别是：

Cloudflare Manage…

但是我的小博客为了走 CN2 没有上 CF 呀 ^-^

所以只能手动修一修了w

1.关闭upload_progress或者拦截PHP_SESSION_UPLOAD_PROGRESS

PHP 侧：

session.upload_progress.enabled = Off

或 WAF（比如 bunkerweb） 侧添加 modsecurity：```
SecRule REQBODY_PROCESSOR "@streq MULTIPART" \
"id:10961801,phase:2,chain,pass,log,msg:'php2shell: upload_progress field trigger',tag:'CVE-2026-109618',severity:'CRITICAL'"
SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" "t:none"
```选择一个就可以了 w

2.让 codex 扫描不安全的 unserialize：```
你是 PHP 安全审计员。在下面这个仓库里做【只读】扫描，找出 PHP2Shell unserialize 链的利用点：
攻击者可控的字节最终进入 unserialize()，并且放行了带 __destruct / __wakeup 的类。

命中判据（三条同时成立）：
1) 调用 unserialize($x) / igbinary_unserialize($x) / yaml_parse($x)；
2) $x 的来源可被外部影响：$_GET/$_POST/$_REQUEST/$_COOKIE/$_FILES、php://input、
请求头、未签名或未加密的 cookie、外部写入的队列消息、用户可写的缓存或 DB 字段；
3) 第二个参数缺失或为 null，或 allowed_classes 里含未审计的类
（allowed_classes => false 视为安全，不计入）。

做法：
- 先 grep -rn --include='.php' -E '\b(unserialize|igbinary_unserialize|yaml_parse)\s\(' .
排除 vendor/ 与 node_modules/；
- 对每个命中回溯 3 层调用链，追 $x 的真正来源（注意 base64_decode、gzuncompress、
hex2bin、urldecode 这类包装，它们不改变"可控"属性）；
- 命中的类要查它是否有危险的 __destruct / __wakeup / __unserialize
（写文件、删文件、发网络请求、执行命令、改全局状态）。

输出一张表，按风险降序：
文件:行号 | 代码片段 | $x 来源 | 外部可控(是/否/不确定) | 放行的类 | 析构器有无危险副作用 | 风险(高/中/低)

不确定的单独列出，并写明缺哪条证据才能定性。
不要改代码；每条命中末尾给一行修复建议（json_decode / allowed_classes=false / 加 HMAC 签名），等我确认后再动。
```

牌（php）没有问题）

Over，可以安心干别的的w