Affected versions of MISP serve uploaded SVG images inline without a restrictive browser sandbox.
The commit explains that SVG files are XML documents rather than passive bitmap images. While scripts inside SVG do not execute when the SVG is rendered through a normal <img>, they can execute when the SVG is navigated to directly or embedded as a document. In that case, malicious <script> elements, event handlers, or javascript: URLs execute on the MISP origin with the viewer’s session.
The affected use cases include:
- organisation SVG logos;
- event-report SVG pictures.
Importantly, the vulnerable behavior is on the serve path, not merely the upload path: the patch notes that a malicious SVG uploaded while SVG support was enabled could remain dangerous even after uploads were later disabled.
Version affected: ≤2.5.45
A new sandboxInlineFile() method is added to RestResponseComponent. When a file is served inline (download=false) and its type is SVG (svg, svgz, or image/svg+xml), the response is augmented with a Content-Security-Policy header containing the sandbox directive (which assigns an opaque origin and disables script execution, plugins, and form submission) along with restrictive default-src, style-src, img-src, and font-src directives that still permit rendering of inline styles, embedded raster images, and data: fonts. An X-Content-Type-Options: nosniff header is also set. The method is invoked from both the generic sendFile() path and the org-logo endpoint. The enable_svg_logos setting description is updated to warn administrators that SVG files remain XML documents and should be left disabled unless required.