CVE-2026-7891: Mendix System.User XPath Rules Can Expose Accounts

Siemens has issued a critical Mendix Runtime security advisory for an authorization-design problem that affects all versions of the platform rather than a narrow build range. Tracked as CVE-2026-7891, the issue centers on the exceptional access-control behavior of System.User: platform-enforced permissions can apply to System.User specializations even where a developer’s entity-level XPath constraints appear to deny access. The practical danger is severe—an application can expose user records or enable privilege escalation when its authorization model relies on restrictions that the runtime does not ultimately enforce. Siemens ProductCERT rates the issue 9.1 out of 10 under both CVSS v3.1 and CVSS v4.0.
For Windows-based enterprise teams running Mendix development environments, self-managed Mendix Runtime deployments, or low-code applications that integrate with Active Directory, Microsoft Entra ID, and line-of-business systems, this is not a conventional “install the patch” bulletin. Siemens’ remediation is a security-model review. Developers must identify applications that use a specialization of System.User—commonly Administration.Account—and move restrictive logic away from XPath-only controls toward deliberately scoped App Security role-management settings. The vendor’s guidance is explicit: built-in System.User access rules cannot be overridden or restricted by access rules placed on a specialization.

Overview: A Critical Vulnerability in the Authorization Model​

Siemens published advisory SSA-814963, “Insecure Inherited Permission in Mendix,” on July 14, 2026. It identifies Mendix Runtime as affected across all versions and describes a documentation gap that left application builders without adequate guidance about the special handling of System.User. The advisory states that this gap can lead to overly permissive rules, unintended exposure of sensitive user data, and privilege escalation in deployed Mendix applications.
This framing matters. The vulnerability is not simply that a toggle was set incorrectly in a sample app. Instead, it involves a mismatch between a developer’s reasonable interpretation of entity security and the runtime’s platform-enforced behavior for a foundational identity entity.
In ordinary Mendix domain-model design, entity access rules specify whether a module role can create or delete objects and read or write an entity’s attributes and associations. XPath constraints can then reduce the set of objects to which the rule applies. Mendix describes these rules as additive: when multiple applicable rules grant rights to the same module role, those rights are combined. That model is understandable for conventional business entities such as orders, invoices, cases, or assets.
System.User is different.
Mendix applications include a System module automatically, and that module provides essential user and user-role entities. Mendix’s security documentation also notes that all application users and accounts are specializations of System.User, with Administration.Account a common default specialization. Because user objects underpin authentication, role assignment, administration, and user lifecycle operations, the platform gives them special treatment.
The vulnerability exists because that special treatment was insufficiently surfaced in access-rule documentation. An app developer could build a security model that appears constrained in Studio Pro, pass a superficial review, and still produce broader access than expected at runtime.

---

What Makes System.User Special​

The updated Mendix documentation now articulates the behavior at the center of CVE-2026-7891 in unusually direct terms. System.User has built-in, platform-enforced access rules. Those rules grant access to its attributes when the requesting user’s role is configured to manage the role assigned to the target user object. Critically, the rules also apply to System.User specializations and cannot be overridden or narrowed through access rules defined on the specialization.
That is a fundamental exception to the normal mental model of inherited entities and access control.

The Normal Rule: Specializations Need Explicit Security​

Mendix ordinarily treats specialization security as explicit. In general, access rules from a generalized entity are not simply inherited as a limiting security boundary by the specialized entity. The platform documentation warns that when a specialization has access rules, developers must ensure all required XPath conditions are applied because generalization-level XPath constraints do not automatically limit specialized objects.
That behavior already requires care. A team might create a business entity that specializes another entity, add a fresh access rule, and unintentionally lose a constraint assumed to be inherited.
With System.User, the situation goes further. The system-level rule applies through the specialization in a manner that a locally defined specialization rule cannot defeat. The developer may place what appears to be an airtight XPath filter on Administration.Account or another custom specialization, but that filter cannot constrain the platform-level System.User access that results from user-role management rights.

The Consequence: XPath Is Not the Final Authority​

