CVE-2026-108883 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the editThirdAppConfig handler that allows any authenticated user to modify third-party application configurations. Low-privileged attackers can replace client id, client secret, agent id and corp id of DingTalk, WeCom or Feishu integrations to redirect directory synchronisation and messaging to attacker-controlled applications or break them.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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 backend logic. Specifically, the editThirdAppConfig handler lacks proper authorization checks, allowing any authenticated user with low privileges to modify configuration settings for third-party integrations such as DingTalk, WeCom, and Feishu. This flaw stems from an insecure direct object reference or missing function-level access control where the system fails to verify whether the requesting user possesses administrative rights before processing changes to sensitive integration parameters. In a typical enterprise environment, these configurations are considered privileged data that should only be modifiable by system administrators who manage organizational identity and communication channels. The absence of this check means that any valid account on the platform can interact with this endpoint without restriction based on role or permission levels.
The technical impact of this vulnerability is severe due to the nature of the affected parameters, which include client IDs, client secrets, agent IDs, and corp IDs for major enterprise communication platforms. By altering these values, an attacker can effectively hijack the integration points established by the organization. For instance, if a low-privileged user replaces the DingTalk or WeCom credentials with those belonging to an application controlled by the attacker, subsequent directory synchronization processes will begin pulling data from and pushing updates to the attacker's infrastructure rather than the legitimate corporate system. This allows for unauthorized access to employee directories, contact lists, and internal messaging structures that are synchronized through these integrations. The manipulation of corp IDs further enables the attacker to impersonate specific organizational units within the platform ecosystem, potentially bypassing certain security boundaries or approval workflows inherent in those third-party services.
From an operational perspective, this vulnerability facilitates a range of malicious activities including data exfiltration, phishing campaigns, and disruption of business continuity. Attackers can intercept sensitive corporate communications by redirecting message flows through their own applications, leading to potential leakage of confidential information such as strategic plans, financial data, or personal identifiable information stored in employee profiles. Additionally, the ability to break these integrations causes denial-of-service conditions for internal communication tools, impacting productivity and collaboration across the organization. The attack vector is particularly dangerous because it does not require privilege escalation from an external perspective; instead, it exploits existing valid credentials obtained through standard authentication mechanisms such as password theft or session hijacking, making it accessible to a wide range of potential adversaries including disgruntled employees or compromised accounts with minimal access rights.
This vulnerability aligns closely with CWE-284 Improper Access Control and is categorized under the MITRE ATT&CK framework technique T1078 Valid Accounts, as well as potentially T1539 Steal Web Session Cookie if session hijacking precedes exploitation. It also relates to CWE-601 URL Redirection to Untrusted Site which may occur when redirecting directory sync operations. To mitigate this risk, organizations must immediately upgrade JeecgBoot to a version where the editThirdAppConfig endpoint enforces strict role-based access control ensuring only users with administrative privileges can modify third-party application configurations. Developers should implement explicit authorization checks at the controller or service layer that validate user roles against required permissions before processing any changes to sensitive configuration data. Furthermore, implementing multi-factor authentication for administrative accounts and monitoring logs for unusual modification patterns of integration settings can provide additional layers of defense against exploitation attempts. Regular security audits focusing on access control logic across all API endpoints are essential to prevent similar vulnerabilities in future releases.