CVE-2026-47074: ex_aws_sns Auth Bypass Vulnerability

CVE-2026-47074 Overview

CVE-2026-47074 is an improper certificate validation flaw [CWE-295] in the ex_aws_sns Elixir library, which provides Amazon Simple Notification Service (SNS) bindings for the ExAws ecosystem. The ExAws.SNS.verify_message/1 function fetches the signing certificate from the SigningCertURL field of an incoming SNS message without confirming that the URL uses HTTPS or that the host belongs to an AWS-owned SNS certificate domain. An unauthenticated attacker can supply an attacker-controlled SigningCertURL, sign a forged SNS message with their own private key, and cause the verification function to return :ok. The issue affects ex_aws_sns from version 2.0.1 up to but not including 2.3.5.

Critical Impact
Attackers can bypass SNS signature verification entirely and inject forged messages into any endpoint that trusts verify_message/1, breaking the integrity assumptions of SNS-driven workflows.

Affected Products

ex_aws_sns versions 2.0.1 through 2.3.4
Elixir applications calling ExAws.SNS.verify_message/1
Elixir applications relying on ExAws.SNS.PublicKeyCache.get/1 for SNS signature trust

Discovery Timeline

2026-05-28 - CVE-2026-47074 published to NVD
2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-47074

Vulnerability Analysis

The vulnerability resides in lib/ex_aws/sns.ex and lib/ex_aws/sns/public_key_cache.ex, specifically the routines 'Elixir.ExAws.SNS':verify_message/1 and 'Elixir.ExAws.SNS.PublicKeyCache':get/1. SNS signature verification depends on retrieving a trusted X.509 certificate that AWS publishes only at specific sns.<region>.amazonaws.com hosts over HTTPS. The vulnerable code instead trusts whatever URL appears in the message's SigningCertURL field. Because the message itself is attacker-controlled, the certificate used to validate the message is also attacker-controlled, which collapses the verification model.

Root Cause

The root cause is missing validation of the certificate source. verify_message/1 does not enforce that the SigningCertURL scheme is https and does not constrain the hostname to AWS SNS certificate domains. The PublicKeyCache.get/1 helper caches and returns whatever certificate is fetched from that URL. No pinning, allowlist, or hostname check exists between input parsing and cryptographic verification.

Attack Vector

An unauthenticated attacker who can reach an HTTP endpoint that forwards request bodies into ExAws.SNS.verify_message/1 crafts a JSON payload mimicking an SNS notification. The attacker hosts a self-signed certificate and corresponding private key on an attacker-controlled URL, places that URL in SigningCertURL, signs the message body fields with the matching private key, and submits the payload. The library fetches the rogue certificate, validates the attacker's signature against the attacker's public key, and returns :ok. Downstream code then processes the forged Subscribe, Notification, or UnsubscribeConfirmation message as if it originated from AWS.

No proof-of-concept code is published in the enriched data; technical details are documented in the GitHub Security Advisory GHSA-8jgf-23q5-x7xx and the CNA CVE-2026-47074 Details.

Detection Methods for CVE-2026-47074

Indicators of Compromise

Inbound SNS-shaped POST requests containing a SigningCertURL whose host does not match sns.<region>.amazonaws.com or whose scheme is not https.
Outbound HTTP/HTTPS requests from application servers to unexpected domains immediately after receiving SNS webhook traffic, indicating certificate fetches from attacker infrastructure.
Application logs showing successful verify_message/1 results followed by SNS actions originating from IP ranges outside AWS.

Detection Strategies

Inspect web server and reverse proxy logs for requests to SNS webhook endpoints carrying non-AWS SigningCertURL values.
Add application-layer logging around ExAws.SNS.verify_message/1 to record the SigningCertURL and the resolved host of every verified message.
Compare deployed ex_aws_sns versions across services against the fixed release 2.3.5 using SBOM or mix.lock inventories.

Monitoring Recommendations

Alert on egress connections from application hosts to domains other than *.amazonaws.com triggered by SNS handler code paths.
Track failure-to-success ratios on SNS verification: a sudden rise in successful verifications from new source IPs warrants review.
Monitor dependency advisories from the OSV Vulnerability EEF-CVE-2026-47074 feed for downstream library updates.

How to Mitigate CVE-2026-47074

Immediate Actions Required

Upgrade ex_aws_sns to version 2.3.5 or later in every Elixir service that processes SNS messages.
Audit all HTTP routes that invoke ExAws.SNS.verify_message/1 and confirm they are now protected by the patched release.
Rotate any secrets, tokens, or downstream actions that may have been triggered by forged SNS messages while a vulnerable version was deployed.

Patch Information

The maintainers fixed the issue in ex_aws_sns2.3.5. The change validates that the SigningCertURL uses HTTPS and that the host belongs to an AWS-owned SNS certificate domain before fetching the certificate. The corrective change is documented in the GitHub Commit Update and the GitHub Security Advisory GHSA-8jgf-23q5-x7xx.

Workarounds

If upgrading immediately is not possible, wrap verify_message/1 with a pre-check that rejects any message whose SigningCertURL is not https and whose host does not match ^sns\.[a-z0-9-]+\.amazonaws\.com$.
Restrict egress from application servers so that certificate fetches can only reach AWS SNS endpoints, neutralizing attacker-controlled URLs.
Place SNS webhook endpoints behind authenticated channels or signed URLs while the upgrade is rolled out.

bash

# Pin the patched release in mix.exs and refresh the lockfile
# mix.exs
# {:ex_aws_sns, "~> 2.3.5"}

mix deps.update ex_aws_sns
mix deps.get
mix compile --force