CVE-2026-92466: microservices-platform Auth Bypass Flaw

CVE-2026-92466 Overview

CVE-2026-92466 is a missing authorization vulnerability [CWE-862] in the zlt2000 microservices-platform project through version 6.0.0. The flaw stems from the zlt.security.auth.urlPermission.enable configuration flag defaulting to false, which disables all permission checks after authentication. Any authenticated user, including accounts with no assigned roles, can invoke administrative APIs. Exposed operations include user creation and updates, role assignment, password resets, user enumeration, and Elasticsearch index deletion. The vulnerability affects the Spring Boot-based zlt-auth-client-spring-boot-starter component used across the platform's microservices.

Critical Impact
Authenticated attackers with minimal privileges can take over administrative functions, escalate to any role, reset arbitrary passwords, and destroy backing Elasticsearch data stores.

Affected Products

zlt2000 microservices-platform versions through 6.0.0
zlt-auth-client-spring-boot-starter component (all deployments relying on default urlPermission configuration)
sc-gateway service using the default application.yml configuration

Discovery Timeline

2026-09-16 - CVE-2026-92466 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92466

Vulnerability Analysis

The microservices-platform project ships a URL-based permission enforcement layer implemented in DefaultPermissionServiceImpl. The component consults the UrlPermissionProperties object to determine whether to evaluate route-level authorization rules. When the zlt.security.auth.urlPermission.enable property is false, the permission service short-circuits and returns an allow decision for every authenticated request. This design collapses the authorization model to a single check: does the caller hold a valid OAuth2 token. Role membership, endpoint sensitivity, and administrative scope are all ignored.

Because the project's default application.yml in sc-gateway ships with the flag disabled, every out-of-the-box deployment inherits the insecure posture. See the VulnCheck advisory on the missing authorization issue for a full technical write-up.

Root Cause

The root cause is an insecure default configuration combined with fail-open authorization logic. The UrlPermissionProperties file defines enable as false by default, and the DefaultPermissionService implementation treats the disabled flag as a global permit rather than a deployment misconfiguration.

Attack Vector

An attacker first obtains any valid account, including a self-registered user with no roles. The attacker then issues HTTP requests to administrative endpoints exposed through sc-gateway. Because URL permission checks are disabled, the gateway forwards requests to backend services without evaluating role claims. Public proof-of-concept scripts demonstrate calls to save or update users, assign roles, reset passwords by user ID, list all users, and delete Elasticsearch indexes. Refer to the GitHub PoC for saving or updating users and the GitHub PoC for deleting an Elasticsearch index for representative request flows.

Detection Methods for CVE-2026-92466

Indicators of Compromise

Authenticated HTTP requests from low-privilege accounts to /api-user/users-anon and other /api-user/* administrative endpoints.
Unexpected POST or PUT calls to role-assignment or password-reset endpoints originating from non-admin user IDs.
DELETE requests against Elasticsearch index management endpoints proxied through sc-gateway.
Bursts of user enumeration calls (for example, /api-user/users/all) followed by targeted privilege changes.

Detection Strategies

Inspect the running configuration for zlt.security.auth.urlPermission.enable and alert when it resolves to false in any deployed profile.
Correlate gateway access logs with identity role data to flag requests where the caller's role set does not include the required administrative role for the invoked path.
Baseline normal API usage per account and identify deviations such as first-time access to administrative routes.

Monitoring Recommendations

Forward sc-gateway and downstream service logs to a centralized analytics platform with OAuth2 subject, request path, and response code fields normalized.
Track changes to user, role, and permission tables in the platform database and alert on modifications not initiated by known administrators.
Monitor Elasticsearch audit logs for indices:admin/delete operations sourced from the microservices platform service account.

How to Mitigate CVE-2026-92466

Immediate Actions Required

Set zlt.security.auth.urlPermission.enable to true in every environment and redeploy the affected services.
Audit all user accounts, remove unknown or unused accounts, and rotate credentials for administrative users.
Review recent changes to roles, permissions, and Elasticsearch indices to identify unauthorized modifications.
Restrict network exposure of sc-gateway to trusted client networks until the configuration change is verified.

Patch Information

No vendor patch is listed in the NVD entry for CVE-2026-92466 as of the publication date. Operators must remediate through configuration hardening and by tracking the upstream zlt2000 microservices-platform repository for future releases that change the default value of the urlPermission.enable flag.

Workarounds

Override the default in each service's application.yml (see the application.yml configuration reference) and populate the URL-to-role mapping used by DefaultPermissionServiceImpl.
Add an external authorization layer, such as an API gateway policy or service mesh policy, that enforces role-based access to administrative paths independently of the application configuration.
Disable self-service account registration or require administrator approval before new accounts become active.

bash

# Enable URL permission enforcement in application.yml
zlt:
  security:
    auth:
      urlPermission:
        enable: true