Skip to main content
CVE-2026-114609VulnerabilityPublished

Keeper commander: fpdf2 implicitly loads external URLs and local image paths when rendering attacker-controlled

Affects keeper-commanderSource GCVE Database

0
Compare
Authoritative record:CVE-2026-114609· Medium 5.8

Not known to be exploited · CVSS 5.8 Medium : upgrade to 18.1.1 when convenient.

Data as of 30 Oct 2026, 07:30 UTC

CVSS 3.1 base score
5.8Medium
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (GitHub_M)CVSS 3.15.8
Patch
Available – fixed in 18.1.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 22 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade keeper-commander to 18.1.1.

Affected software

ProductAffectedFixed in
Homebrewkeeper-commanderpkg:brew/keeper-commanderOther threatsAffected
  • >=17.0.21 <18.1.1
Fixed in
  • 18.1.1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## Summary `fpdf2` implicitly dereferences image resource references supplied to rendering APIs. If an application passes untrusted HTML, SVG, template data, or image paths into those APIs, `fpdf2` may issue outbound HTTP(S) requests or attempt to open local filesystem paths. This behavior is relevant in applications that render untrusted or user-provided input without sanitizing or restricting embedded resource references. ## Description In affected versions, `fpdf2` uses a shared internal image-loading mechanism for multiple features. This loader: * fetches `http://` and `https://` URLs over the network * opens other string values as local filesystem paths During document processing, resource references embedded in input content are automatically dereferenced using this mechanism. This behavior is reachable through: * `FPDF.image()` * `FPDF.write_html()` via HTML `<img src="...">` * `FPDF.image()` when rendering SVG files containing `<image href="...">` or `xlink:href="...">` * template image elements that forward values into `FPDF.image()` If an application renders attacker-controlled input through these APIs, that input can cause: * outbound HTTP(S) requests to attacker-chosen destinations * local file open attempts for attacker-chosen paths This may enable Server-Side Request Forgery (SSRF) in applications that render untrusted content. Local file access impact is limited: the library attempts to open the referenced path, but successful embedding depends on the target being a valid and supported image or SVG resource. `file://` URLs are not specially handled; raw filesystem paths such as `/path/to/file` or `../../file.png` are the relevant local-path cases. ## Impact This issue affects applications that render untrusted or partially trusted content using `fpdf2`. Applications may be impacted if they: * pass untrusted HTML into `write_html()` * render untrusted SVG with embedded `<image>` references * pass user-controlled strings into `image()` * allow untrusted template definitions or template field values to control image paths Potential impacts include: * outbound requests to internal or external network services * limited local file access attempts depending on file type and parsing success (limited to content that fpdf2 recognizes as a supported image or SVG resource) The severity depends on how `fpdf2` is integrated and whether untrusted input is allowed to control resource references. **Example scenarios** HTML: ```python pdf.write_html('<img src="http://127.0.0.1:8000/internal.png">') ``` SVG: ```xml <image href="http://169.254.169.254/latest/meta-data/" /> ``` Direct image path: ```python pdf.image("../../.env") ``` **Workarounds** Applications can mitigate this by: - not rendering untrusted HTML, SVG, or template content - rejecting user-controlled `src` / `href` / image-path values - mapping resources through an application-defined allowlist - converting user-supplied images to trusted in-memory objects before passing them to `fpdf2` **Credits** - @kule500 for identifying SSRF via HTML <img> handling - @BudongJW for identifying SVG <image> resource loading as an additional vector - @redyank for analysis of the shared image loading mechanism - @manop55555 for identifying a DNS rebinding bypass in the initial REMOTE_PUBLIC implementation

References

Community reviews

Loading reviews…