ghsa

### Impact An out-of-bounds read was found in Exiv2 versions v0.28.5 and earlier. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The out-of-bounds read is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to cause a denial of service by crashing Exiv2, if they can trick the victim into running Exiv2 on a crafted image file. Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. For example, to trigger the bug in the Exiv2 command-line application, you need to add an extra command-line argument such as delete. ### Patches The bug is fixed in version v0.28.6. ### Credit Thank you to @dragonArthurX for reporting this issue. ### Details (from original report by @dragonArthurX ) **Version:** Tested on v0.28.5 (latest official release) Commit: 907169fa...

A Session Fixation vulnerability existed in Payload's SQLite adapter due to identifier reuse during account creation. A malicious attacker could create a new account, save its JSON Web Token (JWT), and then delete the account, which did not invalidate the JWT. As a result, the next newly created user would receive the same identifier, allowing the attacker to reuse the JWT to authenticate and perform actions as that user. This issue has been fixed in version 3.44.0 of Payload.

Payload uses JSON Web Tokens (JWT) for authentication. After log out JWT is not invalidated, which allows an attacker who has stolen or intercepted token to freely reuse it until expiration date (which is by default set to 2 hours, but can be changed). This issue has been fixed in version 3.44.0 of Payload.

A malicious user may submit a specially-crafted complex payload that otherwise meets the default request size limit which results in excessive memory and CPU consumption of Vault. This may lead to a timeout in Vault’s auditing subroutine, potentially resulting in the Vault server to become unresponsive. This vulnerability, CVE-2025-6203, is fixed in Vault Community Edition 1.20.3 and Vault Enterprise 1.20.3, 1.19.9, 1.18.14, and 1.16.25.

### Summary It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the [specification](https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt). Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. ### Mitigations The release v0.5.14 includes following mitigations: - The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size. - The default is 2 Gigabytes (2^31 bytes). - Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig. - The dictionary size will not ...

### Summary If users log in to Coder via OIDC, and the OpenID Identity Provider does not return a refresh token, then Coder may allow their web session to continue beyond the expiration of the token returned by the OpenID Identity Provider. ### Details When a user logs in via OIDC, Coder stores the OIDC token and refresh token (if any) in its datastore and sets an APIKey in the user's cookies. If there is a refresh token, then when the OIDC token is expired and a request is made with the APIKey, we attempt to refresh the OIDC token. If refresh fails, the Coder API request is also failed and the user needs to log in again. However, if there is no refresh token provided, then affected versions of Coder fail to enforce the expiry of the OIDC token, and allow users to make API requests even if it is expired so long as their APIKey stored in cookies has not expired. Coder APIKeys have an expiry and lifetime of 24 hours, but Coder is configured to extend the lifetime of the APIKey by up t...

This is the same vulnerability as https://github.com/edgelesssys/contrast/security/advisories/GHSA-h5f8-crrq-4pw8. The original vulnerability had been fixed for release `v1.8.1`, but the fix was not ported to the main branch and thus not present in releases `v1.9.0` ff. Below is a brief repetition of the relevant sections from the first GHSA, where you can find the full details. ### Impact * [Workload secrets](https://docs.edgeless.systems/contrast/1.11/architecture/secrets#workload-secrets) are visible to Kubernetes users with `get` or `list` permission on `pods/logs`, and thus need to be considered compromised. * Since workload secrets are used for [encrypted storage](https://docs.edgeless.systems/contrast/1.11/howto/encrypted-storage) and [Vault integration](https://docs.edgeless.systems/contrast/1.11/howto/vault), those need to be considered compromised, too. ### Patches Patches: * https://github.com/edgelesssys/contrast/commit/5a5512c4af63c17bb66331e7bd2768a863b2f225 * https...

### Impact Any admin that can create or modify and execute process-definitions could gain access to sensitive data or resources. This includes but is not limited to: - Running executables on the application host - Inspecting and extracting data from the host environment or application properties - Spring beans (application context, database pooling) ### Attack requirements The following conditions have to be met in order to perform this attack: - The user must be logged in - The user must have the admin role (ROLE_ADMIN), which is required to change process definitions - The user must have some knowledge about running scripts via a the Camunda/Operator engine ### Patches Version 12.16.0 and 13.1.2 have been patched. It is strongly advised to upgrade. ### Workarounds If no scripting is needed in any of the processes, it could be possible to disable it altogether via the `ProcessEngineConfiguration`: ``` @Component class NoScriptEnginePlugin : ProcessEnginePlugin { override fun p...

### Impact When visiting a specific URL, an anonymous user could cause the NodeJS server part of Volto to quit with an error. ### Patches The problem has been patched and the patch has been backported to Volto major versions down until 16. It is advised to upgrade to the latest patch release of your respective current major version: - Volto 16: [16.34.0](https://github.com/plone/volto/releases/tag/16.34.0) - Volto 17: [17.22.1](https://github.com/plone/volto/releases/tag/17.22.1) - Volto 18: [18.24.0](https://github.com/plone/volto/releases/tag/18.24.0) - Volto 19: [19.0.0-alpha4](https://github.com/plone/volto/releases/tag/19.0.0-alpha.4) ### Workarounds Make sure your setup automatically restarts processes that quit with an error. This won't prevent a crash, but it minimises downtime. ### Report The problem was discovered by FHNW, a client of Plone provider kitconcept, who shared it with the Plone Zope Security Team (security@plone.org).

FormCms v0.5.5 contains a stored cross-site scripting (XSS) vulnerability in the avatar upload feature. Authenticated users can upload .html files containing malicious JavaScript, which are accessible via a public URL. When a privileged user accesses the file, the script executes in their browser context.