CVE-2026-92466 is a missing authorization flaw in zlt2000 microservices-platform through version 6.0.0. A configuration flag that enforces permission checks defaults to off, so authenticated users with no roles can reach administrative APIs. NVD scores it High (8.8). We could not confirm a fixed version.
What's affected
The NVD record lists microservices-platform through 6.0.0 as affected. The weakness is CWE-862, missing authorization, and the vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
The record names the setting involved: zlt.security.auth.urlPermission.enable. It defaults to false, which disables all permission checks after a user has authenticated. The record says the affected APIs include user management, role assignment and Elasticsearch index operations.
We did not find a vendor advisory or release note naming a fixed version, and the project page we could read did not state one either. Check the project's repository for a release newer than 6.0.0 and for any note on the setting, and treat the situation as unpatched until you confirm otherwise. The record's references include third-party test scripts. We have not used them and do not describe them here.
How to check if you're exposed
Start with your configuration. Look in your configuration files and any configuration server for the setting zlt.security.auth.urlPermission.enable. If it is absent or false, permission checks after authentication are off on your deployment.
Then test your own deployment with accounts that have no roles. Confirm, in a non-production copy, that those accounts are refused on administrative endpoints for user management, role assignment and search index operations. The result tells you whether you are exposed in practice.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Find out whether the setting is enabled in every environment, and read the project's documentation on what enabling it changes.
- Test the change in a staging copy before production, since turning on enforcement can break existing role mappings.
- Put administrative APIs behind a network boundary or gateway that limits who can reach them.
- Review user, role and index changes for anything you did not make.
- Watch the project repository for a release after 6.0.0.
Why it matters
Authentication answers who you are and authorization answers what you may do. This flaw is a case of the second one being optional. With the flag off, the platform treats every logged-in user as allowed everywhere, so a user with no roles can do what an administrator can.
Secure defaults matter because many deployments never change them. A setting that turns a safety control off by default means the safe state is something each operator has to know to enable. The KEV flag in the record is false and no source we read reports exploitation.
Quick check
Is there a patched release?
We could not confirm one. Check the project repository for versions after 6.0.0.
Is this a coding bug or a configuration issue?
The record describes a default that disables checks. Enabling the flag may address it in your deployment, but verify that on a test copy.
Sources
Last reviewed: 18 October 2026.
