phpMyAdmin 本身不执行 PHP 代码，真正风险来自配置失控、disable_functions 漏设及 Web 服务器错误解析 PHP 文件；需关闭主题切换、锁定 themes 目录、禁用 setup、Web 层拦截 PHP 解析、加固 PHP 运行时并更新 vendor 组件。
phpMyAdmin 本身不执行 PHP 代码，真正危险的是被绕过后的任意命令执行
phpmyadmin 是一个 php 应用，它自身不会“执行用户提交的 php 代码”——它只执行 sql。所谓“执行任意 php 代码”的风险，实际来自三类被攻击者利用的通道：php.ini 配置失控、disable_functions 漏设、以及 web 服务器对 php 文件的错误解析（比如上传 .php 后门并直接访问）。phpmyadmin 的配置文件（config.inc.php）若可写，或主题目录（themes/）未锁定，也可能成为恶意 php 文件的落脚点。
禁用 phpMyAdmin 中所有可能加载外部 PHP 逻辑的入口
重点不是“禁用某个按钮”，而是掐断动态加载、主题切换、插件注入等机制：
-
$cfg['ThemeManager'] = false;—— 关闭主题切换，防止恶意主题中嵌入 PHP 逻辑（如通过include加载远程或本地恶意文件） - 清空
themes/default/外所有子目录（如pmahomme），只保留themes/default/且确保其不可写（chmod -w themes/default） - 检查
config.inc.php中是否定义了$cfg['Servers'][$i]['auth_type'] = 'signon'或'http'，这类认证方式若后端脚本可控，可能引入任意代码执行；推荐统一用'cookie'并配合$cfg['LoginCookieRecall'] = false; - 删除或重命名
setup/目录（如果存在）——该目录含配置生成器，历史上多次曝出远程代码执行漏洞
封死 Web 层对 PHP 文件的解析能力（关键防线）
即使 phpMyAdmin 配置再严，只要 Web 服务器允许上传并解析 PHP 文件，攻击者就能绕过一切前端限制。必须在 Apache/Nginx 层做硬性拦截：
- Apache：
<Directory "/path/to/phpmyadmin"> <FilesMatch "\.php$"> Require all denied </FilesMatch> </Directory>，同时确保php_admin_flag engine off生效 - Nginx：在 server 块中添加
location ~ ^/phpmyadmin/.*\.php$ { return 403; }，注意路径前缀要和实际部署一致 - 禁止上传目录执行 PHP：若 phpMyAdmin 允许导入（如
import.php），确保上传临时目录（如/tmp或upload/）本身**不被 Web 服务器映射为可执行路径**，且无.php解析规则
检查并加固底层 PHP 运行时环境
phpMyAdmin 安全最终依赖于 PHP 自身的限制是否生效：
- 确认
disable_functions已启用且不含空格：disable_functions = exec,shell_exec,system,passthru,proc_open,popen,pcntl_exec,curl_exec,file_get_contents,putenv,ini_set - 强制开启
phar.readonly = 1和phar.require_hash = 1，防止 Phar 反序列化链利用 - 禁用动态代码执行相关配置：
allow_url_include = Off、allow_url_fopen = Off（除非业务明确需要） - 不要依赖
open_basedir单独防护——它可被proc_open+chroot绕过，必须和disable_functions配合使用
最易被忽略的一点：phpMyAdmin 的 libraries/vendor/ 下可能包含可被利用的第三方组件（如旧版 Twig、Symfony HttpFoundation），升级不能只看 phpMyAdmin 版本号，还要确认 vendor 目录是否随主程序更新。手动替换 vendor 很危险，建议用官方完整包覆盖而非仅更新核心文件。
立即学习“PHP免费学习笔记（深入）”；
