CVE-2026-118611: Unpatched Alpine iLX-F511 Bluetooth OBEX Heap Overflow — Mitigation and Detection Guide

The Zero Day Initiative has published ZDI-26-829, disclosing a heap-based buffer overflow in the Bluetooth OBEX (Object Exchange) packet handling code of the Alpine iLX-F511 aftermarket automotive head unit. The flaw — tracked as CVE-2026-118611 — was demonstrated at Pwn2Own, carries a CVSS score of 6.8, and critically: it is unpatched as of this writing. No authentication is required. An attacker within Bluetooth range of a vehicle running this head unit can achieve arbitrary code execution on the device.

This isn't a theoretical lab curiosity. Pwn2Own-proven bugs in automotive infotainment systems historically become public proof-of-concept material within months of disclosure, and aftermarket head units are installed in millions of vehicles with zero patch management infrastructure. If your organization operates fleet vehicles, executive transport, or service vehicles equipped with this unit — or if you're advising clients who do — this needs to be on your risk register today.

Technical Analysis

Affected Product

How the Vulnerability Works

OBEX is the session protocol Bluetooth uses for object transfers — phonebook sync (PBAP), message access (MAP), and file push (OPP). Head units parse incoming OBEX packets during and after pairing, and in many implementations certain OBEX operations are reachable pre-authentication or during the pairing handshake window.

The flaw sits in the packet parsing path: malformed or oversized OBEX fields overflow a heap allocation in the OBEX handling component, corrupting adjacent heap metadata. With heap grooming — entirely feasible over repeated Bluetooth connections — that corruption becomes control-flow hijack and arbitrary code execution in the context of the media/Bluetooth service on the unit.

Why defenders should care about the blast radius:

1. No authentication required. The attacker doesn't need to pair, know a PIN, or have prior access. Proximity within Bluetooth range (typically ~10m, extended with directional antennas) is sufficient.
2. Infotainment is a pivot point. Modern head units bridge to the vehicle CAN bus, store synced contacts and call logs, cache paired phone credentials, and often run Android-based stacks with broad local privileges. Code execution here is a foothold, not an endpoint.
3. No patch exists. ZDI's 0-day disclosure track means this was reported to Alpine and the coordinated disclosure window elapsed without a fix. Compensating controls are the only option.

Exploitation Status

• Proven exploitable: Demonstrated at Pwn2Own — meaning a working exploit exists in researcher hands.
• In-the-wild exploitation: Not confirmed as of publication.
• CISA KEV: Not listed (typically reserved for vulnerabilities with confirmed active exploitation; monitor for addition).
• Public PoC: Not yet released, but Pwn2Own bugs frequently see public write-ups and derivative PoCs within 3–6 months.

The 6.8 CVSS reflects the adjacency constraint, but don't let the "Medium" label breed complacency — for targeted scenarios (executive vehicles, valet/dealership service lanes, parking structures), the physical requirement is trivially satisfied.

Detection & Response

Detection on the head unit itself is constrained — it's an embedded Linux appliance without an EDR ecosystem. Honest guidance: your detection strategy here is (a) monitoring for anomalous service behavior on the device where logging is accessible, (b) detecting post-exploitation behavior if the unit is used to pivot, and (c) hunting for OBEX service instability — crash loops are the most reliable signal of overflow attempts, since failed exploitation corrupts the heap and crashes the daemon.

Sigma Rules

These rules target the post-exploitation and instability patterns observable if head unit (or Linux-based telematics gateway) logs reach your SIEM via syslog forwarding. The highest-fidelity signal is a Bluetooth/OBEX daemon spawning shell or system utility child processes — that should essentially never happen.

---
title: Bluetooth or OBEX Daemon Spawning Shell or Utility Processes
description: Detects obexd, bluetoothd, or related Bluetooth service processes spawning shells or system utilities — a strong indicator of post-exploitation following Bluetooth stack compromise such as CVE-2026-118611 (Alpine iLX-F511 OBEX heap overflow). Legitimate OBEX daemons never execute child processes.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-829/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/10
id: 3f8a1c92-7e44-4b5a-9d61-2c8e4f7a91b3
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/obexd'
      - '/bluetoothd'
      - '/obex-data-server'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/busybox'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
  condition: selection_parent and selection_child
