Raghu Bharadwaj

Posted on Sep 1 Originally published at techveda.live

Open-Source Device CVEs: What to Patch by Vertical (August 2026)

#linux #security #embedded #opensource

August 2026 brought 11 open-source device CVEs and advisories worth acting on across three packages: U-Boot, systemd, and BlueZ. Only five of the 11 carry a CVE number, which is the main thing to take from this month. None is in the CISA Known Exploited Vulnerabilities catalog. Proof-of-concept code is published for two, and we found no evidence of exploitation in the wild. Most have a fix upstream, but several BlueZ fixes exist only as commits and two have no fix at all, so the action is to take your distribution's patched package or cherry-pick, then rebuild your image.

This is the device stack beyond the kernel. It is the bootloader, the C library, the init system, the TLS and networking code, the media pipeline, and the container runtime that sit inside a shipped image. Which of these open-source device CVEs matter to you depends on what is actually in your image and your software bill of materials (SBOM).

The EU Cyber Resilience Act creates software-inventory and vulnerability-handling duties that make SBOM-style tracking operationally necessary, so the SBOM is the list you check this report against. This month the pressure was on the Bluetooth stack. BlueZ published nine advisories in August, more than the rest of our watchlist combined, and most of them carry no CVE number.

A note on coverage. This edition swept the bootloader, C library, init and Bluetooth parts of the stack in full. We did not complete a sweep of the TLS and crypto libraries, the remaining connectivity packages, the remote-access tools, the parsing libraries, the media pipeline, or the container runtime this month. Those are not reported as clear; they are unexamined, and we would rather say so than imply a clean result we did not verify.

We report a package CVE only when it meets one of three tests: a CVSS base score of 7.0 or higher, or a place in the CISA KEV catalog, or clear reachability in a normal device build. Severity numbers come from the source named for each item, because upstream projects, NVD enrichment, and downstream scorers such as the CISA ADP do not always score the same issue the same way.

Kernel CVEs are not here; they are covered by our weekly kernel advisory.

Most of this month's device stack work has no CVE number

The main finding this month is not a single vulnerability. It is that a CVE feed would have shown you almost none of this. BlueZ published nine security advisories in August 2026. Seven of them have no CVE identifier at all. The systemd project fixed a root-level udev issue in the same month, also with no CVE. If your process is to scan an SBOM for CVE identifiers and patch what comes back, that process found two BlueZ issues in August. The project published nine.

The systemd case shows the shape of the problem clearly. The scsi_id helper did not sanitise device metadata read from the kernel, so the ID_WWN, ID_WWN_VENDOR_EXTENSION, and ID_WWN_WITH_EXTENSION values could carry an embedded newline. That allowed an attacker to inject a SYSTEMD_WANTS= line and start a unit of their choosing as root. Plugging in a malicious SCSI or iSCSI device is enough to trigger it, because udev runs at boot as root and parses whatever the device reports.

It was fixed in systemd 261, 260.2, 259.6, and 258.8, and published as advisory GHSA-m8q3-73v4-wvg7. No CVE was assigned, so no CVE-based scan will ever raise it.

This matters for the Cyber Resilience Act specifically. The duty is to know which known vulnerabilities affect your product. A known vulnerability with a published upstream advisory and a published fix is a known vulnerability whether or not anyone minted an identifier for it.

Tracking the advisory feeds of the packages in your SBOM, alongside the CVE feed, is the practical way to meet that. This month is a good argument for doing so: on the CVE feed alone you would have seen roughly a fifth of what BlueZ actually told its users.

Open-source device CVEs to update this month

