2026年PHP代码审查必须聚焦「污染链中段」，优先逆向追踪eval、assert、system、include、file_get_contents等高危函数入口，结合filter_input、json_decode等中间处理函数识别被“洗过”但仍可控的变量，严格验证上下文可信性。
直接上结论：2026 年 PHP 代码审查，不能再只盯 $_GET 和 mysql_query 这类“老面孔”，必须把注意力转向「污染链中段」——那些被 filter_input、json_decode、parse_str、extract 处理过，却未重置可信边界的变量。
从哪几个函数开始逆向追踪最有效
别通读全项目。先搜高危函数入口，再倒查参数是否可控。2026 年真实漏洞里，83% 的 RCE 和 SQLi 都藏在这些调用之后：
-
eval、assert：只要参数含base64_decode($_GET['x'])或urldecode($input)，立刻标记为高危 -
system、exec、shell_exec：检查是否用了escapeshellarg()，但更关键的是看它前面有没有str_replace('..', '', $_GET['path'])这类“假清理” -
include、require_once：重点查路径拼接是否用了$_GET['tpl'] . '.php'，哪怕加了basename()，也要验证是否绕过（如test%00.php） -
file_get_contents、unlink：搜索$_FILES['up']['name']或$_GET['file']是否直接进路径，警惕phar://、data://协议注入
为什么只搜 $_GET 和 $_POST 会漏掉 70% 的漏洞
因为用户输入早被“洗”过了。真实代码里，它可能已经走过这些路径：
-
filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT)—— 这个过滤不防 SQL 注入，只清数字，但后面如果拼进 SQL，照样崩 -
parse_str($_SERVER['QUERY_STRING'], $params)—— 把整个 query string 批量导入变量空间，$$key = $value级别的变量覆盖风险 -
$data = json_decode(file_get_contents('php://input'), true); $filename = $data['file'];—— JSON 键名未校验白名单，直接进file_put_contents($filename, ...) -
extract($_POST)—— 全局变量污染高发区，尤其搭配$$var动态调用时，等于给攻击者开变量命名权
静态工具能代替人工审查吗
不能。它们是筛子，不是判官：
立即学习“PHP免费学习笔记（深入）”；
-
phpcs --standard=PSR12只管缩进和命名，对if ($user->role !== 'admin') return;写在函数中间而非开头的权限绕过毫无反应 -
phpstan level=5能报出Undefined variable $db，但发现不了$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];这种拼接逻辑 -
RIPS会漏掉业务逻辑漏洞，比如“导出 CSV”功能中，$filename = $_GET['name'] . '.csv';表面安全，实则可通过report%00.csv截断后缀，写入任意文件
真正有效的组合是：phpcs 拦低级不一致，phpstan 捕类型隐患，人工死盯三件事：数据是否可控、过滤是否到位、上下文是否可信。
最容易被忽略的复杂点：上下文可信性判断
同一个变量，在不同上下文里风险等级天差地别。比如 $filename：
- 作为
file_get_contents($filename)参数：要防路径穿越、协议注入 - 作为
header("Location: /{$filename}");输出：要防 CRLF 注入 - 作为
echo htmlspecialchars($filename);输出：要防 XSS，但得确认编码是否在输出前做、是否用了ENT_QUOTES - 作为
new PDO("mysql:host=localhost;dbname={$filename}")：这已经不是注入问题，而是架构错误——数据库名绝不该由用户控制
审查时，必须带着上下文走一遍执行流。脱离上下文谈“这个变量已过滤”，等于没审。
