Compliance Impact

This vulnerability results in a container-to-host confidentiality breach by allowing an attacker to read sensitive host data such as password hashes from /etc/shadow.

Such unauthorized access to sensitive information can lead to violations of data protection standards and regulations like GDPR and HIPAA, which mandate strict controls over the confidentiality and integrity of personal and sensitive data.

Therefore, if exploited, this vulnerability could compromise compliance with these regulations by exposing sensitive authentication data and potentially enabling further unauthorized access.

Useful 0 Not Useful 0

Executive Summary

CVE-2026-47833 is a symlink vulnerability in the setupBpmLogs component of Cloud Foundry's BPM (Bosh Process Manager) that allows container-to-host privilege escalation.

The vulnerability occurs because setupBpmLogs follows symbolic links when opening and changing ownership of the bpm.log file. This behavior enables a compromised process inside a BPM container to manipulate files on the host system.

Specifically, an attacker can cause the root user on the host to change ownership of arbitrary host files to the vcap user, including sensitive files like /etc/shadow. Since /etc/shadow is bind-mounted as read-only into the container, the attacker can then read password hashes from it.

This results in a container-to-host confidentiality breach affecting every bpm-managed job.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability allows an attacker with access inside a BPM container to escalate privileges to the host system by changing ownership of critical host files.

The attacker can take ownership of the /etc/shadow file on the host, which contains password hashes, and read sensitive authentication data.

As a result, the attacker can compromise host security, potentially leading to unauthorized access to the host system and other sensitive data.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the setupBpmLogs component following symlinks for bpm.log and changing ownership of arbitrary host files, such as /etc/shadow. Detection would involve checking for unexpected ownership changes on critical host files like /etc/shadow, especially if ownership has been changed to the vcap user.

You can detect potential exploitation by monitoring file ownership changes and suspicious log file modifications inside bpm containers.

• Check ownership of /etc/shadow on the host: ls -l /etc/shadow
• Look for bpm.log symlinks inside containers: find /path/to/bpm/container -name bpm.log -type l -ls
• Audit recent changes to /etc/shadow: stat /etc/shadow
• Monitor logs for appended bpm JSON log lines to host files.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade bpm-release to version v1.4.30 or later, where this vulnerability has been fixed.

Until the upgrade can be applied, restrict local access to bpm containers to trusted users only, as the attack requires local access.

Monitor and audit file ownership changes on critical host files such as /etc/shadow to detect any unauthorized modifications.

Useful 0 Not Useful 0