CVE-2026-66086: UNISOC Modem SIB1 Overflow
TL;DR - CVE-2026-66086 is a stack-based buffer overflow in the UNISOC modem OTA stack. - T8100, T9100, and UDX710 chipsets are affected; no fixed firmware version is disclosed. - NVD scores it 9.8. No public PoC or confirmed in-the-wild exploitation is currently identified.
Are You Affected?
CVE-2026-66086 affects the modem OTA stack in devices built around the UNISOC T8100, T9100, and UDX710 chipsets. The available UNISOC advisory identifies chipset families, not complete device models or firmware builds. Potentially affected products include smartphones, cellular routers, industrial equipment, and other embedded systems that use these modem platforms.
The advisory does not publish a vulnerable firmware range. The most precise version statement currently available is: affected firmware version range: not disclosed. A current Android, Linux, or application patch level does not establish that the modem firmware is fixed. Modem components may be updated independently by the device OEM.
| Field | Assessment |
|---|---|
| CVE | CVE-2026-66086 |
| NVD CVSS base score | 9.8 |
| Vendor CVSS score | 8.3 |
| Attack vector | Network, according to the vendor CVSS vector; exact radio-layer prerequisites are not disclosed |
| Authentication or privileges required | None / no privileges required |
| User interaction | None |
| Affected products | UNISOC T8100, T9100, and UDX710 chipsets |
| Affected version range | Not disclosed by the vendor |
| Patch available | No specific public fixed build identified |
| Fixed version | Not specified in the retrieved UNISOC advisory |
Inventory teams should identify chipset families rather than relying only on operating-system version reports. Device procurement records, modem firmware identifiers, OEM security bulletins, diagnostic tools, and hardware inventory platforms may provide the required information. If the chipset cannot be confirmed, treat an in-scope cellular device as potentially affected until its manufacturer provides a determination.
For background on how malware-related terminology differs from vulnerability terminology, see our malware versus virus glossary.
The Fix, If You’re in a Hurry
There is no specific fixed version number in the retrieved UNISOC bulletin. The required remediation is the latest modem or full-device firmware update supplied by the device manufacturer, with confirmation that the release addresses CVE-2026-66086. A generic operating-system update is not sufficient evidence unless the OEM release notes explicitly state that the modem firmware was updated.
For managed fleets, create a remediation exception for every T8100-, T9100-, or UDX710-based device that lacks an OEM confirmation. Record the device model, current modem firmware build, OEM response, update availability, and installation date. Escalate to the manufacturer when the device is still supported but no patch is available.
Technical Notes
There is no universal upgrade command for UNISOC modem firmware. Firmware deployment is OEM-specific and may occur through an over-the-air system update, a carrier package, a vendor service tool, or a controlled reflash process. Do not flash an image from another model or region merely because it contains a newer operating-system build.
For Linux systems using ModemManager, a practical containment command is:
sudo mmcli -m 0 --disable
On systems managed by NetworkManager, the corresponding radio-level workaround may be:
sudo nmcli radio wwan off
These commands disable cellular modem use; they do not patch CVE-2026-66086. Validate the modem index with mmcli -L, confirm that the service can tolerate loss of cellular connectivity, and apply the OEM firmware update as soon as one becomes available. On phones and embedded devices without an equivalent administrative control, remove cellular service, power down the device, or isolate it from operational use where the business impact is acceptable.
Analyst’s Take: The first task is asset confirmation, not exploit hunting. The affected firmware range is undisclosed, and the available sources identify chipset families rather than complete device models, so organizations should map T8100, T9100, and UDX710 hardware to modem builds and request OEM confirmation. Until then, disabling cellular use is containment, not remediation.
How This Vulnerability Works
CVE-2026-66086 is classified as CWE-121, stack-based buffer overflow. The vulnerable code is in the modem OTA stack and processes scheduling information contained in SIB1, or System Information Block Type 1, messages. SIB1 is cellular system information broadcast by a network and is used by devices during network acquisition and operation.
The reported root cause is improper validation of SIB1 scheduling information before it reaches a stack-backed buffer or related parsing logic. The supplied material does not identify the exact field length, copy operation, memory layout, or exploit payload. It is therefore not possible to state whether exploitation requires a rogue base station, a malicious operator-controlled network, physical radio proximity, or another specific cellular condition.
The impact described by the NVD includes remote code execution or denial of service without additional execution privileges. The vendor’s CVSS vector assigns high impact to confidentiality, integrity, and availability. Those outcomes indicate serious potential consequences, but the available sources do not establish a working exploit path, reliability, persistence mechanism, or whether modem compromise can directly cross into the host operating system.
Technical Notes
At a high level, the processing path is:
Cellular broadcast
|
v
SIB1 scheduling information
|
v
UNISOC modem OTA parser
|
v
Insufficient validation
|
+--> stack-based buffer overflow
|
+--> possible denial of service or remote code execution
Ordinary application-layer HTTP inspection is not a sufficient control. SIB1 is radio-layer signaling, and many enterprise sensors cannot inspect its contents. The most useful technical questions for the OEM are the vulnerable SIB1 field, the required radio conditions, whether the modem restarts after a failed parse, and whether the modem and application processor have an isolation boundary that limits post-exploitation impact.
Severity, Explained
NVD reports a CVSS base score of 9.8, placing the issue in the critical range. The retrieved NVD response did not include a CVSS vector string, so the individual NVD component values cannot be independently verified from the supplied record. UNISOC publishes a score of 8.3 with this vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
The vendor vector means the vulnerability is network reachable, has low attack complexity, requires no privileges, and does not require user interaction. It also assigns high impact to confidentiality, integrity, and availability, while keeping the security scope unchanged. In operational terms, a vulnerable device may be exposed without an attacker first obtaining an account or persuading a user to open content.
“Network” in the vendor vector should not automatically be interpreted as Internet reachability. The technical description involves SIB1 cellular broadcasts, while the source material does not specify the radio equipment, proximity, subscription, or network-control conditions required for delivery. That uncertainty affects exposure modeling, but it does not eliminate the need to patch: an attacker may not need access to the device’s IP address or enterprise credentials.
The score difference between NVD and UNISOC should be documented rather than averaged away. Use the higher score for conservative prioritization, and use the vendor’s vector to understand the stated attack assumptions. Confirm whether an OEM has issued a device-specific severity assessment.
Is It Being Exploited?
CVE-2026-66086 is not listed in the CISA Known Exploited Vulnerabilities catalog as of the 2026-10-12 assessment. There is consequently no CISA KEV confirmation of exploitation in the wild, no KEV due date, and no CISA ransomware-campaign designation for this CVE.
The reviewed NVD and vendor-reference material identifies no public proof of concept, exploit repository, exploitation campaign, or ransomware association. Neither a public PoC nor confirmed in-the-wild exploitation is currently known from the supplied sources. This does not prove that exploitation has never occurred, because KEV and public repository coverage are incomplete and modem attacks may be difficult to observe.
| Question | Current answer |
|---|---|
| Public PoC identified? | No |
| Confirmed exploitation in the wild? | Not confirmed |
| Listed in CISA KEV? | No |
| Ransomware association? | None identified |
| Exploitability concern | High, because the vendor states network reachability, no privileges, and no user interaction |
Treat the vulnerability as pre-exploitation risk rather than waiting for a campaign announcement. The absence of exploit code can change quickly after technical details or a firmware diff becomes available. Prioritize devices that remain connected to cellular networks, provide critical connectivity, or cannot be rapidly recovered after a modem crash.
Detecting It in Your Environment
Detection is challenging because the vulnerable input is radio-layer SIB1 data, which is generally unavailable in enterprise network telemetry. Most organizations will need to combine hardware inventory with modem firmware records and operational symptoms. Start by identifying devices using T8100, T9100, or UDX710, then compare their modem firmware builds against OEM advisories.
A sudden cluster of modem resets, cellular registration failures, baseband crashes, or unexplained loss of service can justify investigation, but these indicators are not specific to CVE-2026-66086. Preserve modem diagnostics and timestamps, including serving-cell information where available. A single registration failure is not proof of exploitation.
For host-based malware monitoring on connected systems, organizations may also evaluate Malwarebytes as part of a broader endpoint security program. Endpoint protection does not inspect or patch the modem’s SIB1 parser, so it should supplement—not replace—OEM firmware remediation.
Technical Notes
On Linux systems using ModemManager, inventory the modem and inspect recent service events:
mmcli -L
mmcli -m 0
journalctl -u ModemManager --since "24 hours ago" \
| grep -Ei 'crash|reset|failed|registration|firmware|assert|modem'
A generic SIEM query for endpoint or gateway telemetry can identify correlated modem instability:
(service="ModemManager" OR process="modemd" OR process="rild")
AND (message matches /reset|crash|assert|watchdog|registration failed|baseband/i)
| stats count(), earliest(_time), latest(_time) by host, message
| where count() >= 3
This is an operational anomaly query, not a CVE signature. It cannot determine whether a malformed SIB1 message caused the event. For cellular security monitoring, collect radio diagnostics from supported test equipment or OEM logs and look for repeated failures associated with the same serving cell, tracking area, or time window. Do not claim attribution without a vendor-confirmed indicator.
Incident Response Considerations
If a potentially affected device shows repeated modem crashes or unexpected cellular behavior, preserve relevant evidence before resetting or reflashing it where operationally possible. Record the device model, chipset, modem firmware, serving-cell information, timestamps, crash logs, and recent changes.
Containment options include disabling cellular connectivity, moving the device to a nonproduction role, isolating it from sensitive systems, or powering it down. The appropriate response depends on whether the modem can access sensitive networks and whether loss of connectivity creates a greater operational risk.
Do not infer compromise solely from a modem restart. Similar symptoms can result from coverage problems, carrier changes, defective hardware, incompatible firmware, or ordinary registration failures. Escalate suspected exploitation to the OEM, carrier, incident-response team, and relevant national vulnerability authorities when evidence supports that conclusion.
References and Further Reading
The primary technical references are the NVD record and the UNISOC security bulletin. The NVD description identifies the SIB1 scheduling-information parsing issue, stack-based buffer overflow, and potential remote code execution or denial of service. The UNISOC bulletin identifies T8100, T9100, and UDX710 as affected chipset families and classifies the issue as CWE-121.
Relevant sources:
- NVD: CVE-2026-66086
- UNISOC Product Security Bulletin
- CISA Known Exploited Vulnerabilities Catalog
- Related security digest: NetScaler, Zitadel, and TOTOLINK
Because no fixed firmware identifier is published in the reviewed advisory, device owners should also consult the security bulletin and support portal for each relevant OEM, carrier, router manufacturer, or embedded-device supplier. Ask specifically whether the vendor’s release includes the CVE-2026-66086 modem fix, which modem build contains it, and whether the update changes the baseband independently of the host operating system.
Start with an inventory of devices using the three affected chipset families and map each one to its modem firmware build. Isolate devices that can safely lose cellular connectivity while obtaining written remediation status from the manufacturer, then monitor for modem failures until the OEM update is installed.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.