This soundbar can be hijacked over Bluetooth to control your computer, no pairing required

The takeaway: Security flaws in consumer hardware don’t usually begin with something as mundane as a soundbar. But in this case, a device built for audio playback can also act as a wireless bridge, sending commands to a connected computer without requiring pairing.

That scenario comes from research into Creative Technology’s Sound Blaster Katana V2X, a midrange soundbar that connects to PCs, Macs, and Linux systems over USB or Bluetooth. Researcher Rasmus Moorats uncovered the issue while experimenting with ways to communicate with the device from Linux. What he discovered went far beyond simple device tinkering.

At the center of the issue is a proprietary communication layer Moorats identified as the Creative Transport Protocol (CTP). The protocol handles routine tasks such as adjusting lighting and sound settings while also enabling two-way communication between the speaker and its connected host.

The unexpected part is how loosely access to the protocol is controlled. Moorats found that any Bluetooth device within range could connect to the speaker and send commands without authentication – or even pairing. That creates a direct communication channel to a device that, in many setups, is physically connected to a computer.

The more serious issue lies in how the speaker handles firmware updates. One available command allows new firmware to be uploaded, but the process lacks code signing or any meaningful validation. Moorats demonstrated the flaw by installing a custom firmware image that simply displayed the word “patched” on the speaker, confirming that arbitrary code could be written to the device.

From there, the research shifted to what that level of control could enable. The Katana V2X runs FreeRTOS, a widely used embedded operating system. Within that environment, Moorats discovered built-in support for Human Interface Device functions, the same class of USB devices that includes keyboards, mice, and webcams.

Although the speaker only exposes basic HID controls by default, its implementation is more flexible than expected. By modifying the device’s USB descriptor set, Moorats was able to make the speaker present itself as an additional device, including a keyboard. Using existing firmware routines, he then enabled it to send keystrokes to the connected computer.

That’s where the pieces come together: a Bluetooth connection provides access to the speaker, the firmware update process does not verify what it is flashing, and the modified firmware can turn the device into a keyboard capable of typing commands on the host machine.

As Moorats wrote: “Chaining it all together, I was able to totally remotely, over the air, upload a custom firmware to my speaker which I hadn’t paired with, which would reboot, flash the custom firmware, and after rebooting type in the command echo pwned and execute it.”

He noted that the demonstration was deliberately simple: “In a real attack scenario, I would execute the keystrokes for opening powershell.exe or similar and paste an actually malicious one-liner into that, but as a proof of concept, this was more than enough for me. A real attacker would also likely disable the routine for updating the firmware in both normal and recovery mode, making it impossible to wipe the malicious firmware from the device or patch it in the future.”

There are some constraints. An attacker would need to be within Bluetooth range, limiting the threat to neighbors, housemates, or people in nearby offices. Even so, the exposure is persistent. Bluetooth remains active on the speaker even in sleep mode, with no clear way to disable it.

The speaker’s USB connection includes a challenge – response authentication step, but Moorats found it can be bypassed by extracting the correct response from the companion app’s binary. Bluetooth connections, notably, do not require any such authentication.

Moorats reported the findings to Creative Technology. After initial silence, CERT Singapore intervened and received a response from the company, which said its engineers did not consider the behavior a vulnerability.