I'm not sure about this. I think this might cause unnecessary fear relative to the risk factor for an SVG (Particularly once CSP is implemented).

Unlike PDFs, we do try to detect malicious files (albeit, not perfectly), and the type of exploits that malicious pdfs have done are quite a bit worse then what someone can do with a malicious svg in a browser. (barring browser bugs)

Yeah… if we want this, I think we should implement both whitelisting for SVGs (for files that are definitely perfectly safe) and blacklisting (for files that are definitely not safe), and allow files in the grey area in the middle with this warning.

In T139168#2422485, @Bawolff wrote:

Unlike PDFs, we do try to detect malicious files (albeit, not perfectly), and the type of exploits that malicious pdfs have done are quite a bit worse then what someone can do with a malicious svg in a browser. (barring browser bugs)

In SVG MediaWiki blocks some content on upload, however it is not retroactively applied to uploaded files. I think this should be fixed, by a Bot, see T281506 (Sorry I reported a security-task which is imho an overkill.)

In T281506, @JoKalliauer wrote:

Illegal SVG-Pattern T279238 are blocked during upload, however they are not retroactively sanitized, so old images still contain security-issues.

How is it possible to find such svg-files (incuding overwritten ones)?

The overwritten svgs should be deleted, the others should be fixed.

Most illegal pattern can be fixed by https://svgworkaroundbot.toolforge.org/ or User:SVGWorkaroundBot . Most common pattern are imho harmless invalid structures such as xlink:href="data:image/jpg;base64,/9j/4AAQSkZJRgABA... (jpg instead of jpeg) , which can be fixed with the Magic number. I never run in any real security-issue, but those blocks should imho be applied retroactively.