CVE-2026-90780 in SIPp
Summary
by MITRE • 09/13/2026
SIPp through 3.7.7 contains a buffer overflow vulnerability in the get_header() function in src/sip_parser.cpp when processing SIP messages with header content exceeding 20,490 bytes. Unauthenticated remote attackers can send crafted SIP messages with oversized headers to overflow the static buffer and crash the process.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in Sippee versions up through 3.7.7 represents a critical security flaw rooted in improper memory management within the session initiation protocol parser. Specifically, the defect resides in the get_header function located in the src/sip_parser.cpp source file. This component is responsible for parsing incoming Session Initiation Protocol messages to extract header information necessary for call setup and control. The core technical issue is a classic buffer overflow condition where the application fails to validate the length of header content before copying it into a fixed-size static buffer. When an attacker crafts SIP messages containing headers that exceed 20,490 bytes, the data written exceeds the allocated memory space, leading to adjacent memory corruption and ultimately causing the process to crash due to stack smashing or invalid memory access.
From an operational perspective, this vulnerability allows for unauthenticated remote exploitation, which significantly lowers the barrier for entry for potential attackers. Since SIP is a foundational protocol for voice over IP communications, many organizations rely on these systems for critical business operations. The ability of an attacker to trigger a denial of service by sending oversized headers means that availability, one of the three pillars of information security confidentiality, integrity, and availability, is directly compromised. An adversary can repeatedly send crafted packets to keep the SIP server or proxy in a crashed state, effectively disrupting communication services for all users relying on that infrastructure. This type of attack does not require authentication, making it particularly dangerous against publicly accessible VoIP endpoints or proxies.
The technical classification of this flaw aligns with CWE-120, which describes buffer copy without checking size limits, and more specifically CWE-787, out-of-bounds write. In the context of the MITRE ATT&CK framework, this vulnerability facilitates initial access via exploitation for denial of service or potentially further lateral movement if the crash leads to unexpected behavior that can be leveraged. The static nature of the buffer in sip_parser.cpp indicates a lack of dynamic memory allocation checks or bounds verification during the parsing phase. This is a common oversight in legacy codebases where performance optimizations sometimes bypass safety checks, assuming input will always conform to expected limits. However, in network-facing applications, such assumptions are fundamentally flawed and must be guarded against with rigorous input validation.
Mitigation strategies for this vulnerability involve both immediate patching and long-term architectural improvements. The primary remediation is to upgrade Sippee to a version later than 3.7.7 where the developers have presumably implemented proper bounds checking in the get_header function. If upgrading is not immediately feasible, network-level mitigations should be employed. This includes configuring firewalls or intrusion prevention systems to inspect SIP traffic and drop packets with header sizes exceeding safe thresholds, such as those greater than 20,490 bytes. Additionally, implementing rate limiting on incoming SIP connections can help mitigate the impact of automated denial-of-service attacks exploiting this flaw. Developers should also conduct code reviews focusing on all buffer operations in network parsers to ensure that no other similar vulnerabilities exist within the same module or related components. Adhering to secure coding standards and utilizing static analysis tools during development can prevent such memory safety issues from being introduced into production systems in the future.