Back to all use cases
Erlang/OTPCross-industry enterprise

The broker is patched. The runtime underneath it is not.

RabbitMQ has taken no CVEs since its end-of-life date. Erlang/OTP 24, the runtime underneath it, has taken 22 -- one of them at CVSS 10.0. Patching the broker does not patch the runtime.

Challenge

Teams track CVEs against the broker they run and stop there. The Erlang/OTP release the broker executes on is a separate piece of software with its own end-of-life date and its own advisory stream, and it is almost never on anyone's inventory.

Environment

RabbitMQ on an Erlang/OTP release past its own community end of life -- typically OTP 24, 25 or 26 under a 3.11, 3.12 or 3.13 broker.

Approach

OSSeva patches the runtime as a first-class artifact, not an afterthought: CVE fixes backported onto the OTP release the broker is qualified against, tracked against the same advisory feed as the broker itself.

What this delivers

Both halves of the stack covered, so a CVE scan of the host stops returning findings nobody owns.

Go deeper

See every EOL & CVE-patching use case