CVE-2026-96274: Baicells Nova 430H DoS and the CTEM Playbook for Unpatchable Telecom Exposure

TL;DR

• CISA advisory ICSA-26-272-04 (published September 29, 2026) describes CVE-2026-96274, an uncaught exception (CWE-248) in the Baicells Nova 430H eNodeB (model pBS3101SH) running firmware BaiBLQ_3.0.12 or earlier.
• An unauthenticated device within radio range can send a malformed uplink message with an invalid NAS payload during connection setup. The eNodeB fails to validate it correctly, forwards it to the core network, and the cell's signaling association is torn down — a temporary service disruption.
• Scoring: CVSS 3.1 = 7.4, CVSS 4.0 = 8.3. The vector is AV:A (adjacent network), availability-only (C:N/I:N/A:H), scope-changed (S:C). It is not remotely exploitable over the internet, and CISA reports no known public exploitation as of publication.
• The hardest part is the remediation line: no fix planned. The vendor did not respond to CISA's coordination requests. That makes this a compensating-control, monitoring, and documented-risk-acceptance problem — not a patch-Tuesday problem.
• Trusteed CTEM helps by keeping the discoverable, network-facing slice of that telecom estate — management interfaces, exposed services, certificates, mail/DNS posture — inventoried and continuously re-evaluated alongside CVE, EPSS, and KEV context, so unpatchable exposure doesn't quietly fall out of your queue.

What is CVE-2026-96274 (Baicells Nova 430H uncaught exception)?

CVE-2026-96274 is an availability flaw in the radio access layer of a small cell. Specifically, it affects the Baicells Nova 430H eNodeB (model pBS3101SH) at firmware BaiBLQ_3.0.12 and earlier, and was published by CISA in the ICS advisory series because these devices deploy into communications and IT infrastructure worldwide.

The practical definition: an attacker with a radio-capable device inside the cell's coverage area — a modified UE, a software-defined radio setup, or an already-attached device — can transmit a crafted uplink message during connection setup that carries an invalid NAS payload. Because the eNodeB does not validate that payload properly, it forwards the malformed message toward the core network. The core cannot process it in context and shuts down the signaling association for the cell, taking service down until the eNodeB and core re-establish connectivity.

Three properties matter more than the raw score:

• Availability only. There is no confidentiality or integrity impact. This is not a data-theft or code-execution bug.
• Scope changed. The vulnerable component (the eNodeB) is not the impacted component (core network signaling), which is exactly why the CVSS vector reads S:C.
• Adjacent, not remote. AV:A in a radio context means RF range. You cannot exploit this from a laptop on the internet.

And one operational property matters most of all: the advisory lists remediation as "no fix planned." Baicells has not responded to CISA's requests to coordinate. Users of affected firmware are directed to contact vendor support. In other words, the exposure is real, unauthenticated, low-effort to trigger — and it will not be closed by a firmware update you can schedule.

Why it matters now

Private cellular is having a moment. CBRS, private LTE and 5G, neutral-host deployments, campus networks, utility field area networks, ports, and public-safety systems are all shipping small cells into places that used to run Wi-Fi or licensed microwave. Each of those radios is a Linux-based IP device with a management plane, an auto-configuration path, and a firmware lifecycle that nobody in the IT security organization owns.

That is the structural problem this advisory exposes. CVE-2026-96274 is not a catastrophic bug. It is a representative one — it shows how a whole asset class behaves:

• It's invisible to agent-based vulnerability management. You cannot install an endpoint agent on an eNodeB. If it isn't in a network scan plan or an asset inventory, it does not exist to your program.
• It's often unpatchable in practice. When a vendor doesn't engage, "upgrade to the fixed version" becomes "wait indefinitely." Meanwhile the device keeps carrying traffic.
• "Adjacent" is not "harmless." Physical and RF adjacency is cheap to obtain in shared tower space, rooftop installations, retail, campus, and multi-tenant industrial sites. On the other side of the coin, availability-only impact is underrated when the affected cell carries a hospital's clinical comms, a port's terminal telemetry, or an electric cooperative's field network.
• Availability incidents get misclassified as operations problems. A cell that drops and re-establishes may be logged as an RF issue or a core misconfiguration, never as a security event, unless someone has defined the signal.

CISA's own recommended practices for this class of gear remain worth internalizing, even though this specific CVE is not internet-exploitable: minimize network exposure of control and radio systems, keep them behind firewalls and isolated from business networks, use hardened remote access where needed, and perform impact analysis before applying defensive changes. Most small cells violate at least one of those on the management plane.

How attacks / risks work

The mechanics are worth understanding because they generalize to a lot of embedded network gear:

