CVE-2026-108880 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the PUT /sys/dict/editDictByLowAppId endpoint that allows any authenticated user to modify low-code application dictionaries. Attackers can supply a dictionary's low_app_id, obtained from GET /sys/dict/list, via the lowAppId parameter or X-Low-App-ID header to rename dictionaries and replace their items.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms within the application's dictionary management subsystem. Specifically, this flaw resides in the PUT /sys/dict/editDictByLowAppId endpoint, which is designed to update low-code application dictionaries. The core technical deficiency lies in the server-side validation logic that fails to verify whether the authenticated user initiating the request possesses administrative privileges or ownership rights over the specific dictionary identified by the provided identifier. Instead of enforcing strict authorization checks based on user roles and resource ownership, the system relies primarily on the presence of a valid authentication token. This oversight allows any logged-in user, regardless of their privilege level, to interact with this endpoint without restriction.
The exploitation path for this vulnerability is straightforward yet impactful. An attacker begins by performing reconnaissance using the GET /sys/dict/list endpoint to enumerate existing dictionaries and extract their associated low_app_id values. Once a target dictionary's identifier is obtained, the attacker constructs a malicious HTTP PUT request targeting the editDictByLowAppId endpoint. By supplying the stolen low_app_id either through the query parameter or via the X-Low-App-ID header, the attacker can successfully execute modification operations on the targeted resource. The system processes these requests as legitimate administrative actions because it does not cross-reference the requesting user's identity with the ownership metadata of the dictionary being modified. This lack of object-level authorization control enables unauthorized actors to rename dictionaries and replace their internal items at will.
The operational impact of this vulnerability extends beyond simple data modification, potentially leading to significant integrity violations within low-code applications that rely on these dictionaries for configuration and behavior definition. Dictionaries in JeecgBoot often store critical lookup values, status codes, or enumeration constants used by various modules across the platform. By altering dictionary items, an attacker can manipulate how forms render, change default statuses of records, or inject malicious options into dropdown menus. This capability facilitates broader attacks such as privilege escalation if certain roles are tied to specific dictionary entries, data corruption that affects downstream reporting and analytics, or denial of service by removing essential configuration values required for application functionality. In enterprise environments where JeecgBoot is used for rapid development, this flaw undermines the trust model assumed in multi-tenant or role-based access control scenarios.
From a classification perspective, this vulnerability aligns with CWE-269, which denotes Improper Privilege Assignment, as well as CWE-862, Missing Authorization, because the application fails to enforce proper access controls on sensitive resources. In terms of tactical mapping within the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts and potentially T1530 Data from Cloud Storage if the dictionaries contain sensitive configuration data, though primarily it falls under lateral movement or persistence mechanisms depending on how the modified dictionary is exploited in subsequent stages. The vulnerability highlights a common pattern in web applications where API endpoints are exposed without adequate middleware checks for resource ownership, particularly when identifiers like low_app_id are passed directly from client inputs rather than being derived from server-side session context.
Mitigation strategies must focus on implementing robust authorization logic at the application layer. Developers should modify the PUT /sys/dict/editDictByLowAppId endpoint to verify that the authenticated user has explicit administrative rights or is the designated owner of the dictionary identified by low_app_id before allowing any modifications. This can be achieved by querying a database table that maps dictionaries to their respective owners and validating this relationship during request processing. Additionally, implementing role-based access control checks ensures that only users with specific high-privilege roles, such as system administrators, are permitted to execute write operations on configuration data. Input validation should also be reinforced to ensure that the low_app_id provided matches an existing resource owned by the requester. For immediate remediation without code changes, deploying a Web Application Firewall rule to restrict access to this endpoint based on user role headers or IP whitelisting for administrative functions can provide temporary protection while patches are developed and deployed.