The vulnerability arises from the setupBpmLogs component following symbolic links when opening and changing ownership (chown) of bpm.log. A malicious process inside a bpm container can exploit this behavior to cause the root user on the host to chown arbitrary files to the vcap user and append log data to them. Specifically, this can be used to take ownership of /etc/shadow on the host, which is mounted read-only inside the container, thereby exposing sensitive password hashes. This is a container-to-host privilege escalation and confidentiality break affecting all bpm-managed jobs in bpm-release versions prior to v1.4.30.

An attacker with limited privileges inside a bpm container can escalate privileges to affect the host system by changing ownership of critical files such as /etc/shadow. This leads to a confidentiality breach where password hashes on the host can be read, compromising host security. The integrity impact is limited (low), and there is no denial of service impact. The CVSS 3.1 base score is 6.1 (medium severity), reflecting local attack vector with low complexity and no user interaction required.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability affects bpm-release versions prior to v1.4.30, so upgrading to v1.4.30 or later is implied as a remediation step. Until an official fix is confirmed, restrict access to bpm containers and monitor for suspicious activity related to file ownership changes. Avoid running untrusted code inside bpm containers.