CWE-636
Allowed-with-ReviewNot Failing Securely ('Failing Open')
Abstraction: Class · Status: Draft
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
102 vulnerabilities reference this CWE, most recent first.
GHSA-72FJ-C222-7598
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31OpenClaw before 2026.3.31 contains a decompression bomb vulnerability in image processing that fails to properly enforce pixel-limit guards on sips. Attackers can exploit this by uploading oversized images to cause denial of service through excessive memory consumption.
{
"affected": [],
"aliases": [
"CVE-2026-41334"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T22:16:39Z",
"severity": "HIGH"
},
"details": "OpenClaw before 2026.3.31 contains a decompression bomb vulnerability in image processing that fails to properly enforce pixel-limit guards on sips. Attackers can exploit this by uploading oversized images to cause denial of service through excessive memory consumption.",
"id": "GHSA-72fj-c222-7598",
"modified": "2026-04-24T00:31:51Z",
"published": "2026-04-24T00:31:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w85g-3h6x-4xh2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41334"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/0ed4f8a72bb140045962e97ab01c94c076b758a4"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-decompression-bomb-denial-of-service-via-image-pixel-limit-guard-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/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-73P9-6HRP-8QHR
Vulnerability from github – Published: 2026-08-28 19:20 – Updated: 2026-08-28 19:20Summary
Several of AIIR's verification and policy paths could return a success/"verified" result without actually enforcing the control they represent — they could fail open rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.
Found during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in 1.7.0.
Affected paths
- A
require_signingpolicy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a "signing required" check without a valid signature. - A CI verification path could report
successregardless of the underlying verification result. - A release-verification gate could advertise policy limits it did not actually enforce.
- A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.
Impact
A consumer relying on these gates (e.g. require_signing, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false "verified"/"pass". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.
Patches
Fixed in 1.7.0. Every affected path now fails closed, each with a regression test. Upgrade to aiir >= 1.7.0.
Workarounds
None for earlier versions other than upgrading. Full cryptographic Sigstore verification (pip install aiir[sign], --verify-signature with --signer-identity/--signer-issuer) provides defense in depth.
Scope note
This advisory covers code present in released versions (< 1.7.0). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped — those were never in a released version and are out of scope.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "aiir"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T19:20:32Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nSeveral of AIIR\u0027s verification and policy paths could return a success/\"verified\" result without actually enforcing the control they represent \u2014 they could **fail open** rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.\n\nFound during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in **1.7.0**.\n\n### Affected paths\n- A `require_signing` policy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a \"signing required\" check without a valid signature.\n- A CI verification path could report `success` regardless of the underlying verification result.\n- A release-verification gate could advertise policy limits it did not actually enforce.\n- A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.\n\n### Impact\nA consumer relying on these gates (e.g. `require_signing`, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false \"verified\"/\"pass\". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.\n\n### Patches\nFixed in **1.7.0**. Every affected path now fails closed, each with a regression test. Upgrade to `aiir \u003e= 1.7.0`.\n\n### Workarounds\nNone for earlier versions other than upgrading. Full cryptographic Sigstore verification (`pip install aiir[sign]`, `--verify-signature` with `--signer-identity`/`--signer-issuer`) provides defense in depth.\n\n### Scope note\nThis advisory covers code present in released versions (`\u003c 1.7.0`). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped \u2014 those were never in a released version and are out of scope.",
"id": "GHSA-73p9-6hrp-8qhr",
"modified": "2026-08-28T19:20:32Z",
"published": "2026-08-28T19:20:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/invariant-systems-ai/aiir/security/advisories/GHSA-73p9-6hrp-8qhr"
},
{
"type": "PACKAGE",
"url": "https://github.com/invariant-systems-ai/aiir"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AIIR verification and policy gates could report success without enforcing the control (fail-open)"
}
GHSA-7C38-49CX-FJVW
Vulnerability from github – Published: 2026-08-29 00:31 – Updated: 2026-08-29 00:31IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB's fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device's own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.
{
"affected": [],
"aliases": [
"CVE-2026-82018"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T22:16:55Z",
"severity": "MODERATE"
},
"details": "IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB\u0027s fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device\u0027s own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.",
"id": "GHSA-7c38-49cx-fjvw",
"modified": "2026-08-29T00:31:03Z",
"published": "2026-08-29T00:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82018"
},
{
"type": "WEB",
"url": "https://blog.amberwolf.com/blog/2026/august/thin-client-thin-crypto-overview"
},
{
"type": "WEB",
"url": "https://kb.igel.com/en/security-safety/current/isn-2026-20-grub-shell-escape-in-igel-os"
},
{
"type": "WEB",
"url": "https://media.defcon.org/DEF%20CON%2034/DEF%20CON%2034%20presentations/DEF%20CON%2034%20presentations/DEF%20CON%2034%20-%20Darren%20McDonald%20-%20Thin%20Client%20Thin%20Crypto%20-%20Bypassing%20Full-Desk%20Encryption%20Across%20Three%20Major%20Thin%20Clients%20Vendors%20without%20Breaking%20a%20Ci.pdf"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/igel-os-12-11-secure-boot-bypass-via-unsigned-igel-conf-file"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/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-8FPG-XM3F-6CX3
Vulnerability from github – Published: 2026-07-23 14:52 – Updated: 2026-08-12 20:31Impact
next-auth (Auth.js) v5 applications that gate access by checking only for the existence of the auth object — the pattern shown in the official session management / protecting resources guide — are affected.
When the Auth.js configuration produces a server-side error, the auth object exposed by the auth() wrapper (in middleware, Route Handlers, etc.) is populated with an error object instead of being null:
{ "message": "There was a problem with the server configuration. Check the server logs for more information." }
Because this object is truthy, any authorization check of the form !!auth (or if (req.auth)) evaluates to true for every request, including unauthenticated ones. The application fails open: instead of denying access when the auth layer is broken, it grants access to everyone.
// middleware.ts — affected pattern
export default auth((req) => {
const { nextUrl, auth } = req
const isLoggedIn = !!auth // <-- always true when the configuration is broken
// ...
})
A representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither issuer nor authorization endpoint set logs:
[auth][error] InvalidEndpoints: Provider "keycloak" is missing both `issuer` and `authorization` endpoint config. At least one of them is required.
…and from that point on auth is the error object above, so !!auth is permanently true. The same fail-open behavior occurs for other server-configuration errors (for example, an unset AUTH_SECRET).
There is no impact while the configuration is valid. The risk materializes when a previously-working deployment becomes misconfigured — e.g. an environment variable is changed or removed during a deploy — at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Because the failure mode is silent and grants access to everyone, the consequences can be severe.
This is an instance of CWE-636 (Not Failing Securely / "Failing Open") leading to improper authorization (CWE-285).
Patches
The fix ensures that a server-configuration error no longer surfaces as a truthy auth object: existence checks fail closed rather than open. This is released in next-auth@<!-- TODO: set patched version on publish -->.
To upgrade:
npm i next-auth@beta
yarn add next-auth@beta
pnpm add next-auth@beta
Workarounds
If you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session:
// middleware.ts
export default auth((req) => {
// `auth.user` is only present on a real session; resilient to config-error objects
const isLoggedIn = !!req.auth?.user
// ...
})
As defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat [auth][error] log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only — for authorization, perform an explicit role/permission check rather than relying on session existence. See the role-based access control guide.
References
- Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting
- Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control
- Auth.js error reference: https://authjs.dev/reference/core/errors
For more information
If you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security
Credits
Reported by @marc-zollingkoffer-syzygy.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0-beta.31"
},
"package": {
"ecosystem": "npm",
"name": "next-auth"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.0"
},
{
"fixed": "5.0.0-beta.32"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73421"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-23T14:52:23Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\n\n`next-auth` (Auth.js) v5 applications that gate access by checking only for the **existence** of the `auth` object \u2014 the pattern shown in the official [session management / protecting resources guide](https://authjs.dev/getting-started/session-management/protecting) \u2014 are affected.\n\nWhen the Auth.js configuration produces a server-side error, the `auth` object exposed by the `auth()` wrapper (in middleware, Route Handlers, etc.) is **populated with an error object instead of being `null`**:\n\n```json\n{ \"message\": \"There was a problem with the server configuration. Check the server logs for more information.\" }\n```\n\nBecause this object is truthy, any authorization check of the form `!!auth` (or `if (req.auth)`) evaluates to `true` for **every** request, including unauthenticated ones. The application *fails open*: instead of denying access when the auth layer is broken, it grants access to everyone.\n\n```ts\n// middleware.ts \u2014 affected pattern\nexport default auth((req) =\u003e {\n const { nextUrl, auth } = req\n const isLoggedIn = !!auth // \u003c-- always true when the configuration is broken\n // ...\n})\n```\n\nA representative trigger is a provider that is missing required configuration. For example, a Keycloak provider with neither `issuer` nor `authorization` endpoint set logs:\n\n```\n[auth][error] InvalidEndpoints: Provider \"keycloak\" is missing both `issuer` and `authorization` endpoint config. At least one of them is required.\n```\n\n\u2026and from that point on `auth` is the error object above, so `!!auth` is permanently `true`. The same fail-open behavior occurs for other server-configuration errors (for example, an unset `AUTH_SECRET`).\n\nThere is **no impact while the configuration is valid**. The risk materializes when a previously-working deployment becomes misconfigured \u2014 e.g. an environment variable is changed or removed during a deploy \u2014 at which point existence-based auth checks silently stop protecting routes and all visitors are treated as authenticated. Because the failure mode is silent and grants access to everyone, the consequences can be severe.\n\nThis is an instance of CWE-636 (Not Failing Securely / \"Failing Open\") leading to improper authorization (CWE-285).\n\n### Patches\n\nThe fix ensures that a server-configuration error no longer surfaces as a truthy `auth` object: existence checks fail **closed** rather than open. This is released in `next-auth@\u003c!-- TODO: set patched version on publish --\u003e`.\n\nTo upgrade:\n\n```sh\nnpm i next-auth@beta\n```\n```sh\nyarn add next-auth@beta\n```\n```sh\npnpm add next-auth@beta\n```\n\n### Workarounds\n\nIf you cannot upgrade immediately, check for a concrete user/session property rather than the bare object, so a configuration-error object is not treated as an authenticated session:\n\n```ts\n// middleware.ts\nexport default auth((req) =\u003e {\n // `auth.user` is only present on a real session; resilient to config-error objects\n const isLoggedIn = !!req.auth?.user\n // ...\n})\n```\n\nAs defense in depth, make Auth.js configuration errors fail loudly in your deployment pipeline (for example, treat `[auth][error]` log lines as a failed health check) so a broken configuration cannot silently reach production. As always, an existing session indicates authentication only \u2014 for authorization, perform an explicit role/permission check rather than relying on session existence. See the [role-based access control guide](https://authjs.dev/guides/role-based-access-control).\n\n### References\n\n- Protecting resources / session management: https://authjs.dev/getting-started/session-management/protecting\n- Role-based access control (RBAC): https://authjs.dev/guides/role-based-access-control\n- Auth.js error reference: https://authjs.dev/reference/core/errors\n\n### For more information\n\nIf you have any concerns, Auth.js requests responsible disclosure, outlined here: https://authjs.dev/security\n\n### Credits\n\nReported by @marc-zollingkoffer-syzygy.",
"id": "GHSA-8fpg-xm3f-6cx3",
"modified": "2026-08-12T20:31:20Z",
"published": "2026-07-23T14:52:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/security/advisories/GHSA-8fpg-xm3f-6cx3"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/commit/d008b9b764bf4b322a87e1822d1dda7789258d8f"
},
{
"type": "PACKAGE",
"url": "https://github.com/nextauthjs/next-auth"
},
{
"type": "WEB",
"url": "https://github.com/nextauthjs/next-auth/releases/tag/next-auth@5.0.0-beta.32"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Auth.js: Configuration errors can cause existence-based auth checks to fail open (auth object populated with an error)"
}
GHSA-8MG9-J9CF-54CJ
Vulnerability from github – Published: 2026-06-18 20:42 – Updated: 2026-06-18 20:42Summary
Empty-scope device re-pairing could confuse caller scope containment. In affected versions, a device re-pairing request with an empty scope set could skip the intended containment guard during re-pairing.
This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.
Impact
When the affected feature is enabled and reachable, this could restore or retain scopes broader than the caller should grant. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.
Patched Versions
The first stable patched version is 2026.4.25.
Mitigations
revoke unexpected device sessions and require fresh pairing for suspicious devices until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.4.24"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53852"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T20:42:40Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nEmpty-scope device re-pairing could confuse caller scope containment. In affected versions, a device re-pairing request with an empty scope set could skip the intended containment guard during re-pairing.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could restore or retain scopes broader than the caller should grant. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.25`.\n\n### Mitigations\n\nrevoke unexpected device sessions and require fresh pairing for suspicious devices until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
"id": "GHSA-8mg9-j9cf-54cj",
"modified": "2026-06-18T20:42:40Z",
"published": "2026-06-18T20:42:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8mg9-j9cf-54cj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53852"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-scope-bypass-via-empty-scope-device-re-pairing"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Empty-scope device re-pairing could confuse caller scope containment"
}
GHSA-8X8C-HP7F-675G
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33Remote Registry Service Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-43532"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T18:15:17Z",
"severity": "HIGH"
},
"details": "Remote Registry Service Elevation of Privilege Vulnerability",
"id": "GHSA-8x8c-hp7f-675g",
"modified": "2024-10-08T18:33:15Z",
"published": "2024-10-08T18:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43532"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43532"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-97FV-H8PQ-9GRG
Vulnerability from github – Published: 2026-09-15 18:32 – Updated: 2026-09-15 18:32Server-Side Request Forgery (SSRF) vulnerability in Slab safeurl allows an attacker who controls a validated URL to reach internal network destinations the library is configured to block.
Only IPv4 addresses are matched against the reserved ranges and the blocklist. Every other address is treated as matching nothing, so a destination that is rejected in its IPv4 form is accepted when written as an IPv6 address, IPv6 entries in the blocklist never match, and a host that resolves to no IPv4 address is accepted regardless of where it points. Deployments that rely on the allowlist instead are unaffected, because there an unmatched address is rejected.
This issue affects safeurl: from 0.1.0 onward.
{
"affected": [],
"aliases": [
"CVE-2026-77866"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T16:17:24Z",
"severity": "CRITICAL"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Slab safeurl allows an attacker who controls a validated URL to reach internal network destinations the library is configured to block.\n\nOnly IPv4 addresses are matched against the reserved ranges and the blocklist. Every other address is treated as matching nothing, so a destination that is rejected in its IPv4 form is accepted when written as an IPv6 address, IPv6 entries in the blocklist never match, and a host that resolves to no IPv4 address is accepted regardless of where it points. Deployments that rely on the allowlist instead are unaffected, because there an unmatched address is rejected.\n\nThis issue affects safeurl: from 0.1.0 onward.",
"id": "GHSA-97fv-h8pq-9grg",
"modified": "2026-09-15T18:32:26Z",
"published": "2026-09-15T18:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77866"
},
{
"type": "WEB",
"url": "https://github.com/slab/safeurl-elixir/commit/feabbd0a13f83028ab24b71710526e9da9841f70"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-77866.html"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-77866"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/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-9FF9-572C-7RG8
Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31Not failing securely ('failing open') in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.
{
"affected": [],
"aliases": [
"CVE-2026-69306"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T17:19:07Z",
"severity": "HIGH"
},
"details": "Not failing securely (\u0027failing open\u0027) in Visual Studio Code allows an unauthorized attacker to bypass a security feature over a network.",
"id": "GHSA-9ff9-572c-7rg8",
"modified": "2026-08-11T18:31:46Z",
"published": "2026-08-11T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69306"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69306"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9R64-6J93-9769
Vulnerability from github – Published: 2026-09-05 12:31 – Updated: 2026-09-05 12:31APITable through 1.13.0-beta.1 contains an incorrect authorization vulnerability in NodePermissionGuard that fails to enforce node-level access control when permission lookups throw exceptions. Attackers with valid Fusion API tokens can write attachments to private datasheets they have been explicitly denied access to by exploiting the unhandled exception in the permission guard.
{
"affected": [],
"aliases": [
"CVE-2026-86120"
],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-05T10:16:43Z",
"severity": "MODERATE"
},
"details": "APITable through 1.13.0-beta.1 contains an incorrect authorization vulnerability in NodePermissionGuard that fails to enforce node-level access control when permission lookups throw exceptions. Attackers with valid Fusion API tokens can write attachments to private datasheets they have been explicitly denied access to by exploiting the unhandled exception in the permission guard.",
"id": "GHSA-9r64-6j93-9769",
"modified": "2026-09-05T12:31:26Z",
"published": "2026-09-05T12:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86120"
},
{
"type": "WEB",
"url": "https://github.com/apitable/apitable/issues/1814"
},
{
"type": "WEB",
"url": "https://github.com/apitable/apitable"
},
{
"type": "WEB",
"url": "https://github.com/apitable/apitable/blob/88b24ce9f359/packages/room-server/src/fusion/middleware/guard/node.permission.guard.ts"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/apitable-through-1.13.0-beta.1-fail-open-authorization-in-the-fusion-api-node-permission-guard"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-CHQM-WXM2-W73W
Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-08-28 15:53Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-gp79-m99v-gjmh. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.5.6 contains an improper access control vulnerability in Mattermost event handlers that fails to validate channel type metadata. Attackers can bypass intended DM policy decisions by sending crafted Mattermost events missing channel type information to process restricted content.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T15:53:21Z",
"nvd_published_at": "2026-06-12T22:16:55Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-gp79-m99v-gjmh. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.5.6 contains an improper access control vulnerability in Mattermost event handlers that fails to validate channel type metadata. Attackers can bypass intended DM policy decisions by sending crafted Mattermost events missing channel type information to process restricted content.",
"id": "GHSA-chqm-wxm2-w73w",
"modified": "2026-08-28T15:53:21Z",
"published": "2026-06-13T00:34:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-gp79-m99v-gjmh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53837"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-missing-channel-type-validation-in-mattermost-event-handlers"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: OpenClaw: Mattermost handlers could fall open when channel type was missing",
"withdrawn": "2026-08-28T15:53:21Z"
}
Mitigation
Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.
No CAPEC attack patterns related to this CWE.