AUGUST 16, 2026
Live Feed
Back to database
Case File

CVE-2026-45084

HIGH · CVSS 8.7 EPSS 0.46% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-08-04 · Last synced 2026-08-16

CyberRota Analysis

AI-Generated

OpenSIPS versions 3.4.0 through 3.6.5 are vulnerable to a denial of service attack due to improper handling of SIP PUBLISH requests in the presence module, which can lead to crashes when processing uninitialized Content-Type headers. A remote attacker can exploit this vulnerability with a single crafted request, potentially impacting service availability. Organizations using affected versions should prioritize upgrading to version 3.6.6 or 4.0.0-rc1 to mitigate this risk.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

GitHub PoC Links

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-45084
Severity
HIGH
CVSS
8.7
EPSS
0.46%

Original NVD Description

OpenSIPS is a Session Initiation Protocol (SIP) server implementation. Versions 3.4.0 through 3.6.5 contain a denial of service vulnerability in the presence module. When the presence module's handle_publish() function processes a SIP PUBLISH request with an Event: presence header and a message body while the configuration option enable_sphere_check=1 is set, it invokes the get_content_type() macro without first calling parse_content_type_hdr(), causing it to dereference uninitialized or NULL Content-Type parsing state and crash. If a Content-Type header is present but unparsed, msg->content_type->parsed is NULL and is dereferenced as a content_t pointer; if the request lacks a Content-Type header entirely, msg->content_type itself is NULL, and both cases lead to a crash. A remote attacker can therefore cause a denial of service against an affected instance with a single PUBLISH request over UDP or TCP, using either a valid Content-Type: application/pidf+xml request or one with the header removed, and the vulnerable code path itself does not enforce authentication (though a deployment's routing configuration may require it before this route is reached). The issue has been fixed in version 3.6.6 and 4.0.0-rc1.