Steeltoe Configuration EUVD-2026-37820

All four of the following conditions must be met simultaneously: (1) The application must run Steeltoe.Configuration.Abstractions 4.0.0-4.1.0 - earlier and later versions are not affected; (2) The Cloud Foundry environment must supply MySQL or PostgreSQL service bindings in VCAP_SERVICES that include TLS client credentials (ssl-cert, ssl-key, ssl-ca for MySQL; SSL Certificate, SSL Key, Root Certificate for PostgreSQL) - bindings without TLS client certs do not trigger the vulnerable code path; (3) The host operating system must be Linux - the fix code explicitly bypasses the secure file creation path on Windows, and File.CreateText on Windows does not produce world-readable files in the same way; (4) The attacker must have local process execution capability within the same container under a UID different from the application process UID, with read access to Path.GetTempPath(). Exploitation is blocked by: single-UID container enforcement, absence of TLS client credentials in VCAP_SERVICES, Windows deployment, use of Kubernetes service bindings instead of Cloud Foundry VCAP_SERVICES, or versions outside the 4.0.0-4.1.0 range.

The provided CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, score 4.7) accurately characterizes this vulnerability. AV:L is appropriate because the attacker must be a local process on the same container; AC:H reflects the non-trivial precondition that another process operating under a different UID must be present and able to access /tmp - a constraint that materially limits exploitation in strict single-UID container deployments. The C:H impact is fully justified: the exposed material includes TLS private keys usable for client impersonation against database servers enforcing mTLS. There is no integrity or availability impact directly from the file exposure. No EPSS score was provided in the source data, so exploitation probability cannot be quantified numerically. No KEV listing exists and no POC code has been identified, meaning this is a disclosed-but-not-actively-exploited vulnerability. Real-world severity is highest for multi-process or shared-UID container environments on Cloud Foundry, and lowest (non-exploitable) for properly isolated single-UID containers, Kubernetes deployments, Windows hosts, and applications not using TLS client credentials. The file persistence issue means exposure compounds over container uptime - a long-running container accumulates more temp files that are never cleaned up.

An attacker who has obtained low-privilege local execution within a Linux Cloud Foundry container running a Steeltoe 4.0.0-4.1.0 application with MySQL or PostgreSQL TLS bindings can enumerate /tmp for world-readable PEM files written by the Connectors library, extract the TLS private key, and subsequently impersonate the application to the database server in mTLS-authenticated sessions. No public exploit code has been identified, but the attack requires only standard file system enumeration tools once local access is established.