deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8g29-8xwr-qmhr
Package: @grackle-ai/server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: <= 0.70.5
Patched in: 0.70.6

Summary: @grackle-ai/server JSON.parse lacks try-catch logic in its gRPC Service AdapterConfig Handling

Details:
### Impact

`JSON.parse(env.adapterConfig)` is called without error handling in three locations within the gRPC service. While the data originates from the server's own SQLite database and should always be valid JSON, database corruption, migration errors, or unexpected state could cause an unhandled exception that crashes the gRPC handler.

Additionally, the parsed result is cast as `Record<string, unknown>` and passed to adapter methods without property validation, creating a theoretical prototype pollution surface if the database is compromised.

**Affected code:**
- `packages/server/src/grpc-service.ts:415` — `reconnectOrProvision` handler
- `packages/server/src/grpc-service.ts:482` — `stopEnvironment` handler
- `packages/server/src/grpc-service.ts:498` — `destroyEnvironment` handler

### Patches

**Fix:** Wrap in try-catch and return a meaningful gRPC error:
```typescript
let config: Record<string, unknown>;
try {
  config = JSON.parse(env.adapterConfig) as Record<string, unknown>;
} catch {
  throw new ConnectError("Invalid adapter configuration", Code.Internal);
}
```

### Workarounds

Ensure database integrity. Back up the SQLite database regularly.

### Resources

- CWE-754: Improper Check for Unusual or Exceptional Conditions
- File: `packages/server/src/grpc-service.ts`
GitHub Security Advisory: GHSA-5j35-xr4g-vwf4
Package: @grackle-ai/server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
Vulnerable versions: <= 0.70.4
Patched in: 0.70.5

Summary: @grackle-ai/server has a Missing Secure Flag on Session Cookie

Details:
### Impact

The session cookie is set with `HttpOnly; SameSite=Lax; Path=/` but does not include the `Secure` flag. This means the cookie will be sent over plain HTTP connections.

Since the server binds to `127.0.0.1` by default and uses HTTP (not HTTPS), this is acceptable for localhost use. However, when `--allow-network` is used to bind to `0.0.0.0`, cookies could be transmitted over insecure network connections and intercepted by an attacker.

**Affected code:**
- `packages/server/src/session.ts:76` — cookie string lacks `; Secure` attribute

### Patches

0.70.5

**Fix:** Conditionally add `; Secure` when served over HTTPS or when `--allow-network` is enabled:
```typescript
const securePart = isHttps ? "; Secure" : "";
return `${SESSION_COOKIE_NAME}=${cookieValue}; HttpOnly; SameSite=Lax; Path=/${securePart}; Max-Age=${maxAge}`;
```

### Workarounds

Do not use `--allow-network` over untrusted networks without a TLS-terminating reverse proxy.

### Resources

- OWASP: Secure Cookie Attribute
- File: `packages/server/src/session.ts`
GitHub Security Advisory: GHSA-3mjm-x6gw-2x42
Package: @grackle-ai/server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 0.70.3
Patched in: 0.70.4

Summary: @grackle-ai/server has Missing Content-Security-Policy and X-Frame-Options Headers

Details:
### Impact

The HTTP server does not set `Content-Security-Policy`, `X-Frame-Options`, or `X-Content-Type-Options` headers on any response. This reduces defense-in-depth against XSS, clickjacking, and MIME-sniffing attacks.

While the current XSS attack surface is small (React-markdown is configured safely, no `dangerouslySetInnerHTML`, Vite does not generate source maps), the absence of these headers means any future XSS vulnerability would have no secondary defense layer.

**Affected code:**
- `packages/server/src/index.ts` — all `res.writeHead()` calls only set `Content-Type`, with no security headers

### Patches

0.70.4

**Fix:** Add security headers to all HTML/API responses:
```typescript
res.writeHead(200, {
  "Content-Type": contentType,
  "Content-Security-Policy": "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:",
  "X-Frame-Options": "DENY",
  "X-Content-Type-Options": "nosniff"
});
```

### Workarounds

Use a reverse proxy (nginx, Caddy) in front of the Grackle server to inject security headers.

### References

