CVE-2026-93309: O-RAN-SC SMO OAM VES Collector DoS Vulnerability

CVE-2026-93309 Overview

CVE-2026-93309 is a resource allocation vulnerability in the O-RAN Software Community (O-RAN-SC) Service Management and Orchestration (SMO) Operations, Administration, and Maintenance (OAM) release dated 2025-06-10. The flaw resides in the Virtual Event Streaming (VES) Collector component. An authenticated remote attacker can trigger uncontrolled resource allocation [CWE-400] through manipulation of unspecified functionality. The exploit has been publicly disclosed, and the O-RAN-SC project has not responded to the bug report as of the CVE publication. The vulnerability primarily affects service availability rather than data confidentiality or integrity.

Critical Impact
Remote authenticated attackers can exhaust VES Collector resources, degrading availability of the SMO OAM telemetry pipeline in O-RAN deployments.

Affected Products

O-RAN-SC SMO OAM release 2025-06-10
VES Collector component within SMO OAM
Downstream O-RAN Service Management and Orchestration deployments consuming this release

Discovery Timeline

2026-09-18 - CVE-2026-93309 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93309

Vulnerability Analysis

The VES Collector is the ingest endpoint for telemetry, faults, and performance events generated by O-RAN network functions. It normalizes events and forwards them into the SMO data pipeline. CVE-2026-93309 allows a low-privileged remote attacker to invoke unspecified functionality that triggers unbounded resource allocation on the collector. Repeated invocation drives memory, connection, or handle consumption to exhaustion, degrading or halting event processing. The issue is categorized as an Uncontrolled Resource Consumption weakness [CWE-400]. Public disclosure includes a proof-of-concept referenced in a GitHub Gist and the upstream Atlassian JIRA ticket SMO-203.

Root Cause

The underlying defect is missing enforcement of allocation limits within the VES Collector request-handling path. When the affected functionality receives a manipulated request, it allocates resources without validating request-rate, size, or cumulative consumption thresholds. Without upstream throttling or per-client quotas, an authenticated caller can drive the collector into a resource-starved state.

Attack Vector

Exploitation requires network reachability to the VES Collector endpoint and low-privilege authentication. No user interaction is required. In typical SMO deployments, this endpoint is exposed to O-RAN network functions and internal management planes, so any compromised or malicious authenticated principal in that trust zone can trigger the condition. Technical exploitation details are published in the GitHub Gist proof-of-concept and tracked in the Atlassian JIRA issue SMO-203.

No verified exploit code is reproduced here. Refer to the VulDB entry for CVE-2026-93309 for additional technical context.

Detection Methods for CVE-2026-93309

Indicators of Compromise

Sudden growth in VES Collector process memory, file descriptors, or open TCP connections without a corresponding rise in legitimate network function activity.
Elevated request volume to VES Collector endpoints originating from a single authenticated identity or a narrow IP range.
VES Collector logs showing repeated allocation-heavy request patterns, timeouts, or out-of-memory events.
Downstream SMO pipeline components reporting event ingestion lag or dropped events.

Detection Strategies

Baseline normal VES Collector request rates per source identity and alert on statistically significant deviations.
Instrument the collector process with resource-consumption metrics (RSS, heap, socket count) and alert on rapid growth.
Correlate authentication logs for VES Collector clients with request volume to identify a single principal driving excessive load.

Monitoring Recommendations

Forward VES Collector application logs and host metrics into a centralized analytics pipeline for continuous evaluation.
Monitor Kubernetes pod restarts, OOMKilled events, and CPU throttling on SMO OAM workloads hosting the VES Collector.
Track authentication events for VES Collector clients and flag new or unexpected identities issuing high request volumes.

How to Mitigate CVE-2026-93309

Immediate Actions Required

Restrict network reachability to the VES Collector endpoint to trusted O-RAN network functions using network policies or firewall rules.
Enforce per-client rate limits and connection caps at an upstream reverse proxy or ingress controller in front of the VES Collector.
Rotate and audit credentials used by clients authorized to submit events to the VES Collector.
Apply resource limits (CPU, memory, file descriptors) to the VES Collector container or process to contain exhaustion impact.

Patch Information

No vendor patch is currently available. The O-RAN-SC project has not responded to the bug report referenced in Atlassian JIRA issue SMO-203 at the time of CVE publication. Track that ticket and the VulDB advisory for fix availability.

Workarounds

Deploy an API gateway or service mesh policy in front of the VES Collector to enforce request-size and request-rate quotas per identity.
Configure Kubernetes resources.limits on the VES Collector pod to bound memory and CPU, forcing restart rather than host-wide degradation.
Segment the VES Collector into a dedicated namespace or node pool so exhaustion does not cascade into other SMO OAM services.
Enable verbose access logging for the collector and pipe logs to a SIEM to accelerate identification of abusive clients.

bash

# Example Kubernetes resource limits for the VES Collector pod
resources:
  limits:
    cpu: "2"
    memory: "2Gi"
  requests:
    cpu: "500m"
    memory: "512Mi"