Description

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache Syncope. When the Syncope SRA is configured for CAS authentication, the target Apereo CAS instance's URL is calculated by unconditionally looking at client-supplied forwarded HTTP headers. 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": "6.1",
  "pubDate": "2026-09-14T14:17:08.450Z",
  "pubdate": "2026-09-14T14:17:08.450Z",
  "executiveSummary": "This vulnerability is classified as URL Redirection to Untrusted Site, commonly known as an Open Redirect. It affects the Apache Syncope Secure Reverse Proxy (SRA) component when configured for CAS (Central Authentication Service) authentication.\nThe root cause lies in the application's failure to validate or sanitize client-supplied forwarded HTTP headers when determining the target URL for CAS authentication. An attacker can manipulate these headers to force the application to redirect users to an arbitrary, potentially malicious, third-party domain.\nThe vulnerability poses a significant risk to user security, primarily by facilitating phishing attacks. By masquerading a malicious link behind a trusted Apache Syncope URL, an attacker can deceive users into revealing sensitive credentials or downloading malware.\nThe issue impacts 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. Exploitation does not require prior authentication, and the impact is primarily centered on the loss of user trust and credential harvesting. Users are strongly advised to update to the provided secure versions, 4.0.8 or 4.1.3, to remediate this flaw.",
  "technicalDetails": "The vulnerability resides within the Apache Syncope SRA (Secure Reverse Proxy) module. When the SRA is configured to utilize Apereo CAS for authentication, the logic governing the determination of the CAS server's redirection target fails to perform adequate input validation. Specifically, the application relies on incoming HTTP headers, such as 'X-Forwarded-Host' or similar request headers, to dynamically construct the target redirection URL.\nThe root cause is the implicit trust placed in client-controlled request headers. In a standard secure implementation, the redirection endpoint should be derived from a hardcoded configuration or a strictly allow-listed set of trusted domains. Because Apache Syncope SRA unconditionally trusts the values provided by the client, an attacker can inject malicious hostnames into these headers during the initial request process.\nThe attack flow proceeds as follows: 1. An attacker identifies a target Apache Syncope instance utilizing SRA with CAS authentication. 2. The attacker crafts a malicious HTTP request directed at the Syncope SRA, injecting a malicious URL or host into the forwarded headers (e.g., modifying the 'X-Forwarded-Host' header to point to an attacker-controlled server). 3. Upon receiving this request, the SRA logic reads the attacker-supplied header to construct the CAS authentication URL. 4. The application triggers an HTTP 302 redirect, instructing the victim's browser to navigate to the attacker's domain rather than the legitimate CAS instance. 5. The user is redirected to the attacker-controlled site, which may mimic the legitimate login page, facilitating credential theft or delivering malicious payloads.\nThis vulnerability exists in the network perimeter where the SRA processes incoming requests. It is reachable by any unauthenticated remote attacker capable of sending HTTP requests to the SRA instance. Because the redirection is performed by the trusted application, users are more likely to interact with the malicious site, increasing the success rate of social engineering efforts. The vulnerability remains present across multiple versions (3.0.x, 4.0.x, and 4.1.x) until the specific patched releases are implemented. Post-exploitation, the primary impact is the facilitation of phishing campaigns and potential session hijacking if the attacker successfully intercepts credentials submitted to the fraudulent site. The lack of validation on the redirect target effectively turns the SRA into an open redirector."
}