- CWE-693: Protection Mechanism Failure
- OWASP: HTTP Security Response Headers
- File: `packages/server/src/index.ts`
GitHub Security Advisory: GHSA-xq7h-vwjp-5vrh
Package: @grackle-ai/powerline (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 0.70.0
Patched in: 0.70.1

Summary: @grackle-ai/powerline Runs Without Authentication by Default

Details:
### Impact

When `--token` is not provided and `GRACKLE_POWERLINE_TOKEN` is not set, the PowerLine gRPC server runs with **zero authentication**. A warning is logged (`"NO AUTH (development only)"`) but nothing prevents deployment in this state. Any client that can reach the PowerLine port can spawn agent sessions, access credential tokens, and execute code.

The default binding is `127.0.0.1` (loopback only), which limits exposure to the local machine. However, if PowerLine is accidentally exposed on a network (e.g., in a container or via port forwarding), the impact is critical.

**Affected code:**
- `packages/powerline/src/index.ts:46` — token defaults to empty string
- `packages/powerline/src/index.ts:63-76` — auth interceptor is only added when token is truthy

### Patches

0.70.1

**Fix:** Require an explicit `--no-auth` flag to run without authentication, rather than defaulting to no auth when the token is empty. Throw an error if starting without a token and without `--no-auth`.

### Workarounds

Always provide `--token` or set `GRACKLE_POWERLINE_TOKEN` when starting PowerLine. The Grackle server does this automatically when managing PowerLine lifecycle.

### Resources

- CWE-306: Missing Authentication for Critical Function
- File: `packages/powerline/src/index.ts`
GitHub Security Advisory: GHSA-w3hv-x4fp-6h6j
Package: @grackle-ai/server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: <= 0.70.2
Patched in: 0.70.3

Summary: @grackle-ai/server has Missing WebSocket Origin Header Validation

Details:
### Impact

The WebSocket upgrade handler in the server validates authentication (API key token or session cookie) but does not check the `Origin` header. A malicious webpage on a different origin could initiate a WebSocket connection to `ws://localhost:3000/ws` if it can leverage the user's session cookie (which is `SameSite=Lax`, allowing top-level navigations).

This enables **cross-origin WebSocket hijacking** — if a user visits a malicious site while a Grackle session is active, the attacker's page could open a WebSocket and subscribe to real-time events (session output, task updates, environment state).

**Affected code:**
- `packages/server/src/ws-bridge.ts:80-91` — connection handler accepts WebSocket upgrades without checking `req.headers.origin`

### Patches

**Fix:** Validate `req.headers.origin` against an allowlist before accepting connections:
```typescript
const origin = req.headers.origin || "";
if (origin && !origin.includes("localhost") && !origin.includes("127.0.0.1")) {
  ws.close(4003, "Invalid origin");
  return;
}
```

### Workarounds

Ensure the Grackle server is only accessible on `127.0.0.1` (the default). Do not use `--allow-network` in untrusted network environments.

### Resources

- CWE-346: Origin Validation Error
- File: `packages/server/src/ws-bridge.ts`
GitHub Security Advisory: GHSA-647h-p824-99w7
Package: @grackle-ai/mcp (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: <= 0.70.1
Patched in: 0.70.2

Summary: @grackle-ai/mcp has a workspace authorization bypass in its knowledge_search MCP tool

Details:
### Impact

The `knowledge_search` and `knowledge_get_node` MCP tools are included in `SCOPED_TOOLS` (visible to scoped agents) but their handlers do not receive `authContext` and do not enforce workspace scoping. A scoped agent in Workspace A can supply an arbitrary `workspaceId` parameter to search or retrieve knowledge graph nodes from Workspace B, bypassing workspace isolation boundaries.

This is a **cross-workspace data leakage** vulnerability affecting any deployment where multiple workspaces contain sensitive knowledge graph data and scoped agents are used.

**Affected code:**
- `packages/mcp/src/tools/knowledge.ts:146-169` (knowledge_search handler)
- `packages/mcp/src/tools/knowledge.ts:244-283` (knowledge_get_node handler)
- `packages/mcp/src/tool-scoping.ts:11` (both tools listed in SCOPED_TOOLS)

**Contrast with correct implementation:** `knowledge_create_node` (same file, lines 334-357) properly receives `authContext` and overrides the user-supplied `workspaceId` for scoped callers.

### Design Note

Cross-workspace knowledge sharing is a legitimate future feature — agents working across different repos may need to collaborate and share knowledge. However, this access should be **opt-in with explicit grants**, not an implicit bypass. The immediate fix locks scoped agents to their own workspace. A future design could introduce:
- Workspace-level "share knowledge with" settings
- A `cross_workspace` scope on scoped tokens
- Explicit `workspaceIds` (plural) in the auth context

### Patches

**Fix:** Add `authContext` parameter to `knowledge_search` and `knowledge_get_node` handlers and enforce workspace scoping, matching the pattern in `knowledge_create_node`:
```typescript
const resolvedWorkspaceId =
  authContext?.type === "scoped"
    ? authContext.workspaceId ?? ""
    : workspaceId ?? "";
```

When cross-workspace collaboration is designed, this check can be relaxed intentionally with proper access controls.

### Workarounds

Do not use scoped agent tokens in multi-workspace deployments until patched. Alternatively, remove `knowledge_search` and `knowledge_get_node` from the `SCOPED_TOOLS` set in `tool-scoping.ts`.

### References

- CWE-284: Improper Access Control
- File: `packages/mcp/src/tools/knowledge.ts`
- File: `packages/mcp/src/tool-scoping.ts`
GitHub Security Advisory: GHSA-7q9x-8g6p-3x75
Package: @grackle-ai/server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.70.0
Patched in: 0.70.1

Summary: @grackle-ai/server: Unescaped Error String in renderPairingPage() HTML Template

Details:
### Impact

The `renderPairingPage()` function embeds the `error` parameter directly into HTML without escaping:
```typescript
const errorHtml = error ? `<p style="color:#e74c3c">${error}</p>` : "";
```

All current call sites pass hardcoded strings, so this is **not exploitable today**. However, the function is architecturally fragile — if a future code change passes user-controlled or dynamic content into the error parameter, it would create an XSS vulnerability.

The `renderAuthorizePage()` function in the same file correctly uses `escapeHtml()` for dynamic content, making this an inconsistency.

**Affected code:**
- `packages/server/src/index.ts:64-89` — `renderPairingPage()` with unescaped error interpolation
- Compare: `packages/server/src/index.ts:130` — `renderAuthorizePage()` correctly uses `escapeHtml()`

### Patches

v0.70.1

**Fix:** Apply `escapeHtml()` to the error parameter:
```typescript
const errorHtml = error ? `<p style="color:#e74c3c">${escapeHtml(error)}</p>` : "";
```

### Workarounds

No workaround needed — all current callers pass hardcoded strings.

### Resources

- CWE-79: Improper Neutralization of Input During Web Page Generation
- File: `packages/server/src/index.ts`
GitHub Security Advisory: GHSA-xvh5-5qg4-x9qp
Package: n8n (NPM)
Severity: HIGH (CVSS 6.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: >= 2.0.0-rc.0, < 2.9.3
Patched in: 2.9.3

Summary: n8n has In-Process Memory Disclosure in its Task Runner

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the JavaScript Task Runner to allocate uninitialized memory buffers. Uninitialized buffers may contain residual data from the same Node.js process — including data from prior requests, tasks, secrets, or tokens — resulting in information disclosure of sensitive in-process data.
- Task Runners must be enabled using `N8N_RUNNERS_ENABLED=true`.
- In external runner mode, the impact is limited to data within the external runner process.

## Patches
The issue has been fixed in n8n versions >= 1.123.22, >= 2.10.1 , and >= 2.9.3. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Use external runner mode (`N8N_RUNNERS_MODE=external`) to isolate the runner process.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-xvh5-5qg4-x9qp
Package: n8n (NPM)
Severity: HIGH (CVSS 6.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: >= 2.10.0, < 2.10.1
Patched in: 2.10.1

Summary: n8n has In-Process Memory Disclosure in its Task Runner

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the JavaScript Task Runner to allocate uninitialized memory buffers. Uninitialized buffers may contain residual data from the same Node.js process — including data from prior requests, tasks, secrets, or tokens — resulting in information disclosure of sensitive in-process data.
- Task Runners must be enabled using `N8N_RUNNERS_ENABLED=true`.
- In external runner mode, the impact is limited to data within the external runner process.

## Patches
The issue has been fixed in n8n versions >= 1.123.22, >= 2.10.1 , and >= 2.9.3. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Use external runner mode (`N8N_RUNNERS_MODE=external`) to isolate the runner process.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-xvh5-5qg4-x9qp
Package: n8n (NPM)
Severity: HIGH (CVSS 6.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: < 1.123.22
Patched in: 1.123.22

Summary: n8n has In-Process Memory Disclosure in its Task Runner

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the JavaScript Task Runner to allocate uninitialized memory buffers. Uninitialized buffers may contain residual data from the same Node.js process — including data from prior requests, tasks, secrets, or tokens — resulting in information disclosure of sensitive in-process data.
- Task Runners must be enabled using `N8N_RUNNERS_ENABLED=true`.
- In external runner mode, the impact is limited to data within the external runner process.

## Patches
The issue has been fixed in n8n versions >= 1.123.22, >= 2.10.1 , and >= 2.9.3. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Use external runner mode (`N8N_RUNNERS_MODE=external`) to isolate the runner process.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-2w8x-224x-785m
Package: sjcl (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-325: Missing Cryptographic Step, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 1.0.8
Patched in: 1.0.9

Summary: sjcl is missing point-on-curve validation in sjcl.ecc.basicKey.publicKey

Details:
All versions of the package sjcl are vulnerable to Improper Verification of Cryptographic Signature due to missing point-on-curve validation in sjcl.ecc.basicKey.publicKey(). An attacker can recover a victim's ECDH private key by sending crafted off-curve public keys and observing ECDH outputs. The dhJavaEc() function directly returns the raw x-coordinate of the scalar multiplication result (no hashing), providing a plaintext oracle without requiring any decryption feedback.
GitHub Security Advisory: GHSA-37mj-c2wf-cx96
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 8.6.61
Patched in: 8.6.61

Summary: Parse Server exposes auth data via /users/me endpoint

Details:
### Impact

An authenticated user calling `GET /users/me` receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely.

### Patches

The `/users/me` endpoint now queries the session and user data separately, using the caller's authentication context for the user query so that all security layers apply correctly.

### Workarounds

There is no known workaround.
GitHub Security Advisory: GHSA-37mj-c2wf-cx96
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.55
Patched in: 9.6.0-alpha.55

Summary: Parse Server exposes auth data via /users/me endpoint

Details:
### Impact

An authenticated user calling `GET /users/me` receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely.

### Patches

The `/users/me` endpoint now queries the session and user data separately, using the caller's authentication context for the user query so that all security layers apply correctly.

### Workarounds

There is no known workaround.
GitHub Security Advisory: GHSA-2299-ghjr-6vjp
Package: parse-server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 8.6.60
Patched in: 8.6.60

Summary: Parse Server: MFA recovery code single-use bypass via concurrent requests

Details:
### Impact

An attacker who obtains a user's password and a single MFA recovery code can reuse that recovery code an unlimited number of times by sending concurrent login requests. This defeats the single-use design of recovery codes. The attack requires the user's password, a valid recovery code, and the ability to send concurrent requests within milliseconds.

### Patches

The login handler now uses optimistic locking when updating auth data that contains consumed single-use tokens. If a concurrent request has already modified the recovery array, the update fails and the login is rejected.

### Workarounds

There are no known workarounds.
GitHub Security Advisory: GHSA-2299-ghjr-6vjp
Package: parse-server (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.54
Patched in: 9.6.0-alpha.54

Summary: Parse Server: MFA recovery code single-use bypass via concurrent requests

Details:
### Impact

An attacker who obtains a user's password and a single MFA recovery code can reuse that recovery code an unlimited number of times by sending concurrent login requests. This defeats the single-use design of recovery codes. The attack requires the user's password, a valid recovery code, and the ability to send concurrent requests within milliseconds.

### Patches

The login handler now uses optimistic locking when updating auth data that contains consumed single-use tokens. If a concurrent request has already modified the recovery array, the update fails and the login is rejected.

### Workarounds

There are no known workarounds.
GitHub Security Advisory: GHSA-p2w6-rmh7-w8q3
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 8.6.59
Patched in: 8.6.59

Summary: Parse Server has SQL Injection through aggregate and distinct field names in PostgreSQL adapter

Details:
### Impact

An attacker with master key access can execute arbitrary SQL statements on the PostgreSQL database by injecting SQL metacharacters into field name parameters of the aggregate `$group` pipeline stage or the `distinct` operation. This allows privilege escalation from Parse Server application-level administrator to PostgreSQL database-level access.

Only Parse Server deployments using PostgreSQL are affected. MongoDB deployments are not affected.

### Patches

Field names in the aggregate `$group._id` object values and `distinct` dot-notation parameters are now validated to only contain alphanumeric characters and underscores, preventing SQL injection via the `:raw` interpolation used in the PostgreSQL storage adapter.

### Workarounds

No workaround. Upgrade to a patched version.
GitHub Security Advisory: GHSA-p2w6-rmh7-w8q3
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.53
Patched in: 9.6.0-alpha.53

Summary: Parse Server has SQL Injection through aggregate and distinct field names in PostgreSQL adapter

Details:
### Impact

An attacker with master key access can execute arbitrary SQL statements on the PostgreSQL database by injecting SQL metacharacters into field name parameters of the aggregate `$group` pipeline stage or the `distinct` operation. This allows privilege escalation from Parse Server application-level administrator to PostgreSQL database-level access.

Only Parse Server deployments using PostgreSQL are affected. MongoDB deployments are not affected.

### Patches

Field names in the aggregate `$group._id` object values and `distinct` dot-notation parameters are now validated to only contain alphanumeric characters and underscores, preventing SQL injection via the `:raw` interpolation used in the PostgreSQL storage adapter.

### Workarounds

No workaround. Upgrade to a patched version.
GitHub Security Advisory: GHSA-g4cf-xj29-wqqr
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 8.6.58
Patched in: 8.6.58

Summary: Parse Server: Denial of Service via unindexed database query for unconfigured auth providers

Details:
### Impact

An unauthenticated attacker can cause Denial of Service by sending authentication requests with arbitrary, unconfigured provider names. The server executes a database query for each unconfigured provider before rejecting the request, and since no database index exists for unconfigured providers, each request triggers a full collection scan on the user database. This can be parallelized to saturate database resources.

### Patches

The fix validates that an authentication provider is configured before executing any database query. Requests with unconfigured providers are now rejected immediately without querying the database.

### Workarounds

There is no known workaround other than upgrading.