SAP Note 3781137: User Data Disclosure in SAP MII (CVE-2026-58244)

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

At a glance

Summary

A runtime servlet in SAP Manufacturing Integration and Intelligence (SAP MII) returned the names of every user account and every role held in the connected User Management Engine (UME) to any caller with a valid MII session. The two request modes that produce those lists carried no authorization check, and the servlet is not restricted to any role by the web deployment descriptor, so a low privileged authenticated account could enumerate the whole directory. The correction adds a UME permission check in front of both handlers and ships a new UME action that grants it.

Affected products and versions

The vulnerable code is in the MII runtime software component XMII, delivered in the software component archive XMII02, in the sap.com~xapps~xmii~web module of the xapps~xmii~ear application. The levels examined, taken from META-INF/SAP_MANIFEST.MF of the delivered archives:

The administration component contains no copy of the affected servlet and no reference to the new permission; it is listed because the patch train ships both components together, not because it carries this correction. SAP Note 3781137 is authoritative for the full list of affected releases and patch levels. The vulnerability was reported to SAP by an external researcher, who is credited in the note.

Technical detail

Entry point

com.sap.xmii.servlet.CECatalog is registered in the web deployment descriptor of the MII web module as servlet CECatalog (declaration at lines 440-443) with URL pattern /CECatalog (mapping at lines 586-589), under context root XMII. The class extends HttpServlet (declaration at line 115) and overrides service() rather than doGet() or doPost(), so it answers both verbs. The descriptor contains no security-constraint and no auth-constraint for this pattern; a grep for security-constraint over the whole descriptor returns nothing. The only gate in front of the servlet is the filter XMII Filter, implemented by com.sap.xmii.system.SecurityFilter (declared at lines 15-18) and mapped to the servlet by name (lines 95-98), which establishes or requires an authenticated MII session and then passes the request down the chain. It evaluates no MII permission. Anyone who can log on to MII at all can reach the servlet, which is the basis for SAP’s PR:L metric.

Input under attacker control

service() (line 142) reads the request parameter Mode and dispatches on its value at lines 214-219. Lookup runs through com.sap.lhcommon.util.WebUtil.getParameter() (lines 206-218), which compares parameter names case insensitively, and the dispatch uses equalsIgnoreCase, so neither the name nor the value is case sensitive. Two values are relevant: UserList routes to handleGetUsersList() and RoleList routes to handleGetRolesList(). A second parameter, Mask, is read inside the handlers and is optional.

Path to the sink

Each handler passes the mask straight to the UME facade:

final String mask = WebUtil.getParameter(req, "Mask");
final List<String> names = UMEManager.getInstance().filterUserNames(mask);

*(CECatalog.java:1277-1285, pre-patch; the sibling at :1306-1314 calls filterRoleNames)*

com.sap.xmii.system.UMEManager.filterUserNames() (lines 440-459) obtains an IUserSearchFilter from UMFactory.getUserFactory(), applies the mask to the unique name only inside if (!StringUtil.isNullOrEmpty(mask)), runs userfact.searchUsers(searchFilter), and collects user.getUniqueName() for every hit. filterRoleNames() (lines 461-480) does the same through UMFactory.getRoleFactory() and searchRoles(). Because the mask is applied conditionally, a request that omits it produces an unrestricted search returning the entire directory rather than a filtered subset. The handler serialises the collected names into a single column dataset named Objectname, one row per account, and streams it to the caller as XML by default, or as JSON when the request asks for it, which is what the shipped user interface does.

The missing control

Neither handler consulted any authorization facility before enumerating, and the dispatcher in service() performs no check either, so the per handler check is the only possible gate on this path. This is notable because the same class already used MII permission checks extensively: the SSCE handlers in the same file call user.hasPermission(new UMEPermissionActionManager("SSCE", "read")) ten times over at lines 1100-1127, and lines 1218-1227 use the equivalent static form SystemPermissionManager.hasPermission("SSCE_MIIContent_Display", "access", user) before returning content. The user and role enumeration handlers did not participate in that scheme.

The data returned is the account inventory of whatever UME data source the AS Java is configured against, which in a typical landscape is an ABAP system or a corporate directory shared with other applications. Account names support password spraying and targeted phishing, and the role list exposes the naming and structure of the privilege model, including custom roles, which tells an attacker which accounts are worth pursuing.

What the patch changes

Both handlers now resolve the calling user and require a new UME permission before doing any work. The added block is identical in both, at new lines 1278-1281 and 1311-1314, and the complete diff of the file is those two hunks and nothing else:

