BusyBox dpkg EUVD-2026-100957

Exploitation requires that the BusyBox dpkg applet (not standard dpkg) is compiled in and actually used for package management, and that an operator removes two packages in a single dpkg invocation where the first package's stanza is larger than the second. Limiting factors: AV:L means local execution is required; UI:R means a human must perform the package-removal operation; the specific ordering condition (larger stanza first) must hold for the second stanza to be dropped; and the impact is confined to status-file integrity (I:L) with no confidentiality (C:N) or availability (A:N) effect and no code execution.

This is a low-priority issue, not a genuine security emergency. The provided CVSS base score is 3.3 (Low) with vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N - a local attack vector requiring user interaction, producing only a limited integrity impact (C:N/A:N, I:L). No EPSS score, no CISA KEV listing, and no POC were provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of exploitation probability. All signals are consistent and point the same direction: local-only, interaction-dependent, no confidentiality or availability loss. The one notable conflict is in the classification metadata rather than the risk signals: CWE-125 (out-of-bounds read) and the 'Information Disclosure' / 'Buffer Overflow' tags do not match the description, which describes a logic error (a field cursor not reset between stanzas) causing status-file data corruption - not a memory read or disclosure. The CVSS C:N confirms there is no confidentiality impact, so the 'Information Disclosure' framing should be disregarded. Net: a reliability/data-integrity defect in a rarely-used applet, appropriately rated Low.

An operator uses BusyBox's dpkg applet to remove two packages in a single invocation, and because write_status_file() does not reset the field cursor between stanzas, the second (smaller) package's stanza is silently dropped from the status file. The result is a corrupted/inconsistent package database rather than code execution or data theft. No public exploit code was identified, and triggering it requires the specific larger-then-smaller stanza ordering plus a deliberate multi-package removal.