Most WAFs when blocking XSS will block obvious tags like script and iframe, but they don't block img.

Theoretically, you can img src='OFFSITE URL', but what's the worse that can happen? I know you can steal IPs with it, but is that it?

Like Anders says: Blender makes a very good point about authentications dialogs, and multithr3at3d is right about the on attributes.  Moreover, Anders add argues about the a tag and Matija have a good link about exploiting libraries doing the rendering.
Yet, no one talked about SVG yet.
First of all let's assume that all input and output is properly sanitized so tricks with onerror/onload are not possible.  And that we are not interested in CSRF.  We are after XSS.
The first concern about <img src= is that it does not follow same origin policy.  But that is probably less dangerous than it sounds.
What the browser does to render an < img > tag
< img src="http://domain/image.png" > is pretty safe because the browser will not invoke a parser (e.g. an XML or HTML parser), it knows that what will come is an image (gif, jpeg, png).
The browser will perform the HTTP request, and it will simply read the MIME of what came (in the Conetent-Type header, e.g. image/png).  If the answer does not have a Content-Type several browsers will guess based on the extension, yet they will only guess image MIMEs: image/jpeg, image/png or image/gif (tiff, bmp and ppm are dubious, some browsers may have a limited support to guess them).  Some browsers may even try to guess the image format based on magic numbers, but then again they will not try to guess esoteric formats.
If the browser can match the (possibly guessed) MIME it loads the correct rendering library, rendering libraries may have an overflow but that is another story.  If the MIME does not match against an image rendering library the image is discarded.  If the rendering library call fails the image is discarded as well.
The browser is never even close to an execution (script) context.  Most browsers enter execution context only from the javascript parser, and they can only reach the javascript parser from the application/javascript MIME or from the XML or the HTML parsers (since they may have embedded scripts).
To perform XSS we need an execution context.  Enters SVG.
Using < img src="domain/blah/blah/tricky.svg" >
Ouch, ouch ouch.  SVG is an XML based vector graphic format, therefore it invokes the XML parser in the browser.  Moreover SVG has the <script> tag!  Yes, you can embed javascript directly into SVG.
This is not as dangerous as it sounds at first.  Browsers that support SVG inside <img> tags do not support scripting inside the context.  Ideally you should use SVG inside <embed> or <object> tags where scripting is supported by browsers.  Yet, do not do it for user provided content!
I would argue that allowing SVG inside <img src= may be dangerous:

An XML parser is used to parse the SVG, whether it is inside the <img> or <object> tag.  The parser is certainly tweaked with some parameters to ignore <script> tags in the <img> context.  Yet, that is quite ugly, it is blacklisting a tag in a certain context.  And blacklisting is poor security.

<script> is not the only way to achieve execution context in SVG, there are also the onmouseover (and family) events present in SVG.  This is again tricky to blacklist.

The XML parser in browsers did suffer from problems in the past, notable with XML comments around script blocks.  SVG may present similar problems.

SVG has full support for XML namespaces.  Ouch again.  xlink:href is a completely valid construct in SVG and the browser inside the XML parser context will likely follow it.


Therefore yes, SVG opens several possible vectors to achieve execution context.  And moreover, it is a relatively new technology and therefore not well hardened.  I would not be surprised to see CVEs on SVG handling.  For example ImageMagick had problems with SVG.