XPath constraints remain powerful and important in Mendix security. They can express rules such as allowing staff to view only records from their department, customers to see their own orders, or field technicians to retrieve assets assigned to their territory. Mendix’s own documentation gives the example of using XPath to limit an employee’s visibility to orders associated with their department.
However, XPath must not be treated as the authoritative control for access to a System.User specialization. That is the central operational lesson from Siemens’ advisory.
A security review that stops at the domain model can therefore reach the wrong conclusion. The real authorization path also includes the application-level user-role configuration—particularly the roles that one user role is allowed to manage. Mendix explains that user management properties are internally translated into System.User entity access rules and that these controls are not applied in microflows that do not check entity access.
In practical terms, the question is no longer just:

“Does the Account entity’s XPath restrict the object?”

Click to expand...

It must also be:

“Can this user role manage the role assigned to the target System.User object?”

Click to expand...

If the latter answer is yes, the built-in platform rule can make relevant System.User attributes readable despite an XPath filter attached to the specialization.

---

The Anonymous User Scenario Raises the Stakes​

Siemens identifies a particularly dangerous recurring configuration: an anonymous user role associated with a System.User entity that gains access to stored records even when the role has no explicitly configured rights. The advisory names this as a common misconfiguration and warns that it can provide access to all stored records.
Anonymous access is inherently high-risk because it converts a potential authenticated-user authorization mistake into a possible internet-facing data-exposure problem. The severity depends on whether anonymous users are enabled, which pages and services they can reach, what user-related attributes are visible, and whether the application exposes account-management workflows or data connected to user objects.
The CVSS v3.1 vector assigned by Siemens is:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
That vector represents network reachability, low attack complexity, no required privileges, no user interaction, and high confidentiality and integrity impact, with no availability impact assessed. The absence of an availability component should not dilute the urgency. For an enterprise application, unauthorized access to user information or the ability to manipulate role-relevant data can be more damaging than a transient outage.

Exposure Is Not Limited to Login Credentials​

The advisory does not claim that every vulnerable deployment exposes passwords or creates automatic administrator takeover. Such conclusions would depend on the specific application design, attribute rights, microflows, exposed endpoints, and identity integration.
But System.User-derived entities can hold highly valuable data and relationships, including:

• Account identifiers and display names
• Email addresses and organizational metadata
• User-role assignments and administrative relationships
• Associations to customer, employee, partner, or tenant records
• Data used by downstream access-control flows
• Personal information synchronized from enterprise identity systems

A user record is also a high-value pivot point. Access to its attributes may reveal identity structure, facilitate account discovery, expose sensitive personnel or customer data, or weaken workflows that assume a user-management restriction is narrower than it really is.
The most acute risk arises when an application combines broad “manageable roles” settings with custom user specializations and XPath restrictions intended to enforce departmental, tenant, regional, or customer boundaries. In that design, the XPath may look like a successful implementation of least privilege while the actual permission boundary is governed elsewhere.

---

Why This Is an Insecure Inherited Permissions Problem​

CVE-2026-7891 is classified as CWE-277: Insecure Inherited Permissions. Both Siemens and the National Vulnerability Database record that weakness classification for the issue. The category fits because the security-relevant permission behavior extends from the protected base entity into specialized user entities in a way that can defeat a developer’s assumptions about local restrictions.
The term inherited needs careful interpretation here. Mendix’s standard access-rule behavior says that ordinary entity access rules are defined explicitly and are not inherited from a generalization as a constraint. The updated documentation makes this distinction clear while separately explaining that the platform-enforced System.User rules do apply to specializations.
That contrast is precisely why this bug is easy to misunderstand:

• Developers may know that a specialization must have explicit rules.
• They may then add precise XPath restrictions to that specialization.
• They may assume those rules are the complete runtime policy.
• The System.User platform behavior creates an additional effective permission path.
• The specialization’s XPath cannot close that path.

This is a security-design problem, not merely a syntax problem. Correcting it requires teams to map the effective permissions that result from role composition, user management configuration, entity access, microflow access, page access, and service exposure.

---

The Practical Fix: Restrict Role Management at App Security Level​

Siemens’ mitigation is concise and important: any security model that relies solely on XPath constraints on a System.User specialization must be revised so that restrictions are enforced at the App Security role-management configuration level. The vendor specifically advises avoiding broad role management and reviewing access rules with the knowledge that System.User platform rules cannot be constrained by a specialization’s access rules.
That means an organization should view manageable user roles as a primary authorization control, not a background administrative convenience.

