CDC-ACM Serial Interface Bypasses TCC on macOS: A Disclosure After Apple Declined

Case: Apple Product Security case OE11057041574014. Reporter: Kevin Kessler, glyph.sh. Reported: 2026-04-26. Apple response: “unable to identify a security issue” (2026-05-20). Publication: 2026-09-24, after 4 months of silence following my final reply.

Summary

macOS classifies the USB Communications Device Class / Abstract Control Model (CDC-ACM) as low-risk and, as a result:

1. On an unlocked Mac, the CDC serial device node /dev/cu.usbmodem* is created and made read/write to any process, with no TCC prompt and no entitlement requirement. TCC gates keyboard input monitoring, screen recording, and file-system regions like ~/Documents, but a serial device that a program is willing to read and write is not on the list.
2. On a locked Mac with Lockdown Mode enabled, if a USB hub has been previously trusted by the user, a new composite device plugged into that hub inherits the trust. macOS does not re-prompt for the composite device, and the CDC-ACM interface on that device enumerates alongside the HID keyboard interface.

Chained, these give a physically present adversary a 24-second exfiltration channel for SSH keys, cloud credentials (AWS, GCP, Azure, Kubernetes), keychain metadata, and environment secrets, running against an unlocked Mac with no consent sheet and nothing visible to the user other than a Finder window, a Spotlight search, and typing in a Terminal window that appears very briefly.

I reported this to Apple on 2026-04-26 with a full write-up, video demonstration, sysdiagnose, and a working proof of concept. Apple declined on 2026-05-20 saying “we don’t see any actual security implications and do not have any precedent for categories of the type you’re recommending.” I replied on 2026-05-21 explaining the exfiltration chain in one sentence. That reply was never answered.

I am publishing this now for two reasons. First, defenders need to know that neither USB Restricted Mode, Lockdown Mode, nor TCC will save them from this specific chain, so they can mitigate. Second, if Apple will not consider “silent exfiltration of the credentials and secrets a user keeps in their home directory, over a serial device that is invisible to TCC” a security issue, users deserve to be told so and to decide for themselves.

Affected

• macOS 26.4.1 (Apple Silicon), the version I tested against. I have no reason to believe earlier or subsequent releases behave differently for the TCC side of this. Test yourself.
• Any USB device that can present a CDC-ACM interface. My PoC uses an ESP32-S3 with USB-A plus a $10 USB-C dongle, ~$20 total in parts, and standard Espressif ESP-IDF v5.4 tooling.
• Any Mac that has ever had a USB hub, dock, or adapter approved by the user, which is essentially every Mac that has ever been plugged into anything through a docking station or a multi-port hub.

Background: the three mechanisms this bypasses

USB Restricted Mode is the default macOS behavior that prevents a new USB accessory from communicating with a locked Mac more than one hour after last unlock. Apple markets it as a defense against opportunistic malicious devices.

Lockdown Mode is Apple’s opt-in extreme-hardening profile. Per Apple’s own documentation, it “blocks wired connections with a computer or accessory when the device is locked.”

TCC (Transparency, Consent, and Control) gates access to protected input and output classes. If you have ever seen the “X wants to control your keyboard” or “X wants to record your screen” sheet, that is TCC. TCC is the layer users are told to trust when they wonder whether a background app can silently read what they are doing.

Finding 1: locked-Mac plus Lockdown Mode plus a trusted hub

Threat model. Adversary has brief physical access to a USB port on a hub, dock, or adapter that the user has previously trusted. The Mac is locked, USB Restricted Mode is on, and Lockdown Mode is on. Whether it has been more than an hour since last unlock is not relevant to this vector, because the hub’s existing trust bypasses that gate.

Behavior observed. A USB composite device plugged into that hub, presenting both an HID Keyboard interface and a CDC-ACM interface, enumerates both interfaces. macOS creates the device node /dev/cu.usbmodem* with full read and write permissions. Nothing prompts the user, because macOS does not re-prompt for devices downstream of an already-approved hub.

