With the Security Patch Day in May 2026, SAP has decided to discontinue the “RSBDCOS0” report. While this may seem like a good decision at first glance from an SAP security perspective, a closer look raises some doubts.
But let’s start from the beginning.
What does the “RSBDCOS0” report do?
The “RSBDCOS0” report allows SAP users to execute operating system commands directly from the SAP GUI without having to log in separately at the operating system level. One could describe “RSBDCOS0” as an “ABAP shell.” It sounds problematic. And it is. Anyone who can execute operating system commands has control over the entire SAP system.
A malicious (internal) attacker who has the ability to execute operating system commands directly can jeopardize the availability (uptime) of the entire SAP system. But the integrity of the SAP system can also be compromised, for example, by planting manipulated SAP kernels or old SAP kernels with security vulnerabilities.
As soon as an SAP user executes OS commands, these commands are not executed with the SAP user’s permissions. Likewise, there is no specific logging at the operating system level to identify who executed this OS command, since the OS command is executed via the OS user <SID>adm. This user has extensive privileges on the operating system and can, among other things, manipulate or even completely delete the SAP kernel. This also applies to other SAP executables.
Using the HDBSQL command on HANA databases, one can read ALL SAP tables or, even worse, manipulate them. This can lead to direct information disclosure, and the integrity of the SAP system can no longer be guaranteed.
The result: All three pillars of the CIA triad (confidentiality, integrity, and availability) have been compromised.
smarterSec Remark:
Operating system commands in SAP must be treated with the utmost caution!
Reader
“But then, deactivating the “RSBDCOS0” report is important and the right thing to do after all…”
Yes and no. The real core issue is the execution of certain critical OS commands. In many scenarios, however, OS commands are still part of an SAP Basis employee’s daily routine, especially in on-premises operations or even with a hosted instance at one of the hyperscalers.
Reader
“The “RSBDCOS0” report has been around for decades. Why is it only now being considered critical?”
A very likely answer is “RISE with SAP,” which shifts responsibility at the operating system level from customers to SAP. Tools such as “RSBDCOS0” are not only risky but also incompatible with this operating model.
Reader
“So far, however, I don’t see any reason not to shut it down.”
In addition to the “RSBDCOS0” report, there are other ways to execute operating system commands.
These include, among others:
- “Call System” Kernel Call via ABAP Code
- Executing OS Commands via Transactions SM49 and SM69
- The two function modules SXPG_COMMAND_EXECUTE and SXPG_COMMAND_EXECUTE_LONG
Until now, the “RSBDCOS0” report has been the de facto “standard method” used by SAP Basis to execute operating system commands. As of today, at least, the execution of “RSBDCOS0” is already logged in the Security Audit Log (albeit only to a very limited extent). This means that, provided the Security Audit Log is continuously monitored, OS commands executed via “RSBDCOS0” could be detected.
However, decommissioning “RSBDCOS0” now results in the use of the respective alternatives.
We have observed that many SAP customers are now writing their own solutions. Customer reports are generally no more secure than the “RSBDCOS0” report.
In fact, they are likely even less secure due to the lack of logging in the security audit log.
Furthermore, a simple Z-clone, such as “Z_RSBDCOS0” will not receive future security updates from SAP and thus poses a permanent security risk.
In “RISE with SAP,” this also constitutes a direct compliance violation.
Here’s what we at smarterSec recommend to our customers:
What does this mean specifically for your SAP environment? Our recommendations:
Enable SCI for ABAP code scans –
Specifically for the kernel call “Call ‘System’“, which executes OS commands directly from within ABAP code. The SAP Code Inspector (SCI) allows you to define your own check patterns and use them to search specifically for such constructs in the ABAP Repository. This step is particularly important because “Call ‘System’” leaves no trace in the Security Audit Log.
Custom test pattern in the ATC (ABAP Test Cockpit) for the SXPG function modules –
The function modules SXPG_COMMAND_EXECUTE and SXPG_COMMAND_EXECUTE_LONG are functionally equivalent to “RSBDCOS0,” but receive far less attention from administrators. Here, too, we recommend a dedicated code scan pattern to track and evaluate the use of these modules in your own code.
Consistently Secure Transactions SM49/SM69 with Authorizations –
The SM49 and SM69 transactions for external operating system commands should be accessible only to an absolutely minimal, specifically identified group of individuals. No composite roles, no inheritance via generic base profiles. Access to transactions SM49/SM69 effectively grants more privileges than SAP_ALL: Anyone who can execute external OS commands has access not only to the SAP system itself, but also to the entire operating system, the database, and all SAP tables that are not even accessible via the normal ABAP application layer. This is a level of access that must never be granted to any standard role.
Our Conclusion
The decision to decommission the “RSBDCOS0” report is well-intentioned but short-sighted. SAP is closing one door but leaving several windows open. The remaining alternatives, such as SM49/SM69, the SXPG function modules, and direct kernel calls via the “Call System” command, are in some cases even harder to monitor than the original “RSBDCOS0” report, because they do not appear in the security audit log at all.
Targeted hardening of the report, combined with mandatory logging of all executed commands, would likely have been a more effective step. Instead, many SAP customers are now shifting their usage to alternative methods, often using custom ABAP code that offers even fewer security mechanisms than the original.
We hope that SAP will take corrective action here: in particular, a native code pattern for SXPG calls in the SAP Code Inspector / ATC would at least significantly improve transparency in customers’ own ABAP code.
Until then, the responsibility lies with the customers’ own SAP teams. And for most of them, OS commands are simply not on their radar.
Not sure where to start? That’s understandable, because the topic is complex, and very few SAP teams have the staff or expertise to tackle it on the side.
We can help.
Related Topics: SAP Security Patchday 05/2026: Say “Farewell” to an Old Friend