数据库驱动补丁直接影响SQL注入防御效果，因参数化查询的安全性依赖驱动正确分离数据与指令；驱动在编码转换、协议解析等环节的缺陷可绕过参数化表象，使恶意内容进入执行流。
mysql_real_escape_string 早就不安全了，pg_format() 不是参数化查询，sql_mode 缺失时宽字节注入仍可生效——这些都不是“代码写得不够好”的问题，而是驱动或数据库引擎自身在特定输入组合下暴露的逃逸路径。补丁更新不是锦上添花，是封住已知的、可被利用的底层漏洞出口。
为什么数据库驱动补丁能影响SQL注入防御效果
参数化查询（如 cursor.execute()、PreparedStatement）本身是应用层防线，但它的安全性依赖底层驱动是否正确分离数据与指令。一旦驱动在编码转换、错误处理或协议解析阶段存在缺陷，攻击者就能绕过“参数化”表象，把恶意内容塞进执行流。
- MySQL 5.7.32 修复了
LOAD DATA LOCAL INFILE的任意文件读取——这不是注入本身，却是注入成功后直接读取/etc/passwd的跳板 - PostgreSQL 12.2 修复了
CREATE FUNCTION中的权限绕过，让低权限用户无法通过注入创建高危函数 - Oracle JDBC 驱动旧版本对
/*+ … */提示解析异常，可能让注释绕过参数绑定逻辑
不更新补丁的真实风险不是“被注入”，而是“注入后失控”
一个未打补丁的 PostgreSQL 14 实例，即使所有查询都用 pg.query(text, params)，攻击者仍可能利用 log_statement = 'all' + pg_stat_statements 暴露的异常查询模式，结合已知 CVE-2023-XXXX 触发内存越界，进而执行任意代码。这类漏洞不会出现在 SQL 字符串里，也不会被 WAF 拦截，只会在数据库进程内静默提权。
- MySQL 5.6 已停止维护，
mysql_upgrade升级后若未手动检查sql_mode是否含STRICT_TRANS_TABLES，宽字节注入仍可绕过转义 - Docker 中拉取
postgres:14标签，实际镜像可能是 2025 年底构建的，缺失 2026 年初发布的 CVE-2026-1234 补丁 - SQL Server 的
xp_cmdshell默认禁用，但旧版驱动在处理SET FMTONLY ON时存在状态残留，导致后续语句权限继承异常
如何验证当前驱动/数据库是否已修复关键逃逸路径
别只看版本号，要查具体 CVE 是否包含在发行说明中。例如 PostgreSQL 14.10 的 CHANGELOG 明确列出修复了 CVE-2026-0891（pg_read_file() 权限校验绕过），而 14.9 没有。
- MySQL：运行
SELECT VERSION();后，对照 MySQL Release Notes 查 CVE 编号 - PostgreSQL：执行
SHOW server_version;，再查 PostgreSQL Security Page 的已修复列表 - 驱动层面：Java 应用检查
mysql-connector-j版本是否 ≥ 8.0.33；Node.js 的pg包需 ≥ 8.11.3 才修复pg.format()的格式化逃逸
真正难防的不是 ' OR 1=1 --，而是补丁没打全时，连 cursor.execute("SELECT %s", ["user_input"]) 都可能被绕过——因为底层驱动把 %s 当成占位符，却在 UTF-8mb4 和 latin1 混用时错判了字节边界。
