zlt2000 microservices-platform CVE-2026-92466

Exploitation requires (1) a deployment running the default configuration where zlt.security.auth.urlPermission.enable is left at its shipped default of false - which is the out-of-the-box state - and (2) any valid authenticated account, even one with zero assigned roles. There is no need for admin privileges, user interaction, or a non-default setup; the default IS the vulnerable state. Exploitation is LIMITED by the need for a low-privilege authenticated session (PR:L, so not fully pre-auth) and is neutralized by operators who explicitly set urlPermission.enable=true to re-enable authorization enforcement. The Elasticsearch-related impact additionally assumes the platform's ES-backed features are deployed.

This is a genuine priority, not a paper tiger. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, 8.7) describes a network-reachable, low-complexity flaw needing only a low-privilege authenticated account, yielding full confidentiality/integrity/availability impact. The core danger is a secure-by-default failure: the zlt.security.auth.urlPermission.enable flag defaults to false in the shipped application.yml (confirmed by the linked v6.0.0 source), so URL permission checks are disabled out of the box and any authenticated user - even one with no assigned roles - reaches administrative APIs. PR:L (rather than PR:N) is the honest limiter: an attacker still needs a valid account, but registration/low-tier access on such platforms is often trivial, and the impact once inside is total (user management, role assignment, password reset, Elasticsearch index deletion). Exploitation status is elevated by publicly available exploit code (VulnCheck-referenced PoCs on GitHub for role assignment, user listing, password reset, user CRUD, and ES index deletion). No EPSS score, no CISA KEV listing, and no SSVC decision data were provided - so there is no evidence of active in-the-wild exploitation, but the combination of default-vulnerable configuration plus working public PoCs makes weaponization straightforward. The real-world risk is bounded primarily by the product's limited production footprint rather than by any technical difficulty.

An attacker obtains or registers a low-privilege account on a deployed microservices-platform instance running the default configuration. Because URL permission enforcement is disabled by default, they send authenticated requests directly to administrative endpoints - assigning themselves an admin role, resetting another user's password, or deleting an Elasticsearch index. Public PoC scripts (C06_set_role_to_user.py, C10_reset_password_by_id.py, C21_delete_es_index.py) demonstrate each step end to end.