ICSA-26-260-01: Bransys ELD Hardcoded MQTT Credentials (CVE-2026-86520) — Detection and Remediation Guide for Fleet Operators

CISA has published ICS Advisory ICSA-26-260-01 covering three vulnerabilities in the Bransys Electronic Logging Device (ELD) mobile application — a product deployed across the U.S. Transportation Systems sector and used by motor carriers to meet FMCSA hours-of-service logging mandates. The headline issue, CVE-2026-86520, is a classic but devastating IoT design failure: the application ships with hardcoded MQTT credentials that grant read access to real-time telemetry data for every active device on the platform. Combined with cleartext transmission of sensitive information and a firmware exposure vector, successful exploitation allows unauthorized parties to access telemetry data and firmware across the Bransys ELD fleet.

For defenders, the implications extend well beyond privacy. Real-time ELD telemetry includes vehicle location, driver identity, engine diagnostics, and duty status. An attacker holding a single credential extracted from one APK or IPA effectively holds a fleet-wide surveillance capability — enabling cargo theft targeting, competitive intelligence gathering, driver tracking, and reconnaissance against transportation critical infrastructure. CISA assigns this advisory a CVSS v3 score of 7.5 (High), and every organization running Bransys ELD on Android below version 11.00.00 or iOS below version 1.1.54 should treat this as an urgent patch-and-rotate event.

Technical Analysis

Affected Products and Versions

Vendor: Bransys (U.S.-headquartered) Critical Infrastructure Sector: Transportation Systems Deployment: United States CVSS v3 Base Score: 7.5 (High) Weakness Classes: CWE-798 (Use of Hard-coded Credentials), CWE-319 (Cleartext Transmission of Sensitive Information)

How the Vulnerabilities Work — Defender's View

CVE-2026-86520 — Hardcoded MQTT Credentials (CWE-798). MQTT is the lightweight publish/subscribe messaging protocol that underpins most telematics platforms. Brokers typically listen on TCP 1883 (cleartext) or TCP 8883 (TLS). The Bransys ELD application embeds identical broker credentials in every shipped copy of the app. Because mobile binaries are trivially reverse-engineered — apktool, jadx, or a simple strings pass over the binary will surface embedded connection strings, client IDs, usernames, and passwords — any actor who downloads the app can extract the credential and authenticate directly to the broker. Worse, the advisory states these credentials grant read access to real-time data for every active device, meaning the MQTT topic ACLs are effectively flat: one credential subscribes to the entire fleet's telemetry topics (typically wildcard subscriptions such as # or devices/+/telemetry). There is no per-device isolation to fall back on.

CVE-2026-86689 — Cleartext Transmission of Sensitive Information (CWE-319). Sensitive data transits without adequate transport encryption. In MQTT deployments this almost always means traffic on port 1883 without TLS, exposing session credentials, device identifiers, and telemetry payloads to anyone with network position — cellular carrier infrastructure, compromised ISP hops, rogue Wi-Fi, or BGP-level interception. Cleartext transmission compounds the hardcoded credential problem: even if the credential were rotated, passive observers could harvest the new one off the wire.

CVE-2026-77960 — Firmware Exposure. The advisory indicates the vulnerability set can extend to unauthorized access of device firmware. Firmware retrieval enables full reverse engineering of the ELD's on-device logic, extraction of additional secrets, discovery of further vulnerabilities, and potentially the development of malicious firmware images or clone devices that spoof legitimate units on the platform.

Attack Chain

1. Attacker downloads the Bransys ELD app from a public app store or obtains an APK/IPA from a device.
2. Static analysis recovers the embedded MQTT broker hostname, port, username, and password.
3. Attacker connects to the broker from any internet-facing host using a standard MQTT client (mosquitto_sub, MQTTX, custom Python with paho-mqtt).
4. With read access scoped to all active devices, attacker subscribes to fleet-wide topics and harvests real-time location, driver, and vehicle telemetry.
5. Cleartext transport (CVE-2026-86689) enables passive credential and data capture for attackers with network position, and the firmware vector (CVE-2026-77960) enables deeper platform compromise.

Exploitation Status

At the time of the advisory's publication, CISA has not reported confirmed in-the-wild exploitation, and these CVEs are not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the exploitation barrier here is effectively zero — no memory corruption, no race conditions, no authentication bypass chaining. The credential is sitting in a publicly distributed binary, and public MQTT brokers with weak or shared credentials are among the most routinely scanned and abused services on the internet. Treat exploitation as probable rather than theoretical, and assume any credential embedded in versions below the fixed releases must be considered compromised.

Detection & Response

Detection for this advisory centers on three observable behaviors: (1) cleartext MQTT traffic on TCP/1883 leaving your network or device estate, (2) unexpected or unauthorized client connections to MQTT brokers — particularly the vendor's — and (3) internal hosts running MQTT subscriber tooling that has no business purpose. Fleet operators with corporate-managed Android devices and any egress visibility can act on all three today.

