Ultrasonic voice injection is an attack that hides spoken commands inside high-frequency sound so a microphone or voice assistant may still transcribe or act on them. It targets speech interfaces that accept voice input, exploiting the gap between human hearing and microphone signal processing to influence system behaviour without audible cues.
How ultrasonic voice injection works
Ultrasonic voice injection is a physical-layer attack against speech interfaces. It takes advantage of the fact that a human listener may not hear the injected command, while a microphone, analog front end, or speech pipeline may still capture enough energy to form a command-bearing signal.
The attacker is not “hacking voice” in the abstract, but shaping sound so the target device’s signal processing turns an inaudible carrier into usable speech content. That makes the attack relevant anywhere a microphone directly drives actions, such as voice assistants, dictation systems, conference room devices, and other always-listening interfaces.
Because the command is hidden in ultrasonic or near-ultrasonic content, ordinary human monitoring can miss it. The core security issue is the gap between human perception and machine perception, especially when the system treats microphone input as implicitly trusted.
Why it can influence speech systems
Speech interfaces often rely on filters, sampling, and preprocessing steps that were designed for convenience and usability, not adversarial robustness. If those steps do not reject or detect out-of-band audio, an attacker can sometimes make a command survive the conversion chain and reach speech recognition or downstream intent handling.
The risk is highest when the voice path can trigger actions automatically, authenticate the user, or call other tools without a second control point. In those cases, a successful injection can become more than a nuisance, it can become an unintended instruction source.
It is useful to think of this as a trust-boundary problem. The device is hearing something the people nearby do not hear, so the environment can appear normal while the machine receives a persuasive input stream.
Where exposure usually exists
Exposure depends less on the brand of device and more on the surrounding deployment pattern. Shared spaces, open microphones, wake-word listeners, and devices that execute commands from ambient speech all increase the attack surface. Poor placement, lack of acoustic controls, and permissive voice-command policy make the situation worse.
Organisations should inventory every speech-enabled system, including embedded assistants, meeting-room devices, mobile assistants, and any application that accepts spoken commands. Review vendor documentation for the audio pipeline and any built-in protections, because the relevant weakness is often in how the device samples and interprets sound rather than in the visible application layer.
For general security baselines around input validation and trust in user-supplied content, the OWASP Top 10 remains a useful reference point for thinking about untrusted input, even though ultrasonic voice injection is not a web-only issue.
How defenders reduce impact
Defence usually starts with limiting what voice input is allowed to do. High-risk actions should not be executable from voice alone, and sensitive workflows should require a stronger confirmation step than spoken commands. Devices should also be configured to reject unnecessary always-on listening where the business use case does not justify it.
Acoustic countermeasures can help, including microphone placement, directional capture, firmware or signal-processing settings that suppress out-of-band content, and environmental design that reduces the chance of hidden audio reaching the device. But no single control is enough on its own, because the attack exploits both the physical environment and the software pipeline.
Detection is typically indirect. Security teams should look for unexpected voice-triggered actions, anomalous assistant logs, and command execution that does not match normal user behaviour or nearby human speech. If a device has been exposed, review whether it could have carried out actions based on malicious audio before the issue was discovered.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V2 — Validation and Business Logic | Ultrasonic voice injection abuses untrusted input reaching command logic |
| Recommendation — Treat spoken commands as untrusted input and require validation before executing actions. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Audio commands are an input channel that can be manipulated before processing |
| Recommendation — Validate and constrain voice-derived input before it can drive system actions. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Speech-enabled applications need secure design and testing against malicious inputs |
| Recommendation — Test speech-enabled functions for malicious-input handling and command abuse. | ||
| MITRE ATT&CK | T1204 — User Execution | The attack relies on a human-facing input path causing an unintended action |
| Recommendation — Map voice-triggered actions to user-execution pathways and monitor for abnormal command initiation. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org