Nobody touched the soundbar. Nobody paired with it, plugged anything into it, or even walked into the room. And yet, on a fully patched Windows machine, keystrokes started appearing in the active window — typed by a $280 gaming speaker sitting on the desk.

That’s not a hypothetical. It’s what security researcher Rasmus Moorats demonstrated against the Creative Sound Blaster Katana V2X, a popular USB-connected gaming soundbar, in a vulnerability he named Pwnd Blaster. The attack chain turns an “innocent” audio peripheral into a remote, wireless version of a BadUSB drop — without the attacker ever needing physical access.

TL;DR

  • The Katana V2X bridges its command protocol (CTP) to Bluetooth Low Energy (BLE) with no pairing and no authentication — anyone within ~15 meters can talk to it.
  • Firmware images are verified with a plain SHA-256 checksum, not a cryptographic signature — any attacker who recalculates the checksum can flash custom firmware.
  • Modified firmware can add a keyboard interface to the speaker’s existing USB HID descriptor, letting it inject keystrokes into the host PC like a remote Rubber Ducky.
  • Creative was notified in April 2026, took two months to respond, and concluded the issue “does not present a cybersecurity risk.” No patch is planned.
  • There is no CVE for this issue, and the device’s Bluetooth radio has no hardware off switch — it stays active even in sleep mode.

Why This Matters to You

If you own this soundbar — or any USB peripheral that also has a Bluetooth companion app — this isn’t an abstract research curiosity. It’s a live, unpatched way for someone in the next room, the office next door, or a shared coworking space to type commands on your PC without touching your keyboard, your mouse, or even your computer.

More broadly, it’s a preview of a problem that’s only going to get bigger: consumer electronics increasingly bundle a wireless control channel and a “smart” firmware update mechanism, built by audio or hardware engineers who never threat-modeled against a remote attacker. Few of these channels get the security scrutiny that browsers or operating systems do.

Table of Contents

How a Soundbar Ended Up With a Keyboard Inside It

To understand why a speaker can “type,” you need to understand USB HID — the Human Interface Device class. It’s the generic language USB uses for anything that sends discrete inputs to a computer: keyboards, mice, game controllers, and also volume buttons and media keys on a soundbar.

The Katana V2X already ships as a Consumer Control HID device — that’s what lets its physical volume knob and mute button send “volume up,” “volume down,” and “mute” signals to your PC, exactly the way a keyboard’s media keys do. The operating system already trusts it as an input device the moment you plug it in. No driver prompt, no user confirmation — USB HID devices are designed to “just work.”

The Pwnd Blaster attack doesn’t break that trust model technically. It abuses it. If a device can already tell your PC “user pressed mute,” nothing stops its firmware from also being able to say “user pressed Ctrl, then R, then typed a command.” The hardware boundary between “volume control” and “full keyboard” turns out to be a few bytes in a configuration descriptor — not a security control.

The Protocol Nobody Was Supposed to Talk To

Creative built a proprietary command interface for the Katana V2X called CTP (Creative Transport Protocol). It’s how the companion app changes EQ presets, RGB lighting, and pushes firmware updates — normally over USB.

CTP does have an authentication step: a challenge-response handshake. On paper, that sounds reasonable. In practice, Moorats found the handshake relies on a static secret key — and that key is sitting in plain sight inside the Creative app’s binaries, extractable with basic reverse engineering. It’s the equivalent of a lock with a challenge-response mechanism where every customer’s “secret” key is printed in the manual.

A static key shared across every unit ever sold isn’t authentication in any meaningful sense — it’s an extra round-trip that does nothing to stop someone who has bothered to look at the app once.

Bluetooth Without Pairing, Without Authentication

Here’s where it gets worse. The same CTP command interface that talks over USB is also bridged to Bluetooth Low Energy (BLE) — and over BLE, even the weak USB challenge-response is dropped entirely.

