Outdated or end-of-life components
A Mendix application is assembled from parts that age: the runtime, Marketplace modules, the Java libraries behind them and the JavaScript inside widgets. Once a vulnerability in any of those is public, exploitation is largely automated, so the exposure is not the flaw itself but the time you take to notice it.
How this shows up in a Mendix application.
A runtime outside MTS or LTS
Running a version that is neither medium nor long term supported, which also invites breaking changes at the worst moment.
Marketplace modules edited in place
Changing a module directly blocks every future update, so the security fixes never arrive.
No SBOM
Nobody can say which components are actually in the application, so nobody can say whether the latest advisory applies.
Composition scanning taken as complete
The Mendix Software Composition Service does not see minified JavaScript libraries or embedded JAR files, and those are where the old versions hide.
Direct role assignments inside modules
Security logic left inside a Marketplace module ties your role model to somebody else's release schedule.
Known-vulnerable components left in place
Components with published issues, such as older ForgotPassword, Encryption or SAML modules, or an outdated CKEditor or jQuery.
What it lets someone do.
Every item below has been found in production applications. None of them requires a sophisticated attacker: they require somebody who reads the page source, edits a request or simply logs in.
How to keep it out.
Keep a current SBOM
One inventory covering runtime, modules, JAR files and JavaScript, refreshed automatically rather than at audit time.
Stay on MTS or LTS
Run a supported runtime and plan the upgrade before support ends, not after an advisory forces it.
Extend, never edit
Custom behaviour in a separate module, so Marketplace updates remain a decision rather than a merge.
What Omnext checks for you.
Omnext builds the SBOM per application and per portfolio, matches components against known CVEs with their exploit probability, and flags licence risk alongside it.
The framework is The S-Unit's.
The S-Unit Top 10 is the work of The S-Unit, the Mendix security specialists. They built it from more than ten years of offensive security work and hundreds of Mendix penetration tests, and they maintain the canonical version. Omnext automates the checks in the Security Analysis module; the framework itself is theirs, and this page explains it in our own words.
Which of the ten are you sure about?
Ten questions, about four minutes, results on screen. Or let the scan answer all ten with evidence from your own model.