Heap Buffer Overflow in NanoSVG: How a Crafted SVG File Could Lead to Arbitrary Code Execution

Severity: 🔴 Critical | File: 3rd/nanosvg.h | Fix: Bounds check before memcpy

Introduction

SVG files are everywhere. They power icons, illustrations, and user-uploaded graphics across millions of applications. Most developers treat them as harmless XML — after all, they're just vector graphics, right?

Wrong.

SVG parsers are complex pieces of software that interpret attacker-controlled data and translate it into memory structures. When that parsing logic skips a bounds check, the consequences can be catastrophic: heap corruption, memory disclosure, or full arbitrary code execution. That's exactly what was found — and fixed — in nanosvg.h, a popular single-header SVG parsing library widely embedded in C and C++ projects.

This post breaks down the vulnerability, explains how it could be exploited, and walks through the fix so you can understand not just what changed, but why it matters.

Background: What Is NanoSVG?

NanoSVG is a lightweight, single-header SVG parser written in C. Its appeal is simplicity — drop one header file into your project and you can parse SVG files. This convenience has made it a popular choice for game engines, GUI frameworks, and desktop applications.

The downside of that simplicity? Less code review, fewer eyes on edge cases, and a codebase that often gets vendored (copied directly into projects) and forgotten.

The Vulnerability Explained

The vulnerability is a heap buffer overflow — a class of memory safety bug where a program writes more data into a heap-allocated buffer than it was sized to hold. In NanoSVG's case, two distinct missing bounds checks were identified:

Issue 1: Unchecked Gradient Stop Count (Line 913)

When NanoSVG processes SVG gradient definitions, it copies gradient stop data using memcpy. The problematic pattern looks like this:

// VULNERABLE — no validation that nstops fits within allocated capacity
memcpy(grad->stops, stops, nstops * sizeof(NSVGgradientStop));

Here, nstops comes directly from parsing attacker-controlled SVG markup. If a crafted SVG declares more gradient stops than the destination buffer (grad->stops) was allocated to hold, the memcpy happily writes beyond the buffer's end — corrupting adjacent heap memory.

The allocation for grad->stops happens earlier with a fixed or estimated capacity. If the parser doesn't verify that nstops <= allocated_capacity before the copy, an attacker can supply an arbitrarily large number of stops.

Issue 2: Unbounded Attribute Stack Index (Line 766)

The second issue involves attrHead, an integer used as an array index into the attr attribute stack:

// VULNERABLE — attrHead not validated against array bounds
attr[attrHead].something = value;

The attr array has a fixed compile-time size. If deeply nested SVG elements push attrHead beyond that size, writes occur past the end of the array into adjacent heap memory. A crafted SVG with excessive nesting depth is all it takes.

How Could an Attacker Exploit This?

Let's walk through a realistic attack scenario:

Step 1 — Craft a malicious SVG

An attacker creates an SVG file containing a linear gradient with a fabricated stop count far exceeding any reasonable allocation:

<svg xmlns="http://www.w3.org/2000/svg">
  <defs>
    <linearGradient id="evil">
      <!-- Parser tricks: metadata claims N stops, actual data overflows buffer -->
      <stop offset="0%" stop-color="red"/>
      <!-- ... hundreds more stops ... -->
    </linearGradient>
  </defs>
  <rect fill="url(#evil)" width="100" height="100"/>
</svg>

Step 2 — Trigger the parse

The attacker delivers this file to a victim application — perhaps through a file upload feature, a document import dialog, or even an image preview in a file manager.

Step 3 — Heap corruption

The unchecked memcpy writes past the allocated buffer. Depending on what lives adjacent in the heap, this can:

• Corrupt heap metadata (enabling heap exploitation primitives)
• Overwrite function pointers or vtables
• Overwrite adjacent object fields to manipulate program logic

Step 4 — Code execution

With careful heap manipulation (heap feng shui), an attacker can turn the overflow into controlled writes, ultimately redirecting execution to attacker-supplied shellcode or ROP chains.

Real-World Impact

Any application that:
- Accepts SVG file uploads from users
- Renders SVG files from the filesystem or network
- Embeds NanoSVG as a vendored dependency

...is potentially vulnerable to remote or local code execution simply by processing a malicious SVG file. No authentication bypass required. No special privileges needed. Just a crafted file.

This is particularly dangerous in:
- Desktop applications that open user files (the attacker sends you an SVG)
- Web services with SVG upload features
- Game engines that load SVG assets
- Document editors that import SVG graphics

The Fix

The fix is conceptually straightforward: validate before you copy.

Gradient Stop Bounds Check

Before performing the memcpy for gradient stops, the patched code verifies that nstops does not exceed the allocated capacity of grad->stops:

// FIXED — validate nstops against allocated capacity before copy
if (nstops > grad->nstops) {
    // Handle error: too many stops, truncate or abort
    nstops = grad->nstops;
}
memcpy(grad->stops, stops, nstops * sizeof(NSVGgradientStop));

The key insight: the number of stops to copy must be bounded by what was actually allocated. If the parsed count exceeds capacity, the code either truncates to the safe maximum or returns an error — but it never writes beyond the buffer.

Attribute Stack Index Check

For the attribute stack overflow, the fix validates attrHead against the array's compile-time size before using it as an index:

// FIXED — check attrHead before indexing into attr array
#define NSVG_MAX_ATTR 128