Package	CVE(s) / advisory	Bug type	Fixed version	Verticals
`U-Boot`	`CVE-2025-70290`, `CVE-2025-70293`	Integer overflows in ZFS and ext4 filesystem parsing at boot. See the note on scoring below	`2026.04`. Recommended baseline `2026.07`	Embedded/IoT, Mobile/Automotive, Medical
`systemd` (`systemd-oomd`)	`CVE-2026-15059`	Local denial of service. A world-writable varlink socket lets any local user make the privileged daemon kill a chosen process (5.5, systemd CNA)	`261`, `260.3`, `259.7`, `258.9`	Cloud/Datacenter, Embedded/IoT, Medical
`systemd` (`udev`)	No CVE. `GHSA-m8q3-73v4-wvg7`	Unit activation as root. Unsanitised SCSI metadata allows `SYSTEMD_WANTS=` injection. Needs physical port access (6.4, systemd CNA)	`261`, `260.2`, `259.6`, `258.8`	Mobile/Automotive, Embedded/IoT, Medical
`BlueZ` (radio range)	`CVE-2026-80186`, `CVE-2026-75032`, and `GHSA-9683-2chf-hfw9` (no CVE)	Stack overflow in `name2utf8` via a crafted discovery packet, needing no pairing (7.2). Out-of-bounds read in AVRCP parsing, needing a paired device (6.3). Stack overflow in the LE Audio BASE parser, pre-authentication and over the air (low)	No release. Commit `381b5d0d`; commits `bd898962` and `58088149`. The LE Audio issue is unfixed	Mobile/Automotive, Embedded/IoT, Medical
`BlueZ` (local, via D-Bus)	No CVEs. `GHSA-4p57-mrcv-r2jc`, `GHSA-75v6-6q44-57hc`, `GHSA-rfcf-9fw3-m9qp`, `GHSA-hhgc-hfgf-8m4x`	Two `sdp-xml` issues via `RegisterProfile`: quadratic parsing denial of service and a heap leak. Two advertisement monitor heap overflows. All need a local caller on the system bus	No release. Commits `308e3536`, `ae6c543e`, `14347c86`	Mobile/Automotive, Embedded/IoT, Medical

A note on the U-Boot scoring. CVE-2025-70290 carries a 9.8, but that score comes only from the CISA ADP auto-scorer, which treated it as network-reachable. There is no NVD primary analysis and no score from the project. The bug parses a filesystem image from local media, so the realistic reading is code execution before the operating system starts, triggered by attacker-supplied storage, rather than anything remote. CVE-2025-70293 has no score from any scorer and is listed here on reachability alone.

Two further BlueZ advisories are outside the table. GHSA-7c3p-mgcr-hf6w, an out-of-bounds access in amp_dump_chanlist, is the one August issue with a real tagged fix: it affects 5.79 and earlier and is fixed in 5.80, so most current images already have it. GHSA-7wjj-8mrm-jhw4, a heap buffer overflow in the BASS broadcast source builder, affects 5.76 and earlier and has no fix, but devices on a recent BlueZ are already past the affected range.

Packages checked this month with nothing that met the inclusion tests: Trusted Firmware-A, GRUB2, musl, and D-Bus. The glibc project published two issues in August, both scored below 7.0 and neither reachable in a normal device build, so they are not listed.

Watch item. BlueZ CVE-2026-80185 is a type confusion in sdp-xml.c, reached through RegisterProfile with crafted nested ServiceRecord data. A local caller who can reach org.bluez.ProfileManager1.RegisterProfile on the system bus can crash bluetoothd with it. The advisory records no released fix and gives the fixed version as unknown, so there is nothing to update to yet. Until there is, you can restrict untrusted local access to org.bluez on the system bus.

One caution on that advisory, GHSA-7mmr-gwqx-vc34. Its title says the issue "leads to arbitrary code execution as root", but its own body says the opposite: "the available evidence establishes local denial of service only", and it is scored 5.5 with no confidentiality or integrity impact. The advisory also states it was generated using AI and asks readers to review it before use. The body and the score are the parts to trust here. If you triage from advisory titles, this one would have sent you after the wrong thing.

Order the work by reachability rather than by score, because the scores this month are unreliable in both directions. Take the two BlueZ issues that need no pairing first: CVE-2026-80186 at 7.2 with a published proof of concept, and the LE Audio BASE parser overflow, which its advisory rates low but describes as pre-authentication and over the air, and which has no fix.

