The scale of this month's release
SAP's August 2026 Security Patch Day, released August 11, included 29 Security Notes: 25 new and 4 updated from prior cycles. Of those, 4 carry SAP's HotNews classification, the highest severity tier the company assigns, alongside 9 rated High Priority, 13 Medium, and 2 Low. Onapsis Research Labs, a third-party firm that specializes in SAP and Oracle application security, contributed research behind 14 of the disclosed vulnerabilities across 11 notes plus one correction note, a share large enough to shape how this month's release should be read by any team relying on SAP's own bulletin as the sole source of truth.
That level of external contribution is worth noting on its own. A meaningful share of the vulnerabilities SAP customers now patch each month originate from dedicated research firms rather than SAP's internal security team alone, which is a useful reminder for any organization deciding how much weight to put on third-party SAP security tooling versus relying on the vendor's own release notes for risk prioritization. Teams that only track SAP's official monthly bulletin without pulling in independent research summaries are, in effect, reading half the story about how these vulnerabilities were found and how urgently they should be treated.
The four HotNews vulnerabilities
SAP Note #3765948 addresses CVE-2026-44772, a code injection flaw in SAP Manufacturing Integration and Intelligence rated CVSS 9.9, described as enabling execution of arbitrary commands on the underlying host with impact extending beyond the vulnerable component itself, in effect a path to total infrastructure compromise. A related note, #3758900, covers CVE-2026-44758, a server-side template injection and SSRF issue also in SAP MII, rated 9.1, though it requires elevated privileges to exploit, which somewhat limits the blast radius compared with its unauthenticated counterpart in the same product.
The other two HotNews notes hit the ABAP layer directly. Note #3747367 covers CVE-2026-44747, a memory corruption vulnerability in SAP NetWeaver Application Server ABAP rated 9.9, an updated note originally issued in July's cycle. Note #3714806 addresses CVE-2026-34265, a separate memory corruption flaw in the ABAP Platform's Application Server rated 9.8, which SAP says could disclose sensitive system information or crash the system outright. Between the two, nearly every organization running an SAP NetWeaver or ABAP Platform landscape has exposure somewhere in this pair, regardless of which specific business modules sit on top of the affected kernel.
Why SAP MII is the vulnerability to watch
SAP Manufacturing Integration and Intelligence is the layer that connects shop-floor systems, production planning, and plant historians into the broader SAP environment, which makes it a comparatively unusual target for a maximum-severity code injection bug. Six separate vulnerabilities in MII were addressed this cycle, and the two HotNews entries specifically threaten the integration point between IT and operational technology that most manufacturers spent the last several years trying to segment more carefully, not less.
For CTOs overseeing manufacturing operations, this note deserves its own escalation path separate from the standard ABAP patching workflow, because the teams that own MII, typically plant IT or OT integration groups, are frequently not the same teams that manage core SAP Basis patching. A HotNews vulnerability that falls into the gap between those two teams' patch calendars is exactly the kind of finding that sits unpatched for months in real environments, and the fix here is organizational as much as technical: someone needs explicit ownership of MII patching who is not waiting on the Basis team's normal SAP maintenance window.
The ABAP kernel flaw affects everyone, regardless of module
CVE-2026-44747's presence in the NetWeaver Application Server ABAP kernel matters because that kernel underlies essentially every SAP deployment, independent of which specific business applications, ERP, CRM, or otherwise, an organization runs on top of it. A memory corruption bug at this layer does not respect module boundaries, and the fact that this note was originally issued in July and updated again in August suggests SAP found the initial fix incomplete or discovered additional attack surface after the first release.
That update pattern is a useful signal in itself: when SAP revises a HotNews note within a month of its original release, it is worth re-verifying that the patch applied in the first cycle actually closed the gap, rather than assuming the July ticket can stay marked complete. Security teams tracking SAP notes by CVE number rather than by note number can miss these silent scope expansions if they are not cross-checking release-note changelog details each cycle, and a note that was closed out in a July compliance report may need to be reopened this month.
Patching is necessary but not sufficient
A recurring theme in this cycle's guidance from both SAP and Onapsis is that the binary patch is only the first step. Several of the affected components require follow-up configuration work: enabling Secure Transformer settings, rotating credential keys that may have been exposed prior to patching, rebuilding affected components rather than simply overlaying the patch, and reviewing authorization assignments that could have been altered if a HotNews flaw was already exploited before the fix landed.
One assessment of this cycle summarized the operational reality bluntly: "This is not a single-platform patch cycle. Basis, manufacturing/OT, commerce, development, cloud, and BI owners all have work to do." That framing captures why SAP patch days increasingly function less like a single IT ticket and more like a coordinated, cross-functional remediation project, one that needs an owner above the individual module teams to make sure nothing falls through the gaps between them.
