Problem
The profile image upload endpoint does not restrict file types beyond checking the file extension. SVG files are XML documents that can contain embedded JavaScript in <script> tags and event handler attributes. When an SVG is uploaded as a profile image and rendered in an <img> tag, script execution is blocked by the browser's SVG-in-img sandbox. However, if the SVG is served inline or via a direct URL in an <object> or <embed> tag, the scripts execute in the page's origin context, enabling stored XSS.
Steps to Reproduce
- Create a malicious SVG:
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.cookie)">
<circle cx="50" cy="50" r="50"/>
</svg>
- Upload it as a profile picture
- Visit any page that renders this SVG in a non-sandboxed context
Proposed Fix
- Block SVG uploads entirely for profile images; accept only JPEG, PNG, and WebP
- Validate magic bytes in addition to the file extension
- If SVG support is required, sanitize the SVG server-side using
svg-sanitize or DOMPurify with SVG namespace enabled
Complexity: Level 2 | Program: GSSOC '26
Problem
The profile image upload endpoint does not restrict file types beyond checking the file extension. SVG files are XML documents that can contain embedded JavaScript in
<script>tags and event handler attributes. When an SVG is uploaded as a profile image and rendered in an<img>tag, script execution is blocked by the browser's SVG-in-img sandbox. However, if the SVG is served inline or via a direct URL in an<object>or<embed>tag, the scripts execute in the page's origin context, enabling stored XSS.Steps to Reproduce
Proposed Fix
svg-sanitizeor DOMPurify with SVG namespace enabledComplexity: Level 2 | Program: GSSOC '26