JeecgBoot EUVD-2026-96593

Requires a valid low-privileged authenticated account on a JeecgBoot instance (version through 3.9.5) and knowledge of a target OSS file record id to pass to GET /sys/oss/file/queryById; ids appear to be enumerable, enabling iteration across other users' records. Limiting factors: authentication is required (PR:L, so no unauthenticated access), only confidentiality of file metadata/URLs is affected (no write or availability impact), and the attacker must supply a valid record id. No special non-default configuration is indicated - the vulnerable queryById handler is part of the standard system OSS file module.

This is a genuine but modest-severity information-disclosure issue, not a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 Medium score are internally consistent with the description: a network-reachable endpoint abusable by any low-privileged authenticated user with low complexity, impacting confidentiality only (VC:L, VI:N, VA:N) and with no scope change. Publicly available POC code exists (VulnCheck-reported, with a GitHub exploit script), which raises practical risk since exploitation is trivial once a record id is known. However, there is NO CISA KEV listing and NO EPSS score was supplied, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals and should not be conflated. The requirement for prior authentication (PR:L) and knowledge of a valid record id meaningfully limits mass-scanning abuse, pointing to opportunistic post-authentication data harvesting rather than unauthenticated mass compromise. One nuance to verify with the vendor: the vulnerability leaks 'direct storage URLs,' so if those object-storage URLs are themselves unauthenticated/presigned-public, the downstream confidentiality impact on actual file contents could exceed the VC:L rating applied to the record metadata.

A low-privileged authenticated JeecgBoot user (e.g., a basic registered account) sends GET /sys/oss/file/queryById with a guessed or enumerated record id. Because the handler omits an ownership/authorization check, the server returns another user's original file name and direct storage URL, which the attacker can iterate over to harvest other tenants' uploaded file references. A public POC script (poc_record_query_by_id.py) automates this request.