Log4j in SAP Environments

For most engineering teams, Log4Shell remediation meant upgrading a dependency in a build. For SAP teams, the vulnerable library often sat inside vendor-shipped Java components they did not build or maintain, and the correction had to arrive through SAP's own security-note process.

That difference created a separate operational problem. SAP landscapes run finance, logistics, manufacturing, analytics, and integration workloads that cannot always absorb an emergency library change. Teams had to identify which products embedded Log4j, confirm the relevant SAP correction, test it inside conservative change windows, and manage exposure while they waited.

This article explains why SAP environments needed their own Log4j playbook, where the library appeared, what the attack traffic looked like in the first wave, and how remediation works when the vendor owns the component. It also connects that experience to the continuing Log4j CVE stream and the value of runtime visibility into software a customer cannot inspect at source.

Key Takeaways

• SAP customers generally could not patch embedded Log4j by changing a dependency version. Remediation flowed through SAP security notes and product-specific corrections.
• Exposure concentrated in the Java side of SAP landscapes, including SAP BusinessObjects BI, integration components, and third-party add-ons that bundled their own copies.
• Onapsis reported that the initial attack wave was overwhelmingly automated. Its researchers did not observe activity specifically targeting SAP products during that period.
• The riskiest time was the wait between public disclosure and an applicable, tested SAP correction for each affected product.
• Embedded Log4j copies inherit the library's continuing vulnerability stream, so the issue did not end after the 2021 and 2022 patch cycle.

Why the SAP Log4j Problem Was Different

Code You Run but Do Not Own

In a typical Java application, remediating Log4Shell meant updating log4j-core, rebuilding the application, testing it, and deploying the new artifact. The development team owned the dependency and the delivery pipeline.

In an SAP landscape, Log4j often arrived inside a vendor-shipped product component. Customers could operate and configure the software, but they did not own the source, build, or dependency graph. The supported fix came as an SAP correction for each affected product on SAP's release schedule.

Replacing an embedded jar manually could also break supportability or introduce incompatibility. Even when a temporary mitigation was technically possible, teams still needed the vendor's product-specific guidance.

Business-Critical Systems, Conservative Change Windows

SAP systems often support core financial, supply-chain, HR, manufacturing, and analytics processes. Changes move through regression testing, transport controls, dependency checks, and tightly managed production windows.

That cadence collided with a vulnerability that was being scanned and exploited within a day of public disclosure. Emergency change processes could accelerate deployment, but they could not remove the need to verify that a vendor correction worked across interconnected SAP components.

The result was an exposure window, not simply a patch ticket. Teams needed compensating controls and evidence about whether suspicious activity occurred while the correction was being assessed and rolled out.

Where Log4j Lived: SAP BusinessObjects and Beyond

SAP Note 3129883 was the central reference for CVE-2021-44228 across affected SAP products. Teams should verify the note number and its current scope in the SAP Support Portal before publication or remediation. SAP security notes require authorized access, commonly through an S-user or an assigned security role, so public articles cannot reproduce the complete live product list reliably.

Publicly documented areas included:

• SAP BusinessObjects BI platform, where the Java-based application and web tiers drew significant attention from the BI community.
• SAP Business One integration components and related connectors that included Java services or third-party libraries.
• SAP integration and connectivity products where customer-deployed content could carry its own Log4j jar.
• Partner and third-party add-ons that bundled Log4j independently of SAP-delivered components.

The exposure followed the Java footprint of the landscape, not the SAP brand alone. ABAP-only components did not become vulnerable simply because they were part of an SAP estate. Conversely, an add-on outside SAP's central note could still carry an affected library.

That last category is especially important. SAP notes describe SAP-delivered software. They cannot inventory every partner extension, custom Java application, or integration package a customer installed alongside it.

Inventory should therefore combine the SAP note with local evidence. Teams need the product version, deployed Java archives, partner add-ons, custom integrations, and the actual hosts or containers where those components run. A landscape diagram alone is not enough because the same product family may contain different libraries across support packages and optional modules.

What the Attack Traffic Actually Looked Like

Mass Exploitation, Not Targeted Campaigns

Onapsis Research Labs telemetry recorded its first Log4Shell attack on December 10, 2021, less than a day after public disclosure. By December 20, the sensors had seen 3,096 attempts from more than 277 unique hosts and more than 50 payload variants, with most activity automated or bot-driven.

