Vulnerability-Lookup

GHSA-MWWR-P57H-56PF

Vulnerability from github – Published: 2026-09-24 19:37 – Updated: 2026-09-24 19:38

Summary

@bytebase/dbhub's read-only mode does not prevent database writes

Details

Summary

Setting readonly = true on the execute_sql tool does not make the connection read-only. The connectors are written to set PostgreSQL default_transaction_read_only=on (and open SQLite in readOnly mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any SELECT that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary files on the server (lo_export), reading arbitrary host files (pg_read_file), and remote code execution (dblink + COPY ... TO PROGRAM). The HTTP transport is unauthenticated and binds to 0.0.0.0 by default, so this is reachable by any network caller of /mcp.

Details

Two problems combine.

1. The database-level read-only control is dead code.

PostgresConnector.connect() only enables it when config.readonly is truthy (src/connectors/postgres/index.ts:175-177):

// SDK-level readonly enforcement: Set default_transaction_read_only for the entire connection
if (config?.readonly) {
  poolConfig.options = (poolConfig.options || '') + ' -c default_transaction_read_only=on';
}

SQLite is gated the same way (src/connectors/sqlite/index.ts:192). ConnectorConfig.readonly is assigned in exactly one place, and only from source.readonly (src/connectors/manager.ts:236-238):

// Pass readonly flag for SDK-level enforcement (PostgreSQL, SQLite)
if (source.readonly !== undefined) {
  config.readonly = source.readonly;
}

source.readonly can never have a value:

SourceConfig has no readonly field (src/types/config.ts:49-62). readonly exists only on the per-tool ExecuteSqlToolConfig / CustomToolConfig.
The TOML loader rejects readonly at source level (src/config/toml-loader.ts:476-481: "readonly must be configured per-tool, not per-source").
The --readonly CLI flag was removed and now hard-exits (src/config/env.ts:30).

So the if (source.readonly !== undefined) check is always false, config.readonly stays unset, and DB-level read-only is never applied in any configuration the loader accepts. The per-tool readonly only ever reaches the classifier; executeSQL() ignores options.readonly and runs multi-statement batches in a plain BEGIN rather than BEGIN READ ONLY (src/connectors/postgres/index.ts:598-666).

(The docs already describe the classifier as "a safety net... not a security boundary." This report is about the DB-level control above, which the code clearly means to apply — see the "SDK-level readonly enforcement" comments — but silently fails to wire up.)

2. The classifier only checks the leading keyword.

areAllStatementsReadOnly() (src/tools/execute-sql.ts:24-27) splits on ; and runs isReadOnlySQL() (src/utils/allowed-keywords.ts) on each statement. isReadOnlySQL matches the first word against an allow-list, scans for mutating keywords only inside WITH, blocks SELECT ... INTO, and special-cases EXPLAIN ANALYZE. It never looks at the functions a statement calls. These all classify as read-only:

SELECT setval('seq', n) / nextval('seq') — sequence write. Needs UPDATE (setval) or USAGE/UPDATE (nextval) on the sequence, which read roles normally hold.
SELECT lo_export(lo, '/path') — writes a file on the server. Needs superuser or pg_write_server_files.
SELECT pg_read_file('/etc/passwd') — reads any file the server user can read. Needs superuser or pg_read_server_files.
SELECT dblink_exec('dbname=...', 'UPDATE ...') — opens a fresh connection (not read-only) and runs writes/DDL. Needs the dblink extension.
SELECT dblink_exec('dbname=...', $$COPY (SELECT 1) TO PROGRAM 'id'$$) — command execution. Needs superuser or pg_execute_server_program, plus dblink.

The read-only test suite covers none of these.

PoC

Point DBHub at a PostgreSQL source with read-only set on the tool:

[[sources]]
id = "default"
dsn = "postgres://app:app@localhost:5432/app"

[[tools]]
name = "execute_sql"
source = "default"
readonly = true

Start it and call execute_sql:

npx @bytebase/dbhub@latest --transport http --port 8080

With any role, a write that should be blocked goes through — the sequence value changes and the call returns success:

SELECT setval('users_id_seq', 1);

With a privileged role, the rest are also accepted and executed:

SELECT lo_export(lo_from_bytea(0, decode('48656c6c6f0a','hex')), '/tmp/dbhub_poc');   -- writes /tmp/dbhub_poc
SELECT pg_read_file('/etc/passwd');                                                  -- reads a host file
SELECT dblink_exec('dbname=app', 'UPDATE users SET admin=true');                     -- write via a new connection
SELECT dblink_exec('dbname=app', $$COPY (SELECT 1) TO PROGRAM 'id > /tmp/pwned'$$);  -- runs a shell command

The decision can be reproduced without a database by running the project's own isReadOnlySQL + splitSQLStatements (with areAllStatementsReadOnly copied from src/tools/execute-sql.ts) over the strings above: direct INSERT/UPDATE/DROP, data-modifying CTEs, SELECT ... INTO, and EXPLAIN ANALYZE INSERT are all rejected, while every function-based statement above returns read-only = true.

Impact

Affects all released versions up to and including 0.22.2, on both stdio and HTTP transports, for PostgreSQL and SQLite. readonly = true does not stop writes. Anyone who can reach the execute_sql input can modify data under read-only mode — a network caller of the unauthenticated /mcp endpoint, a malicious MCP client, or untrusted content reaching an agent wired to DBHub through prompt injection. When the configured database role is privileged (common, since DBHub is often pointed at an existing admin DSN), the same access yields arbitrary file write on the server, arbitrary host-file read, and remote code execution on the database host.

Maintainer note (consolidation)

Tracking this as the canonical advisory for "read-only mode does not prevent database writes." The following reports describe the same root cause (read-only enforced only by the keyword classifier; the connection-level backstop was never wired) and are closed as duplicates:

GHSA-7rgf-cwgq-c2qc — same unwired driver-level backstop, plus the SQLite write-effecting PRAGMA gap.
GHSA-m689-287g-5xpc — SQLite assignment-form PRAGMA write bypass (a subset of the above).

Preserving the SQLite-specific remediation from those reports: in isReadOnlySQL, the assignment form PRAGMA x = ... must be classified as a write (only the query/introspection form is read-only), and SQLite read-only executions are additionally guarded at the engine via PRAGMA query_only=ON.

GHSA-j656-3hf2-fvjc (MySQL/MariaDB -- comment parsing + multipleStatements) is a distinct root cause and is tracked separately.

Fix: https://github.com/bytebase/dbhub/pull/342 — adds engine-level read-only enforcement per tool (Postgres BEGIN READ ONLY, SQLite query_only, MySQL/MariaDB START TRANSACTION READ ONLY) plus the classifier hardening above.

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bytebase/dbhub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-636",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T19:37:59Z",
    "nvd_published_at": "2026-09-24T18:17:16Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n \nSetting `readonly = true` on the `execute_sql` tool does not make the connection read-only. The connectors are written to set PostgreSQL `default_transaction_read_only=on` (and open SQLite in `readOnly` mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any `SELECT` that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary files on the server (`lo_export`), reading arbitrary host files (`pg_read_file`), and remote code execution (`dblink` + `COPY ... TO PROGRAM`). The HTTP transport is unauthenticated and binds to `0.0.0.0` by default, so this is reachable by any network caller of `/mcp`.\n \n### Details\n \nTwo problems combine.\n \n**1. The database-level read-only control is dead code.**\n \n`PostgresConnector.connect()` only enables it when `config.readonly` is truthy (`src/connectors/postgres/index.ts:175-177`):\n \n```ts\n// SDK-level readonly enforcement: Set default_transaction_read_only for the entire connection\nif (config?.readonly) {\n  poolConfig.options = (poolConfig.options || \u0027\u0027) + \u0027 -c default_transaction_read_only=on\u0027;\n}\n```\n \nSQLite is gated the same way (`src/connectors/sqlite/index.ts:192`). `ConnectorConfig.readonly` is assigned in exactly one place, and only from `source.readonly` (`src/connectors/manager.ts:236-238`):\n \n```ts\n// Pass readonly flag for SDK-level enforcement (PostgreSQL, SQLite)\nif (source.readonly !== undefined) {\n  config.readonly = source.readonly;\n}\n```\n \n`source.readonly` can never have a value:\n \n- `SourceConfig` has no `readonly` field (`src/types/config.ts:49-62`). `readonly` exists only on the per-tool `ExecuteSqlToolConfig` / `CustomToolConfig`.\n- The TOML loader rejects `readonly` at source level (`src/config/toml-loader.ts:476-481`: \"readonly must be configured per-tool, not per-source\").\n- The `--readonly` CLI flag was removed and now hard-exits (`src/config/env.ts:30`).\n \nSo the `if (source.readonly !== undefined)` check is always false, `config.readonly` stays unset, and DB-level read-only is never applied in any configuration the loader accepts. The per-tool `readonly` only ever reaches the classifier; `executeSQL()` ignores `options.readonly` and runs multi-statement batches in a plain `BEGIN` rather than `BEGIN READ ONLY` (`src/connectors/postgres/index.ts:598-666`).\n \n(The docs already describe the classifier as \"a safety net... not a security boundary.\" This report is about the DB-level control above, which the code clearly means to apply \u2014 see the \"SDK-level readonly enforcement\" comments \u2014 but silently fails to wire up.)\n \n**2. The classifier only checks the leading keyword.**\n \n`areAllStatementsReadOnly()` (`src/tools/execute-sql.ts:24-27`) splits on `;` and runs `isReadOnlySQL()` (`src/utils/allowed-keywords.ts`) on each statement. `isReadOnlySQL` matches the first word against an allow-list, scans for mutating keywords only inside `WITH`, blocks `SELECT ... INTO`, and special-cases `EXPLAIN ANALYZE`. It never looks at the functions a statement calls. These all classify as read-only:\n \n- `SELECT setval(\u0027seq\u0027, n)` / `nextval(\u0027seq\u0027)` \u2014 sequence write. Needs UPDATE (setval) or USAGE/UPDATE (nextval) on the sequence, which read roles normally hold.\n- `SELECT lo_export(lo, \u0027/path\u0027)` \u2014 writes a file on the server. Needs superuser or `pg_write_server_files`.\n- `SELECT pg_read_file(\u0027/etc/passwd\u0027)` \u2014 reads any file the server user can read. Needs superuser or `pg_read_server_files`.\n- `SELECT dblink_exec(\u0027dbname=...\u0027, \u0027UPDATE ...\u0027)` \u2014 opens a fresh connection (not read-only) and runs writes/DDL. Needs the `dblink` extension.\n- `SELECT dblink_exec(\u0027dbname=...\u0027, $$COPY (SELECT 1) TO PROGRAM \u0027id\u0027$$)` \u2014 command execution. Needs superuser or `pg_execute_server_program`, plus `dblink`.\n \nThe read-only test suite covers none of these.\n \n### PoC\n \nPoint DBHub at a PostgreSQL source with read-only set on the tool:\n \n```toml\n[[sources]]\nid = \"default\"\ndsn = \"postgres://app:app@localhost:5432/app\"\n \n[[tools]]\nname = \"execute_sql\"\nsource = \"default\"\nreadonly = true\n```\n \nStart it and call `execute_sql`:\n \n```\nnpx @bytebase/dbhub@latest --transport http --port 8080\n```\n \nWith any role, a write that should be blocked goes through \u2014 the sequence value changes and the call returns success:\n \n```sql\nSELECT setval(\u0027users_id_seq\u0027, 1);\n```\n \nWith a privileged role, the rest are also accepted and executed:\n \n```sql\nSELECT lo_export(lo_from_bytea(0, decode(\u002748656c6c6f0a\u0027,\u0027hex\u0027)), \u0027/tmp/dbhub_poc\u0027);   -- writes /tmp/dbhub_poc\nSELECT pg_read_file(\u0027/etc/passwd\u0027);                                                  -- reads a host file\nSELECT dblink_exec(\u0027dbname=app\u0027, \u0027UPDATE users SET admin=true\u0027);                     -- write via a new connection\nSELECT dblink_exec(\u0027dbname=app\u0027, $$COPY (SELECT 1) TO PROGRAM \u0027id \u003e /tmp/pwned\u0027$$);  -- runs a shell command\n```\n \nThe decision can be reproduced without a database by running the project\u0027s own `isReadOnlySQL` + `splitSQLStatements` (with `areAllStatementsReadOnly` copied from `src/tools/execute-sql.ts`) over the strings above: direct INSERT/UPDATE/DROP, data-modifying CTEs, `SELECT ... INTO`, and `EXPLAIN ANALYZE INSERT` are all rejected, while every function-based statement above returns read-only = true.\n \n### Impact\n \nAffects all released versions up to and including 0.22.2, on both stdio and HTTP transports, for PostgreSQL and SQLite. `readonly = true` does not stop writes. Anyone who can reach the `execute_sql` input can modify data under read-only mode \u2014 a network caller of the unauthenticated `/mcp` endpoint, a malicious MCP client, or untrusted content reaching an agent wired to DBHub through prompt injection. When the configured database role is privileged (common, since DBHub is often pointed at an existing admin DSN), the same access yields arbitrary file write on the server, arbitrary host-file read, and remote code execution on the database host.\n \n\n---\n\n### Maintainer note (consolidation)\n\nTracking this as the canonical advisory for \"read-only mode does not prevent database writes.\" The following reports describe the same root cause (read-only enforced only by the keyword classifier; the connection-level backstop was never wired) and are closed as duplicates:\n\n- **GHSA-7rgf-cwgq-c2qc** \u2014 same unwired driver-level backstop, plus the SQLite write-effecting `PRAGMA` gap.\n- **GHSA-m689-287g-5xpc** \u2014 SQLite assignment-form `PRAGMA` write bypass (a subset of the above).\n\nPreserving the SQLite-specific remediation from those reports: in `isReadOnlySQL`, the assignment form `PRAGMA x = ...` must be classified as a write (only the query/introspection form is read-only), and SQLite read-only executions are additionally guarded at the engine via `PRAGMA query_only=ON`.\n\nGHSA-j656-3hf2-fvjc (MySQL/MariaDB `--` comment parsing + `multipleStatements`) is a distinct root cause and is tracked separately.\n\nFix: https://github.com/bytebase/dbhub/pull/342 \u2014 adds engine-level read-only enforcement per tool (Postgres `BEGIN READ ONLY`, SQLite `query_only`, MySQL/MariaDB `START TRANSACTION READ ONLY`) plus the classifier hardening above.",
  "id": "GHSA-mwwr-p57h-56pf",
  "modified": "2026-09-24T19:38:00Z",
  "published": "2026-09-24T19:37:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytebase/dbhub/security/advisories/GHSA-mwwr-p57h-56pf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61788"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytebase/dbhub/pull/342"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytebase/dbhub/commit/872bb338f7d31f6afe517a076ac3e3edafaaaf08"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytebase/dbhub"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytebase/dbhub/releases/tag/v0.22.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@bytebase/dbhub\u0027s read-only mode does not prevent database writes"
}

GHSA-P9JG-FCR6-3MHF

Vulnerability from github – Published: 2026-07-01 21:51 – Updated: 2026-07-01 21:51

Summary

OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms

Details

Summary

A flaw in com.ongres.scram:scram-client allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from SCRAM-SHA-256-PLUS (with channel binding) to standard SCRAM-SHA-256 (without channel binding), bypassing strict client-side enforcement policies.

Component Breakdown

This occurs due to a two-part failure in TlsServerEndpoint when a server presents an X.509 certificate using a modern signature algorithm that lacks traditional WITH naming structures (such as Ed25519 or post-quantum algorithms):

The internal hash derivation method fails to parse the algorithm name, swallows the resulting NoSuchAlgorithmException, and silently returns an empty byte array via the deprecatedgetChannelBindingData()` API.
The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.

Impact & Scope

This issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).

Drivers operating under a "prefer" or "allow" policy (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.

Remediation

Update your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.

If you are interacting with the ScramClient builder API directly (e.g., writing a custom driver or database extension):

Migrate Deprecated APIs: Stop using TlsServerEndpoint.getChannelBindingData(). Transition immediately to TlsServerEndpoint.getChannelBindingHash(), which correctly propagates NoSuchAlgorithmException up the stack.
Adopt Explicit Policies: Leverage the newly introduced ChannelBindingPolicy API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.

ScramClient client = ScramClient.builder()
    .advertisedMechanisms(serverMechanisms)
    .username(user)
    .password(pass)
    // Explicitly enforce strict boundaries if needed.
    .channelBindingPolicy(ChannelBindingPolicy.REQUIRE) 
    .channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)
    .build();

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.ongres.scram:scram-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.ongres.scram:scram-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:51:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA flaw in `com.ongres.scram:scram-client` allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from `SCRAM-SHA-256-PLUS` (with channel binding) to standard `SCRAM-SHA-256` (without channel binding), bypassing strict client-side enforcement policies.\n\n## Component Breakdown\n\nThis occurs due to a two-part failure in `TlsServerEndpoint` when a server presents an `X.509` certificate using a modern signature algorithm that lacks traditional `WITH` naming structures (such as `Ed25519` or post-quantum algorithms):\n\n1. The internal hash derivation method fails to parse the algorithm name, swallows the resulting `NoSuchAlgorithmException, and silently returns an empty byte array via the deprecated `getChannelBindingData()` API.\n2. The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication.\n\n## Impact \u0026 Scope\n\nThis issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).\n\nDrivers operating under a \"prefer\" or \"allow\" policy  (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.\n\n## Remediation\n\nUpdate your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.\n\nIf you are interacting with the `ScramClient` builder API directly (e.g., writing a custom driver or database extension):\n\n- Migrate Deprecated APIs: Stop using `TlsServerEndpoint.getChannelBindingData()`. Transition immediately to `TlsServerEndpoint.getChannelBindingHash()`, which correctly propagates `NoSuchAlgorithmException` up the stack.\n- Adopt Explicit Policies: Leverage the newly introduced `ChannelBindingPolicy` API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.\n\n```java\nScramClient client = ScramClient.builder()\n    .advertisedMechanisms(serverMechanisms)\n    .username(user)\n    .password(pass)\n    // Explicitly enforce strict boundaries if needed.\n    .channelBindingPolicy(ChannelBindingPolicy.REQUIRE) \n    .channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)\n    .build();\n```",
  "id": "GHSA-p9jg-fcr6-3mhf",
  "modified": "2026-07-01T21:51:17Z",
  "published": "2026-07-01T21:51:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ongres/scram"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms"
}

GHSA-Q2GC-XJQW-QP89

Vulnerability from github – Published: 2026-04-09 17:32 – Updated: 2026-05-06 02:40

Summary

OpenClaw: strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts

Details

Impact

strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts.

The approval-timeout fallback could allow inline eval commands that strictInlineEval was meant to require explicit approval for.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

Package: openclaw (npm)
Affected versions: <=2026.4.2
Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @zsxsoft and @KeenSecurityLab for reporting.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

5.9 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:32:49Z",
    "nvd_published_at": "2026-04-28T19:37:46Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nstrictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts.\n\nThe approval-timeout fallback could allow inline eval commands that strictInlineEval was meant to require explicit approval for.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c=2026.4.2`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @zsxsoft and @KeenSecurityLab for reporting.",
  "id": "GHSA-q2gc-xjqw-qp89",
  "modified": "2026-05-06T02:40:53Z",
  "published": "2026-04-09T17:32:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-q2gc-xjqw-qp89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42423"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/d7c3210cd6f5fdfdc1beff4c9541673e814354d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-strictinlineeval-approval-boundary-bypass-via-approval-timeout-fallback"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: strictInlineEval explicit-approval boundary bypassed by approval-timeout fallback on gateway and node exec hosts"
}

GHSA-Q5JF-9VFQ-H4H7

