CVE-2024-1248: Federated JIT Provisioning Role Overwrite in WSO2 Identity Products

Technical summary

This vulnerability stems from improper role segregation in JIT provisioning workflows during federated authentication. When silent JIT provisioning encounters a federated user whose username matches an existing local account, the system fails to isolate the federated user's role assignments from the local account's security context. The result is an unintended write operation that overwrites local user roles with federated IDP-assigned roles. Exploitation requires three conditions: (1) federated authentication with silent JIT enabled, (2) knowledge of an existing local username, and (3) access to an attacker-controlled federated IDP or compromise of a trusted IDP. The CVSS 3.1 score of 4.8 (MEDIUM, network-accessible, high attack complexity) reflects the integrity and availability impact from role manipulation, constrained by the attack prerequisites.

Business impact

This vulnerability primarily threatens organizations using federated identity solutions with silent JIT provisioning. The main business risk is privilege escalation for targeted local accounts—an attacker can downgrade a user's role access, potentially disrupting legitimate business operations or compliance enforcement. While the federated IDP typically assigns minimal roles by default, if an organization has configured the federated IDP to assign elevated roles, the risk escalates significantly. Downstream effects include unauthorized access denial, operational disruption for key users, and potential audit/compliance violations if role-based access controls are used for regulatory reporting. The need to re-provision and validate affected user roles creates incident response overhead.

Affected systems

CVE-2024-1248 affects the following WSO2 products: API Manager, Identity Server, Identity Server as Key Manager, Open Banking AM, and Open Banking IAM. Any deployment of these products using federated authentication with silent JIT provisioning enabled is potentially vulnerable. Organizations using these platforms should audit whether federated SSO is active and whether JIT user provisioning is enabled for any upstream identity providers. Non-federated deployments or those with JIT provisioning explicitly disabled are not affected.

Exploitability

Exploitation has moderate barriers. An attacker must (1) discover or know a valid local username within the target organization, (2) have or control access to a federated identity provider configured to trust the victim organization, and (3) perform account creation via federated authentication using that username. The high attack complexity (AC:H in CVSS) reflects these prerequisites. Once conditions align, the attack itself is straightforward—the provisioning mechanism does the privilege escalation automatically. No special techniques, zero-days, or advanced exploitation are required; the vulnerability is a logic flaw in normal provisioning flow. This has not been added to CISA's Known Exploited Vulnerabilities catalog.

Remediation

Remediation involves two primary paths: (1) upgrade affected WSO2 products to patched versions that properly segregate federated and local user roles during JIT provisioning, and (2) immediately disable silent JIT provisioning if upgrades are not feasible. Organizations should also audit their federated IDP configurations to ensure only necessary roles are assigned during provisioning. Consider implementing additional controls such as role change alerts, restricting JIT provisioning to new accounts only (not existing local accounts), and requiring administrative approval for cross-authentication provisioning workflows.

Patch guidance

Contact WSO2 directly or consult the vendor's security advisory for specific patch version numbers and availability timelines for each affected product. Patches should be validated in a test environment before production deployment, as identity and access management changes carry operational risk. Given the complexity of federated auth configurations, schedule maintenance windows and notify users of any potential session disruption. After patching, re-verify that role assignments for all affected users are correct, as the patch may not automatically restore pre-exploitation role states.

Detection guidance

Monitor authentication and provisioning logs for patterns indicating role overwrites during federated user creation. Specifically, look for: (1) federated user creation events where a username matches an existing local account, (2) unexplained role changes tied to JIT provisioning events, and (3) audit trail gaps in identity management systems. Implement alerting on role modification events, particularly downgrades or changes initiated by non-administrative accounts. Review user access reports comparing expected roles (from your authorization matrix) to actual assigned roles, flagging discrepancies. Correlate failed and successful authentication events from federated IDPs with role change timestamps.

Why prioritize this

This vulnerability warrants prompt but not emergency action. The MEDIUM severity and high attack complexity mean it is not a critical system threat, but the targeted nature of the attack (can degrade specific user privileges) and the prevalence of federated auth in modern organizations warrant prioritization within normal patch cycles. Organizations heavily reliant on federated identity platforms should prioritize higher. Those with strict role-based access controls tied to compliance (healthcare, finance) should also elevate priority. It does not currently appear in active exploit campaigns (KEV status: false).

Risk score, explained

The CVSS 3.1 score of 4.8 reflects a network-accessible attack (AV:N) with high complexity (AC:H), no privileges required (PR:N), no user interaction (UI:N), and unchanged scope (S:U). Impact is limited to integrity loss (role overwrite) and availability loss (access disruption), with no confidentiality compromise. The score is moderate because while the attack is network-reachable, it requires knowledge of valid usernames and either control of or access to a federated IDP—realistic but not trivial. The severity is constrained further by the fact that federated IDPs typically assign minimal roles, limiting damage unless explicitly misconfigured.

Frequently asked questions