Bluechi: privilege escalation in bluechi via unrestricted cross-node systemd dependencies

Eclipse Bluechi is a multi-node systemd service controller. It lets a single 'host' node orchestrate systemd units on a fleet of 'managed' nodes — its flagship deployment is Red Hat's RHIVOS (in-vehicle OS) and similar automotive/edge platforms. The flaw (CWE-863, incorrect authorization) is that Bluechi doesn't restrict cross-node systemd dependencies: a process with root on a managed node can craft a unit file whose Requires=/Wants=/Before= relationships reach back to the *host* node, causing the host to execute or override unit files on the attacker's behalf. Affected versions are everything prior to the upstream fix shipped by the Eclipse Bluechi project and backported by Red Hat in late 2025; the GHSA does not yet pin specific version numbers.

Red Hat's HIGH / 7.2 rating is defensible *inside the RHIVOS threat model*, where a managed node is a less-trusted partition (the qm container) and the host is the safety-critical OS — crossing that boundary is exactly the design failure CVSS scope-change is meant to flag. For a typical enterprise patch queue, the rating is generous: the attacker already needs root on a managed node, the vector is AV:P (Physical), EPSS is 0.00178 (8th percentile), there is no public PoC, no KEV listing, and Bluechi has essentially zero install base outside automotive/edge stacks. Net effect: real bug, narrow audience, MEDIUM in a general enterprise context.

Why this verdict

• Pre-existing root required: PR:H means the attacker has already compromised one node — this is a lateral/escalation primitive, not an initial-access bug. Friction adjustment: −1.0.
• AV:P (Physical) vector: CVSS itself classifies the attack surface as physical-adjacent; remote exploitation is not in scope. Friction adjustment: −0.7.
• Install base is automotive/edge-only: Bluechi's flagship deployment is RHIVOS in-vehicle OS; install base in general enterprise is effectively zero. For the typical noisgate reader, the population at risk rounds to nothing. Friction adjustment: −1.0.
• No exploitation signal: EPSS 0.00178, not KEV-listed, no public PoC, no GreyNoise traffic — exploit development cost is high and reward niche. Friction adjustment: −0.5.
• Role multiplier: Bluechi *is* a control-plane component on the systems where it runs — a successful chain ends in host-node root and fleet pivot across managed nodes. That triggers the high-value-role floor of MEDIUM for enterprise readers (install base <1%), and would floor at HIGH for organizations actually running RHIVOS or Bluechi-managed fleets. RHIVOS operators should treat this as HIGH per the canonical orchestrator rule.

Why not higher?

Not HIGH for the general enterprise audience because the install base is vanishingly small, the attacker needs PR:H on a managed node before the bug is reachable, and the CVSS vector is AV:P. Without remote reachability or a broad install base, HIGH would misallocate patching attention away from genuinely externally reachable bugs.

Why not lower?

Not LOW or IGNORE because the underlying flaw is a real authorization break in an orchestrator: where Bluechi *is* deployed, it sits in the trust boundary between less-trusted and safety-critical partitions, and the chain ends in full host compromise. Anyone running RHIVOS, the bluechi RPM, or an edge Quadlet stack must treat it as a HIGH-floor bug per the canonical-orchestrator rule.

1. Inventory for the bluechi and bluechi-agent packages — Run a one-shot package query across your fleet (rpm -qa | grep bluechi, Ansible ad-hoc, or your existing CMDB query) to confirm whether you have any install base at all. For 99% of enterprise readers this returns zero and the CVE moves to documented-and-closed. No mitigation SLA applies (MEDIUM verdict) — complete the sweep as part of normal monthly hygiene.
2. Restrict writable unit-file paths on managed nodes — On any host running bluechi-agent, harden systemd's UnitPath= and apply ReadOnlyPaths=/etc/systemd/system via a drop-in for the agent service. This prevents a root-on-managed-node attacker from authoring the malicious unit in Step 2 of the chain. Roll out within the standard 365-day MEDIUM remediation window per noisgate SLA.
3. Enforce SELinux confinement on bluechi-agent — Verify the agent runs under a confined domain (RHIVOS ships bluechi_agent_t) and that policy denies unit-file writes from non-admin domains. Use ausearch -m AVC -ts recent | grep bluechi to confirm denials are being logged.
4. Ship Bluechi controller logs to your SIEM — Forward host-node journalctl -u bluechi-controller and managed-node bluechi-agent logs. Alert on cross-node unit activations that didn't originate from your orchestration pipeline — that's the high-signal detection for Step 3.

Run this on each suspected Bluechi host (managed node *or* controller) as root or via your config-management agent: sudo bash check-cve-2025-2515.sh. It checks for the bluechi/bluechi-agent packages, compares versions against the Red Hat-fixed build, and reports VULNERABLE / PATCHED / UNKNOWN.

#!/usr/bin/env bash
# check-cve-2025-2515.sh — Bluechi cross-node systemd dependency authorization flaw
# Exit codes: 0 = PATCHED or NOT_INSTALLED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

FIXED_RHEL='0.9.0-1'   # placeholder — replace with the RHSA-pinned fixed NVR for your stream
FIXED_UPSTREAM='0.9.0' # upstream Eclipse Bluechi tag containing the auth check

found=0
status='PATCHED'

for pkg in bluechi bluechi-agent bluechi-controller; do
  if rpm -q "$pkg" >/dev/null 2>&1; then
    found=1
    ver=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' "$pkg")
    echo "[*] $pkg installed: $ver"
    # rpmdev-vercmp returns 11 if $ver < FIXED_RHEL, 12 if greater, 0 if equal
    if command -v rpmdev-vercmp >/dev/null 2>&1; then
      rpmdev-vercmp "$ver" "$FIXED_RHEL" >/dev/null 2>&1
      rc=$?
      case $rc in
        0|12) : ;;             # equal or newer → still patched
        11)   status='VULNERABLE' ;;
        *)    status='UNKNOWN' ;;
      esac
    else
      status='UNKNOWN'
    fi
  fi
done

if [ $found -eq 0 ]; then
  echo 'NOT_INSTALLED'
  exit 0
fi

# Bonus: surface agent process so you know the daemon is actually running
if pgrep -a bluechi-agent >/dev/null 2>&1 || pgrep -a bluechi-controller >/dev/null 2>&1; then
  echo '[*] Bluechi daemon active'
fi

echo "$status"
case $status in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. GHSA-hcr2-46j7-rjhp (GitHub Security Advisory)
2. Red Hat CVE-2025-2515 advisory
3. Eclipse Bluechi project
4. NVD entry for CVE-2025-2515
5. RedPacket Security CVE alert
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS lookup
8. Red Hat In-Vehicle OS (RHIVOS) overview