libgphoto2 EUVD-2026-115211

Requires physical attachment of a USB device that spoofs a Jeilin JL2005B/C/D camera so that libgphoto2's jl2005c camera driver is selected and jl2005c_init() runs; the malicious device must report an allocation-table entry count of 1022 or more, producing an oversized alloc_table_size that overflows both the local stack 'info' buffer and the heap priv->table buffer. Limiting factors: exploitation needs physical/local access to a USB port (AV:P) - it is not reachable over a network - and the target must actually probe/mount the device via the jl2005c driver path; it does require no authentication (PR:N) and no user interaction beyond device enumeration (UI:N). The pre-patch code lacked any bounds check on the device-supplied entry count; the vendor fix adds that validation, and updating is the fix the evidence provides.

The dominant, risk-limiting signal is the attack vector: the supplied CVSS 4.0 vector is AV:P (physical), meaning exploitation requires an attacker to physically connect a malicious USB device to the host - this is not a remotely reachable flaw despite the high 7.0 score and the 'RCE' tag. The remaining metrics are severe (AC:L, PR:N unauthenticated, UI:N, VC:H/VI:H/VA:H), so once a rogue device is attached the technical impact is full compromise of the affected process, but the physical prerequisite sharply narrows real-world exposure to scenarios involving untrusted USB peripherals (kiosks, shared workstations, forensic/evidence handling, supply-chain-tampered cameras). There is no KEV listing in the input and no EPSS score was provided, so there is no evidence of active exploitation or a quantified exploitation probability; the VulnCheck advisory and a hackmd technical write-up are present as a public PoC reference, but the input does not mark it as confirmed working exploit code. The vuln.today decision label is 'this_week', consistent with a serious memory-corruption bug that is not an emergency because of the physical access barrier. Net: this is a genuine code-execution-class bug worth patching on the stated this_week cadence, but it is a physical-access issue, not a widespread remote threat - the high CVSS reflects impact, not ease of reach.

An attacker crafts or reflashes a USB device to impersonate a Jeilin JL2005B/C/D camera and physically connects it to a target Linux machine where libgphoto2's jl2005c driver probes it; the spoofed device reports 1022 or more allocation-table entries, triggering stack- and heap-based buffer overflows in jl2005c_init() that overwrite the saved return address and adjacent heap data to potentially execute attacker-controlled code. A public PoC reference exists (VulnCheck advisory and a hackmd write-up); it is not verified as working exploit code. Exploitation requires physical access (AV:P) but no authentication (PR:N) and no additional user interaction beyond the device being enumerated.