SAP Note 3689080 addresses a Server-Side Request Forgery (SSRF) weakness, tracked as CVE-2026-24316, in SAP NetWeaver Application Server for ABAP. A leftover testing report shipped with the eCATT tooling could be misused to make the server send HTTP requests to arbitrary internal or external endpoints. SAP released the fix in March 2026, and this post breaks down what the note covers and how to remediate it.
This one is ours: our research team flagged this SSRF pattern with the RedRays ABAP Code Scanner, our static-analysis engine for custom and standard ABAP code, and SAP subsequently closed it out in this note.
What was the issue
SAP NetWeaver AS for ABAP shipped an ABAP report that was originally built for testing purposes. That report accepted a target address and made the application server issue HTTP requests to it - and it did not adequately restrict where those requests could go. In practice that means the report could be pointed at arbitrary destinations, including internal endpoints that sit behind the server and are not meant to be reachable from the outside. This is the classic pattern behind Server-Side Request Forgery: an attacker gets the trusted server to make requests on their behalf.
According to the note, a successful attacker would need to be an authenticated user on the ABAP system holding only the basic authorization required to run reports - no elevated administrator rights are called for. The potential impact is rated low for both confidentiality and integrity, with no impact on availability. Because the SSRF crosses a trust boundary (the CVSS scope is marked as changed), interaction with sensitive internal endpoints is the primary concern. In line with standard vendor-advisory practice, we are keeping this summary at a descriptive level and are not publishing exploitation steps or proof-of-concept details.
The vulnerable code vs. the fix
The change sits in report EC_ODATA_TEST_GET_METADATA, the eCATT OData test utility named in the note - the correction instruction adds a deprecation notice as the very first statement the report executes, ahead of the report's full removal in a later support package.
VulnerableREPORT ec_odata_test_get_metadata.
DATA lp_ecatt_odata TYPE REF TO cl_ecatt_apl_odata_client.REPORT ec_odata_test_get_metadata.
WRITE 'Test Report is outdated and will be deleted with the next Support Package'.
DATA lp_ecatt_odata TYPE REF TO cl_ecatt_apl_odata_client.How to fix it
The remediation is straightforward: apply SAP Note 3689080. SAP's fix removes the vulnerable test report entirely, since it was no longer needed - so there is no configuration to tune or exception to weigh, just get the correction onto the system. You can either implement the Support Packages and Patches referenced by the note or, if you cannot move to the target support-package level immediately, apply the correction instruction it provides.
The note applies across a wide swath of SAP_BASIS releases (740, the 750 through 816 line, and 918). The support-package levels that carry the fix are listed below - if your system is at or above the level shown for your release, you already have the correction.
| SAP_BASIS release | Fixed in support package |
|---|---|
| 740 | SAPKB74035 |
| 750 | SAPK-75035INSAPBASIS |
| 752 | SAPK-75218INSAPBASIS |
| 753 | SAPK-75316INSAPBASIS |
| 754 | SAPK-75414INSAPBASIS |
| 755 | SAPK-75512INSAPBASIS |
| 756 | SAPK-75610INSAPBASIS |
| 757 | SAPK-75708INSAPBASIS |
| 758 | SAPK-75806INSAPBASIS |
| 816 | SAPK-81602INSAPBASIS |
| 918 | SAPK-91801INSAPBASIS |
If you manage a large landscape, the hard part is rarely applying a single patch - it is knowing which of your systems carry code exposed to this pattern in the first place. That is the gap the RedRays ABAP Code Scanner is built to close: it is the same static-analysis engine that surfaced this SSRF pattern for our research team, and it runs across custom and standard ABAP code to catch this class of issue before it ever needs a Security Note.
Catch SSRF like this before SAP has to patch it
An unrestricted, user-controlled outbound HTTP call is exactly the kind of issue the RedRays ABAP Code Scanner catches automatically in custom ABAP code - the same pattern behind CVE-2026-24316, found here in a standard SAP report before it ever reached a Security Note.
Explore ABAP Code ScannerThis vulnerability was identified by the RedRays research team using the RedRays ABAP Code Scanner, and SAP addressed it in this Security Note. This article summarizes the relevant details for defensive patch-management purposes and includes only a short, minimal code excerpt above illustrating the specific fix - not the full correction instruction. Always refer to the official note in the SAP Support Portal for authoritative guidance.
