CVE-2026-114610 in fpdf2
Summary
by MITRE • 10/22/2026
fpdf2 is a PDF creation library for Python. From 2.5.0 until 2.8.8, fpdf2's SVGObject.build_xref() passes nested SVG <use> references to GraphicsContext.add_item(), whose default clone=True deep-copy behavior copies the complete referenced graphics tree during FPDF.image() processing. Repeating references at each nesting level makes the in-memory object count and processing work grow exponentially, allowing a small user-controlled SVG to consume excessive CPU and memory, raise MemoryError, fail PDF generation jobs, and reduce or exhaust worker capacity. ResourceAccessPolicy does not prevent the issue because the references are inline and require no external resource, XML entity, local file, or permissive network setting. This issue is fixed in version 2.8.8.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within fpdf2 versions ranging from 2.5.0 to 2.8.8 represents a critical algorithmic complexity flaw rooted in the library's handling of Scalable Vector Graphics, specifically concerning nested use references. When an SVG document containing deeply nested <use> tags is processed by the FPDF.image() method, the internal function svgObject.build_xref passes these references to graphicsContext.add_item(). The default behavior for this addition operation involves a deep copy mechanism where clone is set to true. This design choice intends to ensure that graphical elements are independent instances within the PDF structure; however, it inadvertently triggers an exponential expansion of in-memory objects when dealing with recursive or nested reference structures. Each level of nesting causes the referenced graphics tree to be duplicated entirely rather than being linked via a pointer or index, leading to a combinatorial explosion of data structures that must be managed by the application runtime.
From a technical perspective, this flaw aligns closely with CWE-400, which describes uncontrolled resource consumption due to algorithmic complexity issues often referred to as ReDoS-like patterns in non-textual contexts. The vulnerability does not rely on external inputs such as XML entities, local file paths, or network-based resources that might be restricted by standard security policies like ResourceAccessPolicy. Instead, the malicious payload is embedded directly within the SVG content itself, making it an inline threat vector. As the parser traverses the nested <use> elements, it recursively instantiates copies of all referenced graphical components at every level. A relatively small and simple SVG file with moderate nesting depth can therefore generate a massive number of internal objects, overwhelming the memory allocator and CPU scheduler before the PDF generation process even completes its initial phases.
The operational impact of this vulnerability is severe for any service that accepts user-supplied SVG files for conversion into PDFs without strict size or complexity limits. Attackers can craft specific SVG inputs designed to trigger this exponential growth, resulting in a Denial of Service condition characterized by excessive CPU utilization and memory exhaustion. In production environments where fpdf2 is used within worker processes such as those found in web frameworks like Flask or Django with Celery workers, this behavior can lead to the rapid termination of worker threads due out-of-memory errors. This not only disrupts legitimate user requests but also reduces the overall capacity of the application server, potentially causing a cascading failure if multiple concurrent attacks are launched against the service endpoint responsible for PDF generation.
Mitigation strategies must focus on both immediate patching and architectural safeguards. The primary remediation is to upgrade fpdf2 to version 2.8.8 or later, where this specific recursive copying behavior has been corrected to handle nested references more efficiently without exponential resource consumption. For environments that cannot immediately update the library, implementing strict input validation on incoming SVG files is essential. This includes limiting the depth of nesting in <use> tags and capping the total number of graphical elements allowed per document. Additionally, integrating a sandboxed execution environment or applying memory limits to the PDF generation process can contain the blast radius if an exploit attempt occurs. Security teams should also monitor for unusual spikes in CPU and memory usage associated with PDF processing endpoints as part of their ongoing threat detection efforts under ATT&CK techniques related to resource hijacking and denial of service attacks.