Skip to main content

OpenSIPS: Out-of-bounds read in IMC unknown-command reply building

Medium 6.3

Published on May 21, 2026 in ,

Description

OpenSIPS published GHSA-3gfr-36cv-g4fc for an IMC unknown-command reply length mismatch in modules/imc/imc_cmd.c:imc_handle_unknown(). The vulnerable code keeps the would-have-been snprintf() length after truncation and passes that oversized length to TM reply construction.

Enable Security reproduced oversized reflected IMC replies in vanilla OpenSIPS 3.5.9 and an ASan global-buffer-overflow while TM read beyond the fixed IMC buffer.

Technical details

The vulnerable unknown-command path formats a reflected error message into imc_body_buf[1024] with snprintf(). When the attacker-supplied command token is too long, snprintf() truncates the actual output but returns the length that would have been written if enough space existed.

The vulnerable code keeps that returned length in the SIP body length field and passes it to TM. TM then reads beyond the end of imc_body_buf while constructing the outgoing reflected IMC MESSAGE reply.

Unlike the IMC #list issue, this path does not require room membership or a large stored room. The request only needs to reach IMC handling and begin with the IMC command prefix, # by default, followed by an oversized unknown command token.

Configuration requirements

The verified path requires:

  • imc loaded and reachable from a SIP route that sends attacker-controlled MESSAGE requests to imc_manager()
  • a MESSAGE body beginning with the IMC command prefix and containing an oversized unknown command token

Production exposure depends on route policy and whether unauthenticated MESSAGE traffic reaches IMC handling.

Impact

A remote attacker can trigger an out-of-bounds read in OpenSIPS IMC unknown-command handling. In ASan testing, the worker aborted with a global-buffer-overflow in tm:build_uac_req(). In vanilla testing, OpenSIPS stayed up but emitted an oversized reflected IMC MESSAGE response whose Content-Length was derived from the attacker-controlled would-have-been length.

This is a memory-disclosure-class issue. The tested vanilla sample returned zero-filled bytes after the intended buffer boundary, so we did not observe sensitive memory disclosure in that sample. However, the server read past the intended buffer boundary and reflected data in the outbound SIP message.

Solutions and recommendations

Upgrade to a fixed OpenSIPS version. OpenSIPS lists fixes in the May 2026 release series, including:

  • OpenSIPS 3.6.6: 303fb58a6
  • OpenSIPS 4.0.0-rc1: d3c4b6da7
  • master: 07d54dbc9

Related IMC hardening commits were also published in the same release series.

If immediate patching is not possible, disable or restrict IMC routes if the feature is not required, limit access to MESSAGE routes that call imc_manager(), and enforce body-size or command-token length checks in routing logic where practical.

References

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.