Sigma Rules

---
title: Cleartext MQTT Broker Connection on TCP 1883
id: 3f7a9c41-2b6d-4e58-9c1a-8d4e5f6a7b8c
status: experimental
description: Detects outbound network connections to MQTT brokers over the cleartext port 1883. Bransys ELD vulnerabilities CVE-2026-86520/CVE-2026-86689 involve MQTT telemetry and cleartext transmission; no fleet telemetry should traverse the network unencrypted.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-01
  - https://attack.mitre.org/techniques/T1040/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1040
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 1883
  filter_local_broker:
    DestinationIp|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
  condition: selection and not filter_local_broker
falsepositives:
  - Authorized on-premises telemetry gateways relaying to vendor brokers (these should be migrated to TLS/8883 rather than whitelisted long-term)
level: high
---
title: MQTT Subscriber Tool Execution on Managed Endpoint
id: 8b2e6d14-5c3f-4a79-b2d8-1e6f9a0b3c4d
status: experimental
description: Detects execution of common MQTT client tooling (mosquitto_sub, MQTT.fx, MQTTX CLI, paho-based scripts) on endpoints. Such tools have no legitimate presence on dispatcher, driver, or general fleet-operations workstations and may indicate credential abuse against an ELD broker following ICSA-26-260-01.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-01
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\mosquitto_sub.exe'
      - '\mosquitto_pub.exe'
      - '\mqttx.exe'
      - '\mqtt-cli.exe'
  selection_cli:
    CommandLine|contains:
      - 'mosquitto_sub'
      - 'paho.mqtt'
      - 'mqtt subscribe'
  condition: 1 of selection_*
falsepositives:
  - IoT developers or telematics engineers with documented MQTT development duties
level: medium
---
title: Egress Connection to TLS MQTT Port From Non-Gateway Host
id: c1d4e7a2-6f8b-4c35-a9d2-7b3e5f1a8c9d
status: experimental
description: Detects outbound connections to MQTT over TLS (TCP/8883) from hosts that are not approved telematics gateways. After credential rotation for CVE-2026-86520, unexpected subscribers authenticating to the broker should be treated as credential leakage.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-01
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1071
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 8883
  filter_gateway:
    Computer|contains: 'TELEMATICS-GW'
  condition: selection and not filter_gateway
falsepositives:
  - Managed mobile devices VPN-ing through corporate egress; tune the gateway filter to your authorized device egress paths
level: low

KQL — Microsoft Sentinel / Defender

This query hunts for cleartext MQTT (1883) and TLS MQTT (8883) egress across firewall/CEF logs and Defender network events, flagging anything outside an approved broker allowlist. Replace the allowlist with your authorized Bransys broker endpoints and gateway IPs once confirmed with the vendor.

let ApprovedBrokers = dynamic(["mqtt.example-bransys-broker.com"]);
let ApprovedGateways = dynamic(["10.20.30.40"]);
let MqttNet = union isfuzzy=true
    (CommonSecurityLog
     | where DestinationPort in (1883, 8883)
     | extend Dest = coalesce(DestinationHostName, DestinationIP), Src = SourceIP, Port = DestinationPort, Proto = "Firewall"),
    (DeviceNetworkEvents
     | where RemotePort in (1883, 8883)
     | extend Dest = coalesce(RemoteUrl, RemoteIP), Src = LocalIP, Port = RemotePort, Proto = "Defender");
MqttNet
| where not(Dest has_any (ApprovedBrokers) and Src in (ApprovedGateways))
| extend Risk = iff(Port == 1883, "CRITICAL: Cleartext MQTT egress (CVE-2026-86689 exposure)", "REVIEW: MQTT/TLS from non-approved path")
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Devices = make_set(DeviceName, 20)
    by Src, Dest, Port, Risk, Proto
| order by Risk asc, Connections desc

Velociraptor VQL

Use this artifact to sweep endpoints for MQTT client tooling and live connections to MQTT ports — useful both for finding unauthorized subscribers and for inventorying which machines still initiate cleartext telemetry sessions.

-- Hunt for MQTT client processes and active connections to MQTT broker ports
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime,
       'process' AS IndicatorType
FROM pslist()
WHERE CommandLine =~ '(?i)mosquitto_(sub|pub)|paho\.mqtt|mqttx|mqtt.*subscribe'
   OR Exe =~ '(?i)mosquitto|mqttx|mqtt-cli'
UNION ALL
SELECT Pid, Name, '' AS CommandLine, '' AS Exe, '' AS Username,
       '' AS CreateTime, 'connection' AS IndicatorType
FROM netstat()
WHERE RemotePort in (1883, 8883) AND State =~ 'ESTAB'

Remediation Script

This Bash script audits Linux-based telematics gateways and jump hosts for cleartext MQTT egress, applies egress firewall rules blocking TCP/1883 while permitting TLS MQTT only to an approved broker IP, and verifies the resulting ruleset. Adjust APPROVED_BROKER to the confirmed Bransys broker address.

#!/usr/bin/env bash
# ICSA-26-260-01 hardening: block cleartext MQTT egress, allowlist TLS MQTT
set -euo pipefail

APPROVED_BROKER="203.0.113.10"   # Replace with confirmed Bransys MQTT broker IP
LOG=/var/log/mqtt_hardening.log

echo "[+] Auditing current MQTT egress connections..." | tee -a "$LOG"
ss -tnp | awk '$5 ~ /:1883$|:8883$/ {print}' | tee -a "$LOG" || true

echo "[+] Auditing installed MQTT client tooling..." | tee -a "$LOG"
for bin in mosquitto_sub mosquitto_pub mqttx mqtt-cli; do
  command -v "$bin" && echo "[!] Found $bin — remove if unauthorized" | tee -a "$LOG"
done
dpkg -l 2>/dev/null | grep -i mosquitto | tee -a "$LOG" || true

echo "[+] Applying egress rules..." | tee -a "$LOG"
# Permit TLS MQTT only to the approved broker
iptables -C OUTPUT -p tcp -d "$APPROVED_BROKER" --dport 8883 -j ACCEPT 2>/dev/null \
  || iptables -A OUTPUT -p tcp -d "$APPROVED_BROKER" --dport 8883 -j ACCEPT
# Block all other MQTT egress (cleartext 1883 and non-approved 8883)
iptables -C OUTPUT -p tcp --dport 1883 -j REJECT 2>/dev/null \
  || iptables -A OUTPUT -p tcp --dport 1883 -j REJECT
iptables -C OUTPUT -p tcp --dport 8883 -j REJECT 2>/dev/null \
  || iptables -A OUTPUT -p tcp --dport 8883 -j REJECT

echo "[+] Persisting rules..." | tee -a "$LOG"
if command -v netfilter-persistent >/dev/null; then
  netfilter-persistent save
elif command -v iptables-save >/dev/null; then
  iptables-save > /etc/iptables/rules.v4 2>/dev/null || iptables-save > /etc/sysconfig/iptables
fi

echo "[+] Verification — outbound MQTT policy:" | tee -a "$LOG"
iptables -L OUTPUT -n -v | grep -E 'dpt:(1883|8883)' | tee -a "$LOG"
echo "[+] Done. Confirm updated app versions (Android >=11.00.00, iOS >=1.1.54) via MDM."

Remediation

1. Update the application immediately. Upgrade all Bransys ELD installations to Android version 11.00.00 or later and iOS version 1.1.54 or later. Enforce this through your MDM platform — do not rely on drivers to self-update. Block or flag devices running vulnerable versions until they are remediated.

2. Treat embedded credentials as compromised — demand rotation. Any credential shipped in a vulnerable build must be considered public. Engage Bransys support to confirm whether the fixed release implements per-device unique credentials, whether the legacy shared credential has been revoked at the broker, and what topic-level ACLs now enforce device isolation. A client update without server-side credential revocation does not close CVE-2026-86520.

3. Eliminate cleartext MQTT. Confirm with the vendor that telemetry now transits exclusively over TLS (TCP/8883) with certificate validation. Block TCP/1883 egress at the firewall for all fleet gateway infrastructure using the script above or equivalent policy. If the vendor still requires 1883, escalate — that is a direct CWE-319 finding that must be closed, not compensated for.

4. Audit broker access logs. Request or review broker authentication logs for connections using the legacy credential from IP addresses outside your known carrier infrastructure and mobile carrier NAT ranges. Any hits indicate active harvesting of your fleet's telemetry.

5. Verify firmware integrity. Given CVE-2026-77960, validate firmware versions and hashes on deployed ELD hardware against vendor-published values, and confirm with Bransys what controls now restrict firmware download access.

6. Reassess vendor risk. This advisory reveals architectural weaknesses (shared credentials, flat ACLs, cleartext transport) rather than a one-off coding error. Incorporate MQTT broker isolation, credential architecture, and transport security into your telematics vendor security questionnaire, and evaluate compensating network segmentation for ELD traffic.

Official references:

• CISA ICS Advisory ICSA-26-260-01: https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-01
• CSAF (machine-readable advisory): linked from the CISA advisory page

Monitor the CISA KEV catalog for additions of CVE-2026-86520, CVE-2026-86689, and CVE-2026-77960 — given the trivial exploitation path, KEV inclusion would materially raise the urgency of the steps above.

Related Resources

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