falsepositives:
  - None expected in normal operation — OBEX daemons do not spawn shells
level: critical
---
title: Bluetooth OBEX Service Crash Loop Indicating Heap Overflow Attempts
description: Detects repeated crashes or restarts of Bluetooth OBEX-related services within a short window. Heap overflow exploitation attempts against OBEX parsers (e.g., CVE-2026-118611) commonly cause daemon crashes during heap grooming before successful exploitation.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-829/
  - https://attack.mitre.org/techniques/T1499/
author: Security Arsenal
date: 2026/04/10
id: 91d2e7b4-3a58-4c6f-b820-5f1a9c3d47e2
status: experimental
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'segfault'
    - 'obexd'
    - 'bluetoothd'
  keywords:
    - 'segfault'
    - 'general protection fault'
    - 'heap corruption'
    - 'SIGSEGV'
  condition: selection and keywords
falsepositives:
  - Rare firmware instability on aging head units — baseline normal crash frequency per device
level: high

KQL (Microsoft Sentinel)

If your fleet telematics, vehicle management infrastructure, or any Linux-based gateway adjacent to these units forwards syslog to Sentinel, hunt for OBEX daemon crashes and anomalous child processes. The second query targets downstream post-exploitation: outbound connections from devices that should have a fixed, known network profile.

// Hunt 1: Bluetooth/OBEX daemon instability — crash loops from overflow attempts
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName has_any ("obexd", "bluetoothd", "obex-data-server")
   or SyslogMessage has_any ("obexd", "bluetoothd")
| where SyslogMessage has_any ("segfault", "SIGSEGV", "heap", "general protection fault", "core dumped")
| summarize CrashCount = count(), FirstCrash = min(TimeGenerated), LastCrash = max(TimeGenerated)
   by Computer, ProcessName
| where CrashCount >= 3
| sort by CrashCount desc;

// Hunt 2: Bluetooth service spawning unexpected child processes (post-exploitation)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("obexd", "bluetoothd")
| where FileName has_any ("sh", "bash", "dash", "busybox", "curl", "wget", "nc", "python")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| sort by TimeGenerated desc;

// Hunt 3: Anomalous outbound connections from head unit / telematics subnets
// Adjust the subnet to your fleet/telematics VLAN range
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP startswith "10.90."
| summarize ConnectionCount = count(), Destinations = make_set(DestinationIP) by SourceIP, DestinationPort
| where ConnectionCount > 100
| sort by ConnectionCount desc;

Velociraptor VQL

For incident responders with access to a compromised or suspect unit (or an associated Linux telematics gateway), this artifact hunts for the forensic residue of OBEX exploitation: crashed daemon cores, unexpected child processes of Bluetooth services, and dropped payloads in writable temp/media paths.

-- CVE-2026-118611 post-exploitation hunt: OBEX daemon children + core dumps + dropped files
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (
   Name =~ '(?i)(sh|bash|dash|busybox|curl|wget|nc|python|perl)$'
)
AND Ppid IN (
   SELECT Pid FROM pslist()
   WHERE Name =~ '(?i)(obexd|bluetoothd|obex)'
)

-- Separately, hunt for core dumps indicating crash-loop exploitation attempts:
-- SELECT FullPath, Size, Mtime FROM glob(globs='/var/crash/*,/tmp/core*,/data/core*,/var/lib/systemd/coredump/*')
-- WHERE Mtime > Now() - 604800

-- And recently written executables in user-writable paths typical of embedded payloads:
-- SELECT FullPath, Size, Mtime FROM glob(globs='/tmp/**,/var/tmp/**,/media/**/tmp/**')
-- WHERE Mtime > Now() - 604800 AND FullPath =~ '(?i)\.(elf|sh|bin)$|/[^.][^/]*$'

Hardening and Verification Script

Since no patch exists, mitigation is configuration-based. The following Bash script is for technicians with shell access to the unit (or an associated telematics gateway) and for fleet IT teams documenting exposure. It inventories Bluetooth/OBEX exposure and applies the primary compensating control — disabling the OBEX profiles that handle unsolicited object transfers while retaining basic hands-free functionality where operationally required.

#!/bin/bash
# CVE-2026-118611 compensating control — Alpine iLX-F511 / Linux head unit exposure audit & hardening
# Run as root. Review each step before applying in production fleet environments.

