On this page (6 sections)
CVE-2026-120446 describes a missing authentication flaw in madong-admin-saas, an admin and multi-tenant SaaS application. According to the GitHub Advisory Database entry, versions through 5.1.4 do not protect the platform tenant management API, so unauthenticated remote attackers can reach endpoints that manage tenants and subscription plans.
If you run this software, or host or maintain a site built on it, you should treat the platform API as exposed until you have confirmed otherwise. The information available so far is thin, and this article separates what is stated from what is still unknown.
What happened
The advisory says the flaw exists because the 'platformapi' middleware key never matches the 'platform' application. In plain terms, the authentication check that is meant to guard the platform area is configured under a name that the application never uses, so the check is never applied to those routes.
As a result, unauthenticated remote attackers can call the /platformapi/tenant/account, bind-plan and sync-data endpoints. The advisory states this allows them to list, create, modify, disable or delete tenants and to bind subscription plans.
The advisory was published on November 2, 2026 and is marked as unreviewed by GitHub. The NVD record repeats the same description, so it is not independent confirmation. The advisory also points to a VulnCheck advisory, and only one independent publisher covers the story so far.
Technical details
Missing authentication (CWE-306) is a configuration or design gap rather than a clever exploit. The application exposes a sensitive function, here tenant administration, and nothing asks the caller to prove who they are. When middleware is registered under one key but the route group refers to another, the framework simply runs no check, and the failure is silent.
The scoring on the advisory page lists network attack vector, low complexity, no privileges and no user interaction required. Impact is low for confidentiality and high for integrity and availability. That matches the described behavior: an outsider can change or remove tenant data far more easily than they can read it.
The advisory references the code at v5.1.4 config/middleware.php, the AccountController, a commit and an issue in the project tracker. The research does not confirm that this commit is a released fix, so do not assume a specific version resolves the problem.
Who is affected
Any deployment of madong-admin-saas at version 5.1.4 or earlier is in scope. The risk is highest where the application is reachable from the internet, because the attack needs only network access. Internal-only deployments behind a VPN or an IP allowlist have a much smaller exposure, though anyone with network access to them could still reach the API.
The consequences fall on the platform operator and on every tenant. Someone able to disable or delete tenants can cause outages and data loss for customers, and changing plan bindings can affect billing and access levels.
How to check your exposure
First confirm which version you run. Check the project's release tag or your deployment's version file, and compare it with 5.1.4. If you deploy from a Git checkout, this read-only command, run in the application directory, lists the tag you are on (if tags are present):
git describe --tagsNext, search your web server access logs for requests to the affected path prefix. This read-only grep lists any requests to the platform API; the log path is an example, so adjust it for your server. Look for requests from addresses you do not recognize, especially POST or DELETE calls and requests that returned a success status.
grep "/platformapi/" /var/log/nginx/access.logAlso review your tenant list and plan assignments for entries you did not create, tenants that were disabled without explanation, or plan bindings that changed. Compare against a recent database backup if you have one.
What to do now
No patched version is named in the advisory, so the priority is to cut off unauthenticated access to the platform API while you wait for, or work out, a proper fix.
0 of 7 done
Detection and monitoring
Keep logging enabled for the platform area and alert on any request to /platformapi/ from outside your allowlist. Watch for sudden changes in tenant counts, tenants switching to a disabled state, or unexpected subscription changes, since those are the outcomes the advisory describes.
From the outside, you can run a read-only check of your own domain with Webforta Scan to review what is publicly reachable, and use Webforta Monitor for uptime alerts, which would surface tenant-facing outages. These do not fix this flaw; the access restriction and code change above do.
Finally, watch the project repository and the advisory for updates. The advisory is unreviewed and lists affected and patched versions as unknown, so details may change as maintainers or reviewers respond.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.