Blind trust: what is hidden behind the process of creating your PDF file?

Every day, thousands of web services generate PDF (Portable Document Format) files—bills, contracts, reports. This step is often treated as a technical routine, “just convert the HTML,” but in practice it’s exactly where a trust boundary is crossed. The renderer parses HTML, downloads external resources, processes fonts, SVGs, and images, and sometimes has access to the network and the file system. Risky behavior can occur by default, without explicit options or warnings. That is enough for a PDF converter to become an SSRF proxy, a data leak channel, or even cause denial of service.

We therefore conducted a targeted analysis of popular HTML-to-PDF libraries written in the PHP, JavaScript, and Java languages: TCPDF, html2pdf, jsPDF, mPDF, snappy, dompdf, and OpenPDF. During the research, the PT Swarm team identified 13 vulnerabilities, demonstrated 7 intentional behaviors, and highlighted 6 potential misconfigurations. These included vulnerability classes such as Files or Directories Accessible to External PartiesDeserialization of Untrusted DataServer-Side Request Forgery, and Denial of Service.

PDF generation is increasingly common across e‑commerce, fintech, logistics, and SaaS. Such services are often deployed inside the perimeter, next to sensitive data, where network controls are looser. This means that even a seemingly harmless bug in the renderer can escalate into a serious incident: leakage of documents, secrets, or internal URLs.

In this article, we present a threat model for an HTML-to-PDF library, walk through representative findings for each library, and provide PoC snippets.

Continue reading

Getting XXE in Web Browsers using ChatGPT

A year ago, I wondered what a malicious page with disabled JavaScript could do.

I knew that SVG, which is based on XML, and XML itself could be complex and allow file access. Is the Same Origin Policy (SOP) correctly implemented for all possible XML and SVG syntaxes? Is access through the file:// protocol properly handled?

Since I was too lazy to read the documentation, I started generating examples using ChatGPT.

Continue reading

Source Code Disclosure in ASP.NET apps

Recently, I came across an interesting ASP.NET application. It appeared to be secure, but it accidentally revealed its source code. Later, I found out that the used method is applicable to disclose code of many other .NET web applications.

Here are the details. If you just see an IIS or .NET app, this is for you.

Continue reading

Grafana 6.4.3 Arbitrary File Read

Grafana is an open-source application used for analytics, monitoring, and data visualization. Thousands of companies use Grafana, including major representatives such as PayPal, eBay, and Intel.

Last fall I found an Authenticated Arbitrary File Read vulnerability (CVE-2019-19499) in this system. Here I’ll share the details about how this vulnerability worked.

Continue reading

Vulnerabilities in the Openfire Admin Console

Openfire is a Jabber server supported by Ignite Realtime. It’s a cross-platform Java application, which positions itself as a platform for medium-sized enterprises to control internal communications and make instant messaging easier.

I regularly see Openfire on penetration testing engagements, and most of the time all interfaces of this system are exposed to an external attacker, including the administrative interface on 9090/http and 9091/https ports:

Openfire Administration Console

Since the Openfire system is available on GitHub, I decided to examine the code of this web interface. This is a short writeup about two vulnerabilities I was able to find.

Continue reading