#maven

Users with low privileges (just plain users in the realm) are able to utilize administrative functionalities within Keycloak admin interface. This issue presents a significant security risk as it allows unauthorized users to perform actions reserved for administrators, potentially leading to data breaches or system compromise. **Acknowledgements:** Special thanks to Maurizio Agazzini for reporting this issue and helping us improve our project.

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request. This could lead to an information disclosure vulnerability.

### Summary BoringSSLAEADContext keeps track of how many OHTTP responses have been sent and uses this sequence number to calculate the appropriate nonce to use with the encryption algorithm. Unfortunately, two separate errors combine which would allow an attacker to cause the sequence number to overflow and thus the nonce to repeat. ### Details 1. There is no overflow detection or enforcement of the maximum sequence value. (This is a missed requirement from the draft Chunked Oblivious OHTTP RFC and so should be inherited from the HPKE RFC 9180, Section 5.2). 2. The sequence number (seq) is stored as 32-bit int which is relatively easy to overflow. https://github.com/netty/netty-incubator-codec-ohttp/blob/1ddadb6473cd3be5491d114431ed4c1a9f316001/codec-ohttp-hpke-classes-boringssl/src/main/java/io/netty/incubator/codec/hpke/boringssl/BoringSSLAEADContext.java#L112-L114 ### Impact If the BoringSSLAEADContext is used to encrypt more than 2^32 messages then the AES-GCM nonce will repeat...

### Impact Attackers can exploit the vulnerability to read and delete files and folders from an arbitrary, writable directory as anyone can set the output folder when submitting the request via the `outputFolder` option. ### Patches The issue was fixed via https://github.com/OpenAPITools/openapi-generator/pull/18652 (included in v7.6.0 release) by removing the usage of the `outputFolder` option. ### Workarounds No workaround available. ### References No other reference available.

Jenkins Report Info Plugin 1.2 and earlier does not perform path validation of the workspace directory while serving report files. Additionally, Report Info Plugin does not support distributed builds. This results in a path traversal vulnerability, allowing attackers with Item/Configure permission to retrieve Surefire failures, PMD violations, Findbugs bugs, and Checkstyle errors on the controller file system by editing the workspace path. As of publication of this advisory, there is no fix.

In Eclipse Ditto starting in version 3.0.0 and prior to versions 3.4.5 and 3.5.6, the user input of several input fields of the Eclipse Ditto Explorer User Interface https://eclipse.dev/ditto/user-interface.html was not properly neutralized and thus vulnerable to both Reflected and Stored XSS (Cross Site Scripting). Several inputs were not persisted at the backend of Eclipse Ditto, but only in local browser storage to save settings of "environments" of the UI and e.g. the last performed "search queries", resulting in a "Reflected XSS" vulnerability. However, several other inputs were persisted at the backend of Eclipse Ditto, leading to a "Stored XSS" vulnerability. Those mean that authenticated and authorized users at Eclipse Ditto can persist Things in Ditto which can - when being displayed by other users also being authorized to see those Things in the Eclipse Ditto UI - cause scripts to be executed in the browser of other users.

Silverpeas Core 6.3 is vulnerable to Cross Site Scripting (XSS) via ClipboardSessionController.

### Impact Executing policy checks using custom schematron files invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability. ### Patches This has been patched and users should upgrade to veraPDF v1.24.2 ### 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: <https://github.com/veraPDF/veraPDF-library/issues/1415>

An issue was discovered in Bouncy Castle Java Cryptography APIs before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.