SAP Note 3758900: Code Injection in SAP MII (CVE-2026-44758)

SAP Security Note 3758900 | CVSS 3.0 base score 9.1 (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) | Component MFG-MII | SAP Security Patch Day, 11 August 2026

At a glance

Summary

SAP Manufacturing Integration and Intelligence (SAP MII) shipped an HTTP endpoint, /XMII/IllumXSLTServlet, that accepted an XSLT stylesheet directly in a request parameter, compiled it, and executed it on the server. Nothing between compilation and execution constrained what the stylesheet was permitted to do, leaving the underlying XSLT processor’s extension-function facilities available to whatever stylesheet was supplied. An authenticated user holding the IllumXSLTServlet permission could therefore run code of their choosing in the application server’s context. SAP’s correction removes the endpoint outright rather than hardening it.

Affected products and versions

The vulnerable code is in the MII runtime software component XMII, delivered in the software component archive XMII02, web module sap.com~xapps~xmii~web.war. That module is deployed at context root XMII (xapps~xmii~ear/META-INF/application.xml:11-16), placing the endpoint at /XMII/IllumXSLTServlet.

The archive manifests give the exact build boundary of the two levels examined:

Only these two levels were on hand, so patch 13 is where the correction was observed rather than necessarily the first level carrying it. SAP Note 3758900 is authoritative for the full list of affected releases and required patch levels.

The administration software component MII_ADMIN (archive MIIADMIN02) moves in the same patch train, from 15.5 SP2 patch 0 to patch 6, but carries none of the vulnerable code. It contributes only the user interface for a separate control described below.

Technical detail

Entry point. The pre-patch deployment descriptor sap.com~xapps~xmii~web/WEB-INF/web.xml declares the servlet at lines 407-412, maps /IllumXSLTServlet to it at lines 538-541, and routes it through the XMII Filter at lines 59-62. That filter is com.sap.xmii.system.SecurityFilter, and since the web application declares no security-constraint and no login-config anywhere in the descriptor, it performs all authentication. SecurityFilter.doFilter passes a request through only if a session already exists, if credentials are supplied on the request itself, or after a UME login (SecurityFilter.java:65-173). The path is not in the unprotected list, which holds only /XMII/error.jsp, /XMII/Illuminator?service=Logout and /XMII/CMSLogicEditor/ (SecurityFilter.java:55-58). The endpoint is therefore reachable only by an authenticated principal.

Two properties of that gate matter. The filter accepts credentials as ordinary request parameters (SecurityFilter.java:179), so no pre-established browser session is needed; and its cross-site request forgery check covers only request URIs beginning /XMII/Illuminator (SecurityFilter.java:84, :169), a prefix that /XMII/IllumXSLTServlet does not match, leaving the endpoint outside that protection.

Inside the servlet, a second gate applies. SystemPermissionManager.hasPermission("IllumXSLTServlet", user) is evaluated before anything else, and an unauthorised caller is rejected with an UNAUTHORIZED_SERVICE_ACCESS exception (IllumXSLTServlet.java:53-57). That check resolves to a UME permission lookup (SystemPermissionManager.java:19-25), so exploitation also requires a role granting this specific permission. This matches SAP’s PR:H rating.

Input under attacker control. Past both gates, the servlet reads four request parameters:

final String strURL       = WebUtil.getParameter(req, "URL");
final String strXMLSource = WebUtil.getParameter(req, "XMLSource");
final String strTransform = WebUtil.getParameter(req, "Transform");
final String strXSLSource = WebUtil.getParameter(req, "XSLSource");

IllumXSLTServlet.java:60-63

WebUtil.getParameter is a case-insensitive lookup returning request.getParameter(key) unmodified, with no filtering of any kind (WebUtil.java:206-218). XSLSource carries raw stylesheet markup; Transform names a location the server fetches a stylesheet from on the caller’s behalf; XMLSource and URL supply the input document.

Path to the sink. The stylesheet is parsed into a DOM and compiled without inspection:

final TransformerFactory tFactory = FactoryManager.createTransformerFactory();
final Transformer processor = tFactory.newTransformer(new DOMSource(xsldoc));

IllumXSLTServlet.java:93-94

and then executed, with its output streamed straight into the HTTP response:

processor.transform(ds, new StreamResult((OutputStream)os));

IllumXSLTServlet.java:113

Nothing between line 94 and line 113 constrains what the stylesheet may do. The only check present is a virus-scanner call at lines 95-108, and it is no barrier: it runs after the Transformer already exists, its exceptions are caught and only logged at warning level, and it never prevents the transform() call. It is inert besides. VirusScanner.validateFileExtensions derives a file extension from its argument and skips its whole body when that extension is empty (VirusScanner.java:92-112, guard at :97), but the servlet passes it processor.getOutputProperty("media-type") (IllumXSLTServlet.java:100), a media type such as text/xml from which no extension is derived.

The missing control. The decisive omission is that no restriction was placed on stylesheet capability. The JAXP secure-processing feature, which suppresses stylesheet-driven Java extension functions, was not in effect on the transformer instance this servlet used, and SAP’s own XML hardener facade, which the same helper class applies to its document-builder path (FactoryManager.java:240), is not applied on the transformer path. The XSLT implementation selected here is Apache Xalan, named as a literal in the same class (FactoryManager.java:196). With secure processing off, Xalan permits a stylesheet to bind a namespace to a Java class and call its methods as extension functions. That documented processor behaviour, not any SAP code, is what turns a compiled stylesheet into arbitrary execution, and it is why the correction removes the endpoint rather than attempting to filter the stylesheet.

