# ex_aws_sns: Trusted-attacker `SigningCertURL` permits complete SNS signature bypass

ex_aws_sns verify_message/1 fetched the signing cert from an unvalidated attacker-supplied SigningCertURL, letting forged SNS messages pass signature verification.

- Payout: Research
- Severity: high
- Program: ex_aws_sns
- Found by (vendor credit): Peter Ullrich, Jonatan Männchen / EEF
- Found by: PJUllrich
- Disclosed: 2026-06-26
- CVE: CVE-2026-47074
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-8jgf-23q5-x7xx
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-8jgf-23q5-x7xx
- Tags: area:web domain:oss domain:web impact:integrity kind:research platform:ghsa sev:high tech:aws technique:source-review vuln:auth-bypass vuln:ssrf

**Target:** Elixir SNS webhook signature verification (ExAws.SNS.verify_message/1)
**Root cause:** verify_message/1 passes message["SigningCertURL"] straight to PublicKeyCache.get/1 without checking HTTPS or that the host is an AWS SNS cert domain, so the RSA signature is verified against an attacker-controlled key.
**Steps:**
1. Generate an RSA keypair and host the public certificate at a URL reachable from the target, e.g. `http://attacker.example/cert.pem`.
2. Build a forged `Notification` payload with arbitrary `TopicArn` and `Message`, compute the canonical string-to-sign per SNS spec, sign with the attacker private key.
3. Set `SigningCertURL` to the attacker URL and `Signature` to the base64 signature.
4. POST the forged payload to any endpoint calling `ExAws.SNS.verify_message/1`.
5. Function returns `:ok`; app treats the message as authentic.
**How found:** Code reading of lib/ex_aws/sns.ex lines 475-483: the three-step verify flow validates params and SignatureVersion but never validates the SigningCertURL scheme or host before PublicKeyCache.get/1 fetches it.
**Exploitation:** Unauthenticated attacker POSTs a forged SNS Notification to a webhook that calls verify_message/1; the library fetches the attacker's cert, verifies the attacker's signature, and returns :ok, so the app accepts spoofed Notifications, SubscribeURL confirmations, or UnsubscribeConfirmations.
**Escalation:** Spoofed SubscribeURL auto-confirmation can hijack topic delivery; spoofed UnsubscribeConfirmation can disrupt legitimate subscriptions.
**Insight:** When a verifier fetches a key/cert from a URL embedded in the untrusted message, the URL itself is attacker input: check scheme and pin the host to the provider's cert domain before fetching, or the signature check is self-referential.