I get some hits every then and there from different IPs, always the same scheme:

GET /blah/Resources/Public/Css/data:image/svg+xml;base64,... HTTP/1.1" 404 795 "http://some.referer/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

Browser seems outdated but legit, the base64-decoded svg-thingie seems legit too and reads:

<?xml version="1.0" ?>
<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0     0 1 1" preserveAspectRatio="none">
  <linearGradient id="grad-ucgg-generated" gradientUnits="userSpaceOnUse" x1="0%" y1="0%" x2="0%" y2="100%">
  <stop offset="0%" stop-color="#fdf226" stop-opacity="1"/>
  <stop offset="100%" stop-color="#fad71b" stop-opacity="1"/>
  <rect x="0" y="0" width="1" height="1" fill="url(#grad-ucgg-generated)" />

so my question is: is this a probe? for what? i read this interesting paper on hidden svg-payload but cannot find anything malicious.

2 Answers 2


It looks like a CSS script (check out the Referrer field) might contain an inline SVG.

This kind of inlining is not supported by all browsers, though. So where a modern Firefox might see


and display an image (or a SVG), an older browser would "believe" this to be a file name. So it appends the name to the base directory it was using, and blithely requests that filename. Which earns it a 404 instead of a cigar.

If this is the case, you either ignore the fact, or could use a Rewrite to answer with a remediation SVG to these malformed requests (it might be awkward if there's more than one SVG in the same virtual path - but you could use a SVG crafted to display 'Upgrade your browser!'), or modify the CSS, if you have access to it, to use a (slower) off-line SVG inclusion instead of the current online one.


Apparently, this used to happen a lot with users of old browser which also installed some "browse enhancing" widget. The widget was probably injecting some JS/CSS in the page, and the result wasn't always correctly interpreted by the browser. Rendering a gradient background in SVG and embed it as a base64 string was a trick used for IE9.

So, I'm convinced that it's nothing you should worry about -- there is a problem somewhere but it definitely seems to be not your problem.

  • according to the devs there is no svg used at all Aug 20, 2013 at 23:49
  • Check the referring URL. The request seems legit, not an exploit, and a 404 is its natural response, so a "probe" makes no sense. Does the Css path exist, at least?
    – LSerni
    Aug 21, 2013 at 6:43
  • Iserni: > Does the Css path exist, at least? nope. Aug 21, 2013 at 15:15
  • And you checked the referer's contents? Maybe there's some error in that file -- something like, you own gogle.com, and Google's webmasters misspelled one of their hrefs...
    – LSerni
    Aug 21, 2013 at 15:27
  • yeah, we run a grep over all access-log and checked all referers, all are legit from our domain and are working Aug 21, 2013 at 15:38

@all: i checked different referers: all of those are legit, but dont produce any kind of svg when browsing manually.

we checked the css-files and found no svg-references at all. the /Resources/Public/Css/ - path is not a valid. i assume this is some kind of probe for whatever.

we have now some rules to monitor those urls, and i'll report if there're some findings.

gracias, senores


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .