Hi, I'm Andre

GitHub LinkedIn

CVE-2026-32096: When Documentation Becomes the Vulnerability

Mar 30, 2026


Introduction

A gap in the AWS SNS documentation and sample code leads developers to potentially introduce Server-Side Request Forgeries (SSRF) in their applications. Tracing that pattern across the open-source ecosystem led to my discovery of CVE-2026-32096.

CVE-2019-6715 was the origin of this research, and what I believe to be the earliest occurrence of such behavior.


What is AWS SNS

AWS Simple Notification Service (SNS) is a pub/sub messaging service. SNS topics can deliver messages to a variety of subscriber types: Lambda functions, SQS queues, and external applications via HTTP/S endpoints. In this post, we will focus on the setup using HTTP/S for external applications.

Before notifications start flowing, SNS needs to know where to send the data. When you subscribe your endpoint, AWS sends a SubscriptionConfirmation message containing a SubscribeURL. Your application makes a GET to that URL, and the subscription is active. This is a one-time step that exists to verify endpoint ownership, preventing someone from subscribing an arbitrary URL without the owner’s consent.

sequenceDiagram participant App as Application participant SNS as AWS SNS Note over App,SNS: One-time confirmation App->>SNS: 1. Subscribe endpoint to topic SNS->>App: 2. POST SubscriptionConfirmation (includes SubscribeURL) rect rgba(255, 0, 0, 0.1) App->>SNS: 3. GET SubscribeURL end SNS->>App: 4. Subscription confirmed Note over App,SNS: Ongoing notifications SNS->>App: 5. POST Notification SNS->>App: 6. POST Notification SNS->>App: ...

After confirmation, every message published to the topic is automatically sent to your endpoint. Your application receives events (email bounces, transcoding results, alerts) without any further handshake.


The Bad Docs

As a developer implementing SNS, you’d likely stumble upon some documentation. Confirm your Amazon SNS subscription describes the process mentioned above:

  1. After subscribing to an Amazon SNS topic, Amazon SNS sends a confirmation message to your endpoint. This message contains a SubscribeURL that you must use to confirm the subscription.

  2. Your endpoint must be set up to listen for incoming messages from Amazon SNS. When the confirmation message arrives, extract the SubscribeURL from the message.

  3. Once you have the SubscribeURL, you can confirm the subscription in one of two ways:
    • Automatic confirmation — Your endpoint can automatically confirm the subscription by sending an HTTP GET request to the SubscribeURL. This method does not require manual intervention.
    • Manual confirmation — If automatic confirmation is not set up, copy the SubscribeURL from the confirmation message and paste it into your browser’s address bar. This will confirm the subscription manually.
  4. You can also verify the subscription status using the Amazon SNS console.

AWS’s official example repository awsdocs/aws-doc-sdk-examples also includes an Elastic Transcoder notification handler that does as described:

// JobStatusNotificationsSampleNotificationHandler.php
// Read raw POST body
$data = file_get_contents('php://input');
$notification = json_decode($data, true);

if ($notification['Type'] == 'SubscriptionConfirmation') {
    // ...
    echo 'url: ', $notification['SubscribeURL'];
    $response = file_get_contents($notification['SubscribeURL']);
    // ...
}

Just with this context, implementing the automatic confirmation is essentially introducing an SSRF into your application. An attacker knowing the endpoint could simply control the SubscribeURL.

sequenceDiagram participant A as Attacker participant App as Vulnerable app participant T as "Target (internal / metadata / attacker)" Note over A,T: No valid SNS signature verified A->>App: POST fake SubscriptionConfirmation JSON rect rgba(255, 0, 0, 0.1) App->>T: GET SubscribeURL (SSRF) end T-->>App: Response (leaked metadata, scan, etc.)

The Good Docs

Other parts of AWS’s documentation describe the process of verifying SNS messages.

When should you verify Amazon SNS signatures?

To correctly verify SNS message signatures, follow these best practices:

Each SNS message includes some important fields for verification.

{
  "Type" : "SubscriptionConfirmation",
  "MessageId" : "165545c9-2a5c-472c-8df2-7ff2be2b3b1b",
  "Token" : "2336412f37f...",
  "TopicArn" : "arn:aws:sns:us-west-2:123456789012:MyTopic",
  "Message" : "You have chosen to subscribe to the topic...",
  "SubscribeURL" : "https://sns.us-west-2.amazonaws.com/?Action=ConfirmSubscription&...",
  "Timestamp" : "2012-04-26T20:45:04.751Z",
  "SignatureVersion" : "1",
  "Signature" : "EXAMPLEpH+...",
  "SigningCertURL" : "https://sns.us-west-2.amazonaws.com/SimpleNotificationService-...pem"
}

In summary, verification works by using asymmetric cryptography. AWS signs each message with a private key. Your application fetches the corresponding public key from SigningCertURL as an X.509 certificate and checks the Signature field against the message contents.

import base64
import requests
from cryptography import x509
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding

cert = x509.load_pem_x509_certificate(requests.get(message["SigningCertURL"]).content)
public_key = cert.public_key()
public_key.verify(
    base64.b64decode(message["Signature"]),
    build_string_to_sign(message),
    padding.PKCS1v15(),
    hashes.SHA256()  # or SHA1 for SignatureVersion 1
)

AWS has also published two libraries for PHP and JS with proper implementations of validation:


CVE-2026-32096

Utilizing a couple of dorks to confirm my theory, GitHub’s code search returned over a thousand hits.

SubscribeURL SubscriptionConfirmation language:php
SubscribeURL SubscriptionConfirmation language:python
SubscribeURL SubscriptionConfirmation language:...

After filtering by repo activity, GitHub stars, and Claude triage, I reported the vulnerability to a couple of candidates. One of them was Plunk, an open-source email platform with ~4,900 stars on GitHub.

I submitted a security advisory for the SSRF vulnerability in its SNS webhook handler, which was assigned CVE-2026-32096.

Timeline

Shoutout to @driaug for the quick response and fast patch!

I’ve since also submitted a report to AWS through HackerOne regarding the insecure sample code in awsdocs/aws-doc-sdk-examples.


References

AWS Documentation

AWS Repositories

CVEs and Advisories

Security Resources