必须执行select version()或@@version获取真实服务端版本，再用curl比对cve记录；严禁依赖mysql --version（仅客户端版本）；需结合nmap验证暴露面、openscap检查配置基线，并手动执行sql核查空密码等高危项。
直接查服务端版本再比对CVE记录
别信 mysql --version，它只显示客户端版本。真正要扫漏洞，必须连上数据库执行 SELECT VERSION() 或查 @@version，拿到类似 8.0.33 或 5.7.42 这样的真实服务端版本号。之后立刻用 curl 查 NVD 公开库：curl -s "https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mysql+8.0.33" | grep -i "auth bypass\|remote code\|privilege escalation"。重点盯 CVE 编号含 CVE-2023- 或 CVE-2024- 的条目——这些大概率已有 PoC 或厂商通告。
容易踩的坑：
-
SHOW VARIABLES LIKE 'version_comment'返回MySQL Community Server (GPL)不代表没打补丁；Debian/Ubuntu/RPM 包可能带定制 patch，得用apt list --upgradable | grep mysql或yum updateinfo list security mysql确认补丁是否真落地 - nmap 扫出的版本（
nmap -p 3306 --script=mysql-info 127.0.0.1）若和SELECT VERSION()不一致，说明有代理、容器或配置未生效，得先统一暴露面
用 OpenSCAP 扫配置基线，但得配对连接方式
OpenSCAP + mysql80-cis profile 能检查弱密码、空用户、过度授权等 60+ 项，但它只支持 TCP 连接，不认 socket。所以不能写 --socket=/var/run/mysqld/mysqld.sock，必须显式指定 --host=127.0.0.1 --port=3306。账号还得有权限：至少能 SELECT mysql.user、mysql.db、performance_schema ——否则直接报错退出。
常见失效原因：
- cron 里调用时，环境不加载
~/.my.cnf，得传参--user=root --password=xxx，或改用MYSQL_PWD环境变量（注意该文件权限必须是600，不能被 group/o 读） - 扫描结果不加时间戳就覆盖：
oscap xccdf eval ... > /var/log/mysql-scan-$(date +\%F-\%H).html，否则无法追溯变化 -
skip_networking=ON在 CIS 检查里算“合规”，但在 Docker 内网场景下等于服务不可达——此时“合规”反而是故障点
手动跑几条关键 SQL 快速揪高危配置
有些风险 OpenSCAP 不覆盖，比如密码插件强度或空密码账户，得自己补查。以下 SQL 直接进库执行，30 秒内出结果：
SELECT User, Host, authentication_string FROM mysql.user WHERE authentication_string = '' OR authentication_string LIKE '*%';
SELECT plugin FROM mysql.user WHERE User = 'root';
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.variables_info WHERE VARIABLE_NAME IN ('local_infile', 'symbolic_links', 'bind_address', 'secure_file_priv');
重点关注：
-
authentication_string = ''表示空密码，立刻删或重置 - 如果
plugin是mysql_native_password，说明没启用 8.0 默认的caching_sha2_password，但不等于更安全——得结合实际连接客户端兼容性判断 -
local_infile=ON或secure_file_priv为空//，属于高危项，必须关或限定目录
别把 sqlmap 当数据库漏洞扫描器用
sqlmap -u "http://x.com?id=1" --dbs 测的是 Web 应用有没有 SQL 注入点，跟 mysqld 进程自身是否存在 CVE 漏洞完全无关。你扫出来的“MySQL 5.7.26 存在漏洞”，指的是服务端二进制本身有缓冲区溢出或认证绕过，不是前端代码拼接了 ' OR 1=1。
真要验证服务层漏洞，优先做三件事：
- 确认版本是否在已知 CVE 影响范围内（用上面
curl方式） - 用
nmap --script=mysql-info验证对外暴露的真实版本 - 检查错误日志里有没有反复出现的
Access denied for user或短时间大量连接，这往往是暴力破解或利用弱口令的痕迹
工具链可以搭，但每一步输出都得人工交叉验证——自动化报告里的“合规”，不等于线上环境真的安全。
