JeecgBoot EUVD-2026-96597

Exploitation requires (1) a valid authenticated account on the target JeecgBoot instance - PR:L, any low-privileged tenant user suffices, no admin needed; (2) a multi-tenant deployment where multiple tenants' sys_tenant records exist to be enumerated; and (3) reachability of the SysTenantController queryTenantAuthInfo endpoint over the network. The specific trigger is that the queryTenantAuthInfo handler performs no ownership/authorization check, so supplying another tenant's small integer ID returns that tenant's record. Limiting factors: authentication is mandatory (not unauthenticated), impact is confined to reading tenant join codes and company-profile fields (no write/integrity or availability impact), and value is low for single-tenant installations where there are no other tenants to enumerate.

This is a moderate, access-control (CWE-862) information-disclosure issue, not a high-urgency flaw. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with only low confidentiality impact (VC:L) and no integrity/availability impact yields a MEDIUM 5.3 - consistent with the description: a low-privileged but authenticated user reads other tenants' sys_tenant records. Publicly available exploit code exists (a GitHub POC and a VulnCheck advisory are referenced), which raises real-world likelihood of opportunistic abuse, but the vulnerability is NOT in CISA KEV and no active exploitation is claimed, so this is 'publicly available exploit code exists' rather than confirmed in-the-wild use. No EPSS score and no SSVC decision data were provided in the input, so automatability and exploitation-trend signals cannot be compared - this limits precision of the risk estimate. The requirement for valid authentication (PR:L) is the key mitigating factor that keeps this out of critical territory: the attacker must already have a tenant account. Bottom line: a legitimate priority for multi-tenant JeecgBoot deployments because exploitation is trivial (AC:L, simple integer-ID iteration) and POC is public, but the impact is bounded to disclosure of tenant join codes and company-profile fields, not system compromise.

An attacker who holds any low-privileged tenant account on a JeecgBoot instance repeatedly calls the SysTenantController queryTenantAuthInfo endpoint, incrementing small integer tenant IDs. Because the handler performs no ownership/authorization check, the attacker harvests other tenants' full sys_tenant records - including house numbers used as tenant join codes and company profile data. A public POC (poc_tenant_ownership_and_pack_approval.py) demonstrating this is already available on GitHub.