MySQL高危提权漏洞（如CVE-2016-6662等）需同步管控进程权限、文件系统配置和SQL运行时状态，仅升级或改密码无法根治；必须验证USER()/CURRENT_USER()、mysqld启动用户、FILE/SUPER权限、plugin_dir可写性，并禁用UDF、关闭日志、加固my.cnf权限及严格配置secure_file_priv。
MySQL高危提权漏洞（如CVE-2016-6662、CVE-2016-6663、CVE-2021-27928）不是靠“打补丁就完事”的类型——它们依赖MySQL进程权限、文件系统配置和SQL运行时状态三者叠加，修复必须同步堵住执行链路。只升级版本或只改密码，大概率留后门。
查清当前是否已暴露在提权链中
攻击者利用这类漏洞的前提是：能写入MySQL可访问的任意路径 + MySQL以高权限（如root）运行 + 具备FILE或SUPER权限。先验证这三点是否成立：
- 执行
SELECT USER(), CURRENT_USER();确认登录用户与实际认证用户是否一致，CURRENT_USER()返回空或''@'localhost'说明存在匿名用户风险 - 检查MySQL启动用户：
ps aux | grep mysqld | grep -v grep，若显示为root而非mysql，提权风险陡增 - 确认关键权限是否被滥用：
SHOW GRANTS FOR 'app_user'@'%';，重点看是否含FILE、SUPER、GRANT OPTION；普通应用账号绝不能有这些 - 查插件目录是否可写：
SHOW VARIABLES LIKE 'plugin_dir';，然后用ls -ld /path/to/plugin_dir确认该路径属主和权限（如为root:root且权限为755，攻击者无法直接写入；若为mysql:mysql且777，危险）
立即切断UDF和日志文件提权路径
UDF提权和日志文件覆盖是最常被利用的两条链，必须手动关闭或加固，不能依赖版本号自动修复：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 禁用UDF功能（除非业务强依赖）：
SET GLOBAL secure_file_priv = '/tmp/';并重启MySQL，使plugin_dir不可写；再执行DROP FUNCTION IF EXISTS sys_exec;等已注册恶意函数 - 关闭general_log和slow_query_log（除非审计刚需）：
SET GLOBAL general_log = 'OFF'; SET GLOBAL slow_query_log = 'OFF';；若必须开启，确保general_log_file指向非敏感路径（如/var/log/mysql/general.log），且该路径不可被MySQL用户以外的账户修改 - 禁止日志路径被篡改：
mysqld启动参数中显式指定--general-log-file=/var/log/mysql/general.log --slow-query-log-file=/var/log/mysql/slow.log，避免运行时动态SET覆盖
修复CVE-2016-6662类配置型漏洞
该漏洞本质是MySQL配置文件（my.cnf）被恶意注入malloc_preload或init_file指令，导致启动时加载恶意so。它不依赖MySQL版本，而取决于配置管理方式：
- 检查所有生效配置文件：
mysql --help | grep "Default options" -A 1，列出/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf等，逐个搜索init_file、malloc_preload、plugin_load - 删除或注释掉任何可疑的
init_file行；若业务真需init SQL，应改用CREATE EVENT或应用层初始化，而非依赖启动加载 - 加固
my.cnf文件权限：chown root:root /etc/my.cnf && chmod 644 /etc/my.cnf；MySQL进程不应有写权限 - MySQL 5.7+ 可启用
secure_file_priv严格模式，设为/var/lib/mysql-files/并确保该目录仅mysql用户可读写，其他路径一律拒绝
验证修复是否真正生效
修完别信“没报错就是好了”——要按攻击者视角重走一遍提权链：
- 用原业务账号从真实客户端IP连接：
mysql -u app_user -p -h10.10.20.5，不是localhost - 尝试触发关键操作：
SELECT LOAD_FILE('/etc/passwd');应返回NULL或报错Can't read file；SELECT @@secure_file_priv;必须返回明确路径，不能是空或NULL - 检查是否还能创建UDF：
CREATE FUNCTION test_func RETURNS STRING SONAME 'xxx.so';应报错Access denied或Function 'test_func' already exists（说明之前删干净了） - 最后做一次最小权限回归测试：执行业务核心SQL（如
INSERT INTO orders...），确认功能正常但越权操作全部拦截
最易被忽略的是配置文件权限和secure_file_priv的实际生效路径——很多团队改了my.cnf却忘了chown，或者设了secure_file_priv但没建对应目录，MySQL会静默降级为不限制。每次变更后务必用mysqladmin var | grep secure_file_priv确认值已加载。
