One of z/OS’s main architectural strengths is its service isolation. Each program runs in its own address space, which means a failure—such as a job ending in an S0C4 abend—is contained and won’t impact the rest of the system. Critical services like Security, CICS, databases, and communications continue to operate independently.

However, since the introduction of XA architecture in the 1980s, z/OS has supported a shared memory area across address spaces: the CSA (Common Storage Area), and its 64-bit counterpart, the ECSA (Extended CSA).

These areas are used to exchange information between address spaces. In CICS, for instance, terminal controllers and the master task exchange data through shared memory—essential to the high-speed performance that characterizes IBM mainframes.

The issue: writing to CSA using user keys

To write to these areas, programs must be loaded from APF-authorized libraries and linked with AC=1. However, for decades, it was possible to simply use a GETMAIN from the assembler to allocate CSA memory using user keys.

This vulnerability was well known among system programmers but was never formally documented or addressed in z/OS updates for over 30 years.

Real-world exploits

The first incident we encountered was in 2002. A client suffered a breach exploiting a separate VTAM vulnerability. On analyzing the malicious code, we discovered it could trigger a software stop by zeroing out the entire CSA, freezing the whole LPAR.

The attacker had deployed two disguised programs in APF libraries: one to escalate privileges to the SPECIAL and OPERATIONS roles, and another to crash the system. While the VTAM issue was mitigated and an investigation was conducted, it was impossible to determine whether any data had been exfiltrated—authorized accesses were not audited.

We later found a very similar piece of code on a technical forum. We added a WTO instruction as a warning: if this code executes, someone’s career may be on the line.

Turning it into a logic bomb

Transforming this code into a logic bomb is easy: embed it in system logon and procedure libraries. It will execute on every IPL—including in the backup environment due to synchronous disk replication—rendering the system unusable.

If this happens, it means the attacker had more knowledge and focus than the system’s defenders—and that’s a serious problem.

A late but effective fix

With z/OS 1.9, IBM introduced the DIAGxx parameter VSM ALLOWUSERKEYCSA(YES/NO), with NO as the recommended setting. However, many software vendors took years to update their products, delaying broad adoption.

Starting in z/OS 2.3, the parameter was removed, and the system behaves as if ALLOWUSERKEYCSA=NO. This officially closes the vulnerability.

What do we do with this code now?

Now we can use the code safely—as a test tool in controlled environments. If your configuration is secure, the system will immediately cancel the program. It’s a clear indicator of whether your protections are working.

Are there more vulnerabilities?

Yes. Some issues take decades to resolve. Others are being discovered today. Security audits in z/OS environments should confirm whether the proper controls are in place—and if risks are documented.

This long-standing vulnerability shows how minor technical oversights can have a catastrophic impact. Fortunately, it can now be mitigated. But the key remains: active monitoring, frequent audits, and ongoing technical training.

Want to know if your system is vulnerable? Would you like to test this code in a safe environment? Contact us—we’ll provide it to you.