CVE-2026-108606: JeecgBoot Auth Bypass Vulnerability

CVE-2026-108606 Overview

CVE-2026-108606 is a missing authorization vulnerability [CWE-862] in JeecgBoot through version 3.9.5. The flaw resides in the AiOcrController.deleteById handler within the jeecg-boot-module-airag module. The handler accepts delete requests from any authenticated user without checking record ownership or role. Attackers with low-privileged accounts can enumerate record identifiers from the unguarded GET /airag/ocr/list endpoint. They can then issue repeated delete requests against every shared OCR prompt record stored in Redis.

Critical Impact

Any authenticated JeecgBoot user can enumerate and delete all shared Optical Character Recognition (OCR) prompt records, causing data loss across tenants that share the AiRag OCR module.

Affected Products

• JeecgBoot versions up to and including 3.9.5
• jeecg-boot-module-airag AiOcrController component
• Deployments using shared Redis-backed OCR prompt storage

Discovery Timeline

• 2026-10-10 - CVE-2026-108606 published to NVD
• 2026-10-15 - Last updated in NVD database

Technical Details for CVE-2026-108606

Vulnerability Analysis

The vulnerability stems from the absence of authorization checks in the deleteById method of AiOcrController. The controller is annotated with authentication requirements but does not verify whether the calling principal owns the targeted OCR record. The companion list endpoint (GET /airag/ocr/list) returns all record identifiers across tenants without filtering by owner. An attacker chains both endpoints to enumerate ids and then delete each record stored in Redis.

Because the OCR prompt records are shared infrastructure, the loss affects every user that depends on those prompts. The vulnerability does not require administrative privileges or user interaction. See the VulnCheck Advisory for JeecgBoot for additional technical context.

Root Cause

The root cause is a missing authorization check [CWE-862] in the delete handler. JeecgBoot authenticates the request but omits a per-record ownership or role-based access verification before invoking the service layer. The list endpoint compounds the issue by exposing identifiers that should be scoped to the requesting user.

Attack Vector

An attacker authenticates with any valid low-privilege account. They issue a GET /airag/ocr/list request to retrieve all stored OCR record ids. For each id, they issue a delete request to the vulnerable deleteById handler. The server processes each delete and removes the corresponding Redis entry without authorization validation.

See the AiOcrController source on GitHub and the public proof of concept for exploitation details.

Detection Methods for CVE-2026-108606

Indicators of Compromise

• Unexplained removal of OCR prompt records from the shared Redis store
• Repeated HTTP requests to /airag/ocr/deleteById originating from a single non-administrative session
• Sequential or scripted GET /airag/ocr/list calls followed by delete requests from the same source IP

Detection Strategies

• Alert on high-frequency calls to AiOcrController delete endpoints by non-privileged roles
• Correlate list enumeration followed by multiple deleteById operations within short time windows
• Baseline normal OCR record delete volume and flag spikes exceeding the baseline

Monitoring Recommendations

• Enable JeecgBoot application access logging for all /airag/ocr/* endpoints and forward to the SIEM
• Monitor Redis key deletions for the OCR namespace and alert on bulk removal events
• Track authenticated session activity for anomalous enumeration patterns against AiRag endpoints

How to Mitigate CVE-2026-108606

Immediate Actions Required

• Restrict network access to the /airag/ocr/* endpoints to trusted administrative users via reverse proxy or API gateway rules
• Disable or remove the AiRag OCR module in deployments that do not require it
• Audit Redis OCR records and back up current state before applying restrictions

Patch Information

As of the NVD last-modified date of 2026-10-15, no vendor patch is referenced in the advisory metadata. Monitor the JeecgBoot repository for an updated release addressing AiOcrController.deleteById authorization. Apply the fixed version when published and validate that both the deleteById and list handlers enforce per-record ownership checks.

Workarounds

• Place a Web Application Firewall (WAF) rule in front of /airag/ocr/deleteById that enforces an administrative role claim
• Modify the AiOcrController locally to add a role or ownership check before delegating to the service layer
• Scope the GET /airag/ocr/list endpoint to return only records owned by the requesting principal

# Example reverse-proxy rule (nginx) restricting the vulnerable endpoint
location ~ ^/airag/ocr/(deleteById|list) {
    allow 10.0.0.0/8;      # internal admin network
    deny all;
    proxy_pass http://jeecgboot_upstream;
}