CVE-2025-65875 is a high severity arbitrary file upload flaw in the AddFont() function of FPDF 1.86 and earlier, scored CVSS 8.8. The record says a crafted PHP file could lead to code execution. I could not confirm a fixed version, so check fpdf.org and restrict font paths.
What's affected
The NVD record says FPDF version 1.86 and earlier are affected and names the AddFont() function. The weakness is CWE-434. FPDF is a PHP class for generating PDF files, and it is installed with Composer as setasign/fpdf.
I could not confirm a fixed version. The Setasign GitHub repository states that it only mirrors official FPDF releases from fpdf.org and that no development happens there. Check fpdf.org for the newest release and its notes. The record also links a GitLab advisory for a similar issue in another PDF font library, tc-lib-pdf-font (CVE-2024-56520), which shows the same family of problem.
The record gives few details, so the facts above are all I can state.
How to check if you're exposed
Find where FPDF enters your projects.
composer show setasign/fpdf
composer why setasign/fpdf
grep -rn "AddFont(" --include=*.php .
The last command lists calls to AddFont. For each one, look at where the file name or path argument comes from. If it is a fixed string in your own code that points to a font folder you control, the risk is low. If any part of it comes from user input, an uploaded file or a database field, treat it as dangerous.
Also check the web server layout: font definition and font files should sit in a folder that users cannot write to. Check whether your application lets users upload files into any folder FPDF reads from.
What to do now
- Run the commands above and note every AddFont call.
- Make sure the font file arguments are fixed values chosen by your code, never user input.
- Keep the font directory read only for the web server user and out of any upload path.
- Check fpdf.org for the latest release and update setasign/fpdf when one addresses this issue.
- If you cannot confirm a fix, treat the library as a trusted input only component and add the controls above.
- Run the free in-browser dependency scan to see FPDF and its known issues in your dependency manifest.
Why it matters
The class is CWE-434, unrestricted upload of a dangerous file type. The record says an attacker can run code by uploading a crafted PHP file through AddFont(). In FPDF, font definitions are PHP files that the library loads, so a path or file that an attacker controls can become code that runs inside your application.
That makes the real risk depend on your code, not only on the library version. A library function that loads code from a path is safe only if the path is trusted. Static code analysis is a good fit: searching for calls where untrusted input reaches a function that loads or includes files finds this kind of problem across a whole codebase.
Because the record is short and I could not confirm a vendor fix, the sensible stance is to harden how you call the function. Treat any later release from fpdf.org as the preferred update. The KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a patched FPDF release?
I could not confirm one. The GitHub mirror says it only copies official releases from fpdf.org, so check there.
Am I safe if no user input reaches AddFont()?
The described attack needs an attacker to supply a crafted PHP file. If only your own fixed font files are ever loaded, the exposure is far lower.
Sources
Last reviewed: 19 October 2026.
