[xml]

A word of caution: There are SVGs which can freeze a page, so make sure that you do not link to any third party SVGs. This is a known bug, but both the Google Chrome and Mozilla team do not want to fix it.

Here is an evil example SVG for demonstration.

DON'T CLICK THIS LINK UNLESS YOU WANT TO RISK CRASHING YOUR BROWSER!

https://asdf10.com/danger.svg

[mmis1000]

Crash a single page or even the whole browser isn't really a security problem though. In fact, there are so many ways to freeze the whole tab or even browser ui with build-in function if you apply it way too many times. (For example, a long chain of blur filters will make the chrome ui non responsive because the render time will skyrocket.)

Although if the affect area does escape the tab, the issue will have higher priority because that would be annoying to user.

[pcthrowaway]

Wait so are recursive XXE attacks like (I'm assuming) this one possible on Github READMEs? Or have they somehow mitigated them?

[nneonneo]

It's recursive, but not XXE. It is 20 layers of nested SVG groups, where the first group contains 10 blue circles, and every subsequent group contains 10 of the previous group. This would render as around 10^20 blue circles.

[pcthrowaway]

SVG is XML-based, unlike HTML which follows the SGML spec

From curling the malicious page you can also see:

    <?xml version="1.0" encoding="UTF-8"?>
        <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="1000" height="1000">

[nneonneo]

Yes, SVGs are XML-based and may be vulnerable to generic XML-based XML external entity (XXE) or exponential entity expansion attacks, but this particular malicious SVG is using SVG-specific features to create the resource exhaustion.

[hashstring]

I think external entities can be disabled completely right, but who knows, it may pay off to check out what GH did here :)