Yes. CISA added CVE-2016-2386 to its Known Exploited Vulnerabilities catalogue on 9 June 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. SQL injection vulnerability in the UDDI server in SAP NetWeaver J2EE Engine 7.40 allows remote attackers to execute arbitrary SQL commands via unspecified vectors.
What it means that SAP NetWeaver SQL injection is being exploited
This is not just a theoretical SAP flaw. Once CISA places a CVE in the Known Exploited Vulnerabilities catalogue, the practical assumption should be that attackers have a working path to abuse it, so exposure is urgent rather than speculative. For SAP environments, that means the vulnerable UDDI server path should be treated as an active entry point until proven otherwise.
Because the issue is SQL injection, the immediate concern is server-side command execution against the database layer through application input that is not safely constrained. That is why the right question is not only whether the CVE is real, but whether the affected SAP instance is reachable, internet-exposed, and still accepting the vulnerable request pattern.
For patch-and-response playbooks, use the same prioritisation discipline you would apply to an actively exploited vulnerability: confirm the asset, confirm the exposure path, then confirm whether exploitation could have been attempted before you decide the work is complete.
How to confirm exposure and reduce the attack window
Start by identifying every SAP NetWeaver J2EE system that contains the UDDI server component and determine whether it is reachable from untrusted networks. If the vulnerable surface is present, treat the instance as exposed until the vendor advisory and the CISA KEV entry have been checked for the exact remediation path and any required compensating controls.
If immediate patching is delayed, reduce the attack window by narrowing network reachability, removing unnecessary exposure, and monitoring for requests and database activity that should not be happening on that service. For SAP estates, the defensive baseline should include the SQL Injection Prevention Guide approach to query safety, plus the SAP-specific hardening and logging discipline described in the SAP Identity and Access Security Guide.
When you need broader programme context for triage, the Vulnerability Management Guide is the right model for turning a KEV-listed issue into a concrete remediation queue, exception record, and verification step.
What to check for after suspected exploitation
For exploited SQL injection, the main follow-on question is whether the attack stopped at data access or progressed into database manipulation, account creation, or application-level persistence. Review database audit trails, application logs, web logs, and any security telemetry that can show suspicious SQL patterns, unexpected administrative actions, or anomalous use of the UDDI server path.
If the application or database account used by the service has broader privileges than it should, the blast radius can be much larger than the original vulnerability suggests. That makes privilege review part of the incident response, not a separate governance task, because an injected query often inherits whatever permissions the application context already had.
Where the question is really about whether you can trust the platform after exploitation, the most useful reference point is database hardening and post-incident verification in the Database Security Guide, especially around auditing, account scope, and database activity monitoring.
Risk and Threat Considerations
SQL injection is dangerous here because it turns an application input flaw into direct database abuse, which can expose data, alter records, or open a path to deeper compromise inside an SAP environment. In a system that supports business-critical processes, even a short exposure window can matter if attackers can reach privileged backend data or application trust relationships.
Failure mechanism: Unvalidated input reaches the database layer through the vulnerable UDDI server path, allowing an attacker to execute crafted SQL commands with the permissions of the application context.
Impact: The attacker may be able to read, modify, or delete data, manipulate business records, or use the compromised service path as a foothold for broader SAP abuse and follow-on persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes urgent prioritisation and verification central. |
| Recommendation — Prioritise, remediate, and verify the SAP exposure as a high-risk vulnerable asset. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about an exploited vulnerability and required remediation urgency. |
| AU-6 — Audit Review, Analysis, and Reporting | Suspected exploitation requires log review and activity correlation. | |
| Recommendation — Track, remediate, and validate the SQL injection flaw on the affected SAP system. Review application and database logs for evidence of exploitation and follow-on activity. | ||
| OWASP ASVS | V8 — Authorization | SQL injection becomes materially worse when application privileges exceed need. |
| V15 — Secure Coding and Architecture | SQL injection is a core application-architecture failure affecting input handling and query construction. | |
| Recommendation — Constrain backend permissions so injected queries cannot exceed the application's required access. Use parameterised query patterns and safe data access design to eliminate injectable SQL paths. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed SAP SQL injection as an exposure-and-verification problem first, not only a patching problem. Confirm whether the instance is reachable, whether the vulnerable component is present, and whether logs show any sign of use before or after remediation.
What to verify: Validate that remediation actually removes the vulnerable request path or blocks it at the effective boundary, and that the SAP service account cannot perform more database activity than the application truly needs. If you cannot confirm that, assume residual risk remains.
Decision rule: If patching must wait, lower exposure immediately and escalate monitoring, because a KEV-listed SQL injection should be handled as an active exploitation candidate rather than a routine backlog item.
Practitioner takeaway: For exploited SAP SQL injection, the key judgement is whether you have reduced both the vulnerability and the reachable blast radius, because fixing one without the other leaves the environment meaningfully exposed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org