What this means. The one-time hub approval is not just a permission to use that hub. It is effectively a persistent enumeration exemption for anything ever connected through it, for any USB class the composite device wants to expose. USB Restricted Mode and Lockdown Mode are both structured around per-device approval and do not model hub-downstream devices as new events.

Correction I want to be upfront about. My original 2026-04-26 report claimed the locked-mode bypass worked without any user interaction at all. I retracted that on 2026-04-28 after re-testing more carefully. macOS does correctly prompt for the first device plugged into a locked Mac. The bypass requires the composite device to be connected via a previously-approved hub. I flagged this to Apple in the case thread the same week. Everything below is the corrected model.

Finding 2: unlocked-Mac TCC bypass (the one Apple declined)

Threat model. Adversary has brief physical access to a USB port on any device the user has approved, while the Mac is unlocked. Plug the device in, wait for the chain to complete, unplug. The full run measured 24 seconds end-to-end. Common scenarios include using someone else’s Mac at a coworking space, an unattended workstation during a meeting break, or a targeted access-badge grab in an office.

Behavior observed. The CDC serial device node /dev/cu.usbmodem* is not enrolled in any TCC service category. Any process on the Mac can open it with O_RDWR without a consent sheet and without an entitlement.

Attack chain. A composite USB device presenting HID Keyboard plus CDC-ACM does the following:

1. HID keyboard interface types the keystrokes to open Terminal (Spotlight, “Terminal”, Enter). Because HID keyboard input goes through the same code path as a real user, TCC does not treat this as input monitoring.
2. The typed shell command redirects a shell session’s stdio through the CDC serial device node. Any script the operator wants to run can now be delivered over the serial channel and its output shipped back over the same channel.
3. Standard shell operations collect the categories of interest that my PoC actually exfiltrated:
   • SSH private keys
   • Cloud provider credentials (AWS, GCP, Azure, Kubernetes)
   • Keychain metadata (item existence and attributes, not the encrypted secret material itself)
   • Environment secrets
4. The exfiltrated data leaves the Mac over the USB serial channel and lands on the attached microcontroller’s flash. In my measurements, end-to-end from plug-in to the device being removed with data on board is 24 seconds. Nothing in the sequence triggers a TCC sheet. What the user sees, if they happen to be looking at the screen, is a Finder window, a Spotlight search, and text being typed in a Terminal window.

Why this is a security issue in plain language. TCC is the mechanism macOS uses to promise users that no application can silently take their screen, keystrokes, or files without their consent. A USB-attached serial device is functionally equivalent to a very fast bidirectional pipe to an untrusted party outside the machine, and the code that talks to it does not need a TCC grant. If the answer is “well, the user opened Terminal”, the answer is also that the user did not open Terminal, a USB device did, and TCC exists precisely to catch that class of thing.

What Apple said

From the case thread:

Nick | Product Security (2026-05-20): Thanks for confirming you’re using a hub. This is the expected behavior when a hub is connected and allowed by a user. As for your “Finding 2”, we don’t see any actual security implications and do not have any precedent for categories of the type you’re recommending.

I replied the next day:

Kevin Kessler (2026-05-21): Data exfiltration is possible from the user directory when a user allows a hub to connect, while the macbook is locked and in lockdown mode.

That reply has not been answered. It has been four months.

I want to steelman Apple’s position. It is defensible to say that “user approved a hub” is the ceiling of what any USB security model can offer, and that once a hub is trusted the trust is transitive by design. It is much harder to defend “the serial device class is not in TCC because we don’t have precedent for including it,” because the exfiltration chain I described in my final reply is exactly the kind of thing TCC was built to catch. TCC has precedent for gating input monitoring, screen recording, and directory access. A serial channel that ships those same secrets off the machine over a wire the user cannot see is the same shape of problem.

Proof of concept

I am not publishing a copy-paste weaponized exploit. I am describing the class at a level a security engineer can reproduce with an evening of work, which is what the disclosure norms exist for.

