CVE-2026-92469: microservices-platform Auth Bypass Vulnerability

CVE-2026-92469 Overview

CVE-2026-92469 is an authorization bypass vulnerability affecting the zlt2000 microservices-platform project through version 6.0.0. The flaw resides in the file-center module, specifically in the DELETE /files/{id} endpoint exposed by FileController.java. The endpoint performs no ownership validation before executing deletions. Any authenticated user can enumerate file identifiers using GET /files and then delete arbitrary users' files along with their metadata by supplying those identifiers to the delete endpoint. The weakness is classified as [CWE-639] Authorization Bypass Through User-Controlled Key, commonly known as an Insecure Direct Object Reference (IDOR).

Critical Impact
Authenticated attackers can permanently delete files and metadata belonging to any user of the platform, resulting in integrity and availability loss across the file-center service.

Affected Products

zlt2000 microservices-platform versions up to and including 6.0.0
file-center module (FileController.java)
Deployments exposing the DELETE /files/{id} endpoint to authenticated users

Discovery Timeline

2026-09-16 - CVE-2026-92469 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92469

Vulnerability Analysis

The vulnerability exists in the file deletion handler defined in FileController.java line 48. The handler accepts a file identifier from the URL path and deletes the matching record and stored object. It does not compare the authenticated principal against the file's owner before executing the delete operation.

Because the GET /files listing endpoint returns identifiers across the tenant scope, an attacker with any valid session can enumerate targets. The attacker then issues a DELETE request against each identifier of interest. The backend proceeds with the deletion because authorization logic only checks that the caller is authenticated, not that the caller owns the resource.

The result is loss of file integrity and availability for other users. Metadata rows are removed alongside the underlying object, preventing recovery through the application's own APIs.

Root Cause

The root cause is a missing ownership check in the delete controller. The endpoint trusts the {id} path parameter as an authorized reference. It does not validate that the caller's user identifier matches the create_by or equivalent owner column on the file record. This is a textbook Insecure Direct Object Reference pattern.

Attack Vector

Exploitation requires network access to the file-center API and low-privilege authenticated credentials. No user interaction is needed. An attacker authenticates, calls GET /files to collect victim file IDs, and then issues DELETE /files/{id} for each target. A public proof of concept demonstrating the flow is available at the CVE Request PoC repository and further described in the VulnCheck advisory.

No verified code examples are provided. Refer to the linked advisories and the upstream microservices-platform repository for technical details.

Detection Methods for CVE-2026-92469

Indicators of Compromise

Repeated GET /files requests from a single authenticated session enumerating identifiers outside the caller's created objects.
DELETE /files/{id} requests where the authenticated user identifier does not match the file record's owner column.
Bulk removal of file rows from the file-center database within a short time window from a single session or source IP.
Application logs showing successful deletions immediately following listing calls from the same token.

Detection Strategies

Correlate access logs from the file-center service to flag sessions issuing high volumes of DELETE /files/{id} requests.
Compare the authenticated principal against the owner field on each deletion event and alert on mismatches.
Baseline normal file deletion rates per user and alert on statistical outliers.

Monitoring Recommendations

Forward file-center HTTP access logs and application audit logs to a centralized analytics platform for query and retention.
Enable database audit logging on the file metadata table to capture the executing user and affected row identifiers.
Monitor object storage backend delete operations issued by the microservice's service account for anomalous spikes.

How to Mitigate CVE-2026-92469

Immediate Actions Required

Restrict access to the file-center service to trusted internal networks until an authorization fix is deployed.
Add a gateway or reverse-proxy rule that blocks DELETE /files/{id} requests where the caller cannot be validated as the file owner.
Revoke or rotate credentials for any account observed enumerating file identifiers followed by deletions.
Back up the file storage bucket and metadata database to enable recovery of any files removed through abuse.

Patch Information

As of publication, no official upstream patch is referenced in the NVD entry. Track the zlt2000/microservices-platform repository and the VulnCheck advisory for a fixed release. Operators maintaining internal forks should modify the delete handler in FileController.java to look up the file record, compare its owner column against the authenticated principal, and return HTTP 403 on mismatch.

Workarounds

Implement an authorization filter in the API gateway that enforces owner-equals-caller checks before forwarding delete requests to file-center.
Change the delete endpoint to accept only file identifiers scoped to the caller, resolved server-side from the session, instead of accepting a client-supplied {id}.
Disable or remove the public GET /files listing to eliminate the enumeration primitive used in exploitation.
Apply short-lived, least-privilege tokens for file operations and audit every use.

bash

# Example gateway rule (pseudocode) enforcing ownership before delete
# Reject DELETE /files/{id} unless the resolved owner matches the JWT subject
location ~ ^/files/(?<file_id>[0-9]+)$ {
    if ($request_method = DELETE) {
        access_by_lua_block {
            local jwt_sub = ngx.var.http_x_user_id
            local owner   = lookup_owner(ngx.var.file_id)
            if owner ~= jwt_sub then
                ngx.exit(403)
            end
        }
    }
    proxy_pass http://file-center-upstream;
}