Moorats demonstrated this directly: he connected to a Katana V2X over BLE without pairing, wrote the bytes 5a 09 01 02 (a CTP firmware-version query) to GATT characteristic 9e9daaec-3a10-4fe8-b69f-7397aff77886, and got the full firmware version string back. No PIN, no pairing prompt, no handshake of any kind — just a write to an open characteristic.

That single proof-of-concept is the whole story in miniature: anyone within Bluetooth range can issue commands to the device as if they were the official app. Range tops out around 15 meters (about 16 yards) — enough to cover an entire open-plan office, a shared apartment wall, or a hotel corridor. And because the speaker’s BLE radio has no hardware off switch and stays active even in sleep mode, the attack surface is exposed around the clock, whether or not anyone is using the speaker.

From a BLE Write to Malicious Firmware

Querying the firmware version is harmless. Pushing a new firmware image is not — and the verification on that path is just as weak as the authentication.

Firmware images for the Katana V2X include a field called CHK2 — a plain SHA-256 checksum. There is no cryptographic signature and no secret involved in validating it. As Moorats put it, the device happily accepts patched firmware as long as CHK2 is correct — which simply means recalculating a hash after editing the file. There’s no key an attacker needs to steal, because there’s no key protecting the firmware at all.

The attack chain, end to end:

  1. Discovery — connect to an unpaired Katana V2X over BLE, from up to ~15 meters away.
  2. Command access — send CTP commands directly over the open BLE characteristic; no authentication required.
  3. Build malicious firmware — take a legitimate firmware image, patch it, recompute the CHK2 checksum so the device accepts it as valid.
  4. Push it over BLE — transfer the modified firmware via CTP firmware-update commands. This takes roughly 10+ minutes over Bluetooth — slow, but it requires no pairing and no return visits.
  5. Device reboots and flashes the attacker’s firmware automatically, since the checksum matches.

At no point does the victim see a prompt, a pairing request, or a permission dialog. The first sign anything happened is the soundbar rebooting — something users already expect after a firmware update.

The Payload: Turning Volume Buttons Into a Keyboard

Once an attacker can supply arbitrary firmware, the last step is making that firmware do something. Moorats located the USB report descriptor inside the firmware — the structure that tells the OS “I am a Consumer Control device” — and appended a full keyboard interface entry to it. After the patched firmware boots, the speaker enumerates to the PC as both an audio/consumer-control device and a keyboard.

For his proof of concept, Moorats repurposed an unused “diagnostic” firmware task — a maintenance routine not normally used in production — and overwrote it with 102 bytes of ARM/Thumb assembly that: waits 20 seconds for USB re-initialization after reboot, types echo pwned with a 20ms delay between keystrokes, then halts cleanly. The entire weaponization, on top of the existing firmware, came to roughly 83 bytes for the descriptor change plus the keystroke payload itself.

That’s intentionally a harmless demonstration. A real attacker isn’t constrained to typing echo pwned — the same mechanism can type anything a human could type: a PowerShell one-liner, a malicious URL followed by Enter, or commands to disable a security tool. The injected keystrokes carry no file, no signature for AV to flag, and arrive through a path most security tooling doesn’t watch at all: a peripheral that has been sitting on the desk, fully trusted, since the day it was unboxed.

The Vendor’s Verdict: Not a Vulnerability

Responsible disclosure, in this case, didn’t go the way it’s supposed to.

Date (2026)Event
Apr 1–9Two attempts to reach Creative through its standard support form go nowhere
Apr 16–20Researcher escalates through SingCERT (Singapore’s national CERT)
May 8Vendor still unreachable
May 25Vendor finally acknowledges the case
Jun 3Vendor responds: the issue “does not present a cybersecurity risk” — no patch planned. Researcher publishes the write-up the same day.

No CVE has been assigned. Creative’s official position is that flashing arbitrary firmware over an unauthenticated Bluetooth channel, on a device that can then type into your PC, is not a security issue worth fixing.

After the public write-up, Creative’s response wasn’t a patch — it was disabling the public firmware download URLs that the v2x-patcher community tool depended on. That tool, built by a third party, attempted to mitigate the issue by disabling CTP-over-BLE on a connected unit (at the cost of breaking the official mobile app’s Bluetooth control). Pulling the firmware downloads broke the volunteer fix along with any future patch attempt, while leaving the original vulnerability untouched.

