JeecgBoot CVE-2026-11502

The third-party login feature - specifically the DingTalk, WeChat, or equivalent OAuth provider integration - must be explicitly enabled in the JeecgBoot deployment; the vendor states this is optional and likely inactive in most projects, which substantially limits the affected population. A victim must actively click a specially crafted OAuth login URL provided by the attacker; passive or drive-by exploitation is not possible (UI:P in CVSS 4.0 vector). The attack is rated High Complexity (AC:H), reflecting that the attacker must successfully deliver the crafted link via social engineering and the victim must complete the OAuth authentication flow before the redirect occurs. The attacker requires no prior authentication or account on the target JeecgBoot instance (PR:N). Exploitation is limited to deployments running JeecgBoot 3.9.0 through 3.9.2 with an active third-party OAuth login configuration.

The CVSS 4.0 score of 1.3 is among the lowest assignable, and the vector encodes multiple compounding mitigants: High Attack Complexity (AC:H), passive user interaction required (UI:P), no confidentiality impact, and only Low integrity impact to the vulnerable system (VI:L) with zero impact to subsequent systems (SC:N/SI:N/SA:N). The exploit maturity modifier E:P confirms a POC exists, which distinguishes this from purely theoretical risk but does not elevate the overall score significantly. No EPSS data was provided in the intelligence feed; however, the low CVSS, the optional nature of the affected feature, and the vendor's own published assessment of low exploitability collectively suggest an EPSS probability well below thresholds warranting emergency response. No CISA KEV listing exists, indicating no confirmed active exploitation campaign. The primary real-world risk is targeted phishing: a threat actor could use a legitimately branded JeecgBoot login URL to lend credibility to a redirect to a credential-harvesting site. This is a genuine - if narrow - risk for organizations with third-party login enabled and user populations susceptible to OAuth phishing.

An attacker identifies a JeecgBoot instance with DingTalk or WeChat login enabled, constructs a legitimate-looking OAuth login URL with the state parameter set to redirect to a credential-harvesting site, and distributes this link via a phishing email targeting the organization's employees. When a victim clicks the link and completes authentication with their DingTalk or WeChat credentials, the application's unvalidated sendRedirect call sends them to the attacker's site rather than the JeecgBoot dashboard. A public proof-of-concept demonstrating this technique is referenced in GitHub issue #9639, lowering the skill threshold for attempted exploitation.