When the cable talks back: USB attacks and the examiner’s own risk

The USB port is an interface, not just a charger

A phone’s USB port is a data interface that the operating system’s kernel serves. When a device is attached, the kernel loads drivers to interpret it: audio, video, storage. A flaw in one of those drivers can be reached by anything that can imitate the device, including a lookalike cable or charger carrying a small board. The attacker needs the device in hand, but not the owner’s cooperation.

The 2025 Amnesty finding

Amnesty International’s Security Lab reported in February 2025, according to The Hacker News and SecurityWeek, that a chain of flaws in Linux USB kernel drivers appeared to have been used on a student activist’s Samsung Android phone after it was seized. The chain was CVE-2024-53104, in the USB video class driver (CVSS 7.8), with CVE-2024-53197 and CVE-2024-50302. Amnesty said it appeared to have been used through a commercial extraction product to bypass the lock screen. Google’s Threat Analysis Group helped analyze the chain, and Android patched the first flaw in February 2025 [S1][S2].

The vendor, Cellebrite, said its tools are not designed for offensive cyber use and that it would stop customers in the country concerned from using its products "at this time"[S1]. The activist is pseudonymized by Amnesty and stays so here. The finding concerns a specific deployment; it is not a statement about every customer or every use of lawful extraction products, and we make no allegation that any vendor deployed anything itself. Amnesty’s own page was not available to us, so we rely on these two accounts.

What NCC's research shows

NCC Group asks whether Linux USB memory-corruption flaws are practical to exploit on modern systems. At DEF CON 34 on 9 August 2026 it described a framework built on inexpensive programmable boards that act as several cooperating USB devices, used against the Linux audio and video class drivers[S3]. NCC cites the Amnesty report as an in-the-wild instance of the same bug class[S3]. At Hexacon on 17 October its researcher gave a talk on the same subject, listing CVE-2024-53150, a USB audio flaw, and CVE-2024-53104[S4]. NCC reports the first as in the US government’s catalog of exploited vulnerabilities[S3]. We give no technique detail and none is needed to understand the point: practical exploitation has moved from a niche to a commodity-hardware problem.

Boot-level routes

A second, separate physical route sits below the operating system. In June 2026 researchers disclosed usbliter8, a flaw in the USB controller code in the boot ROM of Apple chips A12 and A13 and related parts. Reports say it needs physical possession, recovery mode, a wired connection and a small microcontroller board, that software updates cannot fix it, and that no compromise of the Secure Enclave has been shown[S7]. At Hexacon a Cellebrite researcher gave a talk whose abstract describes a generic approach to the same controller flaw across chips from A5 to A13. The exact list of devices is not settled in the sources we have, and nothing in them says the work was used against an individual[S4]. A separate article in this series covers boot ROM flaws.

The examiner's workstation is a target too

The same logic runs the other way. In April 2021 Signal wrote that Cellebrite’s extraction software parsed untrusted app data without standard exploit mitigations, so a specially formatted file on a scanned phone could run code on the examiner’s computer. Signal said such code could alter reports undetectably, published a harmless demonstration and withheld the exploit. It also said the software bundled video-library files built in 2012. That is Signal’s claim, not a court finding, and nothing we read shows any report was ever altered in a real case. The post we read carries no vendor response[S5].

In August 2024 a public vulnerability record (CVE-2024-7448) described command injection in a commercial acquisition product when it acquires from Android: device-supplied identifier strings were passed to a shell command without cleaning, so a malicious connected device could run code on the examiner’s machine. The record rates it 8.0 and, according to the record, a later release fixed it. We found no report of exploitation in the wild[S6].

Our assessment

We read the evidence as pointing in one direction. Physical access to a phone, and physical connection to it, are attack surfaces in their own right. Amnesty’s report indicates they can be exploited in a custody setting[S1][S2]. They are also surfaces on which defenders depend. The risk to an examiner’s machine is as old as forensic software, and it belongs to any program that parses data from an untrusted device, as the two warnings above show.

Our assessment is that the practices around any tool matter more than the choice of tool. A second, independent method for key findings, hash verification of evidence and an acquisition machine that is isolated and updated all reduce the cost of a mistake whichever product is used.

What the Lab is watching

We are watching for Amnesty’s own publication[S1] to be re-read in full, for any new advisory on acquisition tools, for platform changes that restrict data access over USB while a phone is locked, and for NCC’s tooling to be released or described in more detail. We are also watching the boot-ROM work for a vendor statement.

What this means for examiners

For a phone’s owner: a strong passcode, a current patch level and a restart before travel or any risk of seizure narrow the exposure to a cable attack. Do not plug a phone into unknown chargers or public charging points. Carry your own cable, and treat a prompt to "trust this computer" or to allow data transfer on an unfamiliar machine as a decision, not a formality.

For examiners: keep acquisition machines isolated and updated, verify evidence by hash, and confirm important findings by a second method. Keep acquisition logs. Note which cables, adapters and accessories touched the phone and in what order, because a wired route is only reconstructable if someone wrote it down. Open evidence on a machine that holds nothing else of value, restore it from a known-good image between cases where practice allows, and treat any unexpected crash or restart of the acquisition software as an event to record, not an inconvenience to retry past.

How it reaches a phone and what it leaves: propagation is physical, by cable, charger or extraction device; the format is a USB connection; traces may include unusual accessory enumeration and restarts in system logs, though a successful kernel attack may leave little; and retention limits what survives.