Skip to main content

madong-admin-saas EUVDEUVD-2026-115205

| CVE-2026-120445 HIGH
Incorrect Authorization (CWE-863)
2026-11-02 VulnCheck GHSA-rj3r-2pcr-8jf9
8.7
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain valid tenant login JWT
  2. Delivery
    Replay token against /platformapi controllers
  3. Exploit
    Authorization check bypassed in multi-tenant mode
  4. Execution
    Create platform administrator account
  5. Impact
    Read all tenant DB settings and seize every tenant

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Two concrete prerequisites, both drawn from the patched code and description: (1) the instance must be deployed in multi-tenant mode - specifically config('tenant.enable') must be true, since the vulnerable branch only skipped the platform-admin-type check in that configuration; and (2) the attacker must possess a valid tenant login JWT (a legitimate low-privilege tenant account, matching PR:L), which is then replayed against the /platformapi controllers. Limiting factors that reduce real-world exposure: single-tenant/monolithic deployments are NOT affected because non-platform tokens are correctly rejected when tenant.enable is not true; exploitation requires an authenticated tenant credential rather than fully anonymous access; and it is bounded to madong-admin-saas versions through 5.1.4.

Impact

This is a genuine high-priority access-control flaw (CWE-863) rather than an inflated high-CVSS issue, but its reach is gated by deployment mode. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) and score 8.7 describe a remotely reachable, low-complexity attack by an already-authenticated low-privilege tenant user that yields full confidentiality, integrity and availability impact on the platform - consistent with the description (create platform admin accounts, read tenant DB settings, take over every tenant). PR:L correctly reflects that a valid tenant login JWT is required, so this is authenticated, not unauthenticated. No EPSS score and no KEV listing were provided, and no confirmed exploit code is present (only a vendor issue, the patch commit, a source-line reference, and a VulnCheck advisory), so there is no public exploit identified at time of analysis and no evidence of active exploitation - the signals point to a credible, high-impact bug disclosed with a patch rather than a mass-exploited threat. The one conflicting/limiting signal to verify is deployment-dependence: the patched code shows the flaw only manifests when multi-tenant mode (config('tenant.enable') === true) is enabled, so single-tenant/monolithic installs are not exposed; the VulnCheck decision label is 'this_week', which matches patch-promptly urgency rather than emergency.

Exploit ScenarioDerived

An attacker who holds (or registers) an ordinary tenant account on a madong-admin-saas instance running in multi-tenant mode logs in normally and obtains a tenant JWT. They replay that same token against the /platformapi platform-management controllers, which - due to the authorization defect - accept it, letting them create a platform administrator account and read every tenant's database configuration. No public working exploit code is identified at time of analysis; the attack requires only a valid tenant credential and low complexity (AC:L).

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Nov 02, 2026

Incorrect authorization in madong-admin-saas through 5.1.4 lets a tenant user replay their login JWT against /platformapi controllers in multi-tenant deployments, where the middleware's platform-admin type check was skipped, allowing creation of platform administrator accounts, reading of tenant database settings, and control over every tenant. Only instances running with multi-tenant mode enabled (config('tenant.enable') true) are exposed; single-tenant deployments reject non-platform tokens correctly. Exploitation requires a valid low-privilege tenant account (PR:L per the assessed vector), and no public exploit code has been identified at time of analysis; the vendor patch is available as an upstream commit.

RemediationAI

Update to a build containing upstream commit 2a199a1523ed749c94b876bc2ae5fedf252b2e39 (https://github.com/madong-code/madong-admin-saas/commit/2a199a1523ed749c94b876bc2ae5fedf252b2e39); the supplied data indicates a vendor patch is available but does not state a released fixed version number, so confirm the tagged release with the vendor advisory before relying on it. If upgrading must wait, the practical compensating control is to take the affected instances out of multi-tenant mode (set tenant.enable to false) on any deployment that does not require tenant isolation, since the vulnerable branch is only reachable in the multi-tenant configuration and non-platform tokens are rejected otherwise - the trade-off is loss of tenant functionality. Additionally, restrict network access to the /platformapi route to trusted administrative addresses at the reverse proxy so tenant JWTs cannot be replayed against it, understanding this is a coarse control that does not fix the authorization logic; rotate the JWT signing secret and invalidate existing tenant tokens so previously issued tokens cannot be reused, which logs out all users; and audit platform administrator accounts and tenant database settings for signs of tampering, since exploitation creates admin accounts and reads tenant DB configuration. Note that the upstream fix is an identity/type gate only - platform-side RBAC is explicitly not enabled in this commit, so controller Permission annotations are not enforced.

Affected VersionsENISA

madong-admin-saas 0 ≤5.1.4

Affected Packages

euvd madong_admin_saas no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is CWE-863 (Incorrect Authorization) in app/platform/middleware/AccessTokenMiddleware.php of madong-admin-saas, a PHP/Webman multi-tenant admin platform. After validating the JWT, the middleware read the token's extra payload to extract admin type codes and was supposed to require the 'platform' type before letting the request reach platform controllers. In the vulnerable 5.1.4 code the rejection branch was gated on config('tenant.enable') !== true, so when multi-tenant mode was on, a token carrying only tenant admin types was not rejected and the platform management API accepted it. The same commit also corrects the middleware registration key in config/middleware.php, which was written as the route prefix 'platformapi' rather than the application name 'platform', so the intended middleware chain was not reliably applied. The patched code makes the admin-type check unconditional, accepts either 'platform' or 'root' types, and adds resolveAdminTypes/hasAdminType helpers that handle both string arrays and object arrays (code keys) because platform logins write 'types' while tenant logins write 'admin_types' into the JWT extra payload. The commit notes that platform-side RBAC is not yet enabled, so the fix is an identity/type gate only; controller #[Permission] annotations remain metadata rather than enforced checks.

Know when Madong Admin Saas gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 8.7 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 8.8 HIGH

Remote HTTP access with low complexity; PR:L because a valid tenant login JWT is required; full C/I/A as the attacker gains platform-admin control within the same application (S:U).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

madong-admin-saas through 5.1.4 contains an incorrect authorization vulnerability in AccessTokenMiddleware that allows authenticated tenant users to access the platform management API in multi-tenant mode. Attackers can reuse a tenant login JWT against /platformapi controllers to create platform administrator accounts, read tenant database settings, and take control of every tenant.

Executive ViewAI

Why It Matters

A high-severity authorization bypass in madong-admin-saas (up to version 5.1.4) enables any tenant user to escalate to platform administrator, exposing all tenants' data and control in multi-tenant deployments. This puts customer data confidentiality and platform integrity at risk, potentially affecting every tenant and requiring immediate leadership attention to patch and verify.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.4%
Top 71% exploitable
Prevalence
Rare
obscure open-source SaaS admin framework, tiny deployment footprint
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Total

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy