CVE-2026-21548: UNISOC nr modem improper input validation DoS
TL;DR - High severity UNISOC NR modem flaw, CVSS 7.5, can cause remote denial of service. - Affects T8100, T9100, T8200, and T8300 on Android 13 through 16. - No confirmed in-the-wild exploitation or verified public PoC, but patch details are not publicly specific.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-21548 |
| CVSS v3.1 | 7.5 High |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| Attack Vector | Network |
| Auth Required | No privileges required |
| Patch Available | Yes, vendor bulletin exists; exact fixed version not publicly specified in retrieved advisory |
CVE-2026-21548 is a network-reachable denial-of-service vulnerability in the UNISOC nr modem component. The root cause is classified as CWE-20 Improper Input Validation, meaning the modem stack does not adequately validate some incoming input before processing it.
For defenders, the practical concern is straightforward: this issue is remotely reachable, requires no privileges and no user interaction, and has a high availability impact according to the published CVSS vector. Even without evidence of active exploitation, those attributes justify prioritizing asset identification and patch coordination with device OEMs and UNISOC support channels.
What Is This Vulnerability?
The public description from NVD and the UNISOC security bulletin states that in nr modem, improper input validation could lead to remote denial of service. In plain terms, the modem component appears to accept or process network-originated input without sufficiently checking that the data conforms to expected bounds, format, state, or protocol conditions. When malformed or unexpected input reaches that code path, the modem may crash, hang, or otherwise stop functioning normally.
The available public sources do not disclose packet-level details, protocol fields, parser routines, crash traces, or specific trigger conditions. That limits how far defenders can go in reproducing the issue from public information alone. Still, the CVSS vector is informative: AV:N/AC:L/PR:N/UI:N indicates a low-complexity, network-accessible issue that does not depend on user action or attacker foothold on the device. The impact profile C:N/I:N/A:H further supports that this is primarily an availability problem rather than a data theft or privilege escalation issue.
From an operational standpoint, a modem-layer denial of service can manifest as dropped cellular connectivity, repeated modem subsystem resets, loss of radio service, or device instability tied to the baseband path. For enterprises deploying field devices, rugged endpoints, mobile terminals, kiosks, or embedded Android-based systems using affected UNISOC platforms, even a non-persistent DoS can have meaningful business impact if devices lose carrier connectivity or require manual recovery.
Technical Notes
Because the vendor has not published deep exploit mechanics, defenders should treat the root cause category as the main technical clue: input received by the NR modem is not sufficiently validated before processing. In practical terms, that means prioritizing radio and modem fault telemetry over exploit-signature-based detection.
Published weakness: CWE-20 Improper Input Validation
Published impact: Remote denial of service
Published component: nr modem
Who Is Affected?
According to the UNISOC security bulletin, the affected chipset families are:
- T8100
- T9100
- T8200
- T8300
The publicly listed affected software version families are:
- Android 13
- Android 14
- Android 15
- Android 16
That is the most specific affected-version information available in the retrieved primary sources. Importantly, the public advisory identifies version families, not exact build fingerprints, firmware package identifiers, BSP revisions, or carrier release numbers. In practice, this means exposure assessment cannot stop at the Android major version. Security teams need to map devices using these UNISOC chipsets to OEM-specific firmware trains and confirm remediation status with device manufacturers or distributors.
If you manage Android devices indirectly through MDM, EMM, telecom partners, or hardware resellers, you may not have direct visibility into the underlying chipset. That is a common obstacle for modem-related CVEs. In those environments, the right assumption is that devices built on the named chipset families and still running vendor software based on the affected Android generations should be treated as potentially vulnerable until the OEM confirms a remediated build.
A second practical challenge is that modem fixes are often delivered through vendor firmware, OTA bundles, carrier images, or BSP updates rather than a standalone package administrators can download and install themselves. So while a patch path exists, determining exactly which shipped device builds contain the fix may require escalation to the OEM or UNISOC support.
CVSS Score Breakdown
The published CVSS v3.1 score is 7.5 High, with vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Each metric matters operationally. AV:N means the vulnerable component is reachable over a network path, which raises priority because the attacker does not need local access. AC:L means exploitation is not considered highly complex by the scoring model. PR:N and UI:N mean the attacker needs neither an authenticated foothold nor help from a user, which materially lowers barriers to abuse.
The scope is S:U, so the security impact remains within the vulnerable component’s security authority rather than crossing into a broader trust boundary. The impact metrics C:N and I:N indicate there is no published evidence of confidentiality or integrity loss. The major driver of the score is A:H, meaning the vulnerability can significantly disrupt availability. That fits the published description of remote denial of service in the modem stack.
For defenders, the score should not be read as “less urgent because there is no data theft.” Availability failures in modem subsystems can have outsized consequences in environments where cellular links are essential for operations, telemetry, dispatch, point-of-sale, vehicle systems, or emergency communications. The fact pattern here supports a meaningful remediation priority even without signs of weaponization.
Exploitation Status
Based on the gathered primary sources, there is no confirmed evidence that CVE-2026-21548 has been exploited in the wild. It is not listed in CISA’s Known Exploited Vulnerabilities catalog at the time of writing. That does not prove exploitation has never occurred, but it does mean there is no CISA-confirmed public signal of active abuse from KEV for this CVE.
There is also no verified public proof of concept identified in the gathered references. No trustworthy, CVE-specific PoC was confirmed from the vendor advisory, NVD references, or a clearly attributable researcher publication. Because the issue is network reachable and low complexity according to the CVSS vector, defenders should avoid equating “no public PoC found” with “low risk.” It is safer to treat this as a patch-and-monitor case rather than a wait-and-see issue.
When public exploit details are absent, the prudent assumption is that capable researchers or adversaries may still be able to reverse-engineer affected firmware updates or identify the faulty parser path independently. That is especially true for modem issues in widely deployed chipset families. So the right message to stakeholders is: no confirmed exploitation is known from primary sources, but exposure should still be reduced promptly.
Technical Notes
Current status based on retrieved sources:
CISA KEV: Not listed
Public PoC: None verified
Confirmed in-the-wild exploitation: None confirmed in retrieved primary sources
How to Detect It
Detection is the weakest part of the public record because the vendor has not disclosed a trigger sequence, packet signature, or low-level parser detail. That means defenders are unlikely to build a high-confidence network IDS signature from public information alone. Instead, focus on symptom-based detection: modem crashes, repeated radio resets, cellular service drops, baseband restarts, and related device instability on affected platforms.
Start by collecting logs from affected Android devices, OEM diagnostics, and any centralized mobile telemetry platform you operate. Look for repeated modem subsystem failures, radio interface layer instability, or unexplained transitions to no-service states. If your fleet includes embedded or managed Android devices, work with the OEM to determine whether crash artifacts from the modem subsystem are exposed via logcat, diag logs, kernel logs, or proprietary support bundles.
You should also correlate operational symptoms with external conditions. For example, repeated modem resets affecting a cluster of devices in the same geography or carrier region may point to environmental network input triggering the bug. Without exploit details, that is not proof of malicious activity, but it is exactly the kind of anomaly worth escalating when vulnerable chipset families are in use.
Technical Notes
Potential Android and device-side patterns to watch for include modem or radio crash indicators such as:
modem crash
modem subsystem restart
RILJ
radio not available
No service
ims service disconnected
baseband restart
Example grep workflow for collected device logs:
grep -Ei "modem crash|subsystem restart|radio not available|baseband|RILJ|no service" device_logcat.txt
Example Splunk-style query for centralized mobile or support logs:
index=mobile_logs ( "modem crash" OR "subsystem restart" OR "radio not available" OR "baseband restart" OR "No service" )
| stats count by device_id, model, os_version, carrier
If you operate network monitoring around lab or field devices, also baseline sudden bursts of detach, reconnect, or radio session instability from endpoints using affected chipsets. There is no public packet signature for this CVE, so anomaly detection is more realistic than strict signature matching.
Mitigation and Patching
The UNISOC bulletin indicates remediation exists through the vendor support path, but the specific fixed version number is not publicly disclosed in the retrieved advisory content. That is the key operational limitation for this CVE. You cannot reliably say “upgrade to build X” from the currently available public data. Instead, the immediate task is to obtain the exact remediated firmware or BSP version from UNISOC, the device OEM, or the carrier/OEM release notes for the affected product.
Because the affected range is publicly given only as T8100/T9100/T8200/T8300 on Android 13, 14, 15, and 16, defenders should inventory those platforms first, then request written confirmation of the fixed build identifier. In change-managed environments, document the OEM response and link it to asset groups so you can prove which devices remain pending and which have received the corrected modem software.
If patch timing is uncertain, mitigation should focus on risk reduction rather than claiming complete protection. Since the vulnerable component is network reachable in the modem path, there may be limited defensive controls available at the OS layer. Still, organizations can reduce exposure by prioritizing updates for internet-facing and field-connected devices, limiting deployment of unpatched units in critical workflows, and increasing monitoring for connectivity instability. Where business continuity matters, prepare recovery procedures for devices that lose radio service, including remote reboot options or spare-device rotation.
Technical Notes
Because the public advisory does not disclose a fixed version number, defenders should use a vendor-confirmed upgrade workflow. Example ADB-based process for verifying current device details before OEM patch deployment:
adb shell getprop ro.product.board
adb shell getprop ro.build.version.release
adb shell getprop ro.build.fingerprint
adb shell getprop gsm.version.baseband
Example internal remediation tracking checklist:
1. Identify devices using T8100, T9100, T8200, or T8300.
2. Record Android major version: 13, 14, 15, or 16.
3. Capture current baseband and firmware identifiers.
4. Obtain OEM or UNISOC confirmation of the remediated build.
5. Deploy OTA or firmware package from the OEM.
6. Re-check baseband and build fingerprint after update.
7. Monitor for recurring modem reset events post-patch.
If your OEM provides an OTA package, the actual upgrade command or process will vary by vendor. In managed environments, a common pattern is to push the OEM update through device management tooling rather than sideloading manually. If no patch is immediately available, the most honest guidance is: treat affected devices as exposed, monitor them closely, and press the supplier for a fixed firmware identifier and deployment timeline.
References
The primary reference for this CVE is the UNISOC security bulletin, which provides the affected chipset families, Android version families, vulnerability type, and CVSS metadata. The NVD entry mirrors the high-level description and links back to the vendor bulletin. CISA KEV status is relevant because it helps defenders distinguish between publicly cataloged active exploitation and vulnerabilities that are serious but not yet known to be exploited.
Use the following references as the authoritative starting point for validation and patch coordination. Since the public advisory does not disclose a fixed version number, these references should be supplemented with direct OEM or UNISOC support communications when building remediation plans.
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-21548
- UNISOC Security Bulletin: https://www.unisoc.com/en/support/product-security-bulletin/2084109408382668801
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
From a defender’s perspective, the most important unresolved question is not whether the issue is real, but which exact OEM firmware builds contain the fix. Until that is clarified through vendor channels, assume any deployment matching the published chipset and Android version ranges may require action.
For further insights on security vulnerabilities, check out our articles on what is a kill switch in a VPN and what is TOCTOU.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.