if (attrHead >= NSVG_MAX_ATTR) {
    // SVG nesting too deep — handle gracefully
    return;
}
attr[attrHead].something = value;

By checking attrHead < NSVG_MAX_ATTR before every array access, deeply nested SVG elements cause a graceful parse failure rather than a heap overflow.

Why These Fixes Work

Both fixes follow the same principle: establish an invariant before a dangerous operation and enforce it. Instead of trusting that input-derived values are safe, the code now explicitly proves they are safe before using them.

This is the essence of defensive programming in C/C++: never assume attacker-controlled values are within expected ranges.

Prevention & Best Practices

1. Never Trust Input-Derived Lengths

Any length, count, or index that originates from parsed input must be validated before use in memory operations. This is especially true for:

• memcpy / memmove / strcpy length arguments
• Array indices
• Allocation sizes

// ❌ Dangerous
memcpy(dst, src, user_supplied_length);

// ✅ Safe
size_t safe_length = MIN(user_supplied_length, dst_capacity);
memcpy(dst, src, safe_length);

2. Use Safe Abstractions Where Possible

If your project allows C++, prefer std::vector, std::array, and range-checked containers over raw arrays and manual memcpy. In C, consider wrapper functions that enforce bounds:

static bool safe_memcpy(void* dst, size_t dst_size,
                         const void* src, size_t copy_size) {
    if (copy_size > dst_size) return false;
    memcpy(dst, src, copy_size);
    return true;
}

3. Enable Compiler and Runtime Protections

Modern compilers and platforms offer mitigations that make exploitation harder (though not impossible):

Enable ASan during development and testing — it would have caught both of these bugs immediately.

4. Fuzz Your Parsers

File parsers are prime targets for fuzzing. Tools like libFuzzer and AFL++ are excellent at finding exactly this class of bug:

# Example: fuzz an SVG parser with libFuzzer
clang -fsanitize=address,fuzzer svg_fuzz_target.c nanosvg_impl.c -o svg_fuzzer
./svg_fuzzer corpus/

A fuzzer generating random/mutated SVG inputs would likely trigger these overflows within minutes.

5. Audit Vendored Dependencies

NanoSVG is a vendored dependency — a copy pasted directly into the project. Vendored code is frequently forgotten after the initial copy:

• It doesn't get updated when upstream fixes bugs
• It doesn't appear in dependency scanners unless specifically configured
• Developers assume "it worked before, it's fine"

Recommendations:
- Maintain an inventory of all vendored code
- Subscribe to security advisories for vendored libraries
- Consider using package managers (vcpkg, Conan, Hunter) that make updates easier
- Run static analysis tools (Coverity, CodeQL, clang-tidy) on vendored code

6. Relevant Security Standards

This vulnerability maps to well-documented weakness categories:

• CWE-122: Heap-based Buffer Overflow
• CWE-129: Improper Validation of Array Index
• CWE-787: Out-of-bounds Write
• OWASP A03:2021: Injection (includes memory injection via crafted input)

The SEI CERT C Coding Standard rules ARR38-C (guarantee that library functions do not form invalid pointers) and MEM35-C (allocate sufficient memory for an object) are directly applicable here.

Lessons for Developers

This vulnerability illustrates several patterns that appear repeatedly in security research:

🔴 Complexity hides bugs. SVG is a complex format. The more states a parser must handle, the more edge cases exist, and the more likely that some path skips a safety check.

🔴 "It's just a file" is a dangerous assumption. Files are user input. Any file format parser must treat its input as potentially adversarial.

🔴 Single-header libraries accumulate technical debt. The convenience of dropping in a .h file comes with the responsibility of maintaining it — including security patches.

🟢 Bounds checking is cheap. The performance cost of an integer comparison before a memcpy is negligible. The security cost of skipping it can be catastrophic.

🟢 Defense in depth helps. Even if a bounds check is missed, ASan in CI, fuzzing, and exploit mitigations like ASLR reduce the likelihood and impact of exploitation.

Conclusion

The heap buffer overflow in nanosvg.h is a textbook example of why input validation is non-negotiable in C/C++ code that processes untrusted data. Two missing bounds checks — one on a gradient stop count, one on an attribute array index — created a critical code execution vulnerability reachable simply by opening a malicious SVG file.

The fix is elegant in its simplicity: check that values derived from input are within safe bounds before using them in memory operations. That's it. Two comparisons stand between a working SVG parser and a critical exploit.

As developers, the key takeaways are:

1. Treat all parsed input as adversarial — especially in C/C++
2. Validate lengths and indices before every memory operation
3. Fuzz your parsers — they will find what code review misses
4. Keep vendored dependencies updated and audited
5. Enable compiler sanitizers in your development and CI pipelines

Security isn't about perfection — it's about building layers of protection so that when one layer fails, another catches the fall. Start with the basics: validate your inputs, check your bounds, and never trust a file just because it has a .svg extension.

This vulnerability was identified and patched as part of a proactive security audit. The fix has been verified by automated scanner re-scan and LLM-assisted code review.

Have questions about memory safety or SVG parsing security? Drop a comment below or reach out to the security team.

Further Reading:
- The Art of Software Security Assessment — Chapter on integer and buffer overflows
- Heap Exploitation Techniques — Understanding how heap overflows become exploits
- libFuzzer Tutorial — Getting started with coverage-guided fuzzing
- NanoSVG GitHub Repository — Upstream source