mysql漏洞如何修复

MySQL 漏洞修复不是洞何打补丁就完事。去年某电商平台被拖库，修复根因是洞何 MySQL 5.7.32 的一个权限提升漏洞（CVE-2021-2307），攻击者通过一个低权限账号拿到服务器 Shell。修复运维团队当时觉得“数据库在内网，洞何没事”，修复结果内网横向移动只用了 20 分钟。洞何漏洞修复必须从版本、修复配置、洞何权限、修复网络四个层面同时下手，洞何缺一个都等于没修。修复

先看版本。洞何很多人用 `mysql --version` 看到 5.7 就以为没问题。修复错了，洞何5.7 系列里 5.7.35 之前的版本有 30 多个已知高危漏洞。修复第一步是确定当前小版本号。执行 `SELECT VERSION();`，如果返回 5.7.33，立刻去 Oracle 官网查 Critical Patch Update 列表。我见过一个案例，某公司升级到 5.7.38 后没重启服务，`SELECT VERSION()` 还是旧值，因为二进制文件替换了但进程没重载。正确做法是停库、替换二进制、重启，再验证。

升级不是万能药。MySQL 8.0 修了旧漏洞，但引入新问题。比如 8.0.26 之前的 `caching_sha2_password` 插件在特定网络环境下会回退到明文传输。修复方式是在 my.cnf 里强制 `default_authentication_plugin=mysql_native_password`，或者升级到 8.0.28 以上。这里有个坑：改认证插件会导致旧客户端连不上，得先确认应用层驱动版本。我一般建议先用 `SHOW VARIABLES LIKE 'default_authentication_plugin';` 查当前值，再决定是否调整。

配置层面的漏洞最容易被忽略。`local_infile` 默认开启时，攻击者能通过 `LOAD DATA LOCAL INFILE` 读取服务器任意文件。修复很简单：在 my.cnf 的 `[mysqld]` 段加 `local_infile=0`。但很多云数据库控制台不暴露这个参数，你得用 `SET GLOBAL local_infile=0;` 临时关，然后写进配置文件持久化。另一个常见问题是 `skip-grant-tables` 被误开，这等于关闭所有权限验证。检查 `SHOW VARIABLES LIKE 'skip_grant_tables';`，如果是 ON，立刻停库改配置。

权限修复要动真格。`SELECT user,host,authentication_string FROM mysql.user;` 看看有没有 `%` 通配符的账号。我处理过一次事故：开发为了方便，建了 `'dev'@'%'` 且密码是 `123456`，结果被扫描器爆破。修复步骤：先 `DROP USER 'dev'@'%';`，再建 `'dev'@'192.168.1.%'` 并设强密码。注意 MySQL 8.0 默认密码策略要求大小写数字符号，`validate_password` 插件可能让你设的密码通不过，先 `SHOW VARIABLES LIKE 'validate_password%';` 看策略，必要时临时调低强度再改。

网络层修复靠防火墙和绑定地址。`bind-address=127.0.0.1` 只允许本机连接，但很多生产环境需要远程访问。那就用 iptables 或云安全组限制源 IP。我见过最离谱的配置：MySQL 监听 0.0.0.0 且安全组开放 3306 到 0.0.0.0/0，数据库直接暴露在公网。修复时先 `netstat -tlnp | grep 3306` 确认监听地址，再改 `bind-address` 为内网 IP，最后用 `nmap` 从外部扫一遍验证端口是否关闭。

补丁管理要有节奏。Oracle 每季度发一次 CPU，但高危漏洞可能随时出紧急补丁。我习惯订阅 MySQL 的 CVE 邮件列表，看到 CVSS 评分 7.0 以上的立刻安排测试。测试环境先跑 `mysqlslap` 压测，确认升级后 QPS 下降不超过 5%，再上生产。别信“这个漏洞不影响我们”这种话——CVE-2022-21449 刚出时很多人觉得只是 Java 问题，结果 MySQL 的 X Plugin 也受影响。

最后说个真实教训。某金融公司修复 CVE-2023-21980 时只升级了主库，从库没动。攻击者通过从库的复制账号提权，因为从库版本旧且 `replication_user` 权限过大。修复必须主从一起升，并且 `GRANT REPLICATION SLAVE` 只给必要权限，别用 `ALL PRIVILEGES`。查一下 `SHOW GRANTS FOR 'repl'@'%';`，如果看到 `ALL PRIVILEGES`，立刻回收重授。

漏洞修复不是一次性任务。每次改完配置，跑一遍 `mysql_secure_installation` 脚本，再手动检查 `SHOW VARIABLES` 里跟安全相关的 20 多个参数。我自己的清单包括：`secure_file_priv` 必须指向特定目录，`sql_mode` 包含 `STRICT_ALL_TABLES`，`log_error_verbosity` 至少为 2 以便审计。这些细节不写进文档，下次换人运维又会踩坑。

很赞哦!（9956）