Can venue broadcasts be spoofed, hijacked or jammed, and what protects them?

Why it matters

A false announcement and a missing announcement create different problems. RNID warns that a fake transport broadcast could mimic an operator's stream and carry malicious instructions; security researchers have demonstrated takeover of a Bluetooth broadcast stream on development hardware. These sources establish reasons to examine sender identity and continuity of listening, without establishing how often attacks occur in operating venues^1,2.

This question concerns whether the listener hears the intended source and whether reception continues. When should a venue broadcast need a code? covers eavesdropping and code distribution. The distinction matters because someone who has permission to hear an encrypted broadcast also holds the shared information on which its packet authentication depends^3,4.

What the evidence shows

A familiar name does not prove who is transmitting. The Public Broadcast Profile allows several transmitters carrying the same audio to use the same broadcast name. ERNW's security researchers describe the discovery information as unauthenticated, and RNID identifies look-alike transport streams as a risk. Taken together, these sources mean that a displayed name helps selection but is insufficient evidence of sender identity. Choosing a rogue stream is also different from taking over a stream to which the receiver has already synchronized^5,4,1,2.

Encryption provides real packet protection, with a shared-code limit. Core 6.0 specifies AES-128 authenticated encryption and message integrity checks for non-empty encrypted isochronous payloads, including audio and control packets. The SIG's security guide explains that this can resist packet modification while an attacker lacks the code. BISON and BACON identify the other side: an attacker who knows the same code can produce packets that pass those checks. Giving every listener the code therefore does not distinguish the venue's transmitter from a malicious code holder^6,7,2,3.

The security levels need careful reading. Core 6.0's LE Security Mode 3 distinguishes no security, an unauthenticated Broadcast_Code and an authenticated Broadcast_Code. The highest of these requires an authenticated method of receiving the code. BAP 1.0.3 requires broadcast receivers to support the first two levels and makes the third optional; its separate assistant-to-receiver control services require encryption. These provisions protect particular exchanges and packets. They do not remove the shared-code limitation identified by the researchers^6,8,3.

Packet-stream takeover has been demonstrated, within a limited setup. In the independent BISON study, with funding unstated, Graz University of Technology researchers used three development boards: a broadcast source, receiver and attacker running modified software. The attack redirected the receiver to a forged stream while the legitimate source continued transmitting. The encrypted-stream analysis assumes access to the shared code. The paper leaves exploiting audio data and demonstrating the impact on finished LE Audio devices to future work. This is evidence of a packet-stream mechanism underlying Auracast, without a representative test of hearing aids, loan receivers or occupied venues².

A relevant CVE concerns weak defaults in one implementation. ERNW researchers, with separate funding unstated, report recovering the default code of a Samsung Galaxy S23 broadcast in under a second in one described demonstration. The old default had only four hexadecimal characters; users could choose another code. Samsung, the manufacturer, records CVE-2025-20908 for its Android 14 and 15 software before SMR Mar-2025 Release 1 and says the patch improves random-value generation. The researchers report a longer replacement default. This personal-phone example concerns the shared code mechanism; it does not establish the defaults of installed venue transmitters or demonstrate their takeover^9,10.

Encryption does not prevent disruption. Public synchronization information exposes when and where broadcast packets will arrive, even with encrypted audio. ERNW's analysis explains why this permits selective radio interference. Core 6.0 also requires a receiver to stop receiving a BIS after a failed message integrity check and notify its host of lost synchronization: rejecting invalid audio does not promise continued reception. Separately, RNID asks for practical tests of ordinary 2.4 GHz congestion in busy transport locations. Congestion, malicious interference and an integrity-check failure should not be treated as the same observed fault^4,6,1.

A jamming experiment measures a shared mechanism. The Korean government-funded SPADE study used one broadcaster, one jammer and seven scanning development boards, with five runs of 10,000 periodic-advertising events. Without its proposed defence, average packet reception was 91.36% without jamming, and every scanner fell below 5% under the tested attack. SPADE kept reception above 80% at each scanner under attack. This tests periodic advertising used by Auracast, rather than speech reception through finished hearing devices; it does not measure the fraction of announcements a venue listener would miss¹¹.

Proposed defences are still research evidence. BACON, an independent university study with funding unstated, adds authentication designed to distinguish the sender even when an attacker knows the broadcast code. Its proof of concept used two development boards and dummy audio; practical audio applications remain future work. Tests of ten runs of 1,000 broadcast-group events found extra processing and power use, and lower packet reception under interference; retransmissions reduced the reception penalty. SPADE changes periodic advertising and uses receiver feedback to identify a jammer. Neither paper establishes that its mechanism is implemented in a venue's products. RNID's suggestion to compare streamed announcements with sound picked up by hearing-device microphones is likewise a proposed mitigation, without a reported validation trial^3,11,1.

