CVE-2026-32096: Plunk Email Platform SSRF Vulnerability

CVE-2026-32096 Overview

CVE-2026-32096 is a Server-Side Request Forgery (SSRF) vulnerability discovered in Plunk, an open-source email platform built on top of AWS SES. Prior to version 0.7.0, the SNS webhook handler lacked proper validation of the SubscribeURL parameter, allowing an unauthenticated attacker to send crafted requests that caused the server to make arbitrary outbound HTTP GET requests to any host accessible from the server.

Critical Impact

Unauthenticated attackers can exploit this SSRF vulnerability to access internal services, cloud metadata endpoints, and other resources accessible from the Plunk server, potentially leading to sensitive data exposure and lateral movement within the infrastructure.

Affected Products

• Plunk versions prior to 0.7.0
• Self-hosted Plunk deployments with exposed SNS webhook endpoints
• Plunk instances connected to AWS SES infrastructure

Discovery Timeline

• 2026-03-11 - CVE CVE-2026-32096 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32096

Vulnerability Analysis

This SSRF vulnerability exists in the SNS webhook handler within the Plunk API (apps/api/src/controllers/Webhooks.ts). When processing AWS SNS subscription confirmation requests, the application directly used the SubscribeURL value from the request body without validating that it pointed to a legitimate AWS SNS endpoint.

AWS SNS sends subscription confirmation requests containing a SubscribeURL that the server must fetch to complete the subscription handshake. An attacker could craft a malicious request mimicking an SNS subscription confirmation but with a SubscribeURL pointing to arbitrary internal or external resources. The server would then make an outbound HTTP GET request to the attacker-controlled URL.

This vulnerability type (CWE-918) is particularly dangerous in cloud environments where instance metadata endpoints (such as http://169.254.169.254/) can be accessed to retrieve IAM credentials, configuration data, and other sensitive information.

Root Cause

The root cause of this vulnerability is the absence of URL validation before processing the SubscribeURL parameter in SNS subscription confirmation requests. The vulnerable code trusted user-supplied input without verifying that:

1. The URL uses the HTTPS protocol
2. The hostname matches the expected AWS SNS endpoint pattern (sns.<region>.amazonaws.com)
3. The request originated from a legitimate AWS source

Attack Vector

The attack can be executed remotely over the network without authentication. An attacker sends a POST request to the SNS webhook endpoint with a Type of SubscriptionConfirmation and a malicious SubscribeURL. The server then performs an HTTP GET request to the attacker-specified URL, enabling:

• Access to internal services and APIs
• Cloud metadata harvesting (AWS IMDSv1)
• Port scanning of internal networks
• Data exfiltration through DNS or HTTP callbacks

The following patch demonstrates the security fix implemented in version 0.7.0:

       // Handle SNS subscription confirmation FIRST (before parsing Message field)
       if (req.body.Type === 'SubscriptionConfirmation') {
         signale.info('SNS Subscription Confirmation received');
-        signale.info('Subscribe URL:', req.body.SubscribeURL);
+
+        // Validate SubscribeURL to prevent SSRF: must be HTTPS and from an official AWS SNS host.
+        // Legitimate URLs look like:
+        //   https://sns.<region>.amazonaws.com/?Action=ConfirmSubscription&...
+        const subscribeURL: unknown = req.body.SubscribeURL;
+        if (typeof subscribeURL !== 'string') {
+          signale.warn('SNS SubscriptionConfirmation missing SubscribeURL');
+          return res.status(400).json({success: false, message: 'Invalid SubscribeURL'});
+        }
+
+        let parsedURL: URL;
+        try {
+          parsedURL = new URL(subscribeURL);
+        } catch {
+          signale.warn('SNS SubscriptionConfirmation has unparseable SubscribeURL');
+          return res.status(400).json({success: false, message: 'Invalid SubscribeURL'});
+        }
+
+        // Only allow HTTPS requests to official AWS SNS endpoints.
+        // The hostname must be exactly sns.<region>.amazonaws.com.
+        const SNS_HOST_RE = /^sns\.[a-z0-9-]+\.amazonaws\.com$/;
+        if (parsedURL.protocol !== 'https:' || !SNS_HOST_RE.test(parsedURL.hostname)) {
+          signale.warn(`SNS SubscriptionConfirmation rejected — disallowed SubscribeURL host: ${parsedURL.hostname}`);
+          return res.status(400).json({success: false, message: 'Invalid SubscribeURL'});
+        }

Source: GitHub Commit Changes

Detection Methods for CVE-2026-32096

Indicators of Compromise

• Unexpected outbound HTTP requests from the Plunk server to internal IP ranges (e.g., 169.254.169.254, 10.x.x.x, 172.16.x.x)
• SNS webhook endpoint receiving requests with non-AWS hostnames in the SubscribeURL field
• Unusual POST requests to the SNS webhook handler with Type: SubscriptionConfirmation from non-AWS source IPs
• Server logs showing fetch requests to internal services or cloud metadata endpoints

Detection Strategies

• Implement network monitoring to detect outbound HTTP requests to RFC 1918 private address ranges and cloud metadata endpoints
• Configure Web Application Firewall (WAF) rules to inspect POST requests to webhook endpoints for suspicious URL patterns
• Enable detailed logging on the Plunk API to capture all SNS webhook requests including SubscribeURL values
• Deploy egress filtering to alert on or block requests to sensitive internal endpoints from the application server

Monitoring Recommendations

• Monitor DNS queries from the Plunk server for unusual resolution patterns indicating SSRF callback attempts
• Set up alerts for HTTP requests to AWS metadata service (169.254.169.254) that do not originate from expected processes
• Review Plunk application logs for SNS SubscriptionConfirmation entries with non-AWS hostnames
• Implement SentinelOne network visibility to track outbound connections and identify anomalous traffic patterns

How to Mitigate CVE-2026-32096

Immediate Actions Required

• Upgrade Plunk to version 0.7.0 or later immediately to apply the security patch
• Restrict network egress from the Plunk server to only required external endpoints
• Implement IMDSv2 on AWS EC2 instances to mitigate SSRF attacks targeting instance metadata
• Review access logs for signs of exploitation prior to patching

Patch Information

The vulnerability has been fixed in Plunk version 0.7.0. The patch adds comprehensive URL validation to the SNS webhook handler, ensuring that SubscribeURL values are:

1. Valid HTTPS URLs
2. Directed only to official AWS SNS endpoints matching the pattern sns.<region>.amazonaws.com

Review the GitHub Security Advisory GHSA-xpqg-p8mp-7g44 for complete details. The fix can be examined in the security patch commit.

Workarounds

• If immediate upgrade is not possible, implement a reverse proxy or WAF rule to validate SubscribeURL values in incoming SNS webhook requests
• Block outbound requests from the Plunk server to internal IP ranges and cloud metadata endpoints at the network level
• Temporarily disable the SNS webhook endpoint if not actively required for operations
• Deploy network segmentation to isolate the Plunk server from sensitive internal resources

# Example: iptables rules to block SSRF to metadata endpoint
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -p tcp --dport 80 -j DROP