ghsa

### Summary Due to a missing error propagation in function `GetNamespaceSelectorsFromNamespaceLister` in `pkg/utils/engine/labels.go` it may happen that policy rules using namespace selector(s) in their `match` statements are mistakenly not applied during admission review request processing. As a consequence, security-critical mutations and validations are bypassed, potentially allowing attackers with K8s API access to perform malicious operations. ### Details As a policy engine Kyverno is a critical component ensuring the security of Kubernetes clusters by apply security-relevant policy rules in the Kubernetes admission control process. We encountered a case where Kyverno did not apply policy rules which should have been applied. This happened in both the mutation and the validation phase of admission control. Effectively Kyverno handled the admission review requests as if those policy rules did not exist. Consequently, the Kube API request was accepted without applying securit...

### Summary Allowlist module contains a bypass vulnerability ### Details The logic for using an allowlist on a Modular Account V2 contained a bug that allowed session keys to bypass any allowlist configuration ### Action If you are using @aa-sdk and/or @account-kit/smart-contracts between the versions of >=4.8.0 and <4.28.1, please upgrade to 4.28.2

## Impacted Deployments **Note that vLLM instances that do NOT make use of the mooncake integration are NOT vulnerable.** ## Description vLLM integration with mooncake is vaulnerable to remote code execution due to using `pickle` based serialization over unsecured ZeroMQ sockets. The vulnerable sockets were set to listen on all network interfaces, increasing the likelihood that an attacker is able to reach the vulnerable ZeroMQ sockets to carry out an attack. This is a similar to [GHSA - x3m8 - f7g5 - qhm7](https://github.com/vllm-project/vllm/security/advisories/GHSA-x3m8-f7g5-qhm7), the problem is in https://github.com/vllm-project/vllm/blob/32b14baf8a1f7195ca09484de3008063569b43c5/vllm/distributed/kv_transfer/kv_pipe/mooncake_pipe.py#L179 Here [recv_pyobj()](https://github.com/zeromq/pyzmq/blob/453f00c5645a3bea40d79f53aa8c47d85038dc2d/zmq/sugar/socket.py#L961) Contains implicit `pickle.loads()`, which leads to potential RCE.

### Impact In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an `XPUB` ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts. Any client with network access to this host can connect to this `XPUB` socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker. By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher. ### Detailed Analysis The `XPUB` socket in question is created here: https://github.com/vllm-project/vllm/blob/c21b99b91241409c2fdf9f3f8c542e8748b317be/vllm/d...

### Summary A stored cross-site scripting (XSS) vulnerability was discovered in the application’s comments feature. This issue allows a malicious actor to inject JavaScript payloads that are stored and later executed in the browser of any user viewing the affected comment. The XSS occurs because the application fails to properly sanitize or encode user input submitted to the comments. Notably, the application sanitizes or does not allow execution of `<script>` tags, but does not account for payloads obfuscated using JavaScript block comments like `/* JavaScriptPayload */`. ### PoC Navigate to a site and page that allows comments and place this in the comments section and submit it: `/*<script>alert('pizzapower')</script>*/` Upon submitting to the page, it will run. And then upon every page visit, it will run. ### Impact An attacker can run arbitrary JS in the victim's browser (any user that visits the page with the comments). This can be chained to do many malicious actions, ...

### Summary An arbitrary file write can be used to write a file with a PHP extension, which then can be browsed to in order to execute arbitrary code on the server. All testing was performed on a local docker setup running the latest version of the application. ### PoC Proof of Concept Navigate to `http://localhost:8085/?LookWiki` which allows you to click `Create a new Graphical configuration` where you specify some parameters and then click `Save`.  After clicking save, this request is made (most headers removed for clarity): ``` POST /?api/templates/custom-presets/test.css HTTP/1.1 Host: localhost:8085 primary-color=%230c5d6a&secondary-color-1=%23d8604c&secondary-color-2=%23d78958&neutral-color=%234e5056&neutral-soft-color=%2357575c&neutral-light-color=%23f2f2f2&main-text-fontsize=17px&main-text-fontfamily=%22Nunito%22%2C+sans-serif&main-title-fontfamily='Nunito'%2C+sans-serif ``` ...

### Summary The request to commence a site backup can be performed without authentication. Then these backups can also be downloaded without authentication. The archives are created with a predictable filename, so a malicious user could create an archive and then download the archive without being authenticated. ### Details Create an installation using the instructions found in the docker folder of the repository, setup the site, and then send the request to create an archive, which you do not need to be authenticated for: ``` POST /?api/archives HTTP/1.1 Host: localhost:8085 action=startArchive&params%5Bsavefiles%5D=true&params%5Bsavedatabase%5D=true&callAsync=true ``` Then to retrieve it, make a simple `GET` request like to the correct URL: ``` http://localhost:8085/?api/archives/2025-04-12T14-34-01_archive.zip ``` A malicious attacker could simply fuzz this filename. ### PoC Here is a python script to fuzz this: ``` #!/usr/bin/env python3 import requests import argpars...

### Summary Reflected XSS has been detected in the file upload form. Vulnerability can be exploited without authentication This Proof of Concept has been performed using the followings: - YesWiki v4.5.3 (doryphore-dev branch) - Docker environnment (docker/docker-compose.yml) ### Vulnerable code The vulnerability is located in the [file](https://github.com/YesWiki/yeswiki/blob/6894234bbde6ab168bf4253f9a581bd24bf53766/tools/attach/libs/attach.lib.php#L724-L735) ``` public function showUploadForm() { $this->file = $_GET['file']; echo '<h3>' . _t('ATTACH_UPLOAD_FORM_FOR_FILE') . ' ' . $this->file . "</h3>\n"; echo '<form enctype="multipart/form-data" name="frmUpload" method="POST" action="' . $this->wiki->href('upload', $this->wiki->GetPageTag()) . "\">\n" . ' <input type="hidden" name="wiki" value="' . $this->wiki->GetPageTag() . "/upload\" />\n" . ' <input type="hidden" name="MAX_FILE_SIZE" value="' . ...

### Summary **Vulnerable Version:** Yeswiki < v4.5.4 **Vulnerable Endpoint:** `/?PagePrincipale%2Fdeletepage` **Vulnerable Parameter:** `incomingurl` **Payload:** `"><script>alert(1)</script>` ### Details Reflected Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. ### PoC **NOTE:** This vulnerability requires admin access. 1. Visit the endpoint as mentioned below and see that an alert box pops up: **URL with Payload:** `https://yeswiki.net/?PagePrincipale%2Fdeletepage&incomingurl="><script>alert(1)</script>` ### Impact An attacker can use a reflecte...

### Summary **Vulnerable Version:** Yeswiki < v4.5.4 **Category:** Injection **CWE: 79:** Improper Neutralization of Input During Web Page Generation (CWE-79) **CVSS:** 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) **Vulnerable Endpoint:** `/?BazaR` **Vulnerable Parameter:** `idformulaire` **Payload:** `<script>alert(1)</script>` ### Details Reflected Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. ### PoC 1. Visit the endpoint as mentioned below and see that an alert box pops up: **URL with Payload:** `https://yeswiki.net/?BazaR&vue=formulaire&ac...