各大技术群和推特上都在疯传去 php.ini 里把 session.upload_progress.enabled 改成 0（或者 Off）就是可以防住这次的漏洞。也就是所谓的“一行配置免打补丁”。
这个我在群里和一些大佬交流了一下，结论是：这招挡不住所有攻击，最多只能帮你挡一半
因为这次爆出来的是两个漏洞
- 第一条攻击路径走的是
session.upload_progress（泄露出来的那份PHP2Shell脚本貌似走的就是这个攻击点） - 但第二条攻击路径在
PHP底层的multipart请求解析器。把upload_progress关了，甚至把file_uploads = Off关了（彻底禁止文件上传），但是 PHP 在收到请求时，按照设计必然需要先解析multipart请求体，导致触发第二条攻击路径。
PHP 的核心开发者 Gina Peter Banyard 也说了
“The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much.”
我唯一能说的是，唯一的缓解办法就是打补丁/升级 PHP。很遗憾我知道得太多了。
目前可能有点用的临时措施
影响是这几个小时里没法在博客后台传图片和更新插件了
session.upload_progress.enabled = 0 先改上
虽然防不住第二个攻击路径，但起码能先拦住一些脚本是不，起码脚本小子能防住
- 面板党：去面板的「PHP 管理」->「配置文件」，搜索
session.upload_progress.enabled，把后面的On或1dou改成0，保存并重载配置。 - 手动党：在对应的 php.ini 里加上
session.upload_progress.enabled = 0，保存并重载配置。
4.2 在 Nginx 直接阻断 multipart 请求
既然都说两条攻击路径都必须通过发送 multipart/form-data 格式的请求体来触发，那最直接的缓解办法就是：在请求到答 PHP-FPM 之前，让 Nginx 直接干死所有带 multipart 头的请求！
在站点的 Nginx 主配置文件的 server {} 块里塞入这三行：
if ($http_content_type ~* "multipart") {
return 403;
}
宝塔面板可以在这里配置：
-
直接打开你的
/www/server/nginx/conf/pathinfo.conf文件 -
把前边三行代码写在文件的第一行，大概是这样的感觉
if ($http_content_type ~* "multipart") {
return 403;
}
set $real_script_name $fastcgi_script_name;
if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
set $real_script_name $1;
set $path_info $2;
}
fastcgi_param SCRIPT_FILENAME $document_root$real_script_name;
fastcgi_param SCRIPT_NAME $real_script_name;
fastcgi_param PATH_INFO $path_info;
- 重载Nginx配置，然后在本地测试一下
curl -i -F "test=1" https://网站域名/index.php如果返回是HTTP/1.1 403 Forbidden就是缓解措施生效了
