Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5678 vulnerabilities reference this CWE, most recent first.

GHSA-64XH-79J6-R5V8

Vulnerability from github – Published: 2026-07-22 22:06 – Updated: 2026-07-22 22:06
VLAI
Summary
n8n: Bypass "Allowed HTTP Request Domains" Credential Restriction in Multiple AI and LLM Nodes
Details

Impact

The credential "Allowed HTTP Request Domains" allowlist was intended to restrict which hosts a credential's secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service.

Only instances where a credential has "Allowed HTTP Request Domains" configured and is shared with non-owner users are affected.

Patches

The issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict workflow creation and editing permissions to fully trusted users only. - Restrict credential sharing to fully trusted users only. - Audit credentials with domain restrictions for unexpected sharing relationships.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.32.0"
            },
            {
              "fixed": "2.32.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:06:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThe credential \"Allowed HTTP Request Domains\" allowlist was intended to restrict which hosts a credential\u0027s secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service.\n\nOnly instances where a credential has \"Allowed HTTP Request Domains\" configured and is shared with non-owner users are affected.\n\n## Patches\nThe issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict workflow creation and editing permissions to fully trusted users only.\n- Restrict credential sharing to fully trusted users only.\n- Audit credentials with domain restrictions for unexpected sharing relationships.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-64xh-79j6-r5v8",
  "modified": "2026-07-22T22:06:06Z",
  "published": "2026-07-22T22:06:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-64xh-79j6-r5v8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/f69dfc6dd2178a14ea1624d2e1d403c2e755042f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.31.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.32.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Bypass \"Allowed HTTP Request Domains\" Credential Restriction in Multiple AI and LLM Nodes"
}

GHSA-652X-M2GR-HPPM

Vulnerability from github – Published: 2025-07-30 16:21 – Updated: 2025-07-30 16:21
VLAI
Summary
OAuth2-Proxy's `--gitlab-group` GitLab Group Authorization config flag stopped working in v7.0.0
Details

The --gitlab-group flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release.

Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in --gitlab-group added to the new X-Forwarded-Groups header to the upstream application.

While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the --gitlab-group config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed.

Impact

This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of --gitlab-group membership restrictions.

Patches

This is patched in v7.1.0

Workarounds

There is no workaround for the Group membership bug. But --gitlab-project can be set to use Project membership as the authorization checks instead of groups; it is not broken.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oauth2-proxy/oauth2-proxy/v7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21411"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-30T16:21:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release.\n\nRegardless of the flag settings, authorization wasn\u0027t restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application.\n\nWhile adding GitLab project based authorization support in #630, a bug was introduced where the user session\u0027s groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user\u0027s group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed.\n\n### Impact\nThis impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of `--gitlab-group` membership restrictions.\n\n### Patches\nThis is patched in v7.1.0\n\n### Workarounds\nThere is no workaround for the Group membership bug. But `--gitlab-project` can be set to use Project membership as the authorization checks instead of groups; it is not broken.",
  "id": "GHSA-652x-m2gr-hppm",
  "modified": "2025-07-30T16:21:04Z",
  "published": "2025-07-30T16:21:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-652x-m2gr-hppm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21411"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/commit/0279fa7dff1752f1710707dbd1ffac839de8bbfc"
    },
    {
      "type": "WEB",
      "url": "https://docs.gitlab.com/ee/user/group"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v7.1.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/github.com/oauth2-proxy/oauth2-proxy/v7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OAuth2-Proxy\u0027s `--gitlab-group` GitLab Group Authorization config flag stopped working in v7.0.0"
}

GHSA-656H-6G23-9XP5

Vulnerability from github – Published: 2025-12-10 06:30 – Updated: 2025-12-10 18:30
VLAI
Details

