SAP Note 3758657: Scheduling Authorization Gap, SAP MII (CVE-2026-44765)

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

Reported to SAP by an external researcher and fixed by SAP. This document describes the defect and the correction as they appear in the shipped code.

At a glance

Summary

The shift scheduling servlet in the SAP MII runtime, part of the Energy Management functions, exposed create, read, update and delete operations over HTTP with no server side authorization check, and was not bound to the web module’s authentication filter. A remote caller reaching those URLs could retrieve, create, modify or delete shift patterns and shift schedules. The August 2026 patch binds the servlet to the authentication filter and adds a permission check in front of every operation, keyed to a UME action that already existed but had only ever decided which buttons the browser drew.

The same code change applies the same treatment to the cost and tariff servlet in the same package. SAP tracks that half separately as CVE-2026-44764 under SAP Note 3758910, and it is described in a companion advisory rather than here.

Affected products and versions

SAP MII releases XMII 15.4 and XMII 15.5, per SAP Note 3758657.

The affected class lives in the runtime software component XMII, delivered in the software component archive XMII02, web module sap.com~xapps~xmii~web of the xapps~xmii~ear application. The administration software component MII_ADMIN (archive MIIADMIN02) does not contain it.

The builds compared here are XMII 15.5 SP2 patch 0 (pr_updateversion MII1552V.05080417, keycounter 1000.15.5.2.0.20250508041720) against XMII 15.5 SP2 patch 13 (pr_updateversion MII1552P.07310816, keycounter 1000.15.5.2.13.20260731081708, build 2026-07-31). Patch 13 is where the correction was observed, not necessarily the first level carrying it; SAP Note 3758657 is authoritative. Systems that never activated the Energy Management functions are still exposed, because the servlet is mapped unconditionally.

Technical detail

