CVE-2026-120445 in madong-admin-saas
Summary
by MITRE • 11/02/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The security flaw identified within madong-admin-saas versions up to 5.1.4 represents a critical failure in access control mechanisms specific to multi-tenant Software as a Service architectures. The vulnerability resides primarily within the AccessTokenMiddleware component, which is responsible for validating authentication tokens and determining user permissions before granting access to protected resources. In a properly secured multi-tenancy model, there must be strict logical separation between tenant-level operations and platform-level administrative functions. However, in this implementation, the middleware fails to adequately distinguish between these two distinct privilege domains when processing requests directed at platform management endpoints. This oversight allows any user who has successfully authenticated as a standard tenant administrator or member to bypass intended restrictions and interact with APIs that are exclusively reserved for super administrators or platform owners.
From a technical perspective, the core issue is an insecure direct object reference combined with broken access control logic within the middleware layer. When a request containing a valid JSON Web Token issued during a tenant login session reaches the /platformapi controllers, the system does not verify whether the token possesses the necessary elevated privileges to execute platform-wide actions. Instead, it appears to accept the presence of any valid authentication token as sufficient proof of authorization for these high-privilege endpoints. This design flaw effectively neutralizes the boundary between tenants and the underlying infrastructure management layer. An attacker can exploit this by capturing a legitimate tenant JWT through standard login procedures or session hijacking techniques and then replaying it against platform administration routes such as user creation, database configuration modification, or system-wide setting changes.
The operational impact of this vulnerability is severe due to its potential for complete environment compromise. By reusing a tenant token against the vulnerable API endpoints, an attacker can create new accounts with full platform administrator privileges. This action grants them unrestricted access to all tenants hosted on the same instance, effectively breaking the isolation guarantees that define multi-tenant SaaS security models. Furthermore, the ability to read tenant database settings exposes sensitive configuration details and potentially credential stores associated with individual customer environments. The most critical consequence is the capability for a single compromised or malicious low-level user to take control of every tenant on the platform. This leads to widespread data exposure, potential data manipulation across all customers, and complete loss of integrity for the entire service ecosystem.
This vulnerability aligns closely with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization in the Common Weakness Enumeration database. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts, specifically within the context of lateral movement or privilege escalation via misconfigured access controls. The attack vector involves using valid credentials obtained from a lower-privileged account to perform actions reserved for higher-privileged roles, which is characteristic of horizontal and vertical privilege escalation attacks in web applications.
To mitigate this vulnerability, immediate remediation efforts should focus on reinforcing the middleware logic to enforce strict role-based access control checks before any request reaches platform management controllers. The AccessTokenMiddleware must be updated to explicitly verify that the authenticated user holds a specific super-administrator or platform-owner role when accessing /platformapi endpoints. Additionally, implementing token scoping where JWTs issued for tenant contexts are cryptographically distinct from those issued for platform administration can prevent reuse across domains. Input validation should also ensure that API routes enforce strict authorization policies regardless of the authentication status. Regular security audits and penetration testing focused on multi-tenancy isolation boundaries are recommended to identify similar logical flaws in other components of the application stack.