ghsa

### Impact `MySQLWriteTool` executes arbitrary SQL provided by the caller using `PDO::prepare()` + `execute()` without semantic restrictions. This is consistent with the name (“write tool”), but in an LLM/agent context it becomes a high-risk capability: prompt injection or indirect prompt manipulation can cause execution of destructive queries such as `DROP TABLE`, `TRUNCATE`, `DELETE`, `ALTER`, or privilege-related statements (subject to DB permissions). **Who is impacted:** Deployments that expose an agent with `MySQLWriteTool` enabled to untrusted input and/or run the tool with a DB user that has broad privileges. ### Patches **Not patched in:** 2.8.11 Recommended improvements (even if keeping the tool intentionally powerful): - Provide a safer API that supports only constrained operations (e.g., `insertRecord`, `updateRecord`) with allowlisted tables/columns. - Add a policy/allowlist layer (e.g., allow only `INSERT`/`UPDATE` on selected tables; forbid `DROP/TRUNCATE/A...

### Impact `MySQLSelectTool` is intended to be a read-only SQL tool (e.g., for LLM agent querying). However, validation based on the first keyword (e.g., `SELECT`) and a forbidden-keyword list does not block file-writing constructs such as `INTO OUTFILE` / `INTO DUMPFILE`. As a result, an attacker who can influence the tool input (e.g., prompt injection through a public agent endpoint) may be able to write arbitrary content to files on the DB server. If the MySQL/MariaDB account has the `FILE` privilege and server configuration permits writes to a useful location (e.g., a web-accessible directory), the impact can escalate to remote code execution on the application host (for example, by writing a PHP web shell). **Who is impacted:** Deployments that expose an agent using `MySQLSelectTool` to untrusted input and run with overly-permissive DB privileges/configuration. ### Patches **Not patched in:** 2.8.11 **Fixed in:** 2.8.12 Recommended fix direction: - Explicitly reject q...

### Summary A flaw in the handling of recovery codes for **app-based multi-factor authentication** allows the same recovery code to be reused indefinitely. This issue does **not** affect email-based MFA. It also only applies when recovery codes are enabled. ### Impact If an attacker gains access to both the user's password and their recovery codes, they can repeatedly complete MFA without the user's app-based second factor. This weakens the expected security of MFA by turning recovery codes into a static, long-term bypass method.

### Background The CNI `portmap` plugin allows containers to emulate opening a host port, forwarding that traffic to the container. For example, if a host has the IP 198.51.100.42, a container may request that all packets to `198.51.100.42:53` be forwarded to the container's network. ### Vulnerability When the `portmap` plugin is configured with the `nftables` backend, it inadvertently forwards all traffic with the same destination port as the host port, **ignoring the destination IP**. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. In the given example above, traffic destined to port 53 but for a _separate container_ would still be captured and forwarded, even though it was not destined for the host. ### Impact Containers (i.e. kubernetes pods) that request HostPort forwarding can intercept all traffic destined for that port. This requires that the `portmap` plugin be explicitly configured to use the `nftables` backend. (Th...

### Summary Siyuan is vulnerable to RCE. The issue stems from a "Zip Slip" vulnerability during zip file extraction, combined with the ability to overwrite system executables and subsequently trigger their execution. ### Steps to reproduce 1. Authenticate 2. Create zip slip payload with path traversal entry `../../../../opt/siyuan/startup.sh`. startup.sh contains malicious code like: ```bash #!/bin/sh echo 'you have been pwned' > /siyuan/workspace/data/pwned.txt echo "pandoc 3.1.0" ``` 3. Upload zip to workspace via `/api/file/putFile` 4. Extract zip via `/api/archive/unzip`, overwrites the existing executable `startup.sh` while maintaining the +x permission 5. Trigger execution by calling `/api/setting/setExport` with `pandocBin=/opt/siyuan/startup.sh`. This calls `IsValidPandocBin()` which executes `startup.sh --version` that outputs "pandoc 3.1.0" and executes any arbitrary malicious code

### Summary Function [**importZipMd**](https://github.com/siyuan-note/siyuan/blob/dae6158860cc704e353454565c96e874278c6f47/kernel/api/import.go#L190) is vulnerable to **ZipSlip** which allows an authenticated user to overwrite files on the system. ### Details An authenticated user with access to the import functionality in notes is able to overwrite any file on the system, the vulnerable function is [**importZipMd**](https://github.com/siyuan-note/siyuan/blob/dae6158860cc704e353454565c96e874278c6f47/kernel/api/import.go#L190), this can escalate to full code execution under some circumstances, for example using the official **docker image** it is possible to overwrite **entrypoint.sh** and after a container restart it will execute the changed code causing remote code execution. ### PoC Code used to generate the ZipSlip: ```python #!/usr/bin/env python3 import sys, base64, zipfile, io, time def prepare_zipslip(filename): orgfile1 = open('Test.md','rb').read() payload = open(...

A vulnerability in mad-proxy versions <= 0.3 allows attackers to bypass HTTP/HTTPS traffic interception rules, potentially exposing sensitive traffic.

### Summary The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links. ### Details The untar code that handles symbolic links in archives is unsafe. Concretely, the computation of the link's target and the subsequent check are flawed: https://github.com/argoproj/argo-workflows/blob/5291e0b01f94ba864f96f795bb500f2cfc5ad799/workflow/executor/executor.go#L1034-L1037 ### PoC 1. Create a malicious archive containing two files: a symbolik link with path "./work/foo" and target "/etc", and a normal text file with path "./work/foo/hostname". 2. Deploy a workflow like the one in https://github.com/argoproj/argo-workflows/security/advisories/GHSA-p84v-gxvw-73pf with the malicious archive mounted at /work/tmp. 3. Submit the workflow and wait for its execution. 4. Connect to the corresponding pod and observe that the file "/etc/hostname" was altered by the untar operation performed on the malicious archive. The attacker can hence alter arbitr...

### Impact Due to unsafe handling and deletion of temporary files during the dictionary upload process, an attacker with access to the backoffice can trigger predictable requests to temporary file paths. The application’s error responses (HTTP 500 when a file exists, 404 when it does not) allow the attacker to enumerate the existence of arbitrary files on the server’s filesystem. This vulnerability does not allow reading or writing file contents. In certain configurations, incomplete clean-up of temporary upload files may additionally expose the NTLM hash of the Windows account running the Umbraco application. The direct impact of this vulnerability is therefore limited to confidentiality, which is reflected in its CVSS base score of 4.9 While the CVSS Base Score captures only the immediate effect, the practical risk varies significantly based on hosting environment and identity configuration. Umbraco Cloud sites run under low-privilege, isolated Azure App Service worker identities, ...

Arbitrary code execution from cookie config. If dynamic cookies are enabled (ie there exists a schema for cookies), the cookie config is injected into the compiled route without first being sanitised. Availability of this exploit is generally low, as it requires write access to either the Elysia app's source code (in which case the vulnerability is meaningless) or write access to the cookie config (perhaps where it is assumed to be provisioned by the environment). However when combined with GHSA-hxj9-33pp-j2cc, this vulnerability allows for a full RCE chain. ### Impact - aot enabled (default) - cookie schema passed to route - Cookie config controllable eg. via env Example of vulnerable code ```js new Elysia({ cookie: { secrets: `' + console.log('pwned from secrets') + '` }, }) .get("/", () => "hello world", { cookie: t.Cookie({ foo: t.Any(), }), }) ``` POC: https://github.com/sportshead/elysia-poc ### Patches Patched by 1.4.17 (https://github.com/elysiajs/elysia/pul...