An SAP vulnerability assessment in the RedRays Security Platform reports classes of issue that a network-reachable SAP service reveals about itself: missing authentication on administrative functions, optional services left enabled, information disclosure, denial of service exposure, and configuration that leaves an access control switched off.
The checks are written per service family, because nothing true of the SAP Java stack is automatically true of the ABAP web stack. What follows is what each family is asked about, in categories rather than as a rule list.
| Class | What it looks like on an SAP system | Typical weakness class |
|---|---|---|
| Missing authentication on a critical function | An administrative or configuration endpoint that answers a stranger and performs privileged work | CWE-306 |
| Unnecessary services enabled | Optional handlers, test services and sample content that ship enabled and are rarely needed in production | CWE-1188 |
| Information disclosure | An endpoint that returns version, configuration, path or component detail to an unauthenticated caller | CWE-200 |
| Denial of service exposure | A component whose known resource-handling defect is reachable from the network | CWE-400 |
| Remote code execution exposure | A component whose known defect allows code or command execution by a remote caller | CWE-94, CWE-78 |
| Access control removed by configuration | A control that exists but is not configured, so the component defaults to permitting the call | CWE-284 |
| Weak or absent transport protection | A service presenting a face that carries no transport encryption where an encrypted one is expected | CWE-319 |
The ABAP web stack is reached through the Internet Communication Framework (ICF), and it is the family where enabled-by-default content dominates. Findings here are typically optional ICF services and test handlers that answer without being needed, endpoints that return more about the system than an anonymous caller should receive, and known defects in the Internet Communication Manager reachable over HTTP.
The message server's HTTP face and the ABAP dispatcher are separate families with their own checks. A frequent finding on this side is not a software defect at all: the SAP Gateway access control lists, secinfo and reginfo, are checked for existence, because a gateway with no access control list registered is a gateway that accepts registrations it should refuse. That is a configuration state a fully patched system reaches without a single missing note.
The Java HTTP stack carries the largest body of checks, and the classic example of the class is the RECON flaw (CVE-2020-6287): an administrative web service in the Java configuration layer that performed no authentication check, so an unauthenticated caller could carry out configuration tasks, including creating an administrative user. A check for an issue of that shape sends a request the affected component answers distinctively and records the answer. It does not create a user, and it does not run a configuration task.
The Java P4 service is a separate family with its own checks, as is SAP Cloud Connector, which sits between a cloud tenant and an on-premise landscape and is worth assessing precisely because it is designed to be reachable from both sides.
HANA is not asked over HTTP. Those checks open a database session and ask the database itself, which means they run only where a database logon is stored against the service. Where no logon is stored, they are skipped rather than run and found clean, which is the single most common reason a HANA host produces a short report. Scanning with and without credentials is the page on that distinction.
Two families sit outside the classic NetWeaver picture and are commonly forgotten in an inventory: the SAP Business One Web UI, and SAP BusinessObjects REST web services. Both are HTTP services that carry business data, both are commonly deployed by a team other than the one that runs the core landscape, and both are asked their own set of questions here.
This page names classes, not the catalogue. Two limits follow from that and both matter when a list like this is used for comparison shopping.
First, a class being listed here does not mean every issue in that class is checked on your landscape. The checks that run are the ones written for the service families your port scan recorded, so the same catalogue produces very different question sets on two landscapes. Second, a class not producing a finding does not mean the class is absent, because absence has several causes and no report distinguishes them. That is the subject of what a clean report does not say.
For the anatomy of a single result, see what one vulnerability finding says, and for who decides how serious it is, published severity against recorded status.
No, and no product should claim to. Checks exist where an issue can be distinguished by what a service answers over the network, or by what a stored logon can read. Where a defect is only distinguishable by patch level, the SAP Security Notes and component version checks that run beside this one are the right instrument.
secinfo or reginfo a vulnerability?It is a missing access control rather than a software defect, and it is reported because the effect on an exposed gateway is what an attacker cares about. The remedy is configuration, not patching.
No. Custom code is a separate capability with a separate input. See ABAP code security scanning.
Parameter values are their own capability, with their own report and their own comparison against recommended values. See SAP profile parameters.