• Program a USB microcontroller that presents a composite device exposing both an HID Keyboard interface and a CDC-ACM interface. My PoC used an ESP32-S3 with USB-A, plus a USB-C dongle (~$20 in parts total), built with ESP-IDF v5.4. Any other CDC-capable board (RP2040, ATmega32u4, etc.) would work equivalently; public composite-device example code exists in every major microcontroller SDK.
• Write a firmware routine that, once the CDC-ACM channel is open on the host, sends a scripted sequence of HID keystrokes to open Terminal and pipe stdio through /dev/cu.usbmodem*, then reads whatever the host shell writes back.
• For Finding 2 (TCC gap on an unlocked Mac): plug the device in. Observe that no TCC prompt appears at any stage.
• For Finding 1 (locked-Mac + Lockdown Mode via trusted hub): first approve any USB hub, dock, or adapter on the Mac (this is a one-time event that many users have already done for their normal dock). Enable Lockdown Mode. Lock the Mac with Ctrl+Cmd+Q. Wait ~10 seconds. Plug the composite device into a spare port on the previously-approved hub. Wait ~60 seconds, unplug, unlock, and inspect the system log (or, in my PoC, ~/Desktop/cdc-lock-test.log) for the /dev/cu.usbmodem* device-node creation event. The one-hour USB Restricted Mode timer is not relevant to this vector; the hub’s existing trust bypasses that gate.

The firmware, host-side observer script, and log of the run were provided to Apple with the original report.

Mitigations

For Apple, in decreasing order of what I would ask for first:

1. Enroll /dev/cu.usbmodem* and /dev/tty.usbmodem* in TCC as a new service category, roughly “Serial device access.” Prompt on first use per process. This is the fix that closes Finding 2 without breaking any legitimate use.
2. Require a signed, entitled process to open a /dev/cu.usbmodem* node. This is a stricter version of the above and would break casual use of Arduino IDE and PlatformIO without a workaround, so option 1 is preferable.
3. Track hub-downstream enumeration as a new device event under Lockdown Mode. If a hub is approved and later a new device appears downstream of it while the Mac is locked and Lockdown Mode is on, re-prompt. This is a meaningfully harder engineering change than the TCC one, which is why I list it second.

For users, as an interim:

• Treat any previously-approved USB hub, dock, or adapter as “always trusted for any device plugged into it.” That is what it actually is. If you would not plug a random USB device into an open port on the Mac itself, do not plug one into a hub either. Physically cover unused ports on shared docks with tape or a port blocker.
• Prefer USB data-blockers (“USB condoms”) on ports you leave plugged into hubs in shared or public spaces.
• Do not leave Arduino IDE, PlatformIO, screen, minicom, or any serial-consuming daemon running when you do not need it. These are not exploited by this chain, but the presence of familiar-looking processes that read serial devices makes an audit harder.
• If you rely on Lockdown Mode as a defense-in-depth layer, understand that this class is not covered by it today. Behave accordingly.

Timeline

For reference: Project Zero publishes at 90 days plus a 14-day grace, ZDI at 120. This report gave Apple 152 days of exclusive access, of which 128 were spent waiting for a reply to my one-sentence rebuttal.

Responsible-disclosure posture

I withheld a weaponized exploit throughout. I withheld it in the original report, throughout the four-month wait, and in this post. The description here is at the level of a defender-education writeup, not a copy-paste attack script. If any defender or Apple engineer wants a working PoC for validation, contact me privately.

I am publishing without an Apple CVE. A CVE ID request has been filed with MITRE CNA-LR (framed as a TL-Root dispute of a vendor bug-bar declination, per MITRE’s own CNA-LR policy). I will update this post with the CVE ID once assigned. Apple issues CVEs only for what they fix, and by their own reply they do not intend to fix this.

Contact

• Kevin Kessler
• kevin@glyph.sh
• https://glyph.sh
• I will answer questions on scope, class, mitigations, or reproduction on any platform this post is shared to. Working exploit code will not be posted publicly under any circumstances.