Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-gj54-gwj9-x2c6: eKuiper /config/uploads API arbitrary file writing may lead to RCE

### Summary eKuiper /config/uploads API supports accessing remote web URLs and saving files in the local upload directory, but there are no security restrictions, resulting in arbitrary file writing through ../. If run with root privileges, RCE can be achieved by writing crontab files or ssh keys. ### Details ```go func fileUploadHandler(w http.ResponseWriter, r *http.Request) { switch r.Method { // Upload or overwrite a file case http.MethodPost: switch r.Header.Get("Content-Type") { case "application/json": fc := &fileContent{} defer r.Body.Close() err := json.NewDecoder(r.Body).Decode(fc) if err != nil { handleError(w, err, "Invalid body: Error decoding file json", logger) return } err = fc.Validate() if err != nil { handleError(w, err, "Invalid body: missing necessary field", logger) return } filePath := filepath.Join(uploadDir, fc.Name) err = upload(fc) ``` - The fc.Name parameter do not safely filtered. ### PoC ``` POST /co...

ghsa
#web#js#git#rce#ssrf#ssh
GHSA-fv2p-qj5p-wqq4: LF Edge eKuiper vulnerable to File Path Traversal leading to file replacement

### Summary Path traversal is also known as directory traversal. These vulnerabilities enable an attacker to read arbitrary files on the server that is running an application. In this case, an attacker might be able to write to arbitrary files on the server, allowing them to modify application data or behavior, and ultimately take full control of the server. ### Details The file handler function trusts the filename provided by the user. This includes the cases when the user uses a path instead of the filename. This makes possible to write arbitrary files to the system and **replace** the files owned by _kuiper_ user on the filesystem. The vulnerable function is `fileUploadHandler` which is shown below: https://github.com/lf-edge/ekuiper/blob/1e6b6b6601445eb05316532f5fbef7f0a863ecfe/internal/server/rest.go#L329-L359 Exploitation of this vulnerability allows an attacker to rewrite the files owned by ekuiper including the main kuiper binaries as they are owned by _kuiper_ user: ![kuip...

GHSA-pr9r-gxgp-9rm8: n8n Vulnerable to Denial of Service via Malformed Binary Data Requests

## Summary Denial of Service vulnerability in `/rest/binary-data` endpoint when processing empty filesystem URIs (`filesystem://` or `filesystem-v2://`). ### Impact This is a Denial of Service (DoS) vulnerability that allows authenticated attackers to cause service unavailability through malformed filesystem URI requests. The vulnerability affects: - The `/rest/binary-data` endpoint - n8n.cloud instances (confirmed HTTP/2 524 timeout responses) Attackers can exploit this by sending GET requests with empty filesystem URIs (`filesystem://` or `filesystem-v2://`) to the `/rest/binary-data` endpoint, causing resource exhaustion and service disruption. ### Patches The issue has been patched in [1.99.0](https://github.com/n8n-io/n8n/releases/tag/n8n%401.99.0). All users should upgrade to this version or later. The fix introduces strict checking of URI patterns. Patch commit: https://github.com/n8n-io/n8n/pull/16229

GHSA-hqp6-mjw3-f586: HashiCorp Vagrant has code injection vulnerability through default synced folders

An authenticated virtual machine escape vulnerability exists in HashiCorp Vagrant versions 2.4.6 and below when using the default synced folder configuration. By design, Vagrant automatically mounts the host system’s project directory into the guest VM under /vagrant (or C:\vagrant on Windows). This includes the Vagrantfile configuration file, which is a Ruby script evaluated by the host every time a vagrant command is executed in the project directory. If a low-privileged attacker obtains shell access to the guest VM, they can append arbitrary Ruby code to the mounted Vagrantfile. When a user on the host later runs any vagrant command, the injected code is executed on the host with that user’s privileges. While this shared-folder behavior is well-documented by Vagrant, the security implications of Vagrantfile execution from guest-writable storage are not explicitly addressed. This effectively enables guest-to-host code execution in multi-tenant or adversarial VM scenarios.

GHSA-j64v-xh5w-8hqj: Microweber CMS API has authenticated local file inclusion vulnerability

An authenticated local file inclusion vulnerability exists in Microweber CMS versions < 1.2.11 through misuse of the backup management API. Authenticated users can abuse the /api/BackupV2/upload and /api/BackupV2/download endpoints to read arbitrary files from the underlying filesystem. By specifying an absolute file path in the src parameter of the upload request, the server may relocate or delete the target file depending on the web service user’s privileges. The corresponding download endpoint can then be used to retrieve the file contents, effectively enabling local file disclosure. This behavior stems from insufficient validation of user-supplied paths and inadequate restrictions on file access and backup logic.

GHSA-3w94-vq2x-v5wr: ethereum does not check transaction malleability for EIP-2930, EIP-1559 and EIP-7702 transactions

### Impact Prior to `ethereum` crate v0.18.0, signature malleability (according to EIP-2) was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559 and EIP-7702 transactions. This is a specification deviation and therefore a high severity advisory if the `ethereum` crate is used for Ethereum mainnet. Note that signature malleability itself is not a security issue, and therefore if the `ethereum` crate is used on a single-implementation blockchain, it's a low/informational severity advisory. ### Patches The issue is fixed in `ethereum` v0.18.0 ### Workarounds You can also manually check transaction malleability outside of the crate. But it's recommended to simply upgrade the version. ### References See PR: https://github.com/rust-ethereum/ethereum/pull/67

GHSA-m43g-m425-p68x: junit-platform-reporting can leak Git credentials through its OpenTestReportGeneratingListener

### Summary This vulnerability affects JUnit's support for writing Open Test Reporting XML files which is an opt-in feature of `junit-platform-reporting`. If a repository is cloned using a GitHub token or other credentials in its URL, for example: ```bash git clone https://${GH_APP}:${GH_TOKEN}@github.com/example/example.git ``` The credentials are captured by `OpenTestReportGeneratingListener` which produces (trimmed for brevity): ```xml <infrastructure> <git:repository originUrl="https://username:[email protected]/example/example.git" /> </infrastructure> ``` ### Details https://github.com/junit-team/junit5/blob/6b7764dac92fd35cb348152d1b37f8726875a4e0/junit-platform-reporting/src/main/java/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.java#L183 I think this should be configurable in some way to exclude select git information or exclude it entirely. ### PoC 1. Clone a repo using a GitHub token as shown above. 2. Enable the listener `junit.platfor...

GHSA-hc55-p739-j48w: @modelcontextprotocol/server-filesystem vulnerability allows for path validation bypass via colliding path prefix

Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files in cases where the prefix matches an allowed directory. Users are advised to upgrade to 2025.7.1 to resolve the issue. Thank you to Elad Beber (Cymulate) for reporting these issues.

GHSA-q66q-fx2p-7w4m: @modelcontextprotocol/server-filesystem allows for path validation bypass via prefix matching and symlink handling

Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files via symlinks within allowed directories. Users are advised to upgrade to 2025.7.1 to resolve. Thank you to Elad Beber (Cymulate) for reporting these issues.

GHSA-h34r-jxqm-qgpr: juju/utils leaks private key in certs

### Summary Certs generated by v4 contain their private key. ## Details ### Background Recently, I encountered an API in Go that’s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it’s better to address them early. This work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments. ### PoC https://go.dev/play/p/vSW0U3Hq4qk ### Impact [This code](https://github.com/juju/utils/blob/0141ef0ee74a0cac603c5c9e4aff194008722f41/cert/cert.go#L120) (cert.NewLeaf) generates certs with the SubjectKeyId set to `sha512.Ne...