Vulnerability from github – Published: 2026-04-10 15:33 – Updated: 2026-04-24 20:42

Summary

Helm's plugin verification fails open when .prov is missing, allowing unsigned plugin install

Details

Helm is a package manager for Charts for Kubernetes. In Helm versions >=4.0.0 and <=4.1.3, Helm will install plugins missing provenance (.prov file) when signature verification is required.

Impact

The bug allows plugin authors to omit provenance (signing) data from plugins, bypassing plugin signature verification upon plugin install/update.

Notably, plugin hooks will be executed as designed on the installed plugin, enabling a malicious plugin to execute arbitrary code.

Patches

This issue has been patched in Helm v4.1.4

Installing/updating a plugin with missing provenance will error if signature verification is required.

Workarounds

Users may manually validate that a plugin archive is not missing provenance data (.prov file) before installation.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

8.4 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "helm.sh/helm/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T15:33:03Z",
    "nvd_published_at": "2026-04-09T16:16:27Z",
    "severity": "HIGH"
  },
  "details": "Helm is a package manager for Charts for Kubernetes. In Helm versions \u003e=4.0.0 and \u003c=4.1.3, Helm will install plugins missing provenance (`.prov` file) when signature verification is required.\n\n### Impact\n\nThe bug allows plugin authors to omit provenance (signing) data from plugins, bypassing plugin signature verification upon plugin install/update.\n\nNotably, plugin hooks will be executed as designed on the installed plugin, enabling a malicious plugin to execute arbitrary code.\n\n### Patches\n\nThis issue has been patched in Helm v4.1.4\n\nInstalling/updating a plugin with missing provenance will error if signature verification is required.\n\n### Workarounds\n\nUsers may manually validate that a plugin archive is not missing provenance data (`.prov` file) before installation.",
  "id": "GHSA-q5jf-9vfq-h4h7",
  "modified": "2026-04-24T20:42:00Z",
  "published": "2026-04-10T15:33:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/security/advisories/GHSA-q5jf-9vfq-h4h7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/commit/05fa37973dc9e42b76e1d2883494c87174b6074f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/helm/helm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/helm/helm/releases/tag/v4.1.4"
    },
    {
      "type": "WEB",
      "url": "https://helm.sh/docs/topics/provenance/#the-provenance-file"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Helm\u0027s plugin verification fails open when .prov is missing, allowing unsigned plugin install"
}

