Edgeless Contrast EUVD-2025-211007

Requires that (1) the deployment actually uses Contrast workload secrets - deployments not using workload secrets (or designed for workload-owner exclusion) are entirely unaffected - and (2) the Contrast initializer runs at CONTRAST_LOG_LEVEL of info or debug, which is the DEFAULT, so no customization is needed for the leak to occur. To then obtain the leaked secret, the actor needs get or list permission on pods/logs via Kubernetes RBAC, or read access to the underlying Kubernetes log storage (notably the cloud provider). Limiting factors: exploitation is gated behind log-read privileges (PR:L, not unauthenticated) and is a passive disclosure with no code execution; only Contrast versions <= 1.8.0 are affected, and the leak stops if the initializer log level is set to warn.

This is a genuine but moderate-priority confidentiality exposure whose real severity hinges on deployment specifics. The vendor's CVSS 4.0 vector (8.5, AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) treats the flaw as high, but the VI:H (integrity) rating is generous: the defect (CWE-532) is a passive information disclosure - the workload secret is written to logs - and any integrity impact is only indirect, arising if the leaked secret is later reused to impersonate or tamper with the workload. My independent read scores it lower (~6.5) with confidentiality-only impact. No EPSS score, KEV listing, or public POC is provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - there is no evidence of active exploitation, only a plausible disclosure path. The most important amplifying signal is NOT the CVSS number but the configuration reality stated by the vendor: because CONTRAST_LOG_LEVEL=info is the DEFAULT, every installation using workload secrets that has not explicitly set the log level is affected out of the box, and the secret is exposed not just to Kubernetes RBAC principals with get/list on pods/logs but to the cloud provider holding the log storage. Note the vector uses AV:A (adjacent) while log access via the Kubernetes API is typically network-reachable - verify the intended attack surface with the vendor. Overall: real and worth patching, but a low-probability, access-gated leak rather than a wormable critical.

A cluster operator, tenant, or compromised low-privilege service account holding get/list permission on pods/logs (or the cloud provider with read access to log storage) reads the Contrast initializer's stderr output from Kubernetes logs and recovers the plaintext workload secret that should be confined to the Coordinator and workload owner. No special crafting is needed - the secret is present in default (info-level) logs - so the 'attack' is passive log inspection. No public exploit code is required or reported.