This is interesting from a security perspective, because it effectively means SVGs can contain scripts. If I was a security researcher, this sort of little-known but apparently widely supported feature is exactly where I would be looking for vulnerabilities.
Well, it's not really a thing. In a browser (the only kind of UA that'll really run any scripts in an SVG), SVG basically gets treated as SGML, all the DOM stuff is the same. If you include it as an image tag, the scripts don't tend to run, AFAIK.
Added to clarify: The types of things you could exploit in a scripted SVG but which wouldn't also apply to HTML, would tend to be exploitable in a static SVG as well.
It breaks expectations. I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context. Embedding or iframing without sandbox isn't/wasn't secure either.
A quick google search on SVG XSS gives:
https://hackerone.com/reports/148853 https://phabricator.wikimedia.org/T85850
Oh definitely, though that's more an administrative problem than a platform problem. Webmasters (or whoever that task falls to today) must understand that SVGs are exactly as dangerous as HTML files in exactly the same ways. Where you would sanitize user-provided HTML, you must also sanitize user-provided SVG.
Now that seems like a bug.