Tag
#maven
### Impact In RESTEasy the insecure `File.createTempFile()` is used in the `DataSourceProvider`, `FileProvider` and `Mime4JWorkaround` classes which creates temp files with insecure permissions that could be read by a local user. ### Patches Fixed in the following pull requests: * https://github.com/resteasy/resteasy/pull/3409 (7.0.0.Alpha1) * https://github.com/resteasy/resteasy/pull/3423 (6.2.3.Final) * https://github.com/resteasy/resteasy/pull/3412 (5.0.6.Final) * https://github.com/resteasy/resteasy/pull/3413 (4.7.8.Final) * https://github.com/resteasy/resteasy/pull/3410 (3.15.5.Final) ### Workarounds There is no workaround for this issue. ### References * https://nvd.nist.gov/vuln/detail/CVE-2023-0482 * https://bugzilla.redhat.com/show_bug.cgi?id=2166004 * https://github.com/advisories/GHSA-jrmh-v64j-mjm9
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>...
ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.
Cross-site scripting (XSS) vulnerability in the edit Service Access Policy page in Liferay Portal 7.0.0 through 7.4.3.87, and Liferay DXP 7.4 GA through update 87, 7.3 GA through update 29, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a service access policy's `Service Class` text field.
### Impact The welcome and about page includes version and revision information about the software in use (including library and components used). This information is sensitive from a security point of view because it allows software used by the server to be easily identified. ### Proof of Concept 1. Welcome page footer: <img width="432" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/a7fd5151-55d5-432b-9d5d-79136833609f"> 2. About page *build information*. <img width="401" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/59fcd8dd-eaee-4bf8-9578-a2a94b2864db"> ### Patches No patch presently available. ### Workarounds No workaround available, although the ADMIN_CONSOLE can be disabled completely. ### References * [About GeoServer](https://docs.geoserver.org/latest/en/user/webadmin/about.html)
### Summary _Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server._ There is a potential XXE(XML External Entity Injection) vulnerability when http4k handling malicious XML contents within requests, which might allow attackers to read local sensitive information on server, trigger Server-side Request Forgery and even execute code under some circumstances. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ https://github.com/http4k/http4k/blob/25696dff2d90206cc1da42f42a1a8dbcdbcdf18c/core/format/xml/src/main/kotlin/org/http4k/format/Xml.kt#L42-L46 XML contents is parsed with DocumentBuilder without security settings on or external entity enabled ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ #### ...
### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...
### Impact Executing policy checks using custom schematron files via the CLI invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability. ### Patches We are currently working on a patch that will be released when ready. ### Workarounds This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust. ### References Original issue: #1488