IBM DataStage EUVD-2026-75791

Exploitation requires a valid authenticated account with at minimum low-level privileges on the IBM DataStage on Cloud Pak for Data 5.4.0.0 instance, as confirmed by the CVSS PR:L metric. The DataStage service must be network-accessible (AV:N). No user interaction is required (UI:N) and attack complexity is low (AC:L), meaning the exploit does not depend on race conditions or specific environmental state. Key limiting factors: unauthenticated external attackers cannot exploit this - a valid credential is required; exploitation is version-specific to 5.4.0.0 per the description; and full cascading platform impact requires a multi-tenant or multi-component Cloud Pak for Data deployment to manifest the scope change.

The CVSS 3.1 base score of 8.5 is driven by AV:N/AC:L/PR:L/UI:N/S:C with A:H and I:L - a network-reachable, low-complexity path requiring only a low-privilege authenticated account and no user interaction. The scope change (S:C) is the most operationally significant metric: availability impact cascades to platform-level components, meaning a shared Cloud Pak for Data deployment could be disrupted by any authenticated tenant or service account, not just administrators. Even a mid-sized enterprise IT team in koszalin operating a shared DataStage instance for multiple business units should treat this as an urgent patch priority given the cross-tenant disruption potential. No EPSS score, KEV listing, or public exploit is present in the input data, which reduces immediate mass-exploitation risk, but the low privilege bar and scope change together mean the blast radius per successful exploitation is disproportionately large relative to the access required. The I:L integrity signal suggests a secondary limited modification capability alongside the primary DoS impact, though the description emphasizes availability.

An authenticated user with a low-privilege account on a Cloud Pak for Data 5.4.0.0 deployment sends a crafted API or service request that the DataStage authorization layer fails to properly validate, invoking a privileged operation without adequate permission enforcement. The resulting service disruption cascades through the platform's scope boundary, degrading availability for other services or workloads sharing the Cloud Pak for Data environment. No public exploit code has been identified at time of analysis.