Hatchet CVE-2026-61681

Requires an authenticated Hatchet tenant able to deliver messages to the SNS UnsubscribeConfirmation ingestor (SNS integration must be in use/reachable). The attacker must construct a valid AWS-signed SNS message but can freely tamper the UnsubscribeURL field because BuildSignature() excludes it from the verified signature, so VerifyPayload() still passes. Meaningful impact further depends on the deployment sitting on a network where a useful internal target exists - most notably an AWS host exposing EC2 IMDS (IMDSv1), reachable internal HTTP APIs, or internal services; IMDSv2, egress-restricted, or on-prem deployments with no sensitive internal endpoints sharply limit the payoff to blind SSRF. Fixed in 0.91.1, which restricts SNS URLs to https on an allowlisted AWS host pattern.

This is a genuine but bounded (moderate) risk. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N = 4.1) correctly identifies a network-reachable SSRF with a scope change but limited confidentiality-only impact. There is NO EPSS score, NO CISA KEV listing, and NO public exploit code in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis' - this is not an urgent, actively-exploited priority. The real risk is highly conditional: the description says exploitation requires an 'authenticated Hatchet tenant', yet the vendor scored PR:H - I dispute this, since a tenant in a multi-tenant orchestrator is typically a normal low-privileged customer (PR:L is more defensible), which would slightly RAISE real-world exploitability above the 4.1 headline. Conversely, the true damage depends entirely on where Hatchet runs: on an EC2/cloud host with a reachable IMDS the payload can harvest IAM credentials (arguably C:H, above the vendor's C:L), whereas on a hardened/on-prem or IMDSv2-only deployment the impact collapses toward blind SSRF with little to exfiltrate. Bottom line: not a widespread-exploitation crisis, but a legitimate cloud-pivot primitive for any authenticated tenant on a cloud-hosted Hatchet instance - patch on normal cadence, prioritize if Hatchet runs in AWS with IMDSv1.

An authenticated tenant on a cloud-hosted Hatchet instance sends an otherwise valid, correctly AWS-signed SNS message to the SNS ingestor but replaces the UnsubscribeURL field (which BuildSignature() never covers) with 'http://169.254.169.254/latest/meta-data/iam/security-credentials/'. VerifyPayload() passes because the tampered field is outside the signature, and the server's http.Get() fetches the attacker-chosen internal URL, potentially returning EC2 IMDS IAM credentials or hitting other internal-only services. No public exploit code is identified, but the signature-exclusion flaw is described precisely enough in the advisory and commit diff to reproduce trivially.