IBM DevOps Deploy CVE-2025-14148

Exploitation requires an authenticated session in IBM DevOps Deploy (versions 8.1 through 8.1.2.3) AND possession of LLM integration configuration privileges - a specific administrative capability, not a standard user role. A precondition is that an LLM integration must already be configured with a saved API Token for there to be anything to recover. Limiting factors: this is not reachable by unauthenticated or low-privileged users, there is no cross-user impact (S:U), and the disclosed asset is confined to the stored LLM API Token (C:H, no integrity or availability impact). These constraints make it primarily an insider-abuse or post-compromise credential-recovery issue rather than a broadly exploitable remote flaw.

This is a moderate, low-priority issue despite its 6.5 (Medium) CVSS score. The CVSS vector (AV:N/AC:L/PR:L/UI:N) implies network-reachable, low-complexity exploitation, but the real gating factor is PR:L combined with a very specific privilege requirement: the attacker must already be an authenticated user holding LLM integration configuration privileges. That is an elevated, administrative-style role in IBM DevOps Deploy, so the practical privilege bar is higher than PR:L alone suggests - arguably PR:H. EPSS is low at 0.30% (21st percentile), there is no CISA KEV listing, and no public exploit was identified, so all exploitation signals agree this is not under active or imminent broad exploitation. No SSVC decision data was provided. The impact is bounded: C:H/I:N/A:N reflects disclosure of a single stored LLM API token to someone who already administers that integration, so the incremental risk is largely an insider/privilege-abuse or post-compromise credential-recovery concern rather than a remote takeover. Signals are consistent (low EPSS, no KEV, no POC, privileged precondition) - this is a genuine-but-low-urgency credential-protection weakness (CWE-522), not a high-real-risk flaw.

An authenticated IBM DevOps Deploy user who holds LLM integration configuration privileges navigates to the LLM integration settings and retrieves a previously saved LLM API Token that should have remained write-only/masked. The recovered token could then be reused to make charges against, or exfiltrate data from, the connected LLM service, or be repurposed in a broader insider or post-compromise scenario. No public proof-of-concept exists; exploitation is low-complexity but requires the elevated configuration role.