CVE-2026-0710
NULL Pointer Dereference in SIPp Causes Remote DoS, Code Execution
Publication date: 2026-01-23
Last updated on: 2026-01-23
Assigner: Fedora Project
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| unknown_vendor | sipp | to 3.7.6 (exc) |
| unknown_vendor | sipp | From 3.7.6 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in SIPp is caused by a NULL pointer dereference in the SendingMessage function when processing specially crafted SIP messages during an active call. It results from insufficient validation of internal message structures, causing the application to crash (segmentation fault). Under certain memory layouts and runtime conditions, this crash can be exploited to execute arbitrary code locally, compromising system integrity and availability. [1]
How can this vulnerability impact me? :
The vulnerability can cause SIPp to crash, leading to a denial of service. Additionally, under specific conditions, an attacker may exploit it to execute unauthorized code locally, which can compromise the system's integrity and availability. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or segmentation faults in SIPp when processing SIP messages, especially during active calls. Detection can also involve replaying specially crafted malformed SIP messages or using AFLNet replay tooling to trigger the NULL pointer dereference. Specific commands are not provided, but using AFLNet or similar fuzzing/replay tools against SIPp version 3.7.3 can help identify the issue. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade SIPp to version 3.7.6 or later, where the vulnerability has been fixed by initializing previously uninitialized members in the SendingMessage class. Until the upgrade, avoid processing untrusted or malformed SIP messages during active calls to reduce the risk of exploitation. [1]