phpMyAdmin 的 config.inc.php 无法禁用系统命令，因其仅为前端界面工具，不干预 PHP 底层执行能力；必须通过 php.ini 的 disable_functions 机制禁用 exec、shell_exec 等高危函数，并重启服务验证生效。
直接禁用 exec、system 等函数是最有效手段，而不是靠 phpMyAdmin 自身配置——它根本不拦截 PHP 的底层执行能力。
为什么 phpMyAdmin 的 config.inc.php 不能禁用系统命令
phpMyAdmin 是个纯前端界面工具，所有数据库操作最终都走 MySQL 协议；它不解析、不拦截、也不限制 PHP 的函数调用。哪怕你在 config.inc.php 里关掉“文件导入”或“SQL 执行”，只要服务器上 PHP 还能运行 shell_exec，攻击者通过上传 WebShell 或利用其他漏洞（如反序列化、模板注入）就能绕过 phpMyAdmin 界面直接调用系统命令。
常见误解是以为改 $cfg['UploadDir'] = '' 或设 $cfg['AllowArbitraryServer'] = false 就安全了——这些只影响 phpMyAdmin 功能开关，对 PHP 解释器本身毫无约束力。
必须在 php.ini 中禁用的高危函数列表
以下函数一旦启用，等于给攻击者开了 shell 入口，只要拿到任意 PHP 执行权限（比如文件上传、日志注入、模板渲染），就能执行任意系统命令：
-
exec、shell_exec、system、passthru、popen、proc_open -
phpinfo（泄露环境细节，辅助攻击） -
assert（PHP 7.2+ 可用于代码执行） -
chroot、scandir、glob（配合目录遍历读取敏感路径） -
file_get_contents、fopen、readfile（读取 /etc/passwd、源码、配置等）
实际写法（在 /etc/php/*/apache2/php.ini 或对应 CLI 配置中）：
disable_functions = exec,shell_exec,system,passthru,popen,proc_open,phpinfo,assert,chroot,scandir,glob,file_get_contents,fopen,readfile
注意：disable_functions 对 ini_set 无效，但能阻止绝大多数 WebShell 直接调用；若业务真需 file_get_contents（比如采集），应单独开白名单，而非全局放开。
禁用后要验证是否生效
光改配置不重启服务=白改。改完后必须做两件事：
- 重启 Web 服务：Apache 用
sudo systemctl restart apache2，Nginx + PHP-FPM 则需sudo systemctl restart php*-fpm和sudo systemctl restart nginx - 写个探针脚本测试，例如
test.php放到 Web 目录下：
<?php var_dump(function_exists('exec'));
var_dump(function_exists('shell_exec'));
echo @exec('id') ?: 'disabled';
?>
访问该页面，输出应为 bool(false) 且无命令结果；若仍返回 uid=33(www-data) 类似内容，说明禁用失败——大概率是改错了配置文件路径，或被其他 ini 文件覆盖（可用 php --ini 查找加载顺序）。
容易被忽略的兼容性陷阱
某些老旧 CMS 或自研系统会偷偷依赖 scandir 加载插件、用 exec 调用 mysqldump 导出，禁用后可能引发：
- phpMyAdmin 自身报错：如 “cannot open themes folder”，说明
opendir/readdir被误禁（这两个不属于命令执行类，应保留） - WordPress 插件备份失败、Typecho 主题扫描异常
- 宝塔面板的“一键部署”功能失效（它内部调用
exec）
所以不要照搬网上的“全量黑名单”。先禁核心命令函数（exec~proc_open），再逐个加 scandir、glob 等，每加一个就跑一遍业务流程。真正危险的是能执行命令的函数，不是能列目录的函数。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
