deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wxw2-rwmh-vr8f
Package: electerm (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 3.3.8
Patched in: 3.3.8

Summary: electerm: electerm_install_script_CommandInjection Vulnerability Report

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

**Command Injection vulnerabilities in electerm:**

A command injection vulnerability exists in `github.com/elcterm/electerm/npm/install.js:150`. The `runMac()` function appends attacker-controlled remote `releaseInfo.name` directly into an `exec("open ...")` command without validation.

**Who is impacted:** Users who run `npm install -g electerm` in Mac OS. An attacker who can control the remote release metadata (version string or release name) served by the project's update server could execute arbitrary system commands, tamper local files, and escalate compromise of development/runtime assets.

---

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Fixed in [59708b38c8a52f5db59d7d4eff98e31d573128ee](https://github.com/electerm/electerm/commit/59708b38c8a52f5db59d7d4eff98e31d573128ee), user no need to upgrade, the new version already published in npm

---

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

no

---

### References
_Are there any links users can visit to find out more?_

[59708b38c8a52f5db59d7d4eff98e31d573128ee](https://github.com/electerm/electerm/commit/59708b38c8a52f5db59d7d4eff98e31d573128ee)
GitHub Security Advisory: GHSA-9hrv-gvrv-6gf2
Package: flowise-components (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise Execute Flow function has an SSRF vulnerability

Details:
### Summary

The attacker provides an intranet address through the base url field configured in the Execute Flow node 
→ Bypass checkDenyList / resolveAndValidate in httpSecurity.ts (not called)
→ Causes the server to initiate an HTTP request to any internal network address, read cloud metadata, or detect internal network services 

### Details

<img width="1280" height="860" alt="9a52a74e6fe2fd78e4962d1d68057fc2" src="https://github.com/user-attachments/assets/20df0006-9129-4886-8928-16d19a617c23" />

Then initiate the call: 

```
POST /api/v1/prediction/d6739838-d3b3-43d9-86ff-911a3d757a7e HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}
```

Server received a request:

<img width="1432" height="172" alt="f45c757fec408e13739db068252ff21b" src="https://github.com/user-attachments/assets/d3dfe0f5-83ec-4c79-ab32-754382a68d5f" />

And there is an echo: 

<img width="1280" height="666" alt="fa0caf0deb306cfeeea8fdf8941a287e" src="https://github.com/user-attachments/assets/55a94d25-120b-4e9c-9517-46c2fc2b667f" />

Fix:
Call secureFetch for verification



### Impact

This is a Server-Side Request Forgery (SSRF) vulnerability that may lead to the following risks: 
- Explore Internal Web Applications
- Access sensitive management interfaces
- Leak internal configuration, credentials, or confidential information

This vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in enterprise environments.
GitHub Security Advisory: GHSA-9hrv-gvrv-6gf2
Package: flowise (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise Execute Flow function has an SSRF vulnerability

Details:
### Summary

The attacker provides an intranet address through the base url field configured in the Execute Flow node 
→ Bypass checkDenyList / resolveAndValidate in httpSecurity.ts (not called)
→ Causes the server to initiate an HTTP request to any internal network address, read cloud metadata, or detect internal network services 

### Details

<img width="1280" height="860" alt="9a52a74e6fe2fd78e4962d1d68057fc2" src="https://github.com/user-attachments/assets/20df0006-9129-4886-8928-16d19a617c23" />

Then initiate the call: 

```
POST /api/v1/prediction/d6739838-d3b3-43d9-86ff-911a3d757a7e HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Authorization: Bearer apikey
Content-Length: 17

{"question": "1"}
```

Server received a request:

<img width="1432" height="172" alt="f45c757fec408e13739db068252ff21b" src="https://github.com/user-attachments/assets/d3dfe0f5-83ec-4c79-ab32-754382a68d5f" />

And there is an echo: 

<img width="1280" height="666" alt="fa0caf0deb306cfeeea8fdf8941a287e" src="https://github.com/user-attachments/assets/55a94d25-120b-4e9c-9517-46c2fc2b667f" />

Fix:
Call secureFetch for verification



### Impact

This is a Server-Side Request Forgery (SSRF) vulnerability that may lead to the following risks: 
- Explore Internal Web Applications
- Access sensitive management interfaces
- Leak internal configuration, credentials, or confidential information

This vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in enterprise environments.
GitHub Security Advisory: GHSA-m7mq-85xj-9x33
Package: flowise (NPM)
Severity: MODERATE (CVSS 5.6)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Weak Default Token Hash Secret

Details:
**Detection Method:** Kolega.dev Deep Code Scan

| Attribute | Value |
|---|---|
| Location | packages/server/src/enterprise/utils/tempTokenUtils.ts:31-34 |
| Practical Exploitability | Medium |
| Developer Approver | faizan@kolega.ai |

### Description
The encryption key for token encryption has a weak default value 'Secre$t' when TOKEN_HASH_SECRET environment variable is not set.

### Affected Code
```
const key = crypto
    .createHash('sha256')
    .update(process.env.TOKEN_HASH_SECRET || 'Secre$t')
    .digest()
```

### Evidence
The default value 'Secre$t' is hardcoded in the source code and is cryptographically weak. This key is used to encrypt user IDs and workspace IDs in JWT tokens.

### Impact
Token forgery - attackers can decrypt and manipulate encrypted token metadata, potentially changing user IDs or workspace IDs to escalate privileges or access unauthorized data.

### Recommendation
Require TOKEN_HASH_SECRET to be set as a strong random value in environment variables. Throw an error on startup if not configured. Use a minimum of 32 bytes of entropy.

### Notes
The TOKEN_HASH_SECRET has a weak hardcoded default 'Secre$t' (lines 31-34 and 50-53). This secret is used to derive an AES-256-CBC encryption key for encrypting sensitive metadata (user ID and workspace ID) embedded in JWT tokens via encryptToken() called at line 394 of passport/index.ts. If TOKEN_HASH_SECRET is not configured, an attacker knowing the default can decrypt the 'meta' field in JWTs to extract user IDs and workspace IDs. While this alone doesn't grant access (the JWT signature is separate), it leaks internal identifiers that could aid other attacks. The .env.example shows '# TOKEN_HASH_SECRET='popcorn'' - another weak value, and it's commented out suggesting it's optional. The application should require this secret to be explicitly set with a strong random value.
GitHub Security Advisory: GHSA-2qqc-p94c-hxwh
Package: flowise (NPM)
Severity: MODERATE (CVSS 5.6)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Weak Default Express Session Secret

Details:
**Detection Method:** Kolega.dev Deep Code Scan

| Attribute | Value |
|---|---|
| Location | packages/server/src/enterprise/middleware/passport/index.ts:55 |
| Practical Exploitability | High |
| Developer Approver | faizan@kolega.ai |

### Description
Express session secret has a weak default value 'flowise' when EXPRESS_SESSION_SECRET is not set.

### Affected Code
```
secret: process.env.EXPRESS_SESSION_SECRET || 'flowise'
```

### Evidence
The default session secret 'flowise' is publicly visible and weak. Session cookies signed with this secret can be forged by attackers.

### Impact
Session hijacking and forgery - attackers can create arbitrary session cookies to impersonate any user, bypassing all authentication mechanisms.

### Recommendation
Require EXPRESS_SESSION_SECRET to be set with a strong random value. Throw an error on startup if not configured. Use cryptographically strong random strings (minimum 256 bits).

### Notes
The Express session secret defaults to the string 'flowise' when EXPRESS_SESSION_SECRET is not set (line 55). This secret is used to sign session cookies via express-session middleware. Since 'flowise' is publicly visible in the source code, an attacker can forge valid session cookies to impersonate any user without authentication. The .env.example file has this commented out (# EXPRESS_SESSION_SECRET=flowise), implying it's optional, which compounds the risk. Unlike development-only defaults, this code path is active in production if the environment variable is not set. The application should require EXPRESS_SESSION_SECRET to be explicitly configured with a cryptographically strong random value and fail to start otherwise.
GitHub Security Advisory: GHSA-cc4f-hjpj-g9p8
Package: flowise (NPM)
Severity: MODERATE (CVSS 5.6)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Weak Default JWT Secrets

Details:
**Detection Method:** Kolega.dev Deep Code Scan

| Attribute | Value |
|---|---|
| Severity | Critical |
| Location | packages/server/src/enterprise/middleware/passport/index.ts:29-34 |
| Practical Exploitability | High |
| Developer Approver | faizan@kolega.ai |

### Description
JWT secrets have weak hardcoded defaults ('auth_token', 'refresh_token', 'AUDIENCE', 'ISSUER'). Attackers can forge valid JWTs and impersonate any user.

### Affected Code
```
const jwtAudience = process.env.JWT_AUDIENCE || 'AUDIENCE'
const jwtIssuer = process.env.JWT_ISSUER || 'ISSUER'
const jwtAuthTokenSecret = process.env.JWT_AUTH_TOKEN_SECRET || 'auth_token'
const jwtRefreshSecret = process.env.JWT_REFRESH_TOKEN_SECRET || process.env.JWT_AUTH_TOKEN_SECRET || 'refresh_token'
```

### Evidence
All JWT defaults are weak strings. Refresh token falls back to auth token which is a design flaw. If any environment variable is unset, weak default is used.

### Impact
Complete authentication bypass. Attackers can forge valid JWTs for any user account. No authentication required to access protected endpoints. Can escalate to admin access.

### Recommendation
Remove all default secrets - require all JWT environment variables to be explicitly set. Add startup validation throwing error if any JWT secret is missing. Use cryptographically random secrets (256+ bits) for each secret independently. Implement JWT secret rotation mechanism.

### Notes
The JWT secrets have genuinely weak hardcoded defaults ('auth_token', 'refresh_token', 'AUDIENCE', 'ISSUER') at lines 29-34. If an administrator deploys without setting the environment variables JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, and JWT_ISSUER, the application will use these trivially guessable values. An attacker knowing these defaults (which are publicly visible in the source code) can forge valid JWTs to impersonate any user, including administrators. The fallback chain at line 34 where jwtRefreshSecret falls back to jwtAuthTokenSecret is an additional design weakness - if only JWT_AUTH_TOKEN_SECRET is set, both tokens share the same secret. While .env.example files provide placeholder values, these are also weak and publicly visible. The application should fail to start if these secrets are not explicitly configured with strong values, rather than silently falling back to insecure defaults.
GitHub Security Advisory: GHSA-gj9q-8w99-mp8j
Package: openclaw (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 2026.4.10
Patched in: 2026.4.10

Summary: OpenClaw: TOCTOU read in exec script preflight

Details:
## Summary

OpenClaw's exec script preflight validator previously validated and then read a script by mutable pathname. A local race could swap the path between validation and read, causing preflight analysis to inspect a different file identity than the one that passed the workspace boundary check.

## Affected Packages / Versions

- Package: `openclaw`
- Ecosystem: npm
- Affected versions: `< 2026.4.10`
- Patched versions: `>= 2026.4.10`

## Impact

The impact is limited. This was not arbitrary full-file disclosure through the preflight error path. The validator only surfaced derived preflight content, such as a matched token, a line number, or the first non-empty JavaScript line in one branch. Exploitation also required the ability to mutate the relevant workspace path during the preflight window.

Still, this was a real TOCTOU boundary bug in code that is supposed to reason about workspace-local script files before execution. A file identity that passed the initial boundary validation could differ from the identity that was later read for preflight analysis.

## Technical Details

The vulnerable flow performed separate path validation and file reads in `validateScriptFileForShellBleed`. Because the read was path-based, an attacker with write access to the workspace path could race replacement of the target after validation but before preflight read.

## Fix

PR #62333 replaced the check-then-read flow with a pinned safe-open/read path using the shared `readFileWithinRoot` helper. The fixed path performs boundary verification around the opened file identity and avoids relying on a mutable pathname for the final preflight read. Regression tests cover both pre-open and post-open swap windows.

## Fix Commit(s)

- `b024fae9e5df43e9b69b2daebb72be3469d52e91` (`fix(exec): replace TOCTOU check-then-read with atomic pinned-fd open in script preflight [AI]`)
- PR: #62333

## Release Process Note

The fix first shipped in `v2026.4.10`. Users should upgrade to `openclaw` `2026.4.10` or newer; the latest npm release already includes the fix.

## Credits

Thanks to @kikayli for reporting this issue.
GitHub Security Advisory: GHSA-c9gw-hvqq-f33r
Package: flowise-components (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Authenticated RCE Via MCP Adapters

Details:
### Summary
Due to unsafe serialization of stdio commands in the MCP adapter, an authenticated attacker can add an MCP stdio server with an arbitrary command, achieving command execution.

### Details
The vulnerability lies in a bug in the input sanitization from the “Custom MCP” configuration in http://localhost:3000/canvas - where any user can add a new MCP, when doing so - adding a new MCP using stdio, the user can add any command, even though your code have input sanitization checks such as validateCommandInjection and validateArgsForLocalFileAccess, and a list of predefined specific safe commands - these commands, for example "npx" can be combined with code execution arguments ("-c touch /tmp/pwn") that enable direct code execution on the underlying OS.

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L223

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L177

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L269


### PoC
Create a new Custom MCP and add an "npx -c" command.
```
{
    "command": "npx",
    "args": [
        "-c",
        "touch /tmp/pwn"
    ]
}
```
<img width="358" height="628" alt="Screenshot 2026-01-12 at 18 32 37" src="https://github.com/user-attachments/assets/d95c1ae2-23a7-4afe-b586-722003baf50e" />

### Impact
This is an authenticated arbitrary command execution due to unsanitized input, even though the input is sanitized, more protections should be added in order to close ways for attackers to execute arbitrary commands.
GitHub Security Advisory: GHSA-c9gw-hvqq-f33r
Package: flowise (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Authenticated RCE Via MCP Adapters

Details:
### Summary
Due to unsafe serialization of stdio commands in the MCP adapter, an authenticated attacker can add an MCP stdio server with an arbitrary command, achieving command execution.

### Details
The vulnerability lies in a bug in the input sanitization from the “Custom MCP” configuration in http://localhost:3000/canvas - where any user can add a new MCP, when doing so - adding a new MCP using stdio, the user can add any command, even though your code have input sanitization checks such as validateCommandInjection and validateArgsForLocalFileAccess, and a list of predefined specific safe commands - these commands, for example "npx" can be combined with code execution arguments ("-c touch /tmp/pwn") that enable direct code execution on the underlying OS.

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L223

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L177

https://github.com/FlowiseAI/Flowise/blob/d848baeb6bd9737a1e7fc912349c45fbdcc7bb38/packages/components/nodes/tools/MCP/core.ts#L269


### PoC
Create a new Custom MCP and add an "npx -c" command.
```
{
    "command": "npx",
    "args": [
        "-c",
        "touch /tmp/pwn"
    ]
}
```
<img width="358" height="628" alt="Screenshot 2026-01-12 at 18 32 37" src="https://github.com/user-attachments/assets/d95c1ae2-23a7-4afe-b586-722003baf50e" />

### Impact
This is an authenticated arbitrary command execution due to unsanitized input, even though the input is sanitized, more protections should be added in order to close ways for attackers to execute arbitrary commands.
GitHub Security Advisory: GHSA-wqq3-wfmp-v85g
Package: mojic (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: <= 2.1.3
Patched in: 2.1.4

Summary: Mojic: Observable Timing Discrepancy in HMAC Verification

Details:
### Summary
The `CipherEngine` in Mojic v2.1.3 uses a standard equality operator (`!==`) to verify the HMAC-SHA256 integrity seal during the decryption phase. This creates an Observable Timing Discrepancy (CWE-208), allowing a potential attacker to bypass the file integrity check via a timing attack.

### Details
In `lib/CipherEngine.js`, the footer check validates the HMAC signature using a standard string comparison:
`if (footerHex !== calcDigest) { ... }`

Standard string comparisons in JavaScript short-circuit; they return `false` the moment a character mismatch occurs. Because the time taken to evaluate the comparison is proportional to the number of matching leading bytes, an attacker can measure the exact microseconds it takes for the engine to throw the `FILE_TAMPERED` error. By repeatedly altering the signature byte-by-byte and analyzing these minute timing differences, a malicious actor can theoretically forge a valid HMAC signature without possessing the decryption password.

### PoC
The vulnerable implementation is located in `lib/CipherEngine.js`, within the `getDecryptStream()` flush method (approximately line 265):

```javascript
// Vulnerable Code
if (footerHex !== calcDigest) {
    this.emit('error', new Error("FILE_TAMPERED"));
    return;
}
```

### Recommended Remediation:
Replace the standard equality operator with Node.js's built-in constant-time comparison utility, crypto.timingSafeEqual().

```JavaScript
// Remediated Code
const footerBuffer = Buffer.from(footerHex, 'hex');
const calcBuffer = Buffer.from(calcDigest, 'hex');

if (footerBuffer.length !== calcBuffer.length || !crypto.timingSafeEqual(footerBuffer, calcBuffer)) {
    this.emit('error', new Error("FILE_TAMPERED"));
    return;
}
```

### Impact
If successfully exploited, an attacker could tamper with the encrypted .mojic payload and forge a valid HMAC signature. This bypasses the integrity seal, tricking the decryption engine into processing maliciously injected emoji streams. Because the engine translates these emojis back into C keywords and raw data chunks, this could ultimately result in arbitrary Code Injection into the restored .c source code when an unsuspecting user decrypts the tampered file.
GitHub Security Advisory: GHSA-jhm7-29pj-4xvf
Package: @node-oauth/oauth2-server (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts, CWE-1289: Improper Validation of Unsafe Equivalence in Input
Vulnerable versions: <= 5.2.1
Patched in: 5.3.0

Summary: @node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes

Details:
## Summary

The token exchange path accepts RFC7636-invalid `code_verifier` values (including one-character strings) for `S256` PKCE flows.  
Because short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force `code_verifier` guesses online until token issuance succeeds.



### Root cause

1. `lib/pkce/pkce.js` (`getHashForCodeChallenge`) only checks that `verifier` is a non-empty string before hashing for `S256`; it does not enforce RFC7636 ABNF (`43..128` unreserved chars).
2. `lib/grant-types/authorization-code-grant-type.js` compares `hash(code_verifier)` to stored `codeChallenge` without validating verifier format/length.
3. In `AuthorizationCodeGrantType.handle`, authorization code revocation happens **after** verifier validation. Invalid guesses fail before revoke, so the same code can be retried repeatedly.

## Steps to Reproduce

### Setup

- PKCE authorization code exists with:
  - `codeChallengeMethod = "S256"`
  - `codeChallenge = BASE64URL(SHA256("z"))` (verifier is one character, RFC-invalid)
- Attacker has intercepted the authorization code value.

### Reproduction

1. Send repeated token requests with guessed `code_verifier` values:

```http
POST /token HTTP/1.1
Host: oauth.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
client_id=client1&
client_secret=s3cret&
code=stolen-auth-code&
redirect_uri=https://client.example/callback&
code_verifier=<guess>
```

2. Observe invalid guesses return `invalid_grant`.
3. Continue guessing (`a`..`z`).
4. When `code_verifier=z`, token issuance succeeds and returns bearer tokens.

### Confirmed PoC output

```text
BRUTE_FORCE_SUCCESS { tries: 26, guess: 'z', status: 200, tokenIssued: true }
```

## Impact

An intercepted authorization code can be redeemed by brute-forcing low-entropy verifiers that the server should have rejected under RFC7636.  
This weakens PKCE’s protection goal and allows token theft when clients generate short/predictable verifiers.

## Recommended Fix

1. Enforce `pkce.codeChallengeMatchesABNF(request.body.code_verifier)` in authorization code token exchange before hashing/comparison.
2. Reject verifier values outside RFC7636 charset/length (`43..128` unreserved).
3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.