echo "=== [1] Identify Bluetooth stack and version ==="
btmgmt info 2>/dev/null || hciconfig -a 2>/dev/null
bluetoothd --version 2>/dev/null

echo "=== [2] Enumerate active OBEX-related services ==="
systemctl list-units --type=service | grep -iE 'obex|bluetooth'
ps aux | grep -iE 'obexd|bluetoothd|obex-data' | grep -v grep

echo "=== [3] Check discoverability — device should NOT be discoverable/pairable ==="
hciconfig 2>/dev/null | grep -iE 'PSCAN|ISCAN'
btmgmt info 2>/dev/null | grep -iE 'discoverable|connectable'

echo "=== [4] HARDEN: Disable discoverable and pairable modes ==="
btmgmt discoverable off 2>/dev/null
btmgmt pairable off 2>/dev/null
btmgmt connectable off 2>/dev/null   # Most aggressive: blocks new connections entirely
hciconfig hci0 noscan 2>/dev/null

echo "=== [5] HARDEN: Disable OBEX profile daemons (OPP/FTP/PBAP unsolicited handling) ==="
systemctl stop obex 2>/dev/null
systemctl disable obex 2>/dev/null
pkill -f obexd 2>/dev/null

echo "=== [6] Verify: no OBEX listeners remain, device not discoverable ==="
ps aux | grep -iE 'obexd' | grep -v grep && echo "WARNING: obexd still running" || echo "OK: no obexd process"
btmgmt info 2>/dev/null | grep -iE 'discoverable|connectable'

echo "=== [7] Enable persistent logging of Bluetooth daemon for crash-loop detection ==="
mkdir -p /var/log/bluetooth
journalctl -u bluetooth -f >> /var/log/bluetooth/bluetoothd.log &
logger -t SECAUDIT "CVE-2026-118611 hardening applied: OBEX disabled, BT non-discoverable"

Note: On consumer head units without accessible shells, steps 4–6 translate to device settings: disable Bluetooth visibility, remove stored pairings, and power the unit's Bluetooth radio off when not actively needed (many iLX-F511 installs support this via settings or steering-wheel control profiles).

Remediation

Primary Guidance — No Patch Available

ZDI-26-829 is a zero-day advisory: Alpine has not released a firmware fix. Until one ships, your entire strategy is attack-surface reduction and monitoring.

Immediate actions (this week):

1. Inventory exposure. Identify every vehicle in your fleet or client environment with an iLX-F511 installed. This is an aftermarket unit — check vehicle service records, dealership/install-shop invoices, and expense reports. Fleet managers frequently don't know these are present.
2. Disable Bluetooth discoverability on affected units. Exploitation requires the attacker to reach the OBEX handler; a non-discoverable, non-pairable device dramatically narrows the attack window.
3. Remove stale pairings and set the unit to require manual confirmation for new pairing requests.
4. Where operationally tolerable, disable Bluetooth entirely and use wired (USB) connectivity for phone integration. This eliminates the attack surface.
5. Physically segment high-risk vehicles. Executive transport and vehicles with access to sensitive facilities should be flagged for priority hardening and, where feasible, head unit replacement with an unaffected model.

Monitoring and detection:

• Where the unit or an associated telematics gateway supports logging, forward syslog to your SIEM and deploy the crash-loop detection above — heap grooming against OBEX parsers is noisy at the service level.
• Watch the ZDI advisory page and Alpine's support site (https://www.alpine-usa.com/support) for firmware releases. Apply any fix on an emergency-change cadence, not your normal patch cycle.
• Monitor CISA KEV for addition of CVE-2026-118611 — listing would signal confirmed in-the-wild exploitation and should trigger immediate escalation.

Longer term:

• Add aftermarket telematics/infotainment to your asset inventory and vulnerability management scope. These devices run unpatchable-in-practice embedded stacks and are invisible to most VMS platforms.
• For procurement: require vendors to disclose Bluetooth/attack-surface architecture and commit to firmware update SLAs before approving in-vehicle device purchases.
• Include proximity-based wireless attacks (Bluetooth, Wi-Fi, TPMS) in red team scope for fleet and executive-protection programs — this Pwn2Own result demonstrates the attack class is mature.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub