CVE-2026-30873 in OpenWRT
Summary
by MITRE • 03/20/2026
OpenWrt Project is a Linux operating system targeting embedded devices. In versions prior to both 24.10.6 and 25.12.1, the jp_get_token function, which performs lexical analysis by breaking input expressions into tokens, contains a memory leak vulnerability when extracting string literals, field labels, and regular expressions using dynamic memory allocation. These extracted results are stored in a jp_opcode struct, which is later copied to a newly allocated jp_opcode object via jp_alloc_op. During this transfer, if a string was previously extracted and stored in the initial jp_opcode, it is copied to the new allocation but the original memory is never freed, resulting in a memory leak. This issue has been fixed in versions 24.10.6 and 25.12.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/24/2026
The vulnerability identified as CVE-2026-30873 resides within the OpenWrt Project, a widely deployed Linux operating system designed for embedded devices such as routers and network appliances. This security flaw specifically affects versions prior to 24.10.6 and 25.12.1, representing a critical memory management issue that could potentially impact the stability and resource utilization of affected devices. The vulnerability manifests in the jp_get_token function, which serves as a lexical analyzer responsible for processing input expressions and breaking them down into discrete tokens. This function handles various token types including string literals, field labels, and regular expressions, all of which require dynamic memory allocation for their processing and storage.
The technical flaw stems from improper memory deallocation within the token extraction and copying process. When the jp_get_token function processes input expressions, it dynamically allocates memory to store extracted results such as string literals and other token components. These results are initially stored within a jp_opcode struct, which serves as an intermediate storage container during the parsing process. Subsequently, the function employs jp_alloc_op to create a new jp_opcode object that receives a copy of the data from the original struct. However, the implementation fails to properly free the memory allocated for string literals and other dynamically allocated components in the original jp_opcode structure, creating a classic memory leak scenario where allocated memory remains unreleased even after being copied to a new location.
This memory leak vulnerability operates at the intersection of multiple cybersecurity domains and can be classified under CWE-401, which specifically addresses improper release of memory. The operational impact of this vulnerability extends beyond simple resource waste, as continuous memory leaks can lead to progressive system degradation, eventual memory exhaustion, and potential denial of service conditions on embedded devices that operate with limited memory resources. The issue is particularly concerning in network infrastructure devices where sustained operation is critical, as memory leaks can accumulate over time and eventually compromise device functionality. Additionally, this vulnerability aligns with ATT&CK technique T1499.001, which covers resource exhaustion attacks through memory consumption, potentially allowing adversaries to exploit the memory leak for sustained system disruption. The vulnerability's presence in the lexical analysis component also raises concerns about potential exploitation for more sophisticated attacks, as memory corruption issues can sometimes be leveraged to achieve arbitrary code execution or other malicious outcomes.
The fix implemented in versions 24.10.6 and 25.12.1 addresses the root cause by ensuring proper memory management during the token copying process. This remediation requires that when data is transferred from the original jp_opcode structure to the newly allocated jp_opcode object, all dynamically allocated memory components are properly freed from the source structure before the copy operation. The solution demonstrates adherence to proper memory management practices and follows industry standards for preventing memory leaks in embedded systems. System administrators and device operators should prioritize upgrading to the patched versions to mitigate the risk of memory exhaustion and maintain the stability of their network infrastructure. Organizations deploying OpenWrt-based systems should also implement monitoring for memory usage patterns to detect potential exploitation attempts and ensure continued system reliability. The vulnerability serves as a reminder of the critical importance of proper memory management in embedded systems where resource constraints and long uptime requirements make memory leaks particularly dangerous.