CVE-2026-73847 — emlog AI 助手 CSRF → SQL 执行 → 管理员接管

关于 emlog pro 的 AI 助手 execute_tool 端点缺少 CSRF 保护的 PoC，它允许攻击者利用管理员已认证的会话，对站点数据库执行任意 SQL——包括完全接管管理员账户。

根本原因

emlog pro 的后台管理面板内置了一个 AI 助手，可通过 POST /admin/ai.php?action=execute_tool 代替管理员执行 SQL。多个问题叠加在这一端点上：

1. 没有 CSRF 令牌。 admin/ 下所有其他破坏性操作文件都会先调用 LoginAuth::checkToken()（例如 admin/media.php:140），而 admin/ai.php 从未这样做。
2. 认证仅依赖会话 Cookie（admin/ai.php:152、User::isAdmin()）——没有 Origin/Referer 检查。
3. 写入确认门槛是一个硬编码的公开字符串。 include/service/ai.php:594：if (trim($confirm_code) !== 'confirm')。任何伪造请求只需发送 confirm_code=confirm 即可。
4. 只读 SQL 完全无需确认（include/service/ai.php:578,589）——仅凭一个已认证请求即可 SELECT 任意表。
5. 只有 blog 表受写入保护（include/service/ai.php:591）—— 及其他所有表均可完全写入。

串联起来：来自管理员浏览器的一个伪造请求即可读取所有表（包括密码哈希），并写入除 blog 之外的所有表，包括直接覆盖 user.password。

PoC

第 1 部分 — 原始影响链（poc_raw_impact.sh）

将 SQL/认证绕过原语与 CSRF 投递问题分离开来。在你控制的本地实例上运行：

./poc_raw_impact.sh http://TARGET admin '<adminpass>'

该脚本以 admin 身份登录，通过列别名绕过方式导出密码哈希，直接经由 user 表覆盖管理员密码，随后使用全新的 cookie jar 以攻击者选定的密码再次登录——证明只要有一个已认证请求到达该端点，即可实现完整账户接管。

第 2 部分 — 真实跨站 CSRF 投递（poc_csrf.html）

用真实浏览器验证 SameSite 问题，而非凭空假设。从与目标不同的任意源托管 poc_csrf.html（不同的 IP 即可——Chrome 将不同的字面量 IP 视为不同站点），并让已登录的管理员在登录后约两分钟内打开它：

python3 -m http.server 8888
# then point poc_csrf.html's form action at your target and get it opened

该表单在加载时自动提交，跨站 POST 一个伪造的 query_database 调用，并附带 confirm_code=confirm。

已实测验证：该伪造的跨站 POST 携带了管理员真实的认证 Cookie（sec-fetch-site: cross-site，Cookie 已附带），返回 200 {"code":0,"msg":"ok",...}，且通过后续的一次已认证读取确认了注入行确实存在。约 48 分钟后，对同一个现已陈旧的 cookie jar 重复完全相同的请求则失败——未附带任何 Cookie，服务器返回了未认证重定向，从而证实约两分钟的 Lax+POST 窗口才是真正的限制条件（反映在 AC:H 中）。

影响

• 完整数据库读取：所有表/列，包括密码哈希以及 emlog_options 中的任何机密（SMTP 凭据、API 密钥等）。
• 完整数据库写入：除 blog 外的所有表，包括 user——可覆盖角色/密码/邮箱，已端到端演示为账户接管。
• 仅影响 role=admin 的账户；writer/editor 会被 User::checkRolePermission() 阻止。这不是从低权限角色的提权——而是将管理员登录状态下的一次恶意链接点击，转化为对站点的完全、悄无声息的攻陷。

修复

在 execute_tool 中加入 LoginAuth::checkToken()，在认证 Cookie 上设置 SameSite=Strict，并将静态的 confirm_code 字符串替换为真正的每会话一次性令牌。完整的修复细节见安全公告。

披露时间线

• 2026-07-31 — 根据 emlog 自带的 SECURITY.md，通过 GitHub Security Advisories 提交报告。
• 2026-08-01 — 维护者发布安全公告并申请 CVE。
• 2026-08-16 — GitHub（作为 CNA）分配了 CVE-2026-73847。

署名说明： 尽管 GHSA 本身已对报告者致谢并接受其提交，但作为 CNA 的 GitHub 在发布 CVE 记录时却没有附上 credits 条目。更正请求已于 2026-08-16 发送至 [email protected]；若该记录得到更正，本 README 将随之更新。

免责声明

本内容在安全公告公开且 CVE 已分配之后发布，仅供防御/教育用途。请勿对你不拥有或未经明确授权测试的 emlog 实例运行本 PoC。