private void handleGetUsersList(...) {
    final User user = SessionHandler.getUser(req);
    if (!user.hasPermission(new UMEPermissionActionManager("UserAccess", "access"))) {
        throw new UserSecurityException("USER_DOES_NOT_HAVE_SERVICE", user.getName(), "UserAccess");
    }
    ...

The permission name is also added as a constant to com.sap.xmii.Illuminator.gui.common.Permissions at line 140:

public static final String USER_ACCESS = "UserAccess";

The string UserAccess does not appear anywhere in the pre-patch runtime tree.

The permission is not usable until it can be granted, so the patch also adds an action to the UME action definitions shipped in DEPLOYARCHIVES/xapps~xmii~umeactions.sda:

<ACTION NAME="XMII_ServerUserAccess">
    <DESCRIPTION LOCALE="en" VALUE="Acess Permission for users maintained on server" />
    <PERMISSION CLASS="com.sap.xmii.Illuminator.security.UMEPermissionActionManager"
                NAME="UserAccess" VALUE="access" />
</ACTION>

That is the only change to the action file, which grows from 291 to 292 actions and keeps its 11 roles. No shipped role definition was amended to include the new action. Of the eleven roles delivered in that file, only SAP_XMII_Super_Administrator covers the new permission, and it does so indirectly because it is assigned the wildcard action XMII_Full_Access, defined as NAME="*" VALUE="*". SAP_XMII_Administrator, SAP_XMII_Developer, SAP_XMII_Read_Only, SAP_XMII_User and the rest list named actions only, so they lose access to these two modes until an administrator grants XMII_ServerUserAccess deliberately. The sink itself, UMEManager, is unchanged.

Verification for defenders

Confirm the component level. In SAP NetWeaver Administrator, open System Information and review the component list, or read the component versions in the MII System Information screen. The runtime component XMII must be at 15.5 SP2 patch level 13 or higher for the release line examined here; take the target level from SAP Note 3781137 for any other release. The patch level is also readable in META-INF/SAP_MANIFEST.MF of the deployed SCA, in the fields pr_softwarecomponentname, pr_release, pr_servicelevel and pr_patchlevel.

Confirm the new action exists. In NetWeaver Administrator, Identity Management, search the UME actions of the MII application for XMII_ServerUserAccess. Its presence proves the xapps~xmii~umeactions archive was redeployed with the application. If the classes were updated but the action is absent, the permission cannot be granted to anyone and the two modes are closed to every account except holders of the wildcard action.

Review who holds it. List the roles and groups that have XMII_ServerUserAccess assigned and the users mapped to them; only accounts that maintain object security in the MII Workbench need it. Also review who holds XMII_Full_Access through SAP_XMII_Super_Administrator, since that wildcard covers the new permission implicitly.

Confirm the gate behaves. The two modes back the user and role picker in the MII object security maintenance screens, which the shipped scripts maintainSecurity.js and maintainTemplatesSecurity.js drive from a search field, so the test is a normal use of the product and needs no crafted request. Sign in with an account that holds no MII administration role, open the security maintenance dialog in the Workbench, and search for a user: on a corrected system the search returns an error instead of a list, while an account holding XMII_ServerUserAccess still gets results. Plan this before rollout, because the picker stops working for any administrator whose role was never granted the new action.

If patching must wait. Confirm that the /XMII context is reachable only from the plant and office networks through the Web Dispatcher or reverse proxy, and review the population that can log on to MII at all, since every one of those accounts could read the directory before the fix.

Detection

Exploitation before the patch leaves no dedicated audit record. MII writes no security log entry for these two modes, and the handlers log only on failure. The available evidence is the HTTP request log of the AS Java, the ICM log, or the Web Dispatcher and reverse proxy logs in front of it, if query strings are recorded there. Search those logs for requests to /XMII/CECatalog carrying a Mode value of UserList or RoleList, case insensitively, since the application matches both the parameter name and its value that way.

Legitimate traffic to these modes has a recognisable shape: it follows a page load of the object security maintenance screens, it always carries a non empty mask because the user interface sends what was typed into the search field, and it comes from accounts that administer MII content. Worth investigating are requests with no mask or a mask short enough to match most of the directory, requests repeated in rapid succession, requests from a session that never loaded the maintenance screen, and requests from accounts with no content administration duties. Response size is a useful secondary signal, since a full enumeration returns one Objectname row per account and is far larger than a search field produces.

After the patch, denied attempts are visible on the server. The rejection throws UserSecurityException, which propagates out of the handler into the catch block in service() at lines 332-335, and that block logs the throwable with PermissionCheck Service Error before returning an error document to the caller. The default trace of the AS Java therefore carries an error entry from com.sap.xmii.servlet.CECatalog containing the resolved text of message key USER_DOES_NOT_HAVE_SERVICE with the caller’s user name and the service name UserAccess. Repeated entries of that kind from one account are either a genuine authorization gap to fix or an account probing the endpoint, and both are worth a look.

References

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

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.