Entry point. com.sap.xmii.servlet.ShiftServlet is mapped to /XMII/EMAShift/* (web.xml lines 674-677, post-patch tree; unchanged by the patch). It overrides HttpServlet.service() rather than doGet/doPost, so one handler accepts every HTTP verb, and it branches on a Mode request parameter into eleven private handler methods covering shift patterns and shift schedules.

Two controls were absent, at different layers. The first is authentication. This module declares no <security-constraint> at all; authentication is done by a servlet filter, com.sap.xmii.system.SecurityFilter, declared as XMII Filter (web.xml lines 15-18), which resolves the caller through UME, builds the MII User object into the session, and forces a login or returns 401 when there is none. In the pre-patch descriptor that filter is mapped to thirty servlets, including ChartServlet, ReportServlet and Illuminator, but not to ShiftServlet. Requests to that path reached service() with no MII session.

The second is authorization. The servlet did not resolve the calling user or consult any permission before dispatching. The convention in the same package is explicit, for instance ReportServlet line 37:

if (!SystemPermissionManager.hasPermission("ReportServlet", user)) {

Pre-patch ShiftServlet.service() (lines 54 to 120) has no equivalent, and the only session reference in the file is the deleteSession call in its finally block at line 118.

Input and path to the sink. Each handler reads its parameters straight off the request: a pattern name, a description and a JSON list of shift schedules deserialized with Gson for create and update, and a numeric identifier for the delete modes. It then calls the business manager: handleCreatePattern (pre-patch lines 142 to 174) ends in ShiftPatternManager.createPatternSchedule(sp), and handleDeleteShiftPattern (lines 225 to 233) in ShiftPatternManager.deleteShiftPatternById(...). Those managers and their DAOs persist to the MII shift tables and hold no permission logic of their own: searching for hasPermission, SystemPermissionManager, UserSecurityHelper and UMEPermission across com/sap/xmii/shift/** returns nothing in either tree, and diff -rq of that package reports zero differing files. The servlet was the only possible gate.

The control existed but was never enforced. The UME action EnergyShiftPattern is declared pre-patch as EMA_SHIFT_PATTERN in com/sap/xmii/Illuminator/gui/common/Permissions.java line 135, byte identical in both trees, and was consulted in exactly one place: the UI hint method in ProductionEventServlet that evaluates read, write and delete at lines 846, 849 and 852 and reads the three results back to the browser so it knows which buttons to render. That is a client side control; it never stood between a request and a write.

A note on the word “scheduling”. The CVE text refers to scheduling functions, which will send administrators to the MII job scheduler. That subsystem’s authorization behaviour did not change and was already gated: CronBean carries @PermissionCheck(name = "Scheduler", ...) and ScheduleEditor annotations, and the Illuminator scheduler services are gated one level up in ServiceManager.checkPermissions line 95, which rejects a null user outright and then calls SystemPermissionManager.hasPermission(serviceName, user). This CVE concerns plant shift scheduling, not the job scheduler.

What the patch changes

1. The servlet is placed behind the authentication filter, by a filter mapping added to the module web.xml (diff/01-web-xml-securityfilter-mapping.diff, new lines 175-178):

+  <filter-mapping>
+    <filter-name>XMII Filter</filter-name>
+    <servlet-name>ShiftServlet</servlet-name>
+  </filter-mapping>

with a matching block for CostServlet in the same hunk, belonging to CVE-2026-44764. This removes unauthenticated reachability and makes a User object available to the second half of the fix.

2. Every operation is gated (diff/02-shiftservlet-dispatcher.diff):

+        final User user = SessionHandler.getUser(req);
         ...
             if (sMode.equalsIgnoreCase(<create operation>)) {
+                UserSecurityHelper.checkShiftReadWriteServiceUser(user);
                 this.handleCreatePattern(req, res, os);

All eleven modes are covered: six read modes require EnergyShiftPattern/read, two create and update modes require read and write together, three delete modes require delete. The file grows from 391 to 405 lines and the whole delta is two imports, the User lookup at line 68, and the eleven guard calls.

3. Six check methods are added to com/sap/xmii/xacute/common/UserSecurityHelper.java at lines 191 to 225 (diff/04-usersecurityhelper-new-checks.diff), three keyed to EnergyShiftPattern and three keyed to EnergyTariff for the companion issue. The diff against the pre-patch class is purely additive:

+    public static void checkShiftReadServiceUser(final User user) throws UserSecurityException {
+        if (!SystemPermissionManager.hasPermission("EnergyShiftPattern", "read", user)) {
+            throw new UserSecurityException("USER_DOES_NOT_HAVE_SERVICE", user.getName(), "EnergyShiftPattern");

SystemPermissionManager.hasPermission(action, access, user) delegates to user.hasPermission(new UMEPermissionActionManager(action, access)) (SystemPermissionManager.java:19-24), the primitive the job scheduler has always used, and UserSecurityException is caught by the servlet’s outer catch (Throwable) and turned into an error response before any manager or DAO call runs. The manager and DAO layers were not touched.

Verification for defenders

Confirm the patch level. Check the XMII component level in NetWeaver Administrator under System Information, or on the MII About screen, against the fixed level named in Note 3758657. The fixed archive analysed here reports 15.5 SP2 patch 13, MII1552P.07310816; the vulnerable baseline reports patch 0, MII1552V.05080417. MII_ADMIN is not an indicator for this CVE.

Confirm the descriptor. This is the strongest single check and needs no class inspection. In the deployed sap.com/xapps~xmii~ear application, open WEB-INF/web.xml of the xapps~xmii~web module and confirm a <filter-mapping> entry binds XMII Filter to servlet name ShiftServlet. If it is absent while ChartServlet and ReportServlet have theirs, the system is running pre-patch code whatever a version string says.

Confirm the class signature, where class inspection is available in-house. ShiftServlet.class should reference the UserSecurityHelper methods checkShiftReadServiceUser, checkShiftReadWriteServiceUser and checkShiftReadWriteDeleteServiceUser, all of which UserSecurityHelper.class should define alongside three checkShiftTarrif* siblings. The misspelling “Tarrif” is SAP’s.

Review the UME action. This is the step most likely to be skipped. In User Management, list the roles and groups holding EnergyShiftPattern at read, write and delete. That action was cosmetic until this patch, so it may have been granted generously, or to nobody, and both directions now matter: over-assignment leaves users able to change shift schedules against a check that finally works, under-assignment breaks the Energy Management screens, since even the read modes now require the read action. Pare write and delete down to the shift administrators, and confirm separately that the unrelated Scheduler and ScheduleEditor actions are held only by job scheduler administrators. Review EnergyTariff at the same time, for the companion issue.

Check reachability. Confirm whether /XMII/EMAShift/ is reachable from outside the plant network through a reverse proxy or Web Dispatcher profile. Pre-patch, network exposure of that path translated directly into exposure of the functions.

Detection

Evidence is thin: neither the servlet nor the managers write an audit record. In the AS Java HTTP access log, look for requests whose path begins /XMII/EMAShift/ and correlate them with the accounts holding EnergyShiftPattern write or delete today. Pre-patch such a request carried no authenticated MII session, so requests with no session cookie, from sources that are not Energy Management client machines, or outside the hours those screens are used, are the interesting ones. The Mode value reaches the access log only when sent as a query parameter, since the servlet reads it through WebUtil.getParameter, which also accepts a form body; the servlet does log it at debug level as Processing Mode [<value>].

On a patched system a denied request produces Shift Service Error in the MII log with a USER_DOES_NOT_HAVE_SERVICE message naming the user; repeated occurrences mean either a role gap or probing. A request arriving with no session produces a NullPointerException from the same place instead, because SessionHandler.getUser returns null without a session (SessionHandler.java:329-335) and the new check dereferences it. That still fails closed before any write and is a distinct signature.

Row level change timestamps on the shift pattern and shift schedule tables are the only durable record of a change made through this path.

References

• SAP Security Note 3758657: https://me.sap.com/notes/3758657
• CVE-2026-44765
• Companion issue fixed by the same code change but tracked separately: SAP Security Note 3758910, CVE-2026-44764, covering the cost and tariff servlet: https://me.sap.com/notes/3758910
• SAP Security Patch Day, August 2026, https://url.sap/sapsecuritypatchday
• CWE-862, Missing Authorization

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.