Successful exploitation allows an attacker to control the content and filename of a file written to a public storage path (/storage/media/YYYY/MM/<controlled-filename>.svg). If this publicly accessible SVG is subsequently rendered by a user's browser via an ``, <object>, or crafted link, the embedded script will execute, leading to persistent XSS.

Affected Product and Versions

• Product: VaahCMS
• Vulnerable Versions: 2.3.1

Vulnerable Endpoint

POST /backend/vaah/manage/media/upload

Critical Flaws

1. Race Condition/Timing Issue: The file is physically saved to disk before any content validation or MIME-type checking is performed.
2. Predictable Path: Malicious files are saved under a predictable public path: /storage/media/YYYY/MM/<controlled-filename>.svg.
3. No Cleanup: Files persist even if the backend returns an error (e.g., {"success": false, "errors": ["Unable to decode input"]}).

Exploitation Flow (Proof of Concept)

1. An attacker creates a specially crafted SVG file (see POC.svg).
2. The attacker sends a request to the vulnerable endpoint, controlling the filename (e.g., xss.svg).
3. Despite a failed backend response, the file is saved to disk, for example, at /storage/media/2025/08/xss.svg.
4. The attacker delivers a link or embeds the path (e.g., in a forum post or email) to a victim, triggering the payload.

Mitigation/Vendor Response

• Vendor: VaahCMS
• Status: Acknowledged, fix pending
• Temporary Mitigation:
  • Disable SVG file uploads entirely in the application
  • Implement server-side file type validation using MIME type checking before storing files
  • Use a dedicated SVG sanitizer library (e.g., enshrined/svg-sanitize for PHP)
  • Store uploaded files outside the web root and serve them through a secure proxy
  • Implement automatic cleanup of files that fail validation

🔗 References

• https://github.com/webreinvent/vaahcms/issues/301

Researcher: Thaw Phone Nyo

Date Disclosed: 2025/10/8