ghsa

Due to a bug in sandboxing logic, `sandbox-runtime` did not properly enforce a network sandbox if the sandbox policy did not configure any allowed domains. This could allow sandboxed code to make network requests outside of the sandbox. A patch for this was released in v0.0.16. Thank you to https://github.com/bendrucker for reporting this issue!

### Overview An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions. ### Am I Affected? You are affected by this vulnerability if you meet all of the following preconditions: 1. Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0 2. Application uses the jws.createVerify() function for HMAC algorithms 3. Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines You are NOT affected by this vulnerability if you meet any of the following preconditions: 1. Application uses the jws.verify() interface (note: `auth0/node-jsonwebtoken` users fall into this category and are therefore NOT affected by this vulnerability) 2. Application uses only asymmetric algorithms (e.g. RS256) 3. Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lo...

alexusmai laravel-file-manager 3.3.1 and below is vulnerable to Directory Traversal. The unzip/extraction functionality improperly allows archive contents to be written to arbitrary locations on the filesystem due to insufficient validation of extraction paths.

A flaw was found in ansible-collection-community-general. This vulnerability allows for information exposure (IE) of sensitive credentials, specifically plaintext passwords, via verbose output when running Ansible with debug modes. Attackers with access to logs could retrieve these secrets and potentially compromise Keycloak accounts or administrative access.

alexusmai laravel-file-manager 3.3.1 and below is vulnerable to Directory Traversal. The zip/archiving functionality allows an attacker to create archives containing files and directories outside the intended scope due to improper path validation.

### Summary A security issue exists in the `exec_in_pod` tool of the `mcp-server-kubernetes` MCP Server. The tool accepts user-provided commands in both array and string formats. When a string format is provided, it is passed directly to shell interpretation (`sh -c`) without input validation, allowing shell metacharacters to be interpreted. This vulnerability can be exploited through direct command injection or indirect prompt injection attacks, where AI agents may execute commands without explicit user intent. ### Details The MCP Server exposes the `exec_in_pod` tool to execute commands inside Kubernetes pods. The tool supports both array and string command formats. The Kubernetes Exec API (via `@kubernetes/client-node`) accepts commands as an array of strings, which executes commands directly without shell interpretation. However, when a string format is provided, the code automatically wraps it in shell execution (`sh -c`), which interprets shell metacharacters without any input v...

### Summary `@vitejs/plugin-rsc` vendors `react-server-dom-webpack`, which contained an unauthenticated remote code execution vulnerability in versions prior to 19.0.1, 19.1.2, and 19.2.1. See details in React repository's advisory https://github.com/facebook/react/security/advisories/GHSA-fv66-9v8q-g76r ### Impact Applications using affected versions of `@vitejs/plugin-rsc` are vulnerable to unauthenticated remote code execution through deserialization of untrusted data. An attacker can execute arbitrary code remotely without authentication, affecting confidentiality, integrity, and availability. ### Recommendations Upgrade immediately to `@vitejs/plugin-rsc@0.5.3` or later. ### Workarounds Applications not using server-side React or React Server Components are unaffected.

### Impact There is an unauthenticated remote code execution vulnerability in React Server Components. We recommend upgrading immediately. The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of: * [react-server-dom-webpack](https://www.npmjs.com/package/react-server-dom-webpack) * [react-server-dom-parcel](https://www.npmjs.com/package/react-server-dom-parcel) * [react-server-dom-turbopack](https://www.npmjs.com/package/react-server-dom-turbopack?activeTab=readme) ### Patches A fix was introduced in versions [19.0.1](https://github.com/facebook/react/releases/tag/v19.0.1), [19.1.2](https://github.com/facebook/react/releases/tag/v19.1.2), and [19.2.1](https://github.com/facebook/react/releases/tag/v19.2.1). If you are using any of the above packages please upgrade to any of the fixed versions immediately. If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler pl...

A vulnerability affects certain React packages¹ for versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as [CVE-2025-55182](https://www.cve.org/CVERecord?id=CVE-2025-55182). Fixed in: React: 19.0.1, 19.1.2, 19.2.1 Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 The vulnerability also affects experimental canary releases starting with 14.3.0-canary.77. Users on any of the 14.3 canary builds should either downgrade to a 14.x stable release or 14.3.0-canary.76. All users of stable 15.x or 16.x Next.js versions should upgrade to a patched, stable version immediately. ¹ The affected React packages are: - react-server-dom-parcel - react-server-dom-turbopack - react-server-dom-webpack

## Summary A security fix is now available for Step CA that resolves a vulnerability affecting deployments configured with ACME and/or SCEP provisioners. All operators running these provisioners should upgrade to the latest release (`v0.29.0`) immediately. The issue was discovered and disclosed by a research team during a security review. There is no evidence of active exploitation. To limit exploitation risk during a coordinated disclosure window, we are withholding detailed technical information for now. A full write-up will be published in several weeks. --- ## Embargo List If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list. --- ## Acknowledgements This issue was identified and reported by Stephen Kubik of the Cisco Advanced Security Initiatives Group (ASIG) --- Stay safe, and thank you for helping us keep the ecosystem secure...