Skip to content
Blog

IBM · IBM DataStage · Cloud Pak for Data

IBM DataStage on Cloud Pak for Data: CVE-2026-81212, Anonymous Writes to the Redis Cache Shared Across Tenants (CVSS 10)

CVE-2026-81212 (CVSS 10, IBM): anyone can write to DataStage 5.4.0.0's shared Redis under any tenant's key, no login needed. Impact, detection, mitigation.

3 min readCVE-2026-81212

On October 20, 2026, IBM published CVE-2026-81212, rated 10.0 — the top of the CVSS 3.1 scale — in IBM DataStage on Cloud Pak for Data 5.4.0.0. That makes three critical flaws in the same release within eight days, following the two path traversals published on October 12.

This one is different in kind: it doesn't target a server so much as the boundary between customers on a shared platform.

CVECVE-2026-81212
ProductIBM DataStage on Cloud Pak for Data
Version cited5.4.0.0
CVSS 3.110.0 (IBM PSIRT)
VectorAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
CWECWE-285 (Improper Authorization)
NVD statusAwaiting Analysis
CISA KEVNo, at the time of writing

The vulnerability

According to the published description, an unauthenticated user can perform an arbitrary write into the platform's shared Redis, under any tenant's key. IBM spells out two consequences:

  • the platform's credential-encryption boundary collapses;
  • an anonymous caller can poison any tenant's cached flow parameters.

The assigned weakness, CWE-285, sums it up: write access to the cache isn't subject to the authorization check that is supposed to keep tenants apart.


What it means in practice

DataStage is a data integration tool. Its flows read from sources, transform data and write to targets, so their parameters typically name connections, paths and databases. Being able to rewrite those cached parameters means being able to change what another tenant's flow will do the next time it runs.

The published vector reads as follows:

  • PR:N and UI:N: no account and no user interaction required;
  • S:C: the impact reaches beyond the vulnerable component — here, into other tenants;
  • C:H/I:H: full loss of confidentiality and integrity;
  • A:N: no availability impact.

A high confidentiality impact for what is described as a write fits with the mention of the credential-encryption boundary. A reasonable guess is that by planting values where the platform expects encryption-related material, or by redirecting where a flow sends its output, an attacker ends up with another tenant's data. That is an inference: IBM doesn't describe the exploitation path, and NVD reports no exploitation.

The most exposed setup is a Cloud Pak for Data instance shared by several teams or business units, each in its own tenant, with network access that isn't locked down.


Affected versions

NVD hasn't analyzed the entry yet and provides no CPE configuration. The description only cites version 5.4.0.0 and doesn't say which version fixes the issue. The IBM bulletin referenced in NVD (IBM support, node 7289603) is the source to follow for the fix or interim fix to apply.


Detection

  • Inventory: identify Cloud Pak for Data deployments running DataStage 5.4.0.0, especially those hosting multiple tenants.
  • Exposure: check which networks can reach the instance. No account is needed, so network access is the only thing standing in the way.
  • Flow integrity: compare the flow parameters actually used in recent runs with their expected definitions (connections, write targets).
  • Redis: if your platform monitoring allows it, look for writes to tenant keys coming from unauthenticated sessions.

Mitigation

  1. Apply the IBM fix listed in the bulletin.
  2. In the meantime, restrict network access to the instance to legitimate user networks only.
  3. Once patched, flush the flow-parameter cache if the platform allows it, to clear out any poisoned values, and rotate the credentials used by flows on instances that were exposed.

Why continuous monitoring matters for data platforms

Three critical CVEs in eight days on a single DataStage release: on products like this, bulletins come in waves and each one calls for action. Tracking them by hand, vendor by vendor, is how some slip through.

With cveo.tech, register your platforms with their exact versions and get an alert as soon as a CVE affects them — even before NVD has analyzed it.

Know which CVEs hit the versions you run.

Add the product and its version: cveo.tech lists the CVEs that affect it right away, then alerts you by email when a new one affects it — including before NVD has finished its analysis. Free, an account is all it takes.

Every Monday

The week's critical CVEs, in your inbox

One email a week: the CVSS ≥ 9 vulnerabilities published in the last seven days, plus our latest analyses. Nothing else.

Double opt-in by email. Unsubscribe in one click, any time.