This Isn’t Just About One Soundbar

The Katana V2X is a single, well-documented example, but the underlying pattern is generic: wireless companion control channel + unsigned firmware + USB HID trust = remote BadUSB. It shows up anywhere a vendor bolts Bluetooth onto a USB peripheral for convenience — keyboards with RGB companion apps, wireless mice with onboard memory, docking stations, webcams, headsets — without applying the same security bar as the OS-level interfaces those devices plug into.

It’s the same trust failure explored from different angles in UEFI bootkits, where malware living below the operating system survives reinstalls and evades EDR simply because nothing at that layer expects to be attacked, and in BYOVD attacks, where attackers reach privileged execution through a legitimate, trusted component rather than breaking the OS itself. Peripherals like the Katana V2X extend that same blind spot from drivers and firmware down to “dumb” hardware sitting on your desk — which is exactly the class of device covered in our look at IoT devices pivoting outside EDR coverage.

Detection: What Blue Teams Can Watch For

This attack is deliberately invisible to most security tooling — there’s no malicious file, no suspicious process, and no network connection at the moment of compromise. Detection has to shift toward the USB and BLE layers themselves.

  • HID enumeration changes. Baseline what each USB peripheral on your fleet enumerates as (interface classes, not just VID/PID). A device that historically reported as “Audio + Consumer Control” and suddenly adds a keyboard interface — without a driver update event to explain it — is a strong anomaly signal. On Windows, this shows up in Plug-and-Play / Microsoft-Windows-Kernel-PnP event log activity; on Linux, in udev/dmesg output reporting a new keyboard interface from an already-known device.
  • Injection timing heuristics. Scripted keystroke injection — whether from a USB Rubber Ducky or a reflashed peripheral — tends to type with unnaturally consistent inter-key timing (here, a flat 20ms). Endpoint tooling that profiles keystroke dynamics can flag this the same way it would flag any other BadUSB-style injection.
  • USB device control / allow-listing. Tools like USBGuard (Linux) or Group Policy USB device installation restrictions (Windows) can enforce that only expected interface classes are permitted per device, blocking a previously-audio-only device from ever being accepted as a keyboard.
  • BLE airspace monitoring. Always-advertising BLE peripherals with writable, unauthenticated GATT characteristics are themselves worth hunting for. Tools such as Wireshark with a BLE-capable sniffer, or Kismet’s BLE support, can surface devices broadcasting in your office that accept unauthenticated writes — a useful signal independent of any specific CVE.
  • Firmware inventory for “dumb” peripherals. Treat firmware versions on USB/Bluetooth peripherals as part of your asset and patch inventory, not just laptops and servers. If a vendor can’t tell you whether firmware updates are cryptographically signed, that peripheral belongs in a higher-risk bucket.

What You Can Do Today

If you own a Sound Blaster Katana V2X specifically:

  • Treat its Bluetooth radio as permanently on — there is no firmware-level off switch, and it stays active in sleep mode.
  • If you don’t need the companion app’s Bluetooth features, the only currently reliable mitigation is physical: keep the unit out of range of untrusted people, since the community patch tool is currently broken after Creative pulled the firmware download URLs it relied on.
  • Watch the researcher’s write-up and GitHub for updates — if Creative reverses course, a fix will likely surface there before any official channel.

More generally, for any Bluetooth-capable USB peripheral:

  • Don’t assume hardware that isn’t a “computer” can’t run attacker-controlled code. If it has a firmware update mechanism, it has an attack surface.
  • Before buying for an office, ask vendors directly whether firmware updates are cryptographically signed — a checksum-only scheme is not a security control.
  • Disable Bluetooth radios on peripherals you don’t actively use them on, where the hardware allows it.
  • Pair this with the broader home and office hardening steps in our mandatory home security checklist — USB and Bluetooth hygiene is one item among several that’s easy to overlook.

Sources