GHSA-QVR7-G57C-MRC7

Vulnerability from github – Published: 2026-03-13 15:48 – Updated: 2026-04-07 18:10

Summary

OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode

Details

Summary

In affected versions of openclaw, local gateway helper credential resolution treated configured but unavailable gateway.auth.token and gateway.auth.password SecretRefs as if they were unset and could fall back to gateway.remote.* credentials in local mode.

Impact

This could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue.

Affected Packages and Versions

Package: openclaw (npm)
Affected versions: <= 2026.3.8
Fixed in: 2026.3.11

Technical Details

The local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked "absent" to the helper layer.

Fix

OpenClaw now tracks whether the local auth input is configured separately from whether it resolves successfully. In local mode, remote fallback is allowed only when the matching local auth input is truly unset. The fix shipped in openclaw@2026.3.11.

Workarounds

Upgrade to 2026.3.11 or later.

Severity

2.5 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T15:48:21Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\nIn affected versions of `openclaw`, local gateway helper credential resolution treated configured but unavailable `gateway.auth.token` and `gateway.auth.password` SecretRefs as if they were unset and could fall back to `gateway.remote.*` credentials in local mode.\n\n## Impact\nThis could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue.\n\n## Affected Packages and Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.8`\n- Fixed in: `2026.3.11`\n\n## Technical Details\nThe local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked \"absent\" to the helper layer.\n\n## Fix\nOpenClaw now tracks whether the local auth input is configured separately from whether it resolves successfully. In local mode, remote fallback is allowed only when the matching local auth input is truly unset. The fix shipped in `openclaw@2026.3.11`.\n\n## Workarounds\nUpgrade to `2026.3.11` or later.",
  "id": "GHSA-qvr7-g57c-mrc7",
  "modified": "2026-04-07T18:10:22Z",
  "published": "2026-03-13T15:48:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qvr7-g57c-mrc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32970"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-credential-fallback-logic-bypass-via-unavailable-local-auth-secretrefs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode"
}

