GHSA-fjwv-jf2v-j499: SSRF
Summary The SNS UnsubscribeConfirmation handler in internal/integrations/ingestors/sns/sns.go makes an unvalidated http.Get() call to payload.UnsubscribeURL without any URL restriction. Because UnsubscribeURL is intentionally excluded from the BuildSignature() signed field list, an attacker can replace this field in a legitimately AWS-signed message with an arbitrary internal URL, bypassing the VerifyPayload() signature check entirely and triggering a Server-Side Request Forgery (SSRF) against internal infrastructure — including the EC2 Instance Metadata Service (IMDS) at 169.254.169.254.
### Impact
This is a Server-Side Request Forgery (SSRF) vulnerability. An attacker with a Hatchet account and an AWS Free Tier account can:
- Reach the EC2 IMDS endpoint and retrieve IAM temporary credentials if Hatchet is deployed on AWS - Port-scan and probe internal services not exposed to the internet - Access internal HTTP APIs (e.g., Kubernetes API server, internal dashboards) from the Hatchet server's network context
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/hatchet-dev/hatchetto a version that resolves this vulnerability.Fixed in 0.91.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs a Hatchet account and an AWS account capable of producing a legitimately AWS-signed SNS message. They can alter the unsigned UnsubscribeURL field after signing, so signature verification does not prevent the malicious URL from being requested.
Which deployments are most exposed?
Hatchet deployments running on AWS are particularly exposed because the server-side request can target the EC2 Instance Metadata Service at 169.254.169.254 and potentially retrieve temporary IAM credentials. Any deployment where the Hatchet server can reach internal HTTP services may also be used to probe or access those services.
What can an attacker access through the SSRF?
The attacker can cause the Hatchet server to make HTTP requests from its own network context. This can be used to probe internal ports and services or reach internal HTTP APIs such as a Kubernetes API server or internal dashboards.