Live › vulnerability › CVE-2026-42864
Go to dashboardThe Raid jira_bot endpoint in FireFighter accepts requests without authentication and fetches attacker-supplied attachment URLs server-side with no validation. An attacker can point it at the cloud metadata service and exfiltrate the pod's temporary AWS credentials as a Jira attachment.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 16:46 UTC, 0h before NVD. All times on this page are UTC.
Teams running firefighter-incident below 0.0.54 with the Raid jira_bot endpoint reachable from untrusted networks are exposed. Exposure to cloud credential theft is highest on EC2 or EKS deployments that do not enforce IMDSv2. Deployments where the endpoint is only reachable on trusted networks are less exposed.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| firefighter-incident | pypi | < 0.0.54 | 0.0.54 |
pip show firefighter-incident and compare the version against 0.0.54./api/v2/firefighter/raid/jira_bot to untrusted networks.HttpPutResponseHopLimit=1.firefighter-incident to 0.0.54 or later./api/v2/firefighter/raid/jira_bot to trusted networks (VPN, internal load balancer).HttpPutResponseHopLimit=1 on EC2/EKS nodes to neutralise the credential theft path.RAID_JIRA_API_PASSWORD if exposure is suspected.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
The POST /api/v2/firefighter/raid/jira_bot endpoint (CreateJiraBotView) is
reachable without authentication (permission_classes = [permissions.AllowAny]).
Its attachments payload is fetched server-side via httpx.get() with no URL
validation, then uploaded as an attachment on the Jira ticket that gets created.
An unauthenticated caller able to reach the ingress can coerce the pod into
fetching arbitrary URLs — including the cloud metadata endpoint at
http://169.254.169.254/ — and exfiltrate the response as a Jira attachment.
On EC2/EKS deployments that do not enforce IMDSv2, this allows theft of the temporary AWS credentials attached to the pod's IAM role. The docstring on the view claims a Bearer token is required, but the code does not enforce it.
Affected code paths:
src/firefighter/raid/views/__init__.py — CreateJiraBotViewsrc/firefighter/raid/serializers.py — LandbotIssueRequestSerializer.attachmentssrc/firefighter/raid/client.py — RaidJiraClient.add_attachments_to_issueFixed in firefighter-incident 0.0.54:
CreateJiraBotView now enforces BearerTokenAuthentication + IsAuthenticated.attachments URLs are validated: http(s) scheme only, max 10 URLs, rejection
of any host resolving to a private, loopback, link-local, reserved, multicast
or unspecified IP (IPv4 and IPv6).KeyError('attachments') surfaced during regression testing.Users should upgrade to 0.0.54 or later.
Until upgrade is possible, any one of the following blocks end-to-end exploitation:
/api/v2/firefighter/raid/jira_bot to trusted
networks only (VPN, internal load balancer).RAID_JIRA_API_PASSWORD;
this breaks jira.create_issue() before the vulnerable attachment fetch is
reached (legitimate traffic is also blocked — emergency mitigation only).HttpPutResponseHopLimit=1 on EC2/EKS nodes. This does
not fix the SSRF itself but neutralises the IAM-credential-theft path.This page as .md · .json · in your agent: get_signal("CVE-2026-42864")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.