GHSA-RMHQ-3PJ8-86QJ

Vulnerability from github – Published: 2026-03-09 09:30 – Updated: 2026-03-09 09:30

Details

An administrator may attempt to block all networks by specifying "*" or "all" as the network identifier. However, these values are not supported and do not trigger any validation error. Instead, they are silently interpreted as network 0 which results in no networks being blocked at all.

Severity

4.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-41759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T09:15:59Z",
    "severity": "MODERATE"
  },
  "details": "An administrator may attempt to block all networks by specifying \"\\*\" or \"all\" as the network identifier. However, these values are not supported and do not trigger any validation error. Instead, they are silently interpreted as network 0 which results in no networks being blocked at all.",
  "id": "GHSA-rmhq-3pj8-86qj",
  "modified": "2026-03-09T09:30:30Z",
  "published": "2026-03-09T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41759"
    },
    {
      "type": "WEB",
      "url": "https://www.mbs-solutions.de/mbs-2025-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V44J-74XG-9J2Q

Vulnerability from github – Published: 2026-09-27 03:31 – Updated: 2026-09-27 03:31

Details

heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential returns None — because the credential ID does not exist or the caller is not authorized to use it — the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redis_host value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend's loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

6.8 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-100860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T02:17:25Z",
    "severity": "MODERATE"
  },
  "details": "heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential returns None \u2014 because the credential ID does not exist or the caller is not authorized to use it \u2014 the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redis_host value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend\u0027s loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.",
  "id": "GHSA-v44j-74xg-9j2q",
  "modified": "2026-09-27T03:31:06Z",
  "published": "2026-09-27T03:31:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/heymrun/heym/security/advisories/GHSA-fmpw-hj3m-xvj6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100860"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/heym-before-0.0.105-authentication-bypass-via-redis-node"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VCGP-9326-PQCP

