Source
ghsa
### 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...
Microweber Cross Site Scripting vulnerability in Microweber v.2.0.9 allows a remote attacker to execute arbitrary code via the create new backup function in the endpoint /admin/module/view?type=admin__backup
Cross Site Scripting vulnerability in Microweber v.2.0.9 allows a remote attacker to execute arbitrary code via the First Name and Last Name parameters in the endpoint /admin/module/view?type=users
Cross Site Scripting vulnerability in Microweber v.2.0.9 allows a remote attacker to execute arbitrary code via the campaign Name (Internal Name) field in the Add new campaign function
An HTML injection vulnerability in Vaultwarden prior to v1.32.5 allows attackers to execute arbitrary code via injecting a crafted payload into the username field of an e-mail message.
An issue in the component src/api/identity.rs of Vaultwarden prior to v1.32.5 allows attackers to impersonate users, including Administrators, via a crafted authorization request.
Vaultwarden v1.32.5 was discovered to contain an authenticated reflected cross-site scripting (XSS) vulnerability via the component /api/core/mod.rs.