What the patch changes

The correction removes the feature rather than hardening it, in two coordinated places.

First, the servlet is emptied. IllumXSLTServlet.java drops from 133 lines to 30, every import for Transformer, TransformerFactory, DocumentBuilder, DOMSource, StreamResult, XMLHandler, VirusScanner and SystemPermissionManager is gone, and the request handler is now a no-op:

public void service(final HttpServletRequest req, final HttpServletResponse res) throws ServletException, IOException {
}

IllumXSLTServlet.java:24-25 (post-patch)

The class still ships, inside sap.com~xapps~xmii~classes~xmii_classes_deploy.jar, but can no longer parse, compile or execute anything.

Second, the route is removed. All three IllumXSLTServlet blocks in web.xml are wrapped in XML comments: the filter mapping (lines 59-62), the servlet declaration (415-420), and the servlet mapping carrying <url-pattern>/IllumXSLTServlet</url-pattern> (546-549). The container no longer routes the URL.

The same patch train ships a separate and much narrower control that belongs to a different issue, CVE-2026-44772 (SAP Note 3765948): two opt-in system properties, SecureTransformer and AllowedList (SystemProperties.java:106-107, getters at :326 and :330), used by the Illuminator Query and Transaction engine (XMLBuilder.java:475-477, :514, :680) to restrict which host a remote stylesheet may be fetched from. It is a source allowlist for a different code path, it does not govern what a stylesheet may do once compiled, and getBooleanProperty returns false for any unset property (SystemProperties.java:227-234), so it stays off until enabled. The administration component surfaces it as three new labels (IMessageSysConfigComp.java:247-249).

Verification for defenders

1. Confirm the patch level. In NetWeaver Administrator, under system information for deployed components, confirm software component XMII is at the patch level named in SAP Note 3758900 for your release line. On the 15.5 SP2 line examined here that is patch 13 or later (keycounter 1000.15.5.2.13 or higher, keylocation MAIN_MII1552P_C). A component still reporting 1000.15.5.2.0 or MAIN_MII1552V_C carries the vulnerable servlet.

2. Inspect the deployed descriptor. In the deployed sap.com~xapps~xmii~web module, open WEB-INF/web.xml and search for IllumXSLTServlet. On a corrected system the three occurrences are present but enclosed in XML comment markers. Any occurrence outside a comment, in particular a live <url-pattern>/IllumXSLTServlet</url-pattern>, means the endpoint is still routed.

3. Probe the route. Issue a plain GET to /XMII/IllumXSLTServlet with no parameters at all; no stylesheet content is needed and none should be sent. A corrected system has no mapping for the path and returns 404 or the application’s standard not-found handling. A 200 response, an XML document, or an application error originating from the servlet indicates the mapping is still live.

4. Review who holds the permission, on any system still awaiting the patch. The permission the servlet checked is granted by the shipped UME action XMII_IllumXSLTServlet, defined in DEPLOYARCHIVES/xapps~xmii~umeactions.sda. No shipped role assigns that action: of the eleven roles in the delivered actions.xml, only SAP_XMII_Super_Administrator covers it, and only indirectly through the wildcard action XMII_Full_Access (NAME="*" VALUE="*"). In User Management, list any custom role or group that assigns XMII_IllumXSLTServlet, and review who holds SAP_XMII_Super_Administrator. On an unpatched system, removing that action from custom roles removes the reachable population.

5. Check the new configuration surface. In the MII administration System Configuration screen, look for a Transformer Settings section containing Secure Transformer and Allowed List. Its presence is a reliable fingerprint that this support package train is installed. That setting belongs to CVE-2026-44772 rather than to this issue; if the Query or Transaction engine loads stylesheets from remote URLs in this landscape, follow the guidance in that advisory, since the setting ships disabled.

Detection

Exploitation would appear in the HTTP access log of the ICM or web dispatcher as requests to /XMII/IllumXSLTServlet. Entries carrying the parameter names XSLSource, Transform, XMLSource or URL are the clearest indicator, though a stylesheet sent in a POST body leaves no trace in the access log, so their absence proves nothing. After the patch, any request to this path is anomalous by definition, since nothing legitimate routes there.

Rejected attempts by an authenticated user lacking the permission produce a distinctive application log entry, Invalid permission to access service IllumXSLTServlet, under the Illuminator log category. Successful transformations produce no comparable entry, so an absence of errors proves nothing. Because a stylesheet executing extension functions runs inside the server JVM, the more reliable signal is host telemetry: child processes spawned by the Java server process, unexpected outbound connections, or files written outside its normal directories, correlated by timestamp against access log entries for the path.

References

• SAP Security Note 3758900: https://me.sap.com/notes/3758900
• CVE-2026-44758
• SAP Security Patch Day, August 2026

This vulnerability was reported to SAP by an external party credited in SAP’s note. This document describes the vulnerability and the correction as observed in the shipped software.

This advisory summarises publicly relevant facts about an SAP Security Note that SAP has already released, together with an analysis of the shipped correction. It is not a substitute for the note itself; customers should always refer to the original note in the SAP Support Portal for authoritative guidance on affected releases and required patch levels. No exploit code is published. RedRays is an independent SAP security vendor and is not affiliated with SAP SE.