ghsa

## Summary ## The file access permissions for files uploaded to or created from File Browser are never explicitly set by the application. The same is true for the database used by File Browser. On standard servers where the *umask* configuration has not been hardened before, this makes all the stated files readable by any operating system account. ## Impact ## The default permissions for new files on a standard Linux system are `0644`, making them world-readable. That means that at least the following parties have full read access to all files managed by the Filebrowser from all *scopes*, as well as its database (including the password hashes stored in there): * All OS accounts on the server * All other applications running on the same server * Any Filebrowser user with *Command Execution* privileges having access to a command that allows reading a file's content ## Vulnerability Description ## On a Linux system, the file access permissions of new files are designated by the syst...

### Impact This is an Open Redirect (CWE-601) vulnerability in the login flow of n8n. Authenticated users can be redirected to untrusted, attacker-controlled domains after logging in, by crafting malicious URLs with a misleading redirect query parameter. This may lead to: - Phishing attacks by impersonating the n8n UI on lookalike domains (e.g., n8n.local.evil.com) - Credential or 2FA theft if users are tricked into re-entering sensitive information - Reputation risk due to the visual similarity between attacker-controlled domains and trusted ones The vulnerability affects anyone hosting n8n and exposing the `/signin` endpoint to users. ### Patches The issue has been patched in [1.98.0](https://github.com/n8n-io/n8n/releases/tag/n8n%401.98.0). All users should upgrade to this version or later. The fix introduces strict origin validation for redirect URLs, ensuring only same-origin or relative paths are allowed after login. Patch commit: https://github.com/n8n-io/n8n/pull/16034

A flaw was found in Infinispan CLI. A sensitive password, decoded from a Base64-encoded Kubernetes secret, is processed in plaintext and included in a command string that may expose the data in an error message when a command is not found.

Ruby WEBrick read_header HTTP Request Smuggling Vulnerability. This vulnerability allows remote attackers to smuggle arbitrary HTTP requests on affected installations of Ruby WEBrick. This issue is exploitable when the product is deployed behind an HTTP proxy that fulfills specific conditions. The specific flaw exists within the read_headers method. The issue results from the inconsistent parsing of terminators of HTTP headers. An attacker can leverage this vulnerability to smuggle arbitrary HTTP requests. Was ZDI-CAN-21876.

Vault Community and Vault Enterprise rekey and recovery key operations can lead to a denial of service due to uncontrolled cancellation by a Vault operator. This vulnerability (CVE-2025-4656) has been remediated in Vault Community Edition 1.20.0 and Vault Enterprise 1.20.0, 1.19.6, 1.18.11, 1.17.17, and 1.16.22.

Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) vulnerability in Apache Airflow Providers Snowflake. This issue affects Apache Airflow Providers Snowflake: before 6.4.0. Sanitation of table and stage parameters were added in CopyFromExternalStageToSnowflakeOperator to prevent SQL injection Users are recommended to upgrade to version 6.4.0, which fixes the issue.

### Impact OpenBao and HashiCorp Vault allowed an attacker to perform unauthenticated, unaudited cancellation of root rekey and recovery rekey operations, effecting a denial of service. ### Patches In OpenBao v2.2.2 and later, manually setting the configuration option `disable_unauthed_rekey_endpoints=true` allows an operator to deny these rarely-used endpoints on global listeners. In a future OpenBao release [communicated on our website](https://openbao.org/docs/deprecation/), we will set this to `true` for all users and provide an authenticated alternative. This vulnerability has been disclosed to HashiCorp; see their website for more information. ### Workarounds If an active proxy or load balancer sits in front of OpenBao, an operator can deny requests to these endpoints from unauthorized IP ranges. ### References See the [deprecation notice](https://openbao.org/docs/deprecation/unauthed-rekey/).

### Impact OpenBao before v2.3.0 and HashiCorp Vault as of the current v1.19.5 may leak sensitive information in logs when processing malformed data. This is separate from the earlier HCSEC-2025-09 / CVE-2025-4166. ### Patches This issue has been fixed in OpenBao v2.3.0 and later. ### Workarounds Like with HCSEC-2025-09, there is no known workaround except to ensure properly formatted requests from all clients. ### Remediation Users with the capability to search through server and audit logs for any possible exposed secrets can refer to the following snippets to aid in searching: Audit Log ``` ... "error":"error converting input for field \"password\": expected type 'string', got unconvertible type 'map[string]interface {}', value: '<sensitive data>'" ... ``` Server Log ``` error converting input for field "password": expected type 'string', got unconvertible type 'map[string]interface {}', value: '<sensitive data>' ``` If any matches are found, rotating the affected secre...

# Command Injection in MCP Server The MCP Server at https://github.com/joshuayoes/ios-simulator-mcp/ is written in a way that is vulnerable to command injection vulnerability attacks as part of some of its MCP Server tool definition and implementation. ## Vulnerable tool The MCP Server exposes the tool `ui_tap` which relies on Node.js child process API `exec` which is an unsafe and vulnerable API if concatenated with untrusted user input. LLM exposed user input for `duration`, `udid`, and `x` and `y` args can be replaced with shell meta-characters like `;` or `&&` or others to change the behavior from running the expected command `idb` to another command. Vulnerable line of code: https://github.com/joshuayoes/ios-simulator-mcp/blob/main/src/index.ts#L166-L207 ```js server.tool( "ui_tap", "Tap on the screen in the iOS Simulator", { duration: z.string().optional().describe("Press duration"), udid: z .string() .optional() .describe("...

### Summary When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge. ### Details In commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain: ct state established,related accept iifname "{{.hostName}}" ether type arp accept iifname "{{.hostName}}" ip6 nexthdr ipv6-icmp icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering", "IPv4 filtering" and "IPv6 filtering" snippets: iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 @nh,528,48 != {{.hwAddrHex}} drop ...