Apply the Principle of Least Manageable Role​

Mendix provides two broad choices when configuring which users a role can manage: All or Selected. A role that can manage all users can create, view, edit, and delete users with any role and grant all roles; Mendix says this setting should normally be reserved for administrators. The more constrained option allows a role to manage only selected user roles, and selecting no roles prevents it from managing users at all.
For remediation, the safest interpretation is simple:

1. Eliminate “All” wherever it is not indispensable.
2. Grant each administrative or managerial role the smallest viable set of manageable roles.
3. Treat role-management configuration as the enforcement point for user-record segmentation.
4. Use XPath as defense in depth for other entities and workflow logic—not as the sole control for restricting System.User specialization visibility.
5. Validate anonymous roles separately and assume they require the strictest possible review.

A department manager, for example, may need to administer only ordinary employee accounts, not security administrators, integration accounts, tenant administrators, or users from other business units. That separation must be encoded in user-role management rather than assumed from a custom XPath filter on an account specialization.

Separate Account Administration from Business Visibility​

A robust Mendix authorization model should avoid using a user specialization as a catch-all business profile entity. Where practical, separate business data—such as department assignment, customer profile, territory, or employee details—into dedicated domain entities with their own explicit and testable authorization rules.
This does not eliminate the need to secure user data. It does, however, reduce the blast radius of the System.User special case. Business permissions can then be scoped against ordinary entities where the standard entity-access model and XPath constraints apply in the expected fashion.
A strong pattern is:

• Use System.User or Administration.Account for identity and account lifecycle requirements.
• Store business profile or tenancy data in dedicated entities.
• Use associations and explicit XPath constraints to secure those business entities.
• Restrict who can manage each application user role in App Security.
• Keep role assignment workflows separate from ordinary profile editing.

This approach makes it easier to reason about who can change identity, who can assign roles, and who can merely update business attributes.

---

A Mendix Security Review Checklist​

The advisory calls for review rather than a version upgrade, so teams should approach remediation as a structured access-control assessment. The following checklist is designed for developers, security architects, and application owners maintaining Mendix applications on Windows workstations or enterprise runtime infrastructure.

1. Inventory Every System.User Specialization​

Identify all entities that directly or indirectly specialize System.User.
Common examples include:

• Administration.Account
• Custom employee-account entities
• Customer portal account entities
• Partner or supplier account entities
• Tenant administrator accounts
• External identity-provider-linked user entities

Mendix documents that application user accounts are specializations of System.User, making this inventory a necessary first step rather than a niche exercise.
For each specialization, document:

• Its attributes and associations
• All access rules and XPath constraints
• All module roles with access
• All pages, microflows, REST services, OData services, or GraphQL services that expose related data
• Every user role that can manage the roles assigned to objects of that specialization

2. Review App Security User-Management Properties​

For each application user role, inspect manageable roles. Focus on roles that have:

• The All setting
• Broad selected-role lists
• Rights to manage privileged roles
• Rights to manage roles used by customer, employee, or partner accounts
• Rights available to users who should have only departmental or tenant-local administration

Mendix states that user-role changes do not take effect immediately because an application may continue to show stale pages or data while sessions persist. This makes session handling and post-change validation important after tightening role-management configuration.

3. Audit Anonymous Access Independently​

Do not assume anonymous user configuration is harmless because a corresponding entity-access matrix appears blank or restricted. Siemens’ advisory specifically calls out the potential for anonymous access to all stored records in the relevant misconfiguration scenario. That makes anonymous application roles a priority review target.
Verify:

• Whether anonymous users are enabled at all
• Which pages, deep links, service endpoints, and login flows are reachable before authentication
• Whether any anonymous user role can reach user-related microflows
• Whether public registration, password reset, account lookup, or invitation features retrieve account objects
• Whether public APIs have distinct authentication and authorization policies

4. Inspect Microflows and APIs, Not Just Pages​

Page visibility should never be mistaken for a complete security boundary. Mendix warns that page-access settings do not stop navigation by other means, such as a deeplink or a forcibly visible button; data and logic must be protected by entity and microflow access constraints.
This is especially relevant in apps that expose:

• Published REST services
• OData or GraphQL services
• Deep links
• Task or workflow pages
• Microflows callable from the client
• Custom account-management interfaces
• APIs serving mobile or desktop clients

Also remember that Mendix microflow access roles are checked when the microflow is executed from the client, while microflows can call other microflows without that same role check. That behavior makes end-to-end flow tracing essential when reviewing privileged account logic.

5. Export and Compare Effective Permissions​

Mendix’s Security Overview can help teams move beyond scattered rule definitions. It aggregates applicable runtime access rules for a selected user role, and the platform notes that any access rule granting a right contributes to the combined effective access. The overview can also export entity, member, and document access information to Excel for review.
There is one crucial limitation: the Security Overview does not show the System module or other protected modules in its module list. That omission means a clean-looking overview cannot, by itself, prove that System.User-related access is safe.
Use the tool as supporting evidence, not as the final answer. Pair it with manual review of App Security role-management settings and targeted runtime tests.

---

Testing the Fix Without Creating a False Sense of Security​

Security changes should be tested with separate accounts representing every relevant trust boundary. Avoid validating only with an administrator account, because administrative access can conceal an over-permission defect rather than reveal it.
Create or use representative accounts for:

• Anonymous visitor
• Ordinary authenticated user
• Department manager
• Tenant administrator
• User administrator
• Integration or service user
• Full application administrator

For each test identity, confirm that the account can access only the intended user records and only the intended functions. Test direct UI flows, deep links, published APIs, and microflows that return account data.
A suitable test plan should include both positive and negative assertions:

1. A manager can administer users in the role set explicitly delegated to that manager.
2. The manager cannot retrieve user data for roles outside that set.
3. A user from one department or tenant cannot view a peer from another boundary.
4. An anonymous request cannot enumerate or retrieve account-related records.
5. A custom API cannot bypass protections present in the standard UI.
6. Role-management restrictions remain effective after a session refresh and after deployment.

The key test is not whether an XPath expression evaluates as expected in isolation. The key test is whether the effective runtime permissions remain constrained when a requester’s manageable roles would otherwise grant System.User access.

---

The Broader Lesson for Low-Code Application Security​

CVE-2026-7891 is a reminder that low-code platforms accelerate development but do not eliminate the need for rigorous authorization architecture. Visual rule editors, role matrices, and declarative XPath constraints make policy easier to express. They do not guarantee that every platform-level exception is obvious to an application team.
There is also a positive takeaway. Mendix’s updated access-rules documentation now explains the System.User special case directly, including why specialization-level XPath restrictions cannot enforce certain user-record boundaries and what App Security configuration must do instead. The documentation gives the specific example of managers who should see users only in their own department and directs developers to restrict which roles each user role can manage.
That clarification is valuable because it replaces an implicit implementation detail with an explicit security rule. Yet the burden remains on organizations to find applications built under the older, incomplete understanding.
For enterprises, the best response is to treat this advisory as an opportunity to improve the entire Mendix authorization posture:

• Make effective permissions a review artifact.
• Enforce least privilege at both the entity and application-role layers.
• Minimize anonymous access.
• Separate identity administration from business-data administration.
• Test cross-role and cross-tenant denial cases as seriously as allowed-access cases.
• Document every exceptional platform security behavior that changes normal modeling assumptions.

The Siemens Mendix Runtime advisory does not call for waiting on a future patch. It calls for action now: reassess role-management settings, stop relying on XPath-only restrictions for System.User specializations, and verify that every user role has no more account-management power than the business requirement demands. That is the durable fix for CVE-2026-7891—and the clearest path to keeping low-code convenience from becoming an authorization blind spot.

---

References​

1. Primary source: CISA
   Published: 2026-07-28T12:00:00+00:00
   
   

   Siemens Mendix Runtime | CISA

   www.cisa.gov
2. Related coverage: docs.mendix.com
   
   

   Configuring Security for a Workflow Process | Mendix Documentation

   Describes how to configure security for a workflow in Mendix Studio Pro.

   docs.mendix.com
3. Related coverage: db.gcve.eu
   
   

   Vulnerability-Lookup

   Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.

   db.gcve.eu