FM, infrared and loops have different exposure paths. Compton-Conley's expert guide, reprinted by HLAA, describes FM receivers tuned to a transmitter's channel and possible interference from other radio services; it also distinguishes encrypted digital radio systems. It describes loops as unencrypted, with spill between rooms and telecoil pickup of electrical interference. These are reasons to examine unwanted signals and continuity, without evidence here of a deliberate venue takeover. The same guide describes infrared as normally unaffected by radio interference and contained by solid surfaces, with windows covered, but vulnerable to sunlight and blocked optical paths. Williams AV, describing its own IR T3 transmitter, also warns about sunlight and plasma screens. Room containment therefore addresses a different question from whether reception can be disrupted^12,13.

Where sources disagree

The SIG's 2023 security guide allows an easy-to-remember code for public announcements and suggests periodically changing it to hinder fake data injection. BISON and BACON show the limit of that advice when an attacker is among the people given the code. Encryption can protect against an outsider who lacks it; the research considers an attacker who has it. The sources address different trust assumptions, so a venue needs to establish which assumption a product's security claim uses^7,2,3.

Security and ease of access also pull in different directions. The SIG recommends long random codes where manipulation must be resisted and acknowledges the burden of entering them; RNID warns that protected streams can exclude listeners. Neither source establishes a universally suitable joining method, and stronger codes alone do not settle sender identity against other code holders^7,1,3.

What would settle it

Authorized tests of current venue transmitters, hearing aids and loan receivers should report hardware and firmware, whether the attacker knows the code, whether the listener selects a look-alike stream or an existing stream is taken over, and time to recover after interruption. Those results would extend the development-board evidence and the specification's loss-of-synchronization rule into actual listening behaviour. Incident counts with a stated collection method would answer the separate question of attack frequency, which these laboratory and design sources do not measure^2,6,1.

Practical audio, battery and compatibility tests of proposed authentication and jamming defences would address the gap between BACON's dummy audio, SPADE's advertising packets and finished assistive listening. Equivalent controlled tests of FM, infrared and loops would be needed before ranking their resistance to deliberate interference; the comparative guidance cited here describes transmission paths and ordinary interference rather than adversarial trials^3,11,12.

Planning while it is open

• Ask suppliers separately about sender impersonation, resistance to interference and recovery after reception stops. Establish whether any claimed authentication protects against another listener who knows the code; a broadcast name or encryption setting alone does not answer that question^4,3,6.
• Where content needs protection from eavesdropping or manipulation, follow the SIG's advice on long random codes; for private content it also recommends authenticated code exchange. Its public-announcement exception and the malicious-code-holder limit are described above. Test the supported joining routes with listeners, including people without smartphones, because code handling can create an access barrier^7,1,3.
• Check the security-update status of the particular equipment. For affected Samsung phone broadcasting, the manufacturer's relevant maintenance release is March 2025 Release 1; that fix must not be treated as evidence that unrelated venue products are fixed or affected¹⁰.
• Assess ordinary interference in the intended setting and record how receivers recover from reception loss. Keep this separate from any authorized security evaluation: RNID's congestion concern, the core's integrity-failure rule and the laboratory attack studies test different conditions^1,6,2,11.
• For FM and loops, check radio interference, adjacent-room spill and magnetic noise as appropriate. For infrared, check sunlight and clear optical paths. For both FM and infrared, include neckloop listening in checks because the telecoil in the listener's hearing device or accessory can still pick up magnetic interference^12,13.

---

Sources

