libgphoto2 CVE-2026-120452

Requires physical/local attack via a malicious or malformed USB camera that is handled by the jl2005c camlib driver in libgphoto2 (through 2.5.34). The attacker must supply small allocation-table values (nb_entries/alloc_table_size read from the device) together with a thumbnail header byte whose width/height imply more RGB565 samples than the input payload actually contains, so in-place byte-swapping overruns the buffer by ~30 KB. Exploitation also depends on passive user interaction (UI:P): the victim must connect the device and have the application process the thumbnail/preview. LIMITING FACTORS: no network vector (AV:P physical only); the specific jl2005c driver code path must be exercised (not all cameras/apps reach it); and only software at or before 2.5.34 lacking the two added bounds checks is affected. These gates confine realistic risk to hands-on, targeted attacks despite the memory-corruption primitive.

This is a genuinely medium/low-urgency issue rather than a high-priority emergency. The CVSS 4.0 vector (AV:P/AC:L/AT:N/PR:N/UI:P, base 5.2 Medium) is the decisive signal: exploitation requires PHYSICAL attacker access via a malicious USB camera plus passive user interaction (UI:P) to trigger thumbnail/preview processing through the jl2005c camlib. There is no KEV listing and no EPSS score supplied in the input, so there is no evidence of active or widespread exploitation - the attack surface (someone must connect an attacker-controlled USB device to a host running libgphoto2) inherently limits scale to targeted, hands-on scenarios. The reported impact is a heap out-of-bounds read AND write (CWE-787), with a ~30 KB overread leaking heap contents into preview images (VC:L/VI:L) and a high availability impact (VA:H) consistent with heap corruption and crashes. A public technical write-up reference exists (hackmd) and VulnCheck published an advisory, but the input does not confirm working weaponized exploit code. The vuln.today priority label is 'this_month', not act_now/emergency, which matches the physical-access gating. Net: real and worth patching on a normal cycle, not a drop-everything network-exploitable flaw.

An attacker crafts a malicious USB camera (or reflashes one) that the jl2005c driver recognizes, supplying small allocation-table values and a thumbnail header byte so that in-place RGB565 byte-swapping runs past the allocated buffer by roughly 30 KB. When the victim connects the device and the application generates a preview/thumbnail, libgphoto2 performs an out-of-bounds heap read and write, leaking adjacent heap contents into the preview image and corrupting memory. A public PoC reference and VulnCheck advisory describe the flaw; the input does not confirm a verified working exploit, and the physical USB vector plus required preview action (UI:P) make this a targeted, close-access scenario.