SweynTooth

SweynTooth is a family of Bluetooth Low Energy vulnerabilities disclosed in February 2020 by researchers at the Singapore University of Technology and Design. The flaws sit in the BLE software development kits supplied by system-on-chip vendors, which means a single defect propagates into every product built on that chip, across manufacturers who often do not know which stack they inherited.

An attacker within radio range can crash a device, force it into a deadlock, or in some cases bypass its security entirely, with no pairing and no authentication. The FDA issued a safety communication because affected chips are used in medical devices. Six years later the research remains relevant, not because the vulnerabilities were hard to fix, but because the patches have to travel from chip vendor to device manufacturer to firmware image to a device somebody has to actually update.

This information is provided for general awareness and defense purposes only.  This information also is not intended to be a complete description of the functionality or risks of the identified tools.

Quick Facts

• Disclosed: February 2020 by Matheus Garbelini, Sudipta Chattopadhyay, and Chundong Wang of the Singapore University of Technology and Design, after a 90-day responsible disclosure period beginning in late 2019.
• What it affects: BLE software development kits from system-on-chip vendors including Texas Instruments, NXP, Cypress, Dialog Semiconductor, Microchip, STMicroelectronics, and Telink.
• Scale: a dozen initial CVEs, later extended, believed to reach more than 480 end products.
• Impact classes: crashes, deadlocks, and in some cases a complete bypass of BLE security.
• Access required: radio proximity only. No pairing, no credentials, no user interaction.
• Why it persists: patches travel from chip vendor to device maker to firmware to end user, and some affected products lack the ROM space to take the fix at all.

What Is SweynTooth?

SweynTooth is not a single bug. It is a set of defects the researchers found by systematically fuzzing BLE implementations at the protocol level, then confirming that the same categories of failure recurred across chips from different manufacturers.

The important structural detail is where the flaws live. They are in the vendor-supplied SDKs and link layer implementations that product developers build on top of, not in the Bluetooth specification and not in application code. A wearable maker, an infusion pump manufacturer, and a smart lock company can all ship the same defect without ever having written the affected line, and frequently without knowing whose stack is inside the module they purchased.

The research is published by the ASSET Research Group, and proof-of-concept code has been public since disclosure. That last point matters for risk assessment: this is not a theoretical capability requiring a well-funded actor.

The Vulnerability Classes and Key CVEs

The family divides into three effect categories. A representative sample of the assigned identifiers:

Vulnerability	CVE	Affected implementation	Effect
Link Layer Length Overflow	CVE-2019-16336	Cypress PSoC 4/6 BLE component	Denial of service, with potential for further exploitation
Link Layer Length Overflow	CVE-2019-17519	NXP KW41Z SDK	Denial of service, with potential for further exploitation
Truncated L2CAP	CVE-2019-17517	Dialog DA14580, SDK 5.0.4 and earlier	Crash and denial of service
Silent Length Overflow	CVE-2019-17518	Dialog DA14680	Crash and denial of service
Link Layer LLID Deadlock	CVE-2019-17061	Cypress	Deadlock; BLE communication halts
Link Layer LLID Deadlock	CVE-2019-17060	NXP	Deadlock; BLE communication halts

Additional identifiers were assigned as the work extended, including issues later associated with medical device advisories. When assessing a specific product, work from the chip and SDK version rather than the vulnerability name, because whether a given device is affected depends on which SDK revision its firmware was built against.

What an Attacker Can Actually Do

Being precise here matters, because SweynTooth is sometimes described as full remote takeover of any Bluetooth device, which overstates it, and sometimes dismissed as “just a crash,” which understates it.

• Crash and denial of service. Malformed link layer packets cause the target to fault. On a fitness tracker that is an annoyance. On a glucose monitor, an infusion pump, or an industrial sensor feeding a control loop, availability is a safety property.
• Deadlock. Some devices stop communicating until they are manually power-cycled, which for a wall-mounted or implanted device is a service call rather than a reboot.
• Security bypass. The most serious class allows an attacker to skip the pairing and authentication that the product’s security model assumes, reaching functionality intended to be protected.
• Potential code execution. The researchers noted that overflow conditions could be developed into remote execution against specific firmware by an attacker willing to reverse engineer it. Treat this as product-specific rather than universal.