Vulnerability from github – Published: 2026-05-04 22:01 – Updated: 2026-05-14 20:48

Summary

net-imap vulnerable to STARTTLS stripping via invalid response timing

Details

Summary

A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS.

Details

When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tls_verified?.

Impact

TLS bypass, leading to cleartext transmission of sensitive information.

Mitigation

Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS.
Connect to an implicit TLS port, rather than use STARTTLS with a cleartext port. This is strongly recommended anyway:
RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
Explicitly verify Net::IMAP#tls_verified? is true, before using the connection after #starttls.

Severity

7.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.9"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-392",
      "CWE-393",
      "CWE-636",
      "CWE-754",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:01:52Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA man-in-the-middle attacker can cause `Net::IMAP#starttls` to return \"successfully\", without starting TLS.\n\n### Details\n\nWhen using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes \"successfully\" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.\n\nThis allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.\n\n### Impact\n\nTLS bypass, leading to cleartext transmission of sensitive information.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.\n* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.\n  This is strongly recommended anyway:\n  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access\n  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context\n* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.",
  "id": "GHSA-vcgp-9326-pqcp",
  "modified": "2026-05-14T20:48:01Z",
  "published": "2026-05-04T22:01:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-vcgp-9326-pqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/0ede4c40b1523dfeaf95777b2678e54cc0fd9618"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/97e2488fb5401a1783bddd959dde007d9fbce42c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/f79d35bf5833f186e81044c57c843eda30c873da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.3.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42246.yml"
    },
    {
      "type": "WEB",
      "url": "https://nostarttls.secvuln.info"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/info/rfc8314"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap vulnerable to STARTTLS stripping via invalid response timing"
}

GHSA-VJR8-6JJG-P3HJ

Vulnerability from github – Published: 2026-03-09 09:30 – Updated: 2026-03-09 09:30

Details

An administrator may attempt to block all traffic by configuring a pass filter with an empty table. However, in UBR, an empty list does not enforce any restrictions and allows all network traffic to pass unfiltered.

Severity

4.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-41760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T09:16:00Z",
    "severity": "MODERATE"
  },
  "details": "An administrator may attempt to block all traffic by configuring a pass filter with an empty table. However, in UBR, an empty list does not enforce any restrictions and allows all network traffic to pass unfiltered.",
  "id": "GHSA-vjr8-6jjg-p3hj",
  "modified": "2026-03-09T09:30:30Z",
  "published": "2026-03-09T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41760"
    },
    {
      "type": "WEB",
      "url": "https://www.mbs-solutions.de/mbs-2025-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM29-7MQ3-9JRG

Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-04-07 18:10

Withdrawn 2026-04-07

Summary

Duplicate Advisory: OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qvr7-g57c-mrc7. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.11 contains a credential fallback vulnerability where unavailable local gateway.auth.token and gateway.auth.password SecretRefs are treated as unset, allowing fallback to remote credentials in local mode. Attackers can exploit misconfigured local auth references to cause CLI and helper paths to select incorrect credential sources, potentially bypassing intended local authentication boundaries.

Severity

2.5 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

2.0 (Low)


                  
                    CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "OpenClaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:10:17Z",
    "nvd_published_at": "2026-03-31T12:16:29Z",
    "severity": "LOW"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-qvr7-g57c-mrc7. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.11 contains a credential fallback vulnerability where unavailable local gateway.auth.token and gateway.auth.password SecretRefs are treated as unset, allowing fallback to remote credentials in local mode. Attackers can exploit misconfigured local auth references to cause CLI and helper paths to select incorrect credential sources, potentially bypassing intended local authentication boundaries.",
  "id": "GHSA-vm29-7mq3-9jrg",
  "modified": "2026-04-07T18:10:17Z",
  "published": "2026-03-31T12:31:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qvr7-g57c-mrc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32970"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-credential-fallback-logic-bypass-via-unavailable-local-auth-secretrefs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode",
  "withdrawn": "2026-04-07T18:10:17Z"
}

CWE-636

Not Failing Securely ('Failing Open')

Summary

Details

PoC

Impact

Maintainer note (consolidation)

Summary

Component Breakdown

Impact & Scope

Remediation

Impact

Affected Packages / Versions

Fix

Verification

Credits

Impact

Patches

Workarounds

Summary

Impact

Affected Packages and Versions

Technical Details

Fix

Workarounds

Summary

Details

Impact

Mitigation

Duplicate Advisory

Original Description

Mitigation