CVE-2026-93307 in SMO OAM
Summary
by MITRE • 09/18/2026
A vulnerability has been found in O-RAN-SC SMO OAM 2025-06-10. Affected is an unknown function of the component VES Collector. Such manipulation of the argument additionalFields.padding leads to uncontrolled memory allocation. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through a bug report but has not responded yet.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the O-RAN-SC SMO OAM component, specifically within the VES Collector module as part of the 2025-06-10 release cycle, represents a critical security flaw rooted in improper input validation and memory management practices. The core technical issue involves an uncontrolled memory allocation triggered by manipulating the additionalFields.padding argument. This type of vulnerability typically arises when software fails to adequately validate or sanitize user-supplied data before using it to determine buffer sizes or allocate heap memory. In this specific instance, the VES Collector, which is responsible for collecting and processing Event Management System (VES) events from various network elements in an Open RAN architecture, accepts a padding field that dictates how much additional space should be allocated during event parsing or storage operations. When an attacker provides a maliciously crafted value for this argument, such as an excessively large integer or a negative number due to type confusion, the application attempts to allocate a disproportionate amount of memory relative to available system resources. This lack of bounds checking allows an external actor to force the server into allocating far more memory than intended, leading directly to resource exhaustion conditions that can destabilize the entire management and orchestration layer.
From an operational perspective, this vulnerability poses a severe risk to the availability and integrity of Open RAN infrastructure. The O-RAN Service Management and Orchestration (SMO) framework serves as the central nervous system for managing non-real-time RICs and other network functions, making it a high-value target for adversaries. By exploiting the uncontrolled memory allocation in the VES Collector, an attacker can launch a remote denial-of-service attack without requiring authentication if the associated API endpoints are exposed or improperly secured. The successful exploitation would result in the rapid depletion of server-side resources, causing the SMO to become unresponsive or crash entirely. This disruption halts critical network management functions, including performance monitoring, fault detection, and configuration updates across the RAN infrastructure. Furthermore, because the exploit has been disclosed publicly, automated scanning tools and malicious actors can easily identify vulnerable instances on the internet, increasing the likelihood of widespread exploitation attempts that could lead to prolonged service outages for mobile network operators relying on this open-source framework.
The classification of this flaw aligns with CWE-789: Uncontrolled Memory Allocation, which describes situations where software allocates memory based on user input without verifying that the requested size is reasonable or within expected limits. This often leads to CWE-400: Uncontrolled Resource Consumption when the excessive allocation causes system resources like RAM or CPU cycles to be exhausted. In terms of offensive security frameworks, this vulnerability facilitates attacks categorized under MITRE ATT&CK technique T1498: Network Denial of Service, specifically through resource exhaustion methods. The fact that the exploit is publicly available significantly lowers the barrier to entry for attackers, allowing even those with limited technical expertise to disrupt services. Although the project maintainers were notified early via a bug report, their lack of response highlights a critical gap in the security maintenance lifecycle of open-source projects used in telecommunications infrastructure. This delay leaves operators exposed until they can implement workarounds or apply community-driven patches if available.
To mitigate this risk, immediate actions should focus on implementing strict input validation and resource limits at both the application and infrastructure levels. Developers must enforce maximum size constraints on the additionalFields.padding parameter to ensure that memory allocation requests remain within predefined safe thresholds. Implementing rate limiting and request size restrictions in reverse proxies or API gateways can also help absorb malicious traffic before it reaches the vulnerable VES Collector service. For operators, monitoring system metrics for sudden spikes in memory usage associated with event processing endpoints is crucial for early detection of exploitation attempts. Additionally, organizations should engage actively with the O-RAN-SC community to encourage timely patching and consider deploying compensating controls such as network segmentation to isolate SMO components from untrusted networks until a formal security update is released by the maintainers.