PHP8.4.27如何修复伪协议文件包含漏洞-php教程-PHP中文网

allow_url_include必须设为off，因其默认关闭，是阻止php://input、data://等伪协议远程代码执行的关键；若手动开启则漏洞仍存在，需修改php.ini并重启服务，且须配合代码层白名单与路径校验。

php8.4.27如何修复伪协议文件包含漏洞

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-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 点。

PHP 8.5.12

修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。

下载

生产环境应同步关闭：

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'])，攻击者就永远在找那个被漏掉的开启方式。