Hack the Elephant One Bite at a Time: NUL byte SQL Injection in pdo_firebird and NULL Pointer Dereference in PDO via pdo_pgsql

Written by and on

The PHP core and its bundled extensions are often viewed as a mature and well-hardened attack surface, but low-level implementation bugs can still slip through. In our earlier research article Hack the Elephant One Bite at a Time: JPEG-Related Memory-Safety Bugs in PHP, we showed memory-safety issues triggered during JPEG parsing in PHP.

As we continued in this direction, we launched a deeper review of PDO as a whole, along with its individual components: the DBMS-specific drivers used to connect to different backends. The scope of this work grew to the point where the analysis surfaced additional vulnerabilities in third-party dependencies. In particular, we identified an integer overflow in PostgreSQL’s client library (libpq), documented in our write-up Attack arithmetic: how an integer overflow in PostgreSQL libpq leads to denial of service. We also uncovered an information disclosure issue in the Firebird 3 client library (fbclient): when a Firebird 3 client communicates with Firebird 4 or later server versions, incorrect length values in XSQLDA fields can trigger an out-of-bounds read and expose unintended data.

However, the core outcomes of our work relate to the PDO extension’s architecture itself. During the audit, we documented a number of driver-specific behaviors and multiple flaws in how drivers interact with their target DBMSs. In this article, we take a detailed look at two representative vulnerabilities:

Through hands-on examples, we show how a deep review of key driver routines exposed serious weaknesses in the defensive mechanisms that web application developers have trusted for years.

Continue reading

Hack the Elephant One Bite at a Time: JPEG-Related Memory-Safety Bugs in PHP

Written by on

PHP is one of the world’s most popular programming languages. The PHP core itself is rarely perceived as an attack surface — attention usually shifts to frameworks and third-party libraries. However, a significant portion of real-world application logic relies on built-in functions from the ext/standard extension, which handles strings, query parameters, data formats, and files. During our research into the C code of this extension, we discovered several memory management bugs. In this article, we take a deep dive into two of them: a heap memory disclosure in getimagesize and a heap buffer overflow in iptcembed.

Continue reading

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

Written by , and on

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 Parties, Deserialization of Untrusted Data, Server-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

Bypassing browser tracking protection for CORS misconfiguration abuse

Written by on

Cross-Origin Resource Sharing (CORS) is a web protocol that outlines how a web application on one domain can access resources from a server on a different domain. By default, web browsers have a Same-Origin Policy (SOP) that blocks these cross-origin requests for security purposes. However, CORS offers a secure way for servers to specify which origins are allowed to access their assets, thereby enabling a structured method of relaxing this policy.

In CORS, the server sends HTTP headers to instruct the browser on rules for making cross-origin requests. These rules define whether a particular HTTP request (such as GET or POST) from a certain origin is allowed. By managing the CORS headers, a server can control its resource accessibility on a case-by-case basis. This maintains the flexibility of cross-origin sharing without compromising overall security.

Continue reading