Description

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Syncope. An administrator with adequate entitlements can get access via REST to the list of existing Access Tokens, including their signed JWT body. These values can be then used to perform further REST requests, impersonating users with higher administration entitlements. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T13:18:45.067Z",
  "pubdate": "2026-09-14T13:18:45.067Z",
  "executiveSummary": "A vulnerability classified as Exposure of Sensitive Information to an Unauthorized Actor exists within Apache Syncope, potentially leading to full administrative account takeover.\nThe vulnerability allows an authenticated administrator with sufficient entitlements to retrieve a list of active access tokens through the product's REST interface.\nThese tokens include the raw, signed JSON Web Token (JWT) bodies, which are sufficient to masquerade as the token owner in subsequent API calls.\nAffected software versions include Apache Syncope 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.7, and 4.1.0-M0 through 4.1.2.\nThe impact is critical as an attacker can perform horizontal or vertical privilege escalation, effectively bypassing existing security controls by impersonating users with higher administrative privileges.\nExploitation requires an existing, authenticated session with specific administrative entitlements. Once an attacker obtains the signed JWT, they possess the credentials necessary to perform actions on behalf of the targeted user, thereby compromising the integrity and confidentiality of the entire identity management infrastructure.",
  "technicalDetails": "The vulnerability resides in the REST API management layer of Apache Syncope, specifically within the endpoint responsible for retrieving system-level authentication metadata.\nThe root cause is an improper authorization check that fails to adequately restrict the visibility of active access tokens to highly privileged system administrators, despite the sensitivity of the data returned by these API calls.\nThe exploitation flow initiates when an attacker, already possessing administrative credentials that grant access to the vulnerable REST endpoint, performs a request to fetch the registry of active Access Tokens. Because the underlying logic does not filter the result set, the server returns a serialized list of these tokens.\nThe payload returned contains the full signed JWT body. In the context of Apache Syncope, these tokens are used to maintain session persistence and represent the identity of the authenticated subject. Since these tokens are cryptographically signed by the server, an attacker who obtains a valid, unexpired token can inject it into the 'Authorization' header of subsequent HTTP requests.\nBy attaching the stolen JWT, the attacker circumvents authentication mechanisms for the duration of the token's validity, effectively assuming the security context (claims and roles) of the original token holder. If the captured token belongs to a super-administrator, the attacker inherits full control over the identity management ecosystem, including user account management, policy configuration, and system settings.\nThe vulnerability affects Apache Syncope versions 3.0.0-M0 through 3.0.16, 4.0.0-M0 through 4.0.7, and 4.1.0-M0 through 4.1.2. The exposure exists entirely via the network-accessible REST interface, making it reachable by any user possessing valid credentials that satisfy the flawed authorization check.\nPost-exploitation, the attacker has the ability to audit system logs, modify directory entries, or provision new administrative accounts, creating a persistent backdoor. Because the action is authenticated and performed using a legitimate JWT, such activities may be difficult to distinguish from standard administrative operations in system logs if token auditing is not granularly implemented."
}