Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
💧 Hex
Not in CISA KEV

ex_aws_sns: Trusted-attacker `SigningCertURL` permits complete SNS signature bypassGHSA-8jgf-23q5-x7xx

Fix: ex-aws/ex_aws_sns@1853d28

GHSA-8jgf-23q5-x7xx is a CWE-295 vulnerability in ex_aws_sns. A fix is available for ex_aws_sns — see the affected versions and patch details below.

Also known asCVE-2026-47074EEF-CVE-2026-47074
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-8jgf-23q5-x7xx.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk
0.00%0.29%0.58%0.88%0.0%0.4%Jun 26Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
💧ex_aws_sns

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.

Description

Summary

ExAws.SNS.verify_message/1 fetches the signing certificate from the SigningCertURL field of the incoming SNS message without validating that the URL uses HTTPS or that its host is an AWS-owned SNS certificate domain. An unauthenticated attacker who can POST to any endpoint that calls verify_message/1 can supply an attacker-controlled SigningCertURL, sign a forged SNS message with their own RSA key, and cause the function to return :ok, completely bypassing SNS signature verification.

Details

In lib/ex_aws/sns.ex (lines 475–483), verify_message/1 performs three checks: validate_message_params/1 (confirms required fields are present), validate_signature_version/1 (confirms SignatureVersion == "1"), then signature verification. The signature step calls ExAws.SNS.PublicKeyCache.get(message["SigningCertURL"]) and passes the result to :public_key.verify/4.

Neither validate_message_params/1 nor any other step checks that SigningCertURL is an HTTPS URL or that the hostname matches the expected pattern (e.g. sns.<region>.amazonaws.com). PublicKeyCache.get/1 in lib/ex_aws/sns/public_key_cache.ex fetches whatever URL is provided and caches the certificate. The RSA signature then verifies against the attacker's own public key, and verify_message/1 returns :ok.

PoC

  1. Generate an RSA keypair and host the DER/PEM public certificate at any URL reachable from the target server (e.g. http://attacker.example/cert.pem).
  2. Build a forged Notification payload with an arbitrary TopicArn and Message, compute the canonical string-to-sign per the SNS spec, and sign it with the attacker private key.
  3. Set SigningCertURL to the attacker URL and Signature to the base64-encoded signature.
  4. POST the forged payload to any SNS webhook endpoint that calls ExAws.SNS.verify_message/1.
  5. The function returns :ok; the application treats the message as authentic.

Configurations

The application must expose an HTTP endpoint that calls ExAws.SNS.verify_message/1 on incoming request bodies (the standard SNS webhook pattern).

Impact

Complete SNS signature authentication bypass. Affects ex_aws_sns from 2.0.1 through 2.3.4. Consequences include spoofing arbitrary Notification payloads, auto-confirming attacker-controlled SubscribeURL values to hijack topic delivery, and spoofing UnsubscribeConfirmation to disrupt legitimate subscriptions. No authentication or special configuration on the attacker side is required. CVSS v4.0: 8.7 (HIGH).

Resources

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
💧Hexex_aws_sns≥ 2.0.1&&< 2.3.52.3.5mix deps.update ex_aws_sns

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ex_aws_sns, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update ex_aws_sns to 2.3.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8jgf-23q5-x7xx is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Summary `ExAws.SNS.verify_message/1` fetches the signing certificate from the `SigningCertURL` field of the incoming SNS message without validating that the URL uses HTTPS or that its host is an AWS-owned SNS certificate domain. An unauthenticated attacker who can POST to any endpoint that calls `verify_message/1` can supply an attacker-controlled `SigningCertURL`, sign a forged SNS message with their own RSA key, and cause the function to return `:ok`, completely bypassing SNS signature verification. ### Details In `lib/ex_aws/sns.ex` (lines 475–483), `verify_message/1` performs three
O3 Security · Impact-Aware SCA

Is GHSA-8jgf-23q5-x7xx in your dependencies?

Find it across Hex, including transitive dependencies.

Scan my dependencies How O3 SCA works
ex_aws_sns: Trusted-attacker `SigningCertURL` permits…