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-beta through 3.6.5 and 4.0.0-beta contain a buffer overflow in the {s.b64encode} string transformation. The size check for {s.b64encode} only verifies that the input fits within the 64 KB transformation buffer, but base64 encoding expands the data by roughly a third, so an input between about 49,153 and 65,535 bytes produces more output than the buffer can hold and overflows it by up to 21,844 bytes. Because these transformation buffers sit next to each other in memory and are reused for chained transformations, the overflow writes attacker-controlled data into the adjacent buffer and corrupts values used by later transformations processing the same SIP message. A remote attacker can trigger this by sending a SIP message with a large header value (roughly 50,000 bytes or more) when the routing script applies {s.b64encode} to attacker-controlled input, making exploitability dependent on the deployment's routing configuration. This issue has been fixed in versions 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 base64 expansion check was added by 4d23613b6 ("core: enforce bounds checks on input-derived lengths (#3888)"), which extends the {s.b64encode} size check in transformations.c to also test calc_base64_encode_len(val->rs.len) against TR_BUFFER_SIZE, accounting for the 4/3 expansion. git tag --contains places it in 3.6.6 and 3.6.7. For 4.0.0 the corresponding master-branch commit was rebased, so hash containment is not meaningful there; the fix was instead confirmed by content — the calc_base64_encode_len(val->rs.len)>TR_BUFFER_SIZE condition is present in transformations.c at tag 4.0.0. Closing CURRENTRELEASE.