Unprotected service in the AudioLink component allows a local attacker to overwrite system files via unauthorized service invocation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-10T04:15:58Z",
    "severity": "MODERATE"
  },
  "details": "Unprotected service in the AudioLink component allows a local attacker to overwrite system files via unauthorized service invocation.",
  "id": "GHSA-656h-6g23-9xp5",
  "modified": "2025-12-10T18:30:25Z",
  "published": "2025-12-10T06:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9056"
    },
    {
      "type": "WEB",
      "url": "https://security.tecno.com/SRC/securityUpdates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-656Q-C3HC-863W

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable improper authorization vulnerability exists in miner_setEtherbase API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-19T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable improper authorization vulnerability exists in miner_setEtherbase API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass.",
  "id": "GHSA-656q-c3hc-863w",
  "modified": "2022-05-13T01:01:38Z",
  "published": "2022-05-13T01:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12115"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0467"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6574-P8RP-GXQH

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46
VLAI
Details

Red Hat 3scale (aka RH-3scale) API Management Platform (AMP) before 2.0.0 would permit creation of an access token without a client secret. An attacker could use this flaw to circumvent authentication controls and gain access to restricted APIs. NOTE: some sources have a typo in which CVE-2017-7512 maps to an OpenVPN vulnerability. The proper CVE ID for that OpenVPN vulnerability is CVE-2017-7521. Specifically, CVE-2017-7521 is the correct CVE ID for TWO closely related findings in OpenVPN. Any source that lists BOTH CVE-2017-7512 and CVE-2017-7521 for OpenVPN should have listed ONLY CVE-2017-7521.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-7512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-07T22:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Red Hat 3scale (aka RH-3scale) API Management Platform (AMP) before 2.0.0 would permit creation of an access token without a client secret. An attacker could use this flaw to circumvent authentication controls and gain access to restricted APIs. NOTE: some sources have a typo in which CVE-2017-7512 maps to an OpenVPN vulnerability. The proper CVE ID for that OpenVPN vulnerability is CVE-2017-7521. Specifically, CVE-2017-7521 is the correct CVE ID for TWO closely related findings in OpenVPN. Any source that lists BOTH CVE-2017-7512 and CVE-2017-7521 for OpenVPN should have listed ONLY CVE-2017-7521.",
  "id": "GHSA-6574-p8rp-gxqh",
  "modified": "2022-05-13T01:46:59Z",
  "published": "2022-05-13T01:46:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7512"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:1712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2017-7512"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1457997"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6578-HF9H-23C9

Vulnerability from github – Published: 2023-07-13 00:30 – Updated: 2024-04-04 06:05
VLAI
Details

In getCurrentState of OneTimePermissionUserManager.java, there is a possible way to hold one-time permissions after the app is being killed due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-21254"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T00:15:24Z",
    "severity": "HIGH"
  },
  "details": "In getCurrentState of OneTimePermissionUserManager.java, there is a possible way to hold one-time permissions after the app is being killed due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.\n\n",
  "id": "GHSA-6578-hf9h-23c9",
  "modified": "2024-04-04T06:05:31Z",
  "published": "2023-07-13T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21254"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/fa539c85503dc63bfb53c76b6f12b3549f14a709"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-07-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-659R-JW2P-4VQJ

Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35
VLAI
Details

A vulnerability in the role-based access control (RBAC) functionality of Cisco Prime Infrastructure could allow an authenticated, remote attacker to perform a privilege escalation in which one virtual domain user can view and modify another virtual domain configuration. The vulnerability is due to a failure to properly enforce RBAC for virtual domains. An attacker could exploit this vulnerability by sending an authenticated, crafted HTTP request to a targeted application. An exploit could allow the attacker to bypass RBAC policies on the targeted system to modify a virtual domain and access resources that are not normally accessible. Cisco Bug IDs: CSCvg36875.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-0096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-18T06:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the role-based access control (RBAC) functionality of Cisco Prime Infrastructure could allow an authenticated, remote attacker to perform a privilege escalation in which one virtual domain user can view and modify another virtual domain configuration. The vulnerability is due to a failure to properly enforce RBAC for virtual domains. An attacker could exploit this vulnerability by sending an authenticated, crafted HTTP request to a targeted application. An exploit could allow the attacker to bypass RBAC policies on the targeted system to modify a virtual domain and access resources that are not normally accessible. Cisco Bug IDs: CSCvg36875.",
  "id": "GHSA-659r-jw2p-4vqj",
  "modified": "2022-05-13T01:35:50Z",
  "published": "2022-05-13T01:35:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0096"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180117-cpi"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102727"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040242"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-65F3-3278-7M65

