Hosts that process SVG can potentially be vulnerable to SSRF, LFI, XSS, RCE because of the rich feature set of SVG.
All of these methods specify a URI, which can be absolute or relative. File and HTTP protocol are important to test, but it could also support other protocols depending on the implementation (e.g. PHP stream schemes), including javascript: and data:.
This document contains a list of the ways about to abuse this functionality in SVG files.
Note that some services that claim to not accept SVG as an input format actually do with a little coaxing.
For uploads, send a JPEG/PNG mime type and filename.
For downloads, have a JPEG/PNG filename and mime type. If refused, check for TOCTOU on the URL (double fetch) and if it follows redirects.
Mime sniffing confusion is probably also possible. Mime sniffing confusion as SVG is difficult to sniff because it can start with extra XML garbage. In fact, the standard file command doesn't include any SVG magic, so it's likely up to the individual implementations.
Images
SVG can include external images directly via the <image> tag.
Note: due to the nature of XSLT, the input doesn't actually have to be a valid SVG file if the xml-stylesheet is ignored, but it's useful to bypass filters.
Also, because this template just wholesale replaces the entire "old" image with the new one.
Javascript
Inline
SVG can natively include inline javascript, just like HTML.