Loading vulnerability…
podinfo through 6.9.0 contains an arbitrary file upload issue in the /store endpoint. An unauthenticated attacker can send a crafted POST request to /store to upload arbitrary files. The application subsequently renders uploaded content without a restrictive Content-Security-Policy (CSP) and without adequate Content-Type validation, enabling attacker-supplied active content (e.g., HTML/JS) to be stored and executed in victims’ browsers as a stored cross-site scripting (XSS) condition.
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 (2 hidden).
This repository is a small standalone Python proof-of-concept exploit for CVE-2025-70849, described as a stored XSS issue in Podinfo's /store feature affecting versions <= 6.10.0. The repo contains two files: a Python mass scanner/exploitation script (CVE-2025-70849.py) and a README documenting the vulnerability and manual curl-based exploitation. The Python script is the main entry point and performs concurrent mass exploitation against a list of targets supplied in a text file. For each target, it normalizes the hostname, tries HTTPS first and then HTTP, and sends a POST request to /store with Content-Type: text/html and a hardcoded HTML payload (<h1>CVE-2025-70849</h1>). If the server responds with HTTP 200 or 202 and returns JSON containing a hash field, the script treats the target as vulnerable, constructs the resulting /store/<hash> URL, prints success, and appends that URL to results.txt using a thread-safe file lock. Primary exploit capability: unauthenticated upload of arbitrary HTML to Podinfo's /store endpoint, resulting in persistent attacker-controlled content accessible via a generated hash URL. Although the bundled payload is only a harmless HTML heading, the exploit path clearly supports replacing it with arbitrary HTML/JavaScript, which is the core stored XSS capability. Operational characteristics: uses requests, disables TLS verification warnings, sets a browser-like User-Agent, uses a 10-second timeout, and scans with a thread pool of 10 workers. This makes it more than a simple single-target PoC but still a basic operational exploit with a hardcoded payload rather than a customizable framework. Repository structure is minimal and purpose-built: one executable Python script for mass exploitation and one README for vulnerability context, affected endpoint, affected versions, and example target/output. No shellcode, reverse shell, privilege escalation, persistence, or post-exploitation logic is present.
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.
1 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.