ghsa

### Problem A vulnerability has been identified in the backend user interface functionality involving deep links. Specifically, this functionality is susceptible to Cross-Site Request Forgery (CSRF). Additionally, state-changing actions in downstream components incorrectly accepted submissions via HTTP GET and did not enforce the appropriate HTTP method. Successful exploitation of this vulnerability requires the victim to have an active session on the backend user interface and to be deceived into interacting with a malicious URL targeting the backend, which can occur under the following conditions: * the user opens a malicious link, such as one sent via email. * the user visits a compromised or manipulated website while the following settings are misconfigured: + `security.backend.enforceReferrer` feature is disabled, + `BE/cookieSameSite` configuration is set to `lax` or `none` The vulnerability in the affected downstream component “Log Module” allows attackers to remove log e...

### Problem Applications that use `TYPO3\CMS\Core\Http\Uri` to parse externally provided URLs (e.g., via a query parameter) and validate the host of the parsed URL may be vulnerable to open redirect or SSRF attacks if the URL is used after passing the validation checks. ### Solution Update to TYPO3 versions 9.5.49 ELTS, 10.4.48 ELTS, 11.5.42 ELTS, 12.4.25 LTS, 13.4.3 LTS that fix the problem described. ### Credits Thanks to Sam Mush who reported this issue and to TYPO3 core & security team member Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2025-002](https://typo3.org/security/advisory/typo3-core-sa-2025-002)

### Problem It has been discovered that the install tool password has been logged as plaintext in case the password hashing mechanism used for the password was incorrect. ### Solution Update to TYPO3 versions 13.4.3 LTS that fixes the problem described. ### Credits Thanks to TYPO3 core & security team member Oliver Hader who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2025-001](https://typo3.org/security/advisory/typo3-core-sa-2025-001)

### Overview OpenFGA v1.3.8 to v1.8.2 (Helm chart openfga-0.1.38 to openfga-0.2.19, docker v1.3.8 to v.1.8.2) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. ### Am I Affected? You are affected by this authorization bypass vulnerability if you are using OpenFGA v1.3.8 to v1.8.2, specifically under the following conditions: 1. Calling Check API or ListObjects with a model that uses [conditions](https://openfga.dev/docs/modeling/conditions), and 2. OpenFGA is configured with caching enabled (`OPENFGA_CHECK_QUERY_CACHE_ENABLED`), and 3. Check API call or ListObjects API calls contain [contextual tuples](https://openfga.dev/docs/concepts#what-are-contextual-tuples) that include conditions. ### Fix Upgrade to v1.8.3. This upgrade is backwards compatible.

A potential Denial of Service (DoS) vulnerability has been identified in Keycloak, which could allow an administrative user with the rights to change realm settings to disrupt the service. This is done by modifying any of the security headers and inserting newlines, which causes the Keycloak server to write to a request that is already terminated, leading to a failure of said request. Service disruption may happen, users will be unable to access applications relying on Keycloak, or any of the consoles provided by Keycloak itself on the affected realm.

A security vulnerability has been identified that allows admin users to access sensitive server environment variables and system properties through user-configurable URLs. Specifically, when configuring backchannel logout URLs or admin URLs, admin users can include placeholders like ${env.VARNAME} or ${PROPNAME}. The server replaces these placeholders with the actual values of environment variables or system properties during URL processing.

### Summary Jte HTML templates with `script` tags or script attributes that include a Javascript template string (backticks) are subject to XSS. ### Details The `javaScriptBlock` and `javaScriptAttribute` methods in the `Escape` class ([source](https://github.com/casid/jte/blob/main/jte-runtime/src/main/java/gg/jte/html/escape/Escape.java#L43-L83)) do not escape backticks, which are used for Javascript [template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#description). Dollar signs in template strings should also be escaped as well to prevent undesired interpolation. ### PoC 1. Use the [Jte Gradle Plugin](https://jte.gg/gradle-plugin/) with the following code in `src/jte/xss.jte`: ```html @param String someMessage <!DOCTYPE html> <html lang="en"> <head> <title>XSS Test</title> <script>window.someVariable = `${someMessage}`;</script> </head> <body> <h1>XSS Test</h1> </body> </html>...

### Impact The Heartcore headless client library depends on [Refit ](https://github.com/reactiveui/refit) to assist in making HTTP requests to Heartcore public APIs. Refit recently published an advisory regarding a CRLF injection vulnerability whereby it is possible for a malicious user to smuggle additional headers or potentially body content into a request. This shouldn't affect Heartcore client library usage as the vulnerable method - `HttpHeaders.TryAddWithoutValidation` - is not used. However, since Refit is a transient dependency for applications using this library, then any users making direct use of Refit could be vulnerable. ### Patches The vulnerable version of Refit has been upgraded to a secure version, as of Umbraco.Headless.Client.Net version 1.5.0, available on [Nuget](https://www.nuget.org/packages/Umbraco.Headless.Client.Net/1.5.0). ### Workarounds If calling Refit from your own code, set any necessary HTTP headers without use of `HttpHeaders.TryAddWithoutValidation...

This issue was identified during Quarkslab's audit of the timestamp feature. ### Summary During the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified. ### Details During timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by `notation`. ### Impact This could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations.

### Summary The issue was identified during Quarkslab's security audit on the Certificate Revocation List (CRL) based revocation check feature. After retrieving the CRL, notation-go attempts to update the CRL cache using the os.Rename method. However, this operation may fail due to operating system-specific limitations, particularly when the source and destination paths are on different mount points. This failure could lead to an unexpected program termination. ### Details In method `crl.(*FileCache).Set`, a temporary file is created in the OS dedicated area (like /tmp for, usually, Linux/Unix). The file is written and then it is tried to move it to the dedicated `notation` cache directory thanks `os.Rename`. As specified in Go documentation, OS specific restriction may apply. When used with Linux OS, it is relying on `rename` syscall from the libc and as per the [documentation](https://man7.org/linux/man-pages/man2/rename.2.html), moving a file to a different mountpoint raises an `E...