This CVE has been rejected.

This issue was addressed through improved state management. This issue is fixed in tvOS 17.4, iOS 17.4 and iPadOS 17.4, macOS Sonoma 14.4, watchOS 10.4. An attacker with physical access may be able to use Siri to access sensitive user data.

Affected: Maven: io.crate:crate

**Component:** `io.crate.protocols.http.HttpBlobHandler` **Affected:** verified against CrateDB 6.2.7 (latest at time of report; the bug has existed since the blob HTTP handler was introduced) **Impact:** any authenticated user can read or delete any blob whose SHA-1 digest they know, and can plant new blobs unconditionally, in any blob table, regardless of `GRANT`s.

---

## Summary

CrateDB has two ways to access blob storage: SQL (`SELECT ... FROM blob.<table>` and friends) and the blob HTTP API (`GET|PUT|DELETE /_blobs/{table}/{digest}`). The SQL path goes through `AccessControl`, which is what enforces privilege grants; that's why `SELECT digest FROM blob.secret_blobs` fails for a user who has no grants on the table.

The HTTP path authenticates the request but never asks `AccessControl` whether the authenticated user is allowed to touch the table. So a user with no grants gets `MissingPrivilegeException` from SQL and `200 OK` plus the blob bytes from `GET /_blobs/secret_blobs/<digest>`.

## Where it lives

`server/src/main/java/io/crate/protocols/http/HttpBlobHandler.java`. The dispatcher:

```java // HttpBlobHandler.java:176 private void handleBlobRequest(@Nullable HttpContent content) throws IOException { if (possibleRedirect(index, digest)) { return; }

if (method.equals(HttpMethod.GET)) { get(index, digest); reset(); } else if (method.equals(HttpMethod.HEAD)) { head(index, digest); } else if (method.equals(HttpMet…

Affected: NuGet: Umbraco.CMS

#### Impact Backoffice users with send for approval permission but not publish permission are able to publish in some scenarios.

#### Explanation of the vulnerability Backoffice users without permission to publish content, but only to send for approval, can bypass the restriction by modifying the request body of the "Send for Approval" request.

Affected: Packagist: silverstripe/framework

When a new `Member` record was created in the cms it was possible to set a blank password. If an attacker knows the email address of the user with the blank password then they can attempt to log in using an empty password. The default member authenticator, login form and basic auth all require a non-empty password, however if a custom authentication method is used it may allow a successful login with the empty password. Starting with this release, blank passwords are no no longer allowed when members are created in the CMS. Programatically created `Member` records, such as those used in unit tests, still allow blank passwords. You may have some `Member` records in your system already which have empty passwords. To detect these, you can loop over all `Member` records with `Member::get()` and pass each record into the below method. It might be sensible to create a [`BuildTask`](https://api.silverstripe.org/5/SilverStripe/Dev/BuildTask.html) for this purpose. ```php private function memberHasBlankPassword(Member $member): bool { // skip default admin as this is created programatically if ($member->isDefaultAdmin()) { return false; } // return true if a blank password is valid for this member $authenticator = new MemberAuthenticator(); return $authenticator->checkPassword($member, '')->isValid(); } ``` Once you have identified the records with empty passwords, it's up to you how to handle this. The mos…

Affected: Packagist: kimai/kimai

### Summary

The SAML authentication success handler in Kimai returns the `RelayState` POST parameter as a redirect destination without validating the host or scheme. After a user successfully authenticates via SAML, they are redirected to an attacker-controlled URL if the IdP includes a malicious `RelayState` value. This enables phishing attacks that steal credentials or session tokens post-SSO.

*Requires SAML to be enabled (non-default configuration).*

### Details

Vulnerable file: `src/Saml/Security/SamlAuthenticationSuccessHandler.php`

```php // Line 27-33 $relayState = $request->request->get('RelayState', $request->query->get('RelayState')); if (\is_scalar($relayState)) { $relayState = (string) $relayState; if ($relayState !== $this->httpUtils->generateUri($request, (string) $this->options['login_path'])) { return $relayState; // No host/scheme validation — any URL accepted } } ```

The only check is that `RelayState` does not equal the configured `login_path`. Any external URL (e.g., `https://attacker.com`) passes this check and is returned as the redirect destination.

The existing unit test `SamlAuthenticationSuccessHandlerTest::testRelayState()` confirms this behavior — an absolute URL in `RelayState` results in a redirect to that URL with no restriction.

### Steps to Reproduce

``` 1. Enable SAML authentication in Kimai 2. Configure a SAML IdP (e.g., SimpleSAMLphp) 3. Initiate IdP-initiated SSO with RelayState=https://attacker.com — or i…

Affected: NuGet: Magick.NET-Q16-AnyCPU, NuGet: Magick.NET-Q16-HDRI-AnyCPU, NuGet: Magick.NET-Q16-HDRI-OpenMP-arm64, NuGet: Magick.NET-Q16-HDRI-OpenMP-x64, NuGet: Magick.NET-Q16-HDRI-arm64, NuGet: Magick.NET-Q16-HDRI-x64, NuGet: Magick.NET-Q16-HDRI-x86, NuGet: Magick.NET-Q16-OpenMP-arm64, NuGet: Magick.NET-Q16-OpenMP-x64, NuGet: Magick.NET-Q16-OpenMP-x86 and 9 more

If a `texture` attribute is specified for a TXT file, an attempt will be made to read it via `texture=ReadImage(read_info,exception);`. Later, when retrieving metrics via the `GetTypeMetrics` function, if this function fails (i.e., `status == MagickFalse`), the calling function will exit immediately but fail to release the texture object, leading to memory leakage.

A broken access control vulnerability previously discovered in the Trend Vision One Role Name component could have allowed an administrator to create users who could then change the role of the account and ultimately escalate privileges.

Please note: ths issue has already been addressed on the backend service and is no longer considered an active vulnerability.

Affected: crates.io: libcrux-ecdh, crates.io: libcrux-ed25519, crates.io: libcrux-psq

In accordance with our [security policy for `libcrux`](https://github.com/cryspen/libcrux/blob/main/SECURITY.md), we publish a GitHub security advisory for any releases whose CHANGELOG includes bug-fixes, and encourage our users to upgrade. The latest releases of the `libcrux-ecdh`, `libcrux-ed25519` and `libcrux-psq` crates contain the following bug-fixes:

## `libcrux-ecdh`

- [#1301](https://github.com/cryspen/libcrux/pull/1301): Check length and clamping in X25519 secret validation. This is a breaking change since errors are now raised on unclamped X25519 secrets or inputs of the wrong length

## `libcrux-ed25519`

- [#1320](https://github.com/cryspen/libcrux/pull/1320): Remove duplicated clamping step during key generation

The issue fixed in #1320 was first reported by Nadim Kobeissi. ## `libcrux-psq`

- [#1319](https://github.com/cryspen/libcrux/pull/1319): Propagate AEADError instead of panicking - [#1301](https://github.com/cryspen/libcrux/pull/1301): Fix broken clamping check for imported X25519 secret keys

The issue fixed in #1319 was first reported by Nadim Kobeissi.

Affected: PyPI: kiwitcms

## Summary

In Kiwi TCMS the fields `TestCase.extra_link` and `TestPlan.extra_link` were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

## Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a `Content-Security-Policy` header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.