1. Gain adjacency. The attacker needs to be within the cell's coverage — a UE-class radio or SDR transmitting in-band. No credentials, no session, no prior relationship with the network.
2. Initiate connection setup. Pre-authentication signaling is, by definition, reachable by any device that wants to attach. The attacker starts a normal connection setup flow.
3. Inject a malformed NAS payload. NAS (Non-Access Stratum) is the control-plane protocol between the device and the core network, carried inside the access network's signaling. The crafted uplink message during setup contains a payload that is structurally invalid.
4. The exception path takes over. The eNodeB hits an uncaught exception (CWE-248) rather than a clean validation rejection. Unhandled error paths classically skip validation and forward bad state downstream — here, straight to the core network.
5. The core protects itself by disconnecting. Unable to parse the message, the core tears down the signaling association for that cell. Service is disrupted until the eNodeB and core re-establish connectivity.
6. Repeat for sustained denial. Because the trigger is a single malformed message, an attacker can re-trigger it. Low cost, high repetition, no authentication barrier.

The generic lesson: uncaught exceptions in parsing code are a security control failure, not a robustness nit. Anywhere you accept input from an untrusted peer — RF, HTTP, SNMP, CWMP/TR-069, API — an unhandled error is a place where validation stops and side effects begin.

The second lesson is about remediation reality. When a vendor goes silent, your program still has to answer three questions: Where are these devices? Who can reach them? What compensating controls are in place? Vulnerability management tools that only emit "patch it" have nothing to say. A continuous exposure management loop does.

Detection and visibility

You cannot packet-inspect the RF link, so detection here is about availability telemetry, control-plane logs, and inventory discipline rather than signature matching.

What good telemetry looks like:

• Cell and signaling-association health. Track S1/N2 association resets, cell outage alarms, and repeated re-establishment events. A signaling association dropping and recovering on its own is exactly the shape of this attack — and exactly the shape of a benign misconfiguration, so you need baselines.
• Correlation windows. Alert when an availability dip coincides with unusual RF activity, abnormal attach attempts, connection-setup failures, or a spike in malformed-message counters at the core.
• Firmware and model inventory. You cannot manage what you cannot version. Record model, firmware build, management IP, site, owner, and last change for every small cell and radio gateway.
• Management-plane exposure. Enumerate eNodeB management interfaces, web UIs, SSH/SNMP endpoints, auto-configuration servers, and the TLS certificates protecting them. If any of that is internet-reachable, you have a second and more remotely accessible problem, even though CVE-2026-96274 itself is not remotely exploitable.
• Change detection. Firmware downgrades, new management endpoints, unexpected configuration changes, and shifts in certificate posture are all worth alerting on.
• A written risk-acceptance record. "No fix planned" will not resolve itself. Document the owner, the compensating controls, the review date, and the trigger conditions that would force a different decision.

Reduce risk / best practices

1. Find every affected device. Build a list of Nova 430H units (model pBS3101SH) at firmware ≤ BaiBLQ_3.0.12, plus the sibling radio and gateway products in the same fleet. Include management IPs, physical sites, and accountable owners.
2. Characterize real adjacency. For each site, ask who can physically or via RF reach the cell — shared towers, rooftops, public venues, industrial campuses, third-party tenants. Adjacency that is easy to obtain multiplies the practical risk well beyond what the CVSS vector implies.
3. Assume no patch is coming, and design around it. Compensating controls worth evaluating: tighter antenna siting and RF containment, strict control of who operates in-band, core-side message hygiene and rate limiting where your core vendor supports it, and automated detection-and-recovery so a dropped cell re-establishes fast.
4. Treat cell availability as a security signal. Define an SLO for signaling-association stability and route anomalies to the SOC, not only to network operations. Otherwise you will keep seeing these events and never call them incidents.
5. Lock down the management plane. No internet-exposed management UIs, no default credentials, no unauthenticated auto-configuration. Segment radio management from business networks, as CISA recommends for this class of gear.
6. Formalize risk acceptance with teeth. Assign an owner, a compensating-control checklist, a review cadence, and explicit triggers (for example: a fix appearing, public exploitation reports, an availability incident, or a regulatory finding).
7. Maintain a vendor escalation path and a fallback plan. Document the support contact, the ask, and the business rationale for continued use if support stays silent — including the migration cost to an alternative platform.
8. Re-evaluate continuously, not annually. New firmware, new sites, new exposures on the same devices, and new threat intelligence all change the answer. A point-in-time assessment from last quarter is already stale.

How Trusteed CTEM helps