Then the systemd udev issue, if your device has an accessible physical port. Then the U-Boot filesystem issues, if your boot flow reads media a user can replace. The local BlueZ and systemd-oomd issues come last on a single-user embedded device, and considerably higher on a shared or multi-tenant host.

Mobile and automotive

On automotive ARM SoCs that actually ship U-Boot, it runs first in the boot chain. Many platforms instead use a vendor fork, a TF-A chain, or a proprietary first stage, so this applies only where U-Boot is in the image.

The August issues are in filesystem parsing rather than the network path. CVE-2025-70290 is an integer overflow in ZFS metadata parsing and CVE-2025-70293 is an integer overflow in the ext4 block group descriptor table. Both are reached when the bootloader reads a filesystem image that an attacker controls, which in practice means removable media or a service partition.

Before treating either as urgent, confirm that the affected filesystem support is enabled in your U-Boot configuration and that the boot flow actually reads content an attacker could influence. The fixes first landed upstream in 2026.04. We recommend 2026.07 or later as the practical baseline, because it clears these filesystem issues and the July network-path issues together.

Bluetooth is the other exposed surface in a vehicle, because the head unit pairs with phones the manufacturer does not control. Three of the August BlueZ issues are reachable from a device within radio range, and they differ in what the attacker must first achieve.

CVE-2026-80186 is a stack buffer overflow in name2utf8 triggered by a crafted Extended Inquiry Response packet during discovery, so it needs no pairing at all. The LE Audio BASE parser overflow in GHSA-9683-2chf-hfw9 is described by its advisory as pre-authentication and over the air, so it also needs no pairing, and it has no fix. CVE-2026-75032, the AVRCP out-of-bounds read, does need a paired device. Radio range is a real constraint, but a car in a car park is within range of anyone standing near it.

There is no BlueZ release to move to. Every August fix exists as a commit rather than a tagged version, and two of the issues have no fix at all. The practical options are your distribution's patched package, which for Debian covers only the AVRCP issue in 5.87-2, or cherry-picking the commits listed in the table. Note also that one of the advertisement monitor overflows affects 5.87, the newest release, so moving to the latest tag does not by itself clear the month.

The infotainment media pipeline is normally the largest surface in a vehicle, because FFmpeg, GStreamer and a browser engine all decode untrusted input. We did not sweep those packages this month, so treat their absence here as unexamined rather than clear.

Embedded and IoT

On small devices the bootloader and the network client are the parts that touch untrusted input. Update U-Boot to 2026.07 if the device mounts a filesystem the user can replace, for example an SD card or a USB stick used for field updates. Minimal images that use BusyBox init or a cut-down udev replacement are not affected by the systemd issues at all.

If your image does run a full systemd, take that update too. The udev scsi_id issue is most relevant on this class of device, because they often expose a physical USB port and run udev as root at boot.

If your device speaks Bluetooth, the BlueZ items above apply here as much as they do in a vehicle, and small devices are often the ones running an older BlueZ that no one has moved in years. Check which version is actually in your image. The rest of the small-device set, including BusyBox, Dropbear, the embedded TLS libraries and the compression and parsing libraries, was not swept this month.

Cloud and datacenter

The systemd-oomd issue is the one that matters most on multi-tenant hosts. Its varlink socket is world-writable at mode 0666, so any local unprivileged account can ask the privileged daemon to kill a process it chooses, and a working proof of concept is published. On a shared host that is a denial-of-service primitive against other tenants' workloads. Update systemd to 261, 260.3, 259.7, or 258.9.

If you cannot take the update immediately, a drop-in setting SocketMode=0600 on the socket unit closes it, and systemd-oomd is not enabled on many minimal server images in the first place.

The four local BlueZ issues also belong here rather than in the field, because they need a caller on the system bus. On a host where untrusted workloads share a machine, narrow the D-Bus policy for org.bluez if the service is present at all; on most servers it should not be. The container runtime is usually the highest-severity item in this section, and it was not swept this month, so check containerd and runc separately.

Medical devices