The precondition throughout is radio range, which in practice means the parking lot, the adjacent suite, the waiting room, or a bag left in a corridor. There is no network path to filter and no credential to steal.

Who Is Affected

The affected chips are general-purpose BLE parts, so the exposure follows wherever cheap Bluetooth radios went, which is essentially everywhere.

• Medical devices. The FDA issued a safety communication in 2020 informing patients, providers, and manufacturers of the risk, noting that exploit code was already public while no confirmed adverse events had been reported. Singapore’s Health Sciences Authority identified dozens of affected medical devices in its own advisory.
• Building and facility systems. Smart locks, access control peripherals, occupancy and environmental sensors, and lighting controls.
• Industrial and logistics equipment. Asset tags, condition monitoring sensors, and handheld tools, where devices stay in service for a decade or more.
• Consumer devices carried into your facility. Wearables, earbuds, and trackers, which arrive on the wrists and in the ears of employees and visitors and are governed by no one’s patch policy.

Why It Still Matters

Chip vendors patched their SDKs quickly. That was the easy part, and it is not what determines whether a device in your building is vulnerable today.

• The patch chain has four links. The chip vendor fixes the SDK, the device manufacturer rebuilds firmware against it, the firmware reaches the field, and someone applies it. Each link adds months, and any one of them can simply not happen.
• Some devices cannot be patched at all. In the closely related BrakTooth research, some affected products were found to lack sufficient ROM space to accept the fix.
• Embedded lifecycles are long. Medical, building, and industrial equipment installed in 2019 is frequently still in service, often past the manufacturer’s support window.
• The pattern repeated. The same research group disclosed BrakTooth in 2021, affecting Bluetooth Classic stacks across more than 1,400 chipsets from vendors including Intel, Qualcomm, Texas Instruments, Infineon, and Silicon Labs, with the most serious issue, CVE-2021-28139, allowing code execution. CISA urged manufacturers to patch after exploit code was released. The distribution problem was identical.

The general lesson practitioners drew is the durable one: RF protocol stacks are considerably less battle-tested than IP networking, and the fix pipeline for embedded radios is far slower than for servers or phones. Related reading in our research: Bluetooth vulnerabilities and Bluetooth data exfiltration.

Can Exploitation Be Detected?

Not by the tools most organizations already own, which is the uncomfortable part of this threat class.

• Nothing crosses the network. BLE traffic never touches your switches, so firewalls, NAC, and network monitoring have no visibility into it whatsoever.
• The targets have no telemetry. A sensor or wearable running a small embedded stack has no agent, usually no meaningful logging, and often no way to report that it faulted.
• The symptom looks like a fault. A device that crashed or deadlocked reads as a hardware problem or a dead battery, so exploitation and malfunction are indistinguishable without RF evidence.
• What does see it: passive RF monitoring, which observes the transmissions themselves and can record which devices were present, when they stopped transmitting, and what else was operating nearby at that moment.

The Inventory Problem

Before detection there is a more basic issue: you cannot patch, replace, or risk-assess devices you cannot enumerate, and BLE inventories are notoriously incomplete.

The technical reason is that BLE devices advertise while looking for a connection and largely go quiet once paired. Tooling that discovers devices by listening for advertisements therefore sees a fraction of what is actually operating, and a paired medical device or sensor that has been running for two years may never appear in a scan at all. An inventory built that way understates the estate, and every device missing from it is a device nobody checked the firmware version on.

How Bastille Helps

Bastille monitors the RF spectrum passively from 100 MHz to 7.125 GHz with software-defined radios, observing Bluetooth and BLE transmissions directly rather than inferring devices from network activity or advertisement scans.

Scope this accurately: RF monitoring identifies the Bluetooth and BLE devices operating in your space and where they are. Determining whether a given unit runs a vulnerable SDK build still requires mapping that device to a model, firmware version, and vendor advisory. The monitoring solves the half of the problem that asset databases cannot, which is knowing what is actually there.

Frequently Asked Questions

What is SweynTooth?

