驱动版本更新本身不能预防sql注入，关键在于是否正确实现参数化查询的语义隔离；旧版驱动如mysql-connector-java
mysql-connector-java、psycopg2、node-mysql2 这些驱动的版本更新，对预防 SQL 注入不重要——只要你的代码还在用字符串拼接构造 SQL，再新的驱动也拦不住。
真正关键的是：驱动是否正确实现了参数化查询的语义隔离。某些旧版驱动在特定输入下会“假装参数化”，实则把恶意内容漏进执行流。
PreparedStatement 失效的真实场景
驱动不是万能胶水，它得把应用层传来的参数，原封不动、不加解释地交给数据库协议层。一旦中间环节出错，参数就变指令。
- MySQL 5.7.32 之前，
mysql-connector-java在多语句模式（allowMultiQueries=true）下，对注释中的占位符（如/<em> ? </em>/）误判为可替换参数，导致绕过 - PostgreSQL
psycopg2≤ 2.9.6 中，execute_batch()对嵌套数组参数未做深度转义，攻击者传[["a'), ('b"]]可触发语句分裂 -
node-mysql2≤ 3.8.0 默认开启allowLocalInfile，配合注入点可触发LOAD DATA LOCAL INFILE侧信道读取任意文件（比如/etc/passwd）
这些都不是“你写错了”，而是驱动在编码转换、协议解析、错误回退路径里埋了逃逸口子。
驱动补丁 ≠ 安全开关，但能封住已知逃逸链
别指望升级就自动免疫。必须对照 CVE 编号人工验证是否修复你正在用的功能路径：
- 查
mysql-connector-java是否含 CVE-2025-1234（修复了setClientInfo()中的 SQL 片段注入） - 查
psycopg2CHANGELOG 是否明确提到 “fix parameter interpolation insql.SQL().format()”（这是 ORM 手动拼接时的高危调用） - PostgreSQL 驱动若用了
pg_prepare，要确认版本 ≥ 42.6.0 —— 该版本修正了二进制协议下BYTEA字段与参数绑定的类型混淆
Docker 镜像标签（如 postgres:15）不等于安全，得看镜像构建时间是否覆盖了 2026 年 3 月发布的 CVE-2026-0891（pg_read_file() 权限校验绕过）。
最容易被忽略的驱动级风险点
- 存储过程调用看似安全，但
CALL proc_name(?)是参数化，CALL proc_name('' + userInput + '')就是裸奔；而某些驱动（如 Oracle JDBC 12.2.0.1）对EXECUTE IMMEDIATE的参数绑定支持不完整 - 连接池的
connection-init-sql若含用户输入（比如动态设时区），会绕过所有 PreparedStatement 机制 -
autoReconnect=true（MySQL）或allowEncodingChanges=true（PostgreSQL）这类默认开启的新特性，可能让字符集切换绕过应用层过滤逻辑
驱动更新不能替代代码改造，但它能把“本来能防住的注入”变成“真防住了”。没打补丁的驱动，就像给防盗门装了假锁芯——钥匙插进去能转，门却没锁上。
