#nodejs

### Impact The Parse Server GraphQL API previously allowed public access to the GraphQL schema without requiring a session token or the master key. While schema introspection reveals only metadata and not actual data, this metadata can still expand the potential attack surface. ### Patches The issue has been addressed by requiring the master key for schema introspection. Additionally, a new Parse Server configuration option, `graphQLPublicIntrospection`, has been introduced. This option allows developers to re-enable public schema introspection if their application relies on it. However, it is strongly recommended to use this option only temporarily and to update the application to function without depending on public introspection. ### Workarounds None available. ### References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-48q3-prgv-gm4w - Fix for Parse Server 7: https://github.com/parse-community/parse-server/pull/9820 - F...

## GitHub Personal Access Token Exposure in docusaurus-plugin-content-gists ### Summary docusaurus-plugin-content-gists versions prior to 4.0.0 are vulnerable to exposing GitHub Personal Access Tokens in production build artifacts when passed through plugin configuration options. The token, intended for build-time API access only, is inadvertently included in client-side JavaScript bundles, making it accessible to anyone who can view the website's source code. ### Affected Versions - All versions < 4.0.0 ### Patched Versions - Version 4.0.0 and later ### Impact When using the affected versions with the recommended configuration pattern: ```javascript plugins: [ [ 'docusaurus-plugin-content-gists', { personalAccessToken: process.env.GITHUB_PERSONAL_ACCESS_TOKEN, }, ], ] ``` The GitHub Personal Access Token is included in the webpack bundle and exposed in production builds at: - `/build/assets/js/main.[hash].js` This allows malicious actors to: - Extract ...

### Summary Possibility to craft a request that will crash the Qwik Server in the default configuration. ### Details When a Qwik Server Action QRL is executed it dynamically load the file containing the symbol. When an invalid qfunc is sent, the server does not handle the thrown error. The error then causes Node JS to exit. ### PoC 1. Setup a Qwik Project `pnpm create qwik@latest` 2. Start the Qwik Server using `pnpm run preview` 3. Execute the following curl command to crash the instance ```bash curl --location 'http://localhost:4173/?qfunc=PPXYallGsCE' \ --header 'Content-Type: application/qwik-json' \ --header 'X-Qrl: PPXYallGsCE' \ --data '{"_entry":"2","_objs":["\u0002_#s_PPXYallGsCE",1,["0","1"]]}' ``` Here the `qfunc` query parameter, `X-Qrl` header and payload need to have the same qrl. The Qwik Server will then crash with the message ``` qrl s_PPXYallGsCE failed to load Error: Dynamic require of "_.js" is not supported at file:///home/michele/Code/qwik/server/en...

### Impact Applications that use the `verifyWebhook()` helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. ### Patches * `@clerk/backend`: the helper has been patched as of `2.4.0` * `@clerk/astro`: the helper has been patched as of `2.10.2` * `@clerk/express`: the helper has been patched as of `1.7.4` * `@clerk/fastify`: the helper has been patched as of `2.4.4` * `@clerk/nextjs`: the helper has been patched as of `6.23.3` * `@clerk/nuxt`: the helper has been patched as of `1.7.5` * `@clerk/react-router`: the helper has been patched as of `1.6.4` * `@clerk/remix`: the helper has been patched as of `4.8.5` * `@clerk/tanstack-react-start`: the helper has been patched as of `0.18.3` ### Resolution The issue was resolved in **`@clerk/backend` `2.4.0`** by: * Properly parsing the webhook request's signatures and comparing them against the signature generated from the received event ### Workarounds If unable to upgrade, developers ...

### Summary A command injection vulnerability exists in the `mcp-server-kubernetes` MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to `child_process.execSync`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). ### Details The MCP Server exposes tools (`kubectl_scale`, `kubectl_patch` , `explain_resource`, etc) to perform several kubernetes operations. An MCP Client can be instructed to execute additional actions for example via prompt injection when asked to read pod logs. Below some example of vulnerable code and different ways to test this vulnerability including a real example of indirect prompt injection that can lead to ...

### Summary Note: [originally posted on H1](https://hackerone.com/reports/3117837) but closed. Cross-posting over to here in abundance of caution instead of a public issue. When utilising the Cloudflare Vite plugin in its default configuration, all files are exposed by the local dev server, including files in the root directory that contain secret information such as: - `.env` - `.dev.vars` ### PoC 1. Create a Workers project that utilises the `@cloudflare/vite-plugin`. For example: - `npm create cloudflare@latest` - select Framework Starter -> React 2. Add any secret files to test if they're accessible. `echo foobar=secret > .dev.vars` for example 3. Run `npm run dev` to start the dev server (after running `npm ci` if necessary to install dependencies) and then hit the following to expose information: `curl http://localhost:5173/.env` may expose any secrets in this file `curl http://localhost:5173/.dev.vars` may expose any secrets in this file `curl http://localhost:5173/packa...

### Summary A command injection vulnerability exists in the `node-code-sandbox-mcp` MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to `child_process.execSync`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges on the host machine, bypassing the sandbox protection of running code inside docker. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). ### Details The MCP Server exposes tools to run code inside a docker container. An MCP Client can be instructed to execute additional actions for example via indirect prompt injection when asked to generate code that read a file. Below some example of vulnerable code and different ways to test this vulnerability including a real example o...

### Summary A command injection vulnerability exists in the `git-mcp-server` MCP Server. The vulnerability is caused by the unsanitized use of input parameters within a call to `child_process.exec`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). ### Details The MCP Server exposes tools (`git_add`, `git_init`, `git_logs`, etcc) to perform several git operations. An MCP Client can be instructed to execute additional actions for example via indirect prompt injection when asked to read git logs. Below some example of vulnerable code and different ways to test this vulnerability including a real example of indirect prompt injection that can lead to arbitrary command injection...

### Impact The `nativeImage.createFromPath()` and `nativeImage.createFromBuffer()` functions call a function downstream that is vulnerable to a heap buffer overflow. An Electron program that uses either of the affected functions is vulnerable to a buffer overflow if an attacker is in control of the image's height, width, and contents. ### Workaround There are no app-side workarounds for this issue. You must update your Electron version to be protected. ### Patches - `v28.3.2` - `v29.3.3` - `v30.0.3` ### For More Information If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).

### Summary A malicious JSON-stringifyable message can be made passing on `verify()`, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in strange objects being accepted as `message`, and those messages could trick `verify()` into returning false-positive `true` values v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this ### PoC This code deliberately doesn't provide `reencode` for now, could be updated later ```js import { randomBytes } from 'crypto'...