ghsa

### 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 ...

### Summary When using an ACL on a device connected to a bridge, Incus generates nftables rules for local services (DHCP, DNS...) that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to DHCP pool exhaustion and opens the door for other attacks. ### Details In commit a7c33301738aede3c035063e973b1d885d9bac7c, the following rules are added at the top of the bridge input chain: iifname "{{.hostName}}" ether type ip ip saddr 0.0.0.0 ip daddr 255.255.255.255 udp dport 67 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::1:2 udp dport 547 accept iifname "{{.hostName}}" ether type ip6 ip6 saddr fe80::/10 ip6 daddr ff02::2 icmpv6 type 133 accept However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering" snippet: iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop iifname "{{.hostName}}" ether...

## Summary Octo-STS versions before v0.5.3 are vulnerable to unauthenticated SSRF by abusing fields in OpenID Connect tokens. Malicious tokens were shown to trigger internal network requests which could reflect error logs with sensitive information. Please upgrade to v0.5.3 to resolve this issue. This version includes patch sets to [sanitize input](https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92) and [redact logging](https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd). Many thanks to @vicevirus for reporting this issue and for assisting with remediation review. ## References - https://github.com/octo-sts/app/security/advisories/GHSA-h3qp-hwvr-9xcq - https://github.com/octo-sts/app/commit/b3976e39bd8c8c217c0670747d34a4499043da92 - https://github.com/octo-sts/app/commit/0f177fde54f9318e33f0bba6abaea9463a7c3afd

### Summary A stored XSS is present in Gogs which allows client-side Javascript code execution. ### Details Gogs Version: ``` docker images REPOSITORY TAG IMAGE ID CREATED SIZE gogs/gogs latest fe92583bc4fe 10 hours ago 99.3MB ``` Application version: `0.14.0+dev` Local setup using: ```bash # Pull image from Docker Hub. docker pull gogs/gogs # Create local directory for volume. sudo mkdir -p /var/gogs # Use `docker run` for the first time. docker run --name=gogs -p 10022:22 -p 10880:3000 -v /var/gogs:/data gogs/gogs ``` The vulnerability is caused by the usage of a vulnerable and outdated component: `pdfjs-1.4.20` under public/plugins/. Read more about this vulnerability at [codeanlabs - CVE-2024-4367](https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/). ### PoC 1. Upload the Proof of Concept file hosted at https://codeanlabs.com/wp-content/uploads/2024/05/poc_generalized_CVE-2024-4367.pdf in a repository. 2. ...

Versions of the package snyk before 1.1297.3 are vulnerable to Insertion of Sensitive Information into Log File through local Snyk CLI debug logs. Container Registry credentials provided via environment variables or command line arguments can be exposed when executing Snyk CLI in DEBUG or DEBUG/TRACE mode. The issue affects the following Snyk commands: 1. When snyk container test or snyk container monitor commands are run against a container registry, with debug mode enabled, the container registry credentials may be written into the local Snyk CLI debug log. This only happens with credentials specified in environment variables (SNYK_REGISTRY_USERNAME and SNYK_REGISTRY_PASSWORD), or in the CLI (--password/-p and --username/-u). 2. When snyk auth command is executed with debug mode enabled AND the log level is set to TRACE, the Snyk access / refresh credential tokens used to connect the CLI to Snyk may be written into the local CLI debug logs. 3. When snyk iac test is executed with...

### Impact The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry (which it does by default since 5.0.0) allowing a possible Man In The Middle attack. ### Patches https://github.com/containers/podman/commit/726b506acc8a00d99f1a3a1357ecf619a1f798c3 Fixed in v5.5.2 ### Workarounds Download the disk image manually via some other tool that verifies the TLS connection. Then pass the local image as file path (podman machine init --image ./somepath)

### Impact Prior to 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero. This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. Leveraging this bug to compromise the soundness of an application using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof). Because this bug does not risk application integrity, correctly written applications are not at risk. ### Fix Please see [#605] for a full description of the bug, and the fix. This fix has been released as part of `ri...