Loading vulnerability…
CVE-2026-32096 is a server-side request forgery vulnerability in Plunk, an open-source email platform built on AWS SES. In versions prior to 0.7.0, the SNS webhook handler can be triggered by an unauthenticated attacker with a crafted request that causes the Plunk server to issue an arbitrary outbound HTTP GET request to a host reachable from the server. The vulnerable condition is in the webhook request handling logic for SNS, where attacker-controlled input is used to direct a server-side network request without sufficient validation or restriction of the destination.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a compact, self-contained proof-of-concept for CVE-2026-32096, an unauthenticated SSRF in useplunk/plunk's SNS webhook handler. The repo contains four files: a README describing the vulnerability and reproduction steps, a docker-compose.yml that provisions a minimal vulnerable Plunk lab with Postgres and Redis, exploit.sh as the main exploit driver, and listener.py as the attacker-side callback server. The exploit flow is straightforward and operational. exploit.sh first waits for the Plunk API health endpoint to return HTTP 200, using Host: api.localhost to satisfy the application's domain-based routing. It then sends a forged AWS SNS SubscriptionConfirmation JSON message to POST /webhooks/sns with an attacker-controlled SubscribeURL. Because the vulnerable application allegedly fetches SubscribeURL without validating the SNS signature, the target performs an outbound HTTP request to the attacker listener. The script interprets a JSON success response as confirmation of SSRF. It also includes a bonus demonstration that swaps SubscribeURL to the AWS metadata endpoint 169.254.169.254 to illustrate post-exploitation impact in cloud environments. listener.py is not the exploit itself but supports exploitation by acting as the attacker-controlled HTTP endpoint. It logs inbound requests in detail and returns a plausible XML ConfirmSubscriptionResponse, making it useful for observing SSRF behavior and request metadata. The repository does not use a known exploit framework such as Metasploit or Nuclei. It is a direct bash-and-python PoC intended for local reproduction and validation. Its main capability is arbitrary outbound HTTP request triggering from the vulnerable server, which can be leveraged for internal network reachability testing, metadata access, and SSRF confirmation.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
7 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.