IBM DataStage CVE-2026-80434

Exploitation requires a valid, authenticated low-privilege account on IBM DataStage on Cloud Pak for Data 5.4.0.0 (PR:L). No special non-default configuration is required beyond having network access to the DataStage API endpoint (AV:N, AC:L). The primary limiting factor is that the attacker must possess a legitimate platform credential - unauthenticated external attackers cannot exploit this without first obtaining account access. The scope change (S:C) implies the runtime cache is shared across services, meaning a single authenticated attacker can affect workloads and state belonging to other tenants or pipelines on the same platform instance.

The vendor-assigned CVSS 7.4 with AV:N/AC:L/PR:L/UI:N/S:C reflects a credible medium-high risk for multi-tenant or shared DataStage deployments: low-privilege authentication is required (PR:L), but once met, exploitation is straightforward (AC:L) and crosses the scope boundary (S:C), potentially impacting other Cloud Pak for Data services sharing the same runtime. No EPSS data was provided, no CISA KEV listing exists, and no POC is publicly known, which collectively reduces urgency for opportunistic exploitation - this is not a drive-by scenario. However, the scope change means even a mid-sized enterprise IT team in opole running shared Cloud Pak for Data infrastructure should treat this as a priority patch during their next maintenance window, since a single rogue or compromised low-privilege account could disrupt shared ETL workloads. The C:L and I:L in the vendor CVSS are lightly supported by the description, which emphasizes DoS as the primary outcome; confidentiality and integrity impacts are possible through cache pollution but not explicitly confirmed. The 'Authentication Bypass' tag in the input metadata is a mislabel - this is an authorization bypass (IDOR), not an authentication bypass.

An attacker with a low-privilege Cloud Pak for Data account sends crafted API requests to the DataStage runtime, substituting another session or pipeline's cache object identifier in place of their own. By repeatedly referencing and manipulating foreign cache entries, they corrupt or exhaust runtime cache state, causing active ETL pipeline jobs to fail or stall across the shared platform.