• Continuous attack surface and asset inventory. Trusteed CTEM discovers and tracks domains, subdomains, IPs, exposed services, and technologies across your estate with ongoing scan plans — covering the network-facing slice of a telecom deployment (management interfaces, portals, provisioning endpoints, certificates, mail and DNS posture for the operator domain) that agent-based tools structurally cannot see.
• CVE findings with exploitability context. Scanner-driven detections are enriched with catalog CVE data and EPSS/KEV context plus available exploit references, so an ICS advisory with no vendor fix shows up in the same prioritized view as everything else — not in a PDF nobody reopens.
• Finding validation and a SOC gate. Not every scanner hit should become an alarm. Trusteed validates exploitability and business context so dashboards and analyst queues focus on actionable risk (should_alarm) rather than raw signal volume — which matters enormously when you are triaging availability-only, adjacent-vector edge cases.
• Deeper application testing where it counts. A dedicated API surface testing worker plus a deep DAST worker for critical applications, useful for telecom management portals, provisioning APIs, and web-facing auto-configuration endpoints.
• Compliance and reporting views. Framework-oriented views and customer reporting let you evidence compensating controls and documented risk acceptance for auditors and leadership.
• Vulnerability intelligence. Trusteed publishes KEV and emergent-threat narratives on the public blog, so your team gets context alongside the findings inside the platform.

You can see the platform at trusteed.io and work findings in the tenant workspace at app.trusteed.io.

Trusteed CTEM vs point tools

Capability	Typical point tool	Trusteed CTEM
Discovery scope	A single domain, IP range, or CI artifact	Domains, subdomains, IPs, services, technologies, TLS and mail/DNS posture, under continuous scan plans
CVE context	Raw template output, version-match or nothing	Findings enriched with catalog CVE data, EPSS/KEV context, and exploit references where available
Noise handling	Every hit is a finding	Validation and business-context gate — only actionable risk becomes an alarm (should_alarm)
Unpatchable exposure	Ticket closes as "no fix available"	Exposure stays visible with owner, compensating controls, and review dates
API and application depth	Generic templates or one DAST mode	Dedicated API surface worker plus deep DAST for critical apps
Reporting	Raw export	Framework-oriented views and customer reporting
Operator workflow	CLI and CI logs	Tenant workspace at app.trusteed.io

FAQ

Is CVE-2026-96274 remotely exploitable over the internet? No. The CVSS vector is AV:A — adjacent network — which in a radio context means within RF range of the cell. That does not make it irrelevant: adjacency is trivial to obtain in shared towers, rooftops, campuses, and public venues, and no authentication is required to trigger it.

What does "no fix planned" actually mean for my risk register? It means the remediation path is no longer a patch. CISA's advisory states the vendor has not responded to coordination requests and lists remediation as no fix planned. Your register should carry a named owner, the compensating controls in place, a review date, and explicit triggers that would force a different decision.

Is this in CISA's KEV catalog? No. KEV lists vulnerabilities with evidence of exploitation in the wild. An ICS advisory is not a KEV listing, and CISA reported no known public exploitation at publication time. Triage on exploitability context plus asset criticality and exposure — not on KEV membership alone, in either direction.

CVSS 7.4 — should we drop everything? No. Read the vector. This is availability-only (C:N/I:N/A:H) with a scope change because core signaling is impacted. The right response is proportionate: locate the devices, characterize adjacency, and put recovery and monitoring in place — not emergency change freezes.

How is CTEM different from a vulnerability scanner in this scenario? A scanner will tell you a firmware version matches a known issue, if it can reach the device at all. CTEM covers the full loop: scope the estate, discover the assets and their network-facing exposure, prioritize by exploitability and business impact, validate what is actually actionable, then mobilize remediation or compensating controls — and re-check continuously as the environment changes.

Can Trusteed CTEM detect the RF-level denial-of-service itself? No, and any vendor claiming otherwise is overselling. RF-layer attacks are detected through radio and core telemetry. What Trusteed CTEM does is keep the discoverable, network-facing exposure of those same assets continuously inventoried and prioritized, correlate CVE and threat intelligence, and help you track the unpatchable risk until a fix or a compensating control changes the picture.

What is the practical attacker effort here? Low skill floor, real hardware requirement. The attacker needs a device capable of transmitting in the target band and being within coverage, plus a malformed payload — no credentials, no user interaction. That combination is what makes a medium-severity availability bug worth tracking seriously in critical infrastructure.

Related resources

• Trusteed CTEM platform — continuous threat exposure management for external and internal attack surface.
• Trusteed tenant app — findings, scan plans, and validated exposure in one workspace.
• CISA ICS Advisory ICSA-26-272-04 — Baicells Nova 430H
• CISA ICS recommended practices and technical information papers
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
• FIRST EPSS — Exploit Prediction Scoring System
• CISA Known Exploited Vulnerabilities Catalog
• OWASP API Security Top 10