SweynTooth is a family of Bluetooth Low Energy vulnerabilities disclosed in February 2020 by researchers at the Singapore University of Technology and Design. The flaws are in BLE software development kits supplied by chip vendors, and they allow an attacker in radio range to crash devices, deadlock them, or bypass their security.

Which chips and vendors are affected?

BLE system-on-chip implementations from Texas Instruments, NXP, Cypress, Dialog Semiconductor, Microchip, STMicroelectronics, and Telink were identified, affecting an estimated 480 or more end products. Whether a specific device is affected depends on the SDK version its firmware was built against.

Does an attacker need to pair with the device?

No. The attacks operate at the link layer and require only radio proximity. There is no pairing, no authentication, and no user interaction involved, which is why network controls are irrelevant to this threat.

How close does an attacker have to be?

Within BLE radio range, which in practice means the same building, an adjacent suite, a waiting area, or a parking area close to an exterior wall. Range varies with the transmitter, antenna, and construction.

Can SweynTooth be used to take over a device completely?

Mostly it causes crashes, deadlocks, or a bypass of the device’s security model. The researchers noted that some overflow conditions could be developed into code execution against specific firmware by an attacker willing to reverse engineer it, so treat full takeover as product-specific rather than a general property of the family.

Are medical devices affected?

Yes. The FDA issued a safety communication in 2020 advising patients, providers, and manufacturers about the risk to certain Bluetooth-enabled medical devices, noting that exploit code was publicly available and that no confirmed adverse events had been reported at the time. Singapore’s Health Sciences Authority published a parallel advisory identifying affected devices.

Has SweynTooth been patched?

The chip vendors patched their SDKs. Whether a particular device in your facility is patched depends on whether its manufacturer rebuilt firmware, shipped it, and whether anyone installed it. Some products cannot accept the fix because they lack sufficient ROM space.

Is SweynTooth still relevant in 2026?

As a live vulnerability it matters wherever long-lived embedded devices were never updated, which is common in medical, building, and industrial estates. As a case study it matters more, because the same distribution failure recurred with BrakTooth in 2021 and will recur with the next BLE stack disclosure.

What is the difference between SweynTooth and BrakTooth?

Same research group, different protocol. SweynTooth targets Bluetooth Low Energy stacks and was disclosed in 2020. BrakTooth, disclosed in 2021, targets Bluetooth Classic link manager implementations across more than 1,400 chipsets, and its most severe issue allows code execution.

Will my firewall, NAC, or endpoint tooling see this?

No. BLE traffic never traverses your network, and the affected devices generally have no agent and no useful logging. Detection has to happen at the radio layer.

How do I find the BLE devices in my environment?

Not reliably with advertisement scanning alone, because BLE devices largely stop advertising once paired. Continuous passive RF monitoring that tracks devices through the pairing lifecycle produces a materially more complete inventory, which is the prerequisite for any patch or replacement program.

How would I know if a device was attacked rather than simply failed?

Without RF history you generally would not, since a crashed or deadlocked device looks like a hardware fault. A record of what was transmitting nearby when the device stopped is usually the only available evidence.

What Can I Do to Defend Against This Threat?

• Inventory the BLE devices actually operating in your space, including paired ones, and reconcile that against your asset database rather than trusting the database alone.
• Map devices to chip and SDK versions through vendor advisories, prioritizing anything where availability is a safety property.
• Ask procurement the awkward question: which BLE stack is in this product, and what is the firmware update mechanism and support window? A device with no update path is a permanent decision.
• Treat unpatchable devices as a placement problem. If it cannot be fixed, control where it sits and who can get within radio range of it.
• Monitor the spectrum continuously, so unexplained device failures can be correlated against what else was transmitting at the time.
• Extend the same discipline to the next disclosure. The specific CVEs matter less than having a process that can answer “which of our devices use that chip, and where are they?” within days rather than quarters.

Wireless protocol stacks are still early in their security maturity compared with IP networking, and the devices carrying them are the hardest in the building to patch. See a demo to understand how Bastille inventories and locates Bluetooth and BLE devices in your environment, or browse more Bastille wireless security research.