RabbitMQ EUVD-2026-85629

Three concrete preconditions must all hold: (1) the rabbitmq_tracing plugin must be enabled (not enabled by default); (2) the attacker must possess the RabbitMQ administrator tag, which the PUT /api/traces/:vhost/:name endpoint explicitly requires; and (3) the target filesystem path must already be writable by the rabbitmq OS user. Exploitation is further limited by the forced '.log' filename suffix, which constrains which files can be overwritten and makes RCE (e.g. via /etc/cron.d/) opportunistic rather than guaranteed. These factors - high privilege plus a permissive filesystem layout - make realistic exploitation an insider/post-compromise scenario rather than a broadly reachable remote flaw.

This is a genuinely low-priority issue despite the RCE potential, and the signals are internally consistent. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N, base 2.1) tells the real story: exploitation requires PR:H (the endpoint explicitly requires the administrator tag) plus AT:P (a specific attack requirement - the target path must already be writable by the rabbitmq OS user), and impact is capped at VI:L (integrity only, no confidentiality or availability). An attacker who already holds the RabbitMQ administrator tag is a highly privileged insider whose ability to write a .log file to disk is a modest incremental gain over their existing broker-wide control. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' The one point where raw impact could be understated is the /etc/cron.d/x.log RCE avenue - but the vendor deliberately rated integrity as Low because the forced '.log' suffix and the requirement that the path already be writable by an unprivileged rabbitmq user sharply constrain practical code execution. Net: high nominal severity ceiling but low real-world risk, gated behind administrator privileges and a permissive filesystem precondition.

An attacker who has obtained (or been legitimately granted and then abused) the RabbitMQ administrator tag on a node where the rabbitmq_tracing plugin is enabled sends PUT /api/traces/:vhost/:name with a traversal payload in the name parameter. Because the write path applies no safe_relative_path check, the plugin writes a '.log'-suffixed file to an arbitrary location writable by the rabbitmq OS user - for example overwriting a config-adjacent .log file, or dropping /etc/cron.d/x.log for code execution if that directory happens to be writable. No public exploit code is identified at time of analysis, and the fix (safe_relative_path on the write side) is already released.