1. Auracast: a revolution in audio accessibility (RNID Auracast report). RNID (Royal National Institute for Deaf People). RNID, 11 February 2025. Nonprofit advocacy (RNID, UK charity) ↩︎ https://rnid.org.uk/wp-content/uploads/2025/02/Final-Auracast-Report-110225.pdf
2. BISON: Attacking Bluetooth’s Broadcast Isochronous Streams. Gasteiger T, Boano CA, Römer K. EWSN 2023; Association for Computing Machinery, 25 September 2023. Independent (Graz University of Technology; funding not stated in the paper) ↩︎ https://www.carloalbertoboano.com/documents/gasteiger23bison.pdf
3. BACON: improving broadcast audio authentication. Gasteiger T, Perazzo P, Schuß M, Boano CA, Basic F, Dini G, Römer K. IEEE MILCOM 2024 (Graz University of Technology; University of Pisa), 28 October 2024. Independent (Graz University of Technology; University of Pisa); funding not stated in the paper ↩︎ https://doi.org/10.1109/MILCOM61039.2024.10774045
4. Part I: Bluetooth Auracast from a Security Researcher’s Perspective. Heinze D, Steinmetz F. ERNW, Insinuator.net, 27 January 2025. Independent (ERNW security researchers; separate research funding not stated) ↩︎ https://insinuator.net/2025/01/auracast-part1/
5. Public Broadcast Profile, version 1.0.2. Bluetooth SIG Audio, Telephony, and Automotive Working Group. Bluetooth SIG, 3 November 2025. Standards body (Bluetooth SIG, an industry association funded by its member companies, which owns the Auracast trademark) ↩︎ https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/pbp_v1-0-2_1761252922/PBP_v1.0.2/out/en/index-en.html
6. Bluetooth Core Specification 6.0: broadcast security in the Generic Access Profile and Low Energy Link Layer. Bluetooth SIG, 27 August 2024. Standards body (Bluetooth SIG, an industry association funded by its member companies, which owns the Auracast trademark) ↩︎ https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-60/out/en/host/generic-access-profile.html
7. Bluetooth Security and Privacy Best Practices Guide, revision R04. Bluetooth SIG Security and Privacy Improvement Program. Bluetooth SIG, 24 January 2023. Standards body (Bluetooth SIG, an industry association funded by its member companies, which owns the Auracast trademark) ↩︎ https://www.bluetooth.com/download/bluetooth-security-and-privacy-best-practices-guide/
8. Basic Audio Profile, version 1.0.3. Bluetooth SIG Generic Audio Working Group. Bluetooth SIG, 23 June 2026. Standards body (Bluetooth SIG, an industry association funded by its member companies, which owns the Auracast trademark) ↩︎ https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/bap_v1-0-3_1782503972/BAP_v1.0.3/out/en/index-en.html
9. CVE-2025-20908: Use of insufficiently random values in Samsung’s Auracast implementation. Heinze D; Steinmetz F. ERNW, Insinuator.net, 13 March 2025. Independent (ERNW security researchers; separate research funding not stated) ↩︎ https://insinuator.net/2025/03/cve-2025-20908-use-of-insufficiently-random-values-in-samsungs-auracast-implementation/
10. Samsung Mobile Security: SMR-MAR-2025, SVE-2024-2271 (CVE-2025-20908). Samsung Mobile. Samsung Mobile Security, March 2025. Manufacturer (Samsung, reporting a vulnerability and patch for its own devices) ↩︎ https://security.samsungmobile.com/securityUpdate.smsb?year=2025&month=03
11. SPADE: Secure Periodic Advertising using Coded Time-Channel Rendezvous for BLE Audio. Ryoo D, Yoo Y, Paek J, Bahk S. IEEE DCOSS-IoT 2023, 2023. Government (Korean Ministry of Environment through KEITI, grant 2021002280002; MSIT through IITP, grant IITP-2023-2021-0-02048; and MSIT through NRF, grant 2021R1A2C1008840; researchers at Seoul National University and Chung-Ang University) ↩︎ https://nsl.cau.ac.kr/~jpaek/docs/spade-dcoss-iot-2023.pdf
12. Comparison of Large Area Assistive Listening Systems. Compton-Conley C. Hearing Loss Association of America (reprint), 2015. Nonprofit advocacy (reprinted by HLAA with the contact address of its Get in the Hearing Loop program; written by Cynthia Compton-Conley, PhD, of Gallaudet University; who paid for the original is not stated) ↩︎ https://www.hearingloss.org/wp-content/uploads/comparison-of-large-area-assistive-listening-systems.pdf
13. IR T3 Infrared Transmitter user manual (MAN 295). Williams AV, 6 November 2024. Manufacturer (Williams AV, maker of the SoundPlus IR T3 transmitter described) ↩︎ https://williamsav.com/wp-content/uploads/2024/11/MAN-295-IRT3-User-Manual.pdf

Change log

• 13 October 2026Published with 13 sources.
• 13 October 2026Audited citations; clarified the takeover demonstration's audio limits, research-defence costs, code-exchange advice and infrared and neckloop qualifications.
• 13 October 2026Second citation check retained the distinction between packet experiments, audio outcomes and venue security.

Cite this question

Every finding here cites its source, and who funded each source is labelled. This site does not recommend products. Found an error or a missing study? Suggest a correction, or see how suggestions are handled.