Onapsis also reported roughly 70 malware families or variants exploiting the vulnerability, including Mirai and Elknot. Post-exploitation behavior included cryptocurrency miners and attempts to steal AWS secrets from environment variables.

The nuance matters. Onapsis said it had not observed probing or exploitation specifically targeting SAP products in that initial wave. The risk to SAP landscapes came from internet-facing Java services being swept up in mass scanning, not from evidence that attackers had built a dedicated SAP campaign at that moment.

Automated does not mean harmless. A bot does not need to recognize an SAP product if a vulnerable service responds to the same JNDI payload as any other Java application.

Filters Bent, Then Broke

Attackers quickly moved beyond obvious payload strings. Onapsis observed base64 encoding, mixed letter case, and obfuscation designed to bypass literal string matching at firewalls and web application filters.

That progression showed why perimeter filtering could reduce commodity probes but could not be the only defense. The application still interpreted the content after it passed the filter, and the exploit's important actions occurred inside the Java process.

For exposed SAP Java services, teams needed multiple controls: temporary request filtering, egress restrictions, vendor corrections, review of application and network logs, and monitoring for unexpected runtime behavior.

The SAP Remediation Path: Notes, Windows, and Waiting

Security Notes, Not Library Upgrades

SAP published product corrections through its security-note process, with SAP Note 3129883 serving as the central reference for CVE-2021-44228. Product-specific notes then addressed individual components. Teams should verify the current note and applicability in the SAP Support Portal because access and scope can change.

The practical workflow is to inventory affected components, match them to the current SAP note, apply the relevant product correction, test connected processes, and review logs for unusual activity. SAP's monthly Security Patch Day remains the cadence for ongoing security corrections, though urgent notes can appear outside the regular cycle.

Non-SAP Java applications and partner components may follow a different path. For those systems, use the vendor's guidance or how to patch the Log4j vulnerability rather than assuming an SAP note covers the dependency.

An assumed-breach posture is useful during the wait. Teams should not conclude that a corrected system was never exploited. Review network, application, identity, and host evidence for activity that began before the patch landed.

The Exposure Did Not End in 2022

Any embedded Log4j 2 copy inherits the library's continuing vulnerability stream. New Log4j CVEs were published in 2025 and 2026, including issues involving TLS hostname verification, log injection, malformed XML, malformed JSON, and silent event loss.

The complete Log4j CVE history shows why a one-time 2021 inventory becomes stale. SAP and add-on vendors may need to assess later entries whenever an affected component or execution path appears in their products.

The structural problem remains the same. A team can know that a library exists without knowing whether the affected appender, layout, or function executes inside a production workload. That is where runtime security adds evidence that a version-only inventory cannot provide.

Visibility When the Fix Is on the Vendor's Schedule

Visibility Into Code You Cannot Open

The SAP constraint is clear: the vulnerable library sits inside a vendor component, there may be no source code or build pipeline to inspect, and the correction arrives on someone else's schedule. During that window, the security team needs to know where the component runs and whether its vulnerable code path is active.

Runtime SCA is designed for that constraint. Raven reconstructs dependency relationships and function-level execution from runtime behavior using eBPF-based instrumentation. It does not require source code or build pipeline access.

For an SAP landscape, that helps answer two practical questions. Does the embedded Log4j copy in this Java component actually execute the vulnerable function? Which workloads carry real runtime exposure, and which only contain a dormant library on disk?

Raven reports that function-level runtime reachability can de-prioritize up to 99% of vulnerabilities. The exact reduction will vary by environment, but the goal is useful even without a specific percentage: narrow a landscape-wide Log4j alert to the Java workloads where vulnerable code actually runs.

This is not a substitute for the SAP correction. It is a way to prioritize, investigate, and manage the exposure window until the supported fix is available and deployed. If the vulnerable path executes, the team has evidence to escalate the affected workload. If it never executes, the finding can be treated differently from an internet-facing service actively reaching the code.

Log4j in SAP environments was never a one-patch event. It was a visibility problem inside vendor-shipped Java components, compounded by conservative change windows and a vulnerability stream that continued after 2021.

The teams best positioned to manage the risk know which components carry the library, which of those actually execute vulnerable code, and how to treat the wait for each SAP correction as an exposure window rather than dead time.

See which embedded libraries actually execute across your SAP landscape, without source code access.