Description

Incorrect Authorization vulnerability in Apache Syncope. Any search requests are transformed into SQL, Neo4J or Elasticsearch / Opensearch queries, depending on the actual deployment configuration. An important component of such transformation is the Realms filter, which ensures that the search results are matching the requester's permissions. For non-recursive search requests it is possible that such Realms filter is rendered as empty, thus voiding any restriction on requester privileges. 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": "9.8",
  "pubDate": "2026-09-14T13:18:45.313Z",
  "pubdate": "2026-09-14T13:18:45.313Z",
  "executiveSummary": "An incorrect authorization vulnerability exists within Apache Syncope that allows unauthorized data access due to flawed search query generation.\nThe vulnerability occurs during the translation of search requests into backend query languages (SQL, Neo4J, Elasticsearch/OpenSearch), specifically involving the Realms filter component.\nFor non-recursive search requests, the Realms filter may be rendered as an empty value, effectively nullifying the security constraints intended to restrict results based on the requester's assigned permissions.\nThis issue 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.\nThe impact involves unauthorized information disclosure, as attackers can bypass authorization controls to access data they are not privileged to view.\nExploitation requires the ability to submit specific search requests where non-recursive parameters trigger the misconfiguration of the backend filter.\nThis vulnerability poses a significant risk to data confidentiality, necessitating immediate patching.",
  "technicalDetails": "The vulnerability resides within the query transformation mechanism of Apache Syncope, which converts user-supplied search criteria into target query languages, including SQL, Neo4J, and Elasticsearch/OpenSearch.\nA critical security requirement in this process is the injection of a 'Realms' filter, which acts as a mandatory access control mechanism to ensure that the backend search scope is limited to the realms for which the authenticated user holds sufficient privileges.\nThe root cause is a flaw in the logic responsible for constructing this Realms filter. Specifically, when a search request is designated as non-recursive, the transformation engine may incorrectly render the filter as an empty or null set instead of applying the expected authorization constraints.\nBy failing to define the scope restriction, the resulting query executed against the backend data store ignores the user's privilege boundaries.\nThe attack flow proceeds as follows: An authenticated user with restricted privileges initiates a non-recursive search request via the application interface or API. The application component responsible for query building evaluates the request parameters and fails to correctly populate the Realms filter due to the aforementioned logic error. The resulting query, which lacks the necessary restrictive clauses, is executed against the backend database or search engine. Consequently, the backend returns the full result set (or a broader set than intended), bypassing the intended authorization checks.\nThis vulnerability allows an attacker to retrieve, view, or potentially influence data that should be protected by the multi-tenancy and authorization model of Apache Syncope.\nThe vulnerability is limited to non-recursive search contexts where the filter generation logic fails. Because this occurs at the query translation layer, it affects all supported backend storage engines (SQL, Neo4J, Elasticsearch/OpenSearch).\nAffected 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. The security flaw is remediated in version 4.0.8 and 4.1.3."
}