allow_url_include必须设为Off，因其默认关闭，是阻止php://input、data://等伪协议远程代码执行的关键；若手动开启则漏洞仍存在，需修改php.ini并重启服务，且须配合代码层白名单与路径校验。
allow_url_include 必须设为 Off
PHP 8.4.27 本身不“修复”伪协议文件包含漏洞，它只是延续了 PHP 长期以来的安全默认：allow_url_include 默认值为 Off（即 0）。这个配置项才是控制 php://input、data://、http:// 等伪协议能否被 include/require 加载的关键开关。只要它保持关闭，绝大多数伪协议 RCE 就无法触发。
常见错误是误以为升级到 8.4.27 就自动免疫——其实如果旧环境手动开启了 allow_url_include=On，升级后该配置仍生效，漏洞照旧存在。
- 检查当前值：
php -i | grep allow_url_include或在脚本中输出ini_get('allow_url_include') - 若返回
1，说明已开启，必须禁用 - 不要依赖 .htaccess 修改（Apache 下对 PHP-FPM 无效），优先改
php.ini
php.ini 中修改后必须重启服务进程
改完 php.ini 里的 allow_url_include = Off 不等于立即生效。PHP-FPM 和 Apache mod_php 都有常驻进程，配置变更需显式重载或重启。
典型遗漏点：
立即学习“PHP免费学习笔记（深入）”；
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- PHP-FPM：执行
sudo systemctl reload php8.4-fpm（Debian/Ubuntu）或sudo systemctl reload php-fpm（RHEL/CentOS），restart比reload更彻底 - Apache + mod_php：需
sudo systemctl reload apache2，仅改.htaccess对include无效 - Docker 环境：镜像层缓存可能使新
php.ini未加载，务必重建容器
别忽略 allow_url_fopen 的连带影响
php://filter 读取源码（如 ?file=php://filter/convert.base64-encode/resource=index.php）不需要 allow_url_include，但依赖 allow_url_fopen=On。虽然它不直接导致代码执行，却是 LFI 利用链的第一步——泄露源码后才能分析过滤逻辑、找 bypass 点。
生产环境应同步关闭：
-
allow_url_fopen = Off（同样写入php.ini） - 注意：某些合法业务（如远程 API 调用用
file_get_contents("https://...")）会中断，需评估替代方案（如curl） -
php://filter在allow_url_fopen=Off时仍可工作，但仅限本地文件；真正失效的是http://类远程流
升级不能代替代码层防御
PHP 8.4.27 修复的是 CVE-2026-109618/109619 这类内核级 RCE，和文件包含漏洞无关。而 include($_GET['page']) 这类代码，在 8.4.27 下只要 allow_url_include=On，照样能打 php://input。
真正的防护必须落在代码里：
- 绝对禁止直接拼接用户输入到
include/require - 必须使用白名单：例如
$pages = ['home', 'about', 'contact']; if (in_array($_GET['page'], $pages)) { include($_GET['page'] . '.php'); } - 路径规范化 +
realpath()校验是否落在预期目录内（防../../../etc/passwd） - Web 目录外的敏感文件（如配置、日志）绝不放在 Web 可访问路径下
配置关得再严，只要代码里还留着 include($_GET['x'])，攻击者就永远在找那个被漏掉的开启方式。
