Cloud Foundry BPM CVE-2026-47833

The attacker must already have code execution inside a bpm-managed container (PR:L - a low-privileged process foothold within the container is sufficient). The container must have write access to the directory where bpm.log is expected, enabling symlink creation at that path. The root-level setupBpmLogs function must execute after the symlink is placed - this happens on job startup or log management events, which occur regularly during normal bpm operation. The host's /etc directory must be bind-mounted into the container (described in the CVE as a read-only /etc bind mount), which is a standard bpm deployment characteristic rather than a non-default option. Exploitation is therefore limited to: (1) environments running bpm-release below v1.4.30, (2) where a container-level compromise has already occurred, and (3) where standard bpm log directory write permissions are in place. There is no requirement for any user interaction, network access, or privileged authentication beyond the initial container foothold.

The vendor-assigned CVSS 3.1 score of 6.1 with S:U (Unchanged scope) appears to understate real-world impact: this vulnerability crosses a container-to-host security boundary, which in standard CVSS methodology typically warrants S:C (Changed scope), and would yield a higher base score closer to 7.3. The discrepancy should be verified with the Cloud Foundry Foundation. That said, the real-world risk is meaningful even under the conservative scoring: AC:L indicates no special exploitation technique is needed, PR:L confirms a container-level foothold is sufficient, and C:H captures that /etc/shadow exposure leaks all host credential hashes. EPSS data is not available in the provided intelligence, so probability of exploitation in the wild cannot be quantified statistically. No CISA KEV listing exists and no POC has been identified at time of analysis, which reduces urgency relative to KEV-listed vulnerabilities. However, the attack chain is straightforward and requires only standard Unix primitives (symlink creation), making weaponization accessible to a moderately skilled attacker who has already compromised a bpm container. Cloud Foundry deployments running bpm-managed jobs in multi-tenant or shared environments carry the highest risk, as a single compromised job can expose host credentials across all co-located jobs.

An attacker who has achieved code execution inside a Cloud Foundry bpm-managed job container - for example, through a vulnerability in a deployed application - creates a symbolic link at the expected bpm.log path within the container pointing to /etc/shadow on the host filesystem. When the root-level setupBpmLogs function runs (e.g., on job start or log rotation), it follows the symlink and chowns /etc/shadow to the vcap user without resolving the link first. The attacker then reads the now-attacker-accessible /etc/shadow file via the pre-existing read-only /etc bind mount inside the container, obtaining all host password hashes for offline cracking. No public exploit code has been identified at time of analysis, but the technique requires only standard Unix symlink primitives.