Fedora Account System
Red Hat Associate
Red Hat Customer
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. 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.
OpenSIPS in Fedora is not affected — every active branch already carries the fix: - rawhide/f45: opensips-4.0.0-9.fc45 - f44: opensips-3.6.7-1.fc44 (built 2026-06-24) - f43: opensips-3.6.7-1.fc43 (built 2026-06-24) There are no EPEL branches for this package, so the above is the full scope of [fedora-all]. Verified against upstream git rather than the advisory version claims. The fix is two commits on the 3.6 branch, de5071a48 ("presence: make sure Content-Type is parsed") and ec38f4f01 ("presence: handle case when Content-Type is missing"), both dated 2026-05-13; git tag --contains puts both first in 3.6.6 and also in 3.6.7. The equivalent pair on master (73279c3fe, 91e13270e) first appears in 4.0.0-rc1 and is present in 4.0.0. So the advisory's "fixed in 3.6.6 and 4.0.0-rc1" is accurate. Also worth noting that the vulnerable path is not reachable in a default configuration: the presence module's enable_sphere_check parameter is backed by sphere_enable, which is initialised to 0, so handle_publish() only reaches the affected get_content_type() call when a deployment explicitly sets modparam("presence", "enable_sphere_check", 1). Closing CURRENTRELEASE.