Allow admins/editors to upload SVGs

[iandunn]

#24251 has a broad and lengthy debate about allowing SVG uploads. Most of it is unresolved, but one thing that I think has consensus is allowing admins and editors to upload SVGs. They already have the ability to add unfiltered HTML, so any JS inside SVGs doesn't necessarily pose a greater risk.

There are a few differences, though:

• It's easier to trick an admin into uploading a malicious SVG than it is to trick them into pasting JS into a post. Most folks think that SVGs are just images, not mini XML applications that can execute JavaScript.
• We'd probably want to display SVGs in the media library, the editor, etc. That means that any malicious JS would automatically execute inside wp-admin, which is something we've ​intentionally avoided in the past, even for admins.

I think we should consider an approach like this:

1. Allow uploading SVGs if current_user_can( 'unfiltered_html' ). Update get_allowed_mime_types(), wp_get_ext_types(), etc.
2. Run the SVG through DOMPurify before/after uploading. We can't trust the client side, so this doesn't work for letting all users upload SVGs. For trusted users, though, it adds an extra layer of protection. This could make it safe enough to allow SVGs to be shown inside wp-admin.

These are all the different places that I can think of where images can be uploaded. Many are similar, but a patch would probably need to account for a few different cases.

• media-new.php multifile uploader
• media-new.php browser uploader
• upload.php Add media file button
• Blocks: Image, Gallery, Cover, File
• Block Editor Set featured image button
• Classic Editor Add Media button

[iandunn]

@otto42 reminded me that ​SVG's can't execute JavaScript when embedded using the <img> tag.

So, that avoids any problems with displaying SVGs in the Media Library. We'd just want to add a comment in the code that it should never be changed to a different method (e.g., <svg>), to avoid a regression.