Mendix applications: unintended data exposure due to authorization misconfiguration

We identified a recurring security issue across multiple Mendix applications where data sources (entities/tables) are accessible to anonymous users or to newly registered users with overly broad permissions. This can lead to unauthorized access to sensitive information without exploiting a software vulnerability in the Mendix platform itself.

The issue is primarily caused by application-level authorization misconfiguration, such as:

  • entity access rules that are too permissive
  • incorrect role mappings
  • missing or overly broad XPath constraints
  • overly permissive rights for the Anonymous user or default/newly registered users

This is a known pattern frequently observed during pentests of Mendix applications, and has now been validated at larger scale across many organisations.

Affected scope

This is not limited to a specific Mendix version or a single product. The scope includes:

  • Mendix Cloud hosted applications (potentially thousands of instances)
  • on-premise Mendix installations
  • internet-facing portals built on Mendix

Because this is an implementation/configuration issue, it can occur in any Mendix application where authorization is not correctly designed and enforced.

How attackers can misuse this

No exploit is needed. Anonymous access or a basic account can be enough to pull data via normal Mendix runtime requests (e.g., /xas), making abuse hard to detect and scalable across many misconfigured apps.

We observed exposed sensitive data (names, contact/address details, customer/internal records, sometimes documents/ID images), leading to GDPR/AVG risk, fraud, phishing, reputational damage, and possible breach notification. Root cause is typically overly permissive app-level authorization (entity access, roles, XPath constraints, microflows), not a Mendix platform vulnerability.

The Mendix client (browser/app) should be considered untrusted; if runtime permissions are too broad, data can be retrieved via normal requests.

What you can do

Organizations are strongly advised to review Mendix application authorization configurations.

Minimum checks:
  1. Review entity access rules for all entities
  2. Review module role mapping and user role assignments
  3. Validate XPath constraints and data visibility rules
  4. Review permissions of the Anonymous user.
  5. Review permissions of newly registered/default users
  6. Disable anonymous access if not strictly necessary
  7. Review exposed published REST services and microflows for authorization enforcement
  8. Consider upgrading to supported Mendix versions (for example 10 LTS / 11 MTS, where applicable in your environment)
  9. Perform a security review and/or pentest focused on authorization and data exposure
If sensitive data is accessible:
  • restrict access immediately
  • review available logging for signs of misuse
  • assess whether a data breach notification is required

Menscan.io and MendixHunter can help map your Mendix exposure and identify internet-facing instances that may require authorization review.

Notes from Mendix

Mendix has indicated that this is not a platform vulnerability, but a configuration and development responsibility for application owners.

Reference: Mendix security guidance (handling security findings related to data exposure)

Collaboration

During pentests, manual reviews, and large-scale public-source inventory, we repeatedly found Mendix apps exposing data to users who should not have access.

The research started with Rudy Dijkstra’s menscan.io, after which DIVD formed a researcher group to confirm this was a structural issue across many organizations, supported by multiple DIVD researchers (including contributors affiliated with SUPERP-MxBlue).