Connected medical devices draw their packages from the other three stacks, so the risk is whichever of these is network-reachable or parses untrusted clinical data. Bluetooth is the clearest example this month. Patient monitors, wearables, glucose meters and hospital gateways commonly use BlueZ to pair with sensors and phones, and the radio-reachable issues above need only a device within range. In a ward or a waiting room that is a low bar.

Weigh CVE-2026-80186 first, because a crafted discovery packet reaches it without a completed pairing, and a proof of concept is published. The LE Audio BASE parser issue deserves attention too, because it is also pre-authentication and currently has no fix, which makes it a candidate for compensating controls rather than patching.

The absence of CVE numbers is a particular problem in this sector. Medical device software inventories and regulatory submissions are frequently organised around CVE identifiers. Seven of the nine BlueZ advisories this month have none, so a device file that tracks CVEs alone will not show them, and a supplier questionnaire asking "which CVEs affect this device" will get an answer that is technically accurate and materially incomplete. Ask suppliers about upstream advisories, not only CVEs.

The packages that parse clinical data and medical video, including SQLite, expat, libxml2, FFmpeg and GStreamer, were not swept this month. On a connected medical device those are usually where the untrusted DICOM, HL7 and FHIR content lands.

Of the confirmed items, U-Boot applies to devices that mount a replaceable filesystem during service, and the systemd udev issue applies to any device with an accessible physical port, which includes bedside and cart-mounted equipment. Medical-device updates go through validation and regulatory change control, including US FDA postmarket cybersecurity guidance, EU MDR, and IEC 62304, so the action is to schedule these updates through the device manufacturer's established change-control process rather than patching in place.

How to check if it applies to you

Three questions decide whether any row above is your problem. First, is the package in your image and your SBOM at all? If it is not built into the product, its CVEs are not yours. Second, is the vulnerable feature actually built or enabled? The U-Boot issues need the relevant filesystem support enabled and a boot flow that reads attacker-influenced content; the systemd-oomd issue needs that daemon to be running.

Third, is your installed version below the fixed version? Distributions often backport a fix without matching the upstream version number, so a vendor package that looks older may already carry the patch. Check your distribution's changelog before assuming you are exposed. For most of the BlueZ items this question is harder than usual, because there is no fixed version to compare against, only a commit.

raghu@techveda.org:~$ systemctl --version
systemd 259 (259.4-1)
raghu@techveda.org:~$ systemctl is-active systemd-oomd
active

Here the device reports systemd 259.4 and confirms that systemd-oomd is running. 259.4 is below the fixed 259.7 on that branch, and the affected daemon is active, so the update applies. For the bootloader, read the version from your build manifest or the boot log rather than from the running system. For libraries without a version command, read the version from your SBOM and compare it to the fixed version in the table.

Key takeaways

Most of this month's device stack work carries no CVE number. BlueZ published nine advisories in August and seven have no CVE; the systemd udev fix has none either. A CVE-only process saw a fraction of it.
BlueZ has no release to move to. Every August fix is a commit rather than a tagged version, two issues have no fix at all, and one advertisement monitor overflow affects 5.87, the newest release. Moving to the latest tag does not clear the month.
The two issues that need no pairing are the ones to weigh first: the name2utf8 overflow (CVE-2026-80186, 7.2, proof of concept published) and the LE Audio BASE parser overflow, which is pre-authentication and unfixed.
The U-Boot ZFS score of 9.8 comes from the CISA ADP auto-scorer and treats a local media-parsing bug as network-reachable. Take the update, but do not let that number set your priority order.
Nothing in this roundup is in the CISA KEV catalog. We checked the whole catalogue against the whole watchlist; only OpenSSL and WebKitGTK appear at all, for historic entries from 2014 and 2019.
Advisory titles are not a triage signal. GHSA-7mmr-gwqx-vc34 is titled "arbitrary code execution as root" and its own body concludes local denial of service only.
This edition swept the bootloader, C library, init and Bluetooth stack only. The TLS libraries, remote-access tools, parsing libraries, media pipeline and container runtime were not examined, so treat them as unchecked rather than clear.
Map each CVE to your SBOM, confirm the feature is built and your version is below the fix, then update the package and rebuild the image.

DEV Community