Vulnerability from github – Published: 2022-03-12 00:00 – Updated: 2023-06-30 22:10
VLAI
Summary
Duplicate Advisory: Improper Authorization in Gogs
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-gw5h-h6hj-f56g. This link is maintained to preserve external references.

Original Description

Impact

Expired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected.

Patches

Expired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev.

Workarounds

In addition to marking PAM accounts as expired, also disable/lock them. Running usermod -L <username> will add an exclamation mark to the password hash and would result in wrong passwords responses when trying to login.

References

https://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62/

For more information

If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6810.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-14T22:58:34Z",
    "nvd_published_at": "2022-03-11T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-gw5h-h6hj-f56g. This link is maintained to preserve external references.\n\n## Original Description\n### Impact\n\nExpired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected.\n\n### Patches\n\nExpired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev.\n\n### Workarounds\n\nIn addition to marking PAM accounts as expired, also disable/lock them. Running `usermod -L \u003cusername\u003e` will add an exclamation mark to the password hash and would result in wrong passwords responses when trying to login. \n\n### References\n\nhttps://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62/\n\n### For more information\n\nIf you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6810.\n",
  "id": "GHSA-65f3-3278-7m65",
  "modified": "2023-06-30T22:10:59Z",
  "published": "2022-03-12T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0871"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/64102be2c90e1b47dbdd379873ba76c80d4b0e78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Improper Authorization in Gogs",
  "withdrawn": "2023-06-30T22:10:59Z"
}

GHSA-65GC-65C8-RC75

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable improper authorization vulnerability exists in admin_peers API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-12114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-19T22:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An exploitable improper authorization vulnerability exists in admin_peers API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.",
  "id": "GHSA-65gc-65c8-rc75",
  "modified": "2022-05-13T01:01:38Z",
  "published": "2022-05-13T01:01:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12114"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0466"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-65H8-27JH-Q8WV

Vulnerability from github – Published: 2026-03-26 19:08 – Updated: 2026-04-10 20:19
VLAI
Summary
OpenClaw: Nostr inbound DMs could trigger unauthenticated crypto work before sender policy enforcement
Details

Summary

Nostr inbound DM handling could perform crypto and dispatch work before sender and pairing policy enforcement, enabling unauthorized pre-auth computation.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: < 2026.3.22
  • Fixed: >= 2026.3.22
  • Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87)
  • Latest published npm version checked: 2026.3.23-2

Fix Commit(s)

  • 1ee9611079e81b9122f4bed01abb3d9f56206c77

Release Status

The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

Code-Level Confirmation

  • extensions/nostr/src/channel.ts now performs authorization before decrypting and dispatching inbound DM content.
  • extensions/nostr/src/nostr-bus.ts adds pre-crypto authorization, size, and rate guardrails before expensive decrypt work.

OpenClaw thanks @kuranikaran for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35627"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T19:08:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nNostr inbound DM handling could perform crypto and dispatch work before sender and pairing policy enforcement, enabling unauthorized pre-auth computation.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `1ee9611079e81b9122f4bed01abb3d9f56206c77`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- extensions/nostr/src/channel.ts now performs authorization before decrypting and dispatching inbound DM content.\n- extensions/nostr/src/nostr-bus.ts adds pre-crypto authorization, size, and rate guardrails before expensive decrypt work.\n\nOpenClaw thanks @kuranikaran for reporting.",
  "id": "GHSA-65h8-27jh-q8wv",
  "modified": "2026-04-10T20:19:14Z",
  "published": "2026-03-26T19:08:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-65h8-27jh-q8wv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35627"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1ee9611079e81b9122f4bed01abb3d9f56206c77"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-unauthenticated-cryptographic-work-in-nostr-inbound-dm-handling"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Nostr inbound DMs could trigger unauthenticated crypto work before sender policy enforcement"
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.