GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6521 vulnerabilities reference this CWE, most recent first.

GHSA-29MV-GCCW-23PV

Vulnerability from github – Published: 2022-05-14 03:44 – Updated: 2025-04-20 03:46
VLAI
Details

The doFilter method in UrlAccessController in HPE Intelligent Management Center (iMC) PLAT 7.2 E0403P06 allows remote bypass of authentication via unspecified strings in a URI.

Severity
9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-5791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-11T21:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "The doFilter method in UrlAccessController in HPE Intelligent Management Center (iMC) PLAT 7.2 E0403P06 allows remote bypass of authentication via unspecified strings in a URI.",
  "id": "GHSA-29mv-gccw-23pv",
  "modified": "2025-04-20T03:46:38Z",
  "published": "2022-05-14T03:44:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5791"
    },
    {
      "type": "WEB",
      "url": "https://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03716en_us"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101224"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96815"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037983"
    },
    {
      "type": "WEB",
      "url": "http://www.zerodayinitiative.com/advisories/ZDI-17-161"
    }
  ],
  "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-29RF-F4VV-PVQ6

Vulnerability from github – Published: 2026-08-14 15:36 – Updated: 2026-08-14 15:36
VLAI
Summary
Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts
Details

The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).

Root Cause

In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:

Line 125: The existing user is looked up by email:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))

Line 164: The OAuth user object is replaced with the existing user:

user = existingUser

Lines 173-176: The OAuth provider is appended to the existing user's signup methods:

signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
    signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod

Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:

if user.EmailVerifiedAt == nil {
    now := time.Now().Unix()
    user.EmailVerifiedAt = &now
}

Line 219: The merged user is saved to the database:

user, err = h.StorageProvider.UpdateUser(ctx, user)

At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.

Attack Chain

  1. Attacker signs up with victim@company.com using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with EmailVerifiedAt = nil.

  2. Some time later, the real owner of victim@company.com logs in via Google OAuth (a completely normal action).

  3. The OAuth callback at line 125 finds the attacker's existing account by email.

  4. At line 164, the Google OAuth identity is linked to the attacker's account.

  5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).

  6. At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.

  7. The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.

  8. The attacker logs in with victim@company.com and the password they originally set. They now have full access to the victim's account, including any data the victim added via their Google session.

Why This Is Zero-Click

The victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.

This is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim's account, even if the victim later revokes Authorizer's OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.

Impact

  • Full account takeover for any user who logs in via OAuth
  • Attacker maintains persistent password-based access even after the victim changes OAuth providers
  • All data the victim creates after OAuth login is accessible to the attacker
  • The victim has no indication their account was pre-staged
  • Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)

Suggested Fix

Before linking an OAuth identity to an existing account, verify that the existing account's email is already verified:

existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))
if err == nil {
    // Account exists. Only link if email is already verified.
    if existingUser.EmailVerifiedAt == nil {
        // Email not verified by original owner. Do NOT link.
        // Either: reject the login, or create a new separate account,
        // or delete the unverified account and create a fresh one for the OAuth user.
    }
}

Additionally, when linking a new OAuth identity, invalidate any existing password on the account or require the user to re-authenticate via the original method.

Credit

Koda Reef

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/authorizerdev/authorizer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260807033110-66fe488fd2a4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-14T15:36:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account\u0027s email was verified by its original owner. An attacker who pre-registers with a victim\u0027s email address (without verifying it) gains persistent password-based access to the victim\u0027s account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).\n\n## Root Cause\n\nIn `internal/http_handlers/oauth_callback.go`, when an OAuth login occurs for an email that already exists in the database:\n\nLine 125: The existing user is looked up by email:\n\n    existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))\n\nLine 164: The OAuth user object is replaced with the existing user:\n\n    user = existingUser\n\nLines 173-176: The OAuth provider is appended to the existing user\u0027s signup methods:\n\n    signupMethod := existingUser.SignupMethods\n    if !strings.Contains(signupMethod, provider) {\n        signupMethod = signupMethod + \",\" + provider\n    }\n    user.SignupMethods = signupMethod\n\nLines 179-181: If the existing account\u0027s email was NOT verified, it is automatically verified:\n\n    if user.EmailVerifiedAt == nil {\n        now := time.Now().Unix()\n        user.EmailVerifiedAt = \u0026now\n    }\n\nLine 219: The merged user is saved to the database:\n\n    user, err = h.StorageProvider.UpdateUser(ctx, user)\n\nAt no point is the existing account\u0027s password invalidated or the owner notified that a new OAuth identity was linked.\n\n## Attack Chain\n\n1. Attacker signs up with `victim@company.com` using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with `EmailVerifiedAt = nil`.\n\n2. Some time later, the real owner of `victim@company.com` logs in via Google OAuth (a completely normal action).\n\n3. The OAuth callback at line 125 finds the attacker\u0027s existing account by email.\n\n4. At line 164, the Google OAuth identity is linked to the attacker\u0027s account.\n\n5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it\u0027s marked as verified).\n\n6. At line 175, \"google\" is appended to the signup methods. The account now has both \"basic_auth\" and \"google\" as valid login methods.\n\n7. The attacker\u0027s original password is still valid in the database. It was never cleared, changed, or invalidated.\n\n8. The attacker logs in with `victim@company.com` and the password they originally set. They now have full access to the victim\u0027s account, including any data the victim added via their Google session.\n\n## Why This Is Zero-Click\n\nThe victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.\n\nThis is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim\u0027s account, even if the victim later revokes Authorizer\u0027s OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.\n\n## Impact\n\n- Full account takeover for any user who logs in via OAuth\n- Attacker maintains persistent password-based access even after the victim changes OAuth providers\n- All data the victim creates after OAuth login is accessible to the attacker\n- The victim has no indication their account was pre-staged\n- Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)\n\n## Suggested Fix\n\nBefore linking an OAuth identity to an existing account, verify that the existing account\u0027s email is already verified:\n\n    existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))\n    if err == nil {\n        // Account exists. Only link if email is already verified.\n        if existingUser.EmailVerifiedAt == nil {\n            // Email not verified by original owner. Do NOT link.\n            // Either: reject the login, or create a new separate account,\n            // or delete the unverified account and create a fresh one for the OAuth user.\n        }\n    }\n\nAdditionally, when linking a new OAuth identity, invalidate any existing password on the account or require the user to re-authenticate via the original method.\n\n## Credit\nKoda Reef",
  "id": "GHSA-29rf-f4vv-pvq6",
  "modified": "2026-08-14T15:36:15Z",
  "published": "2026-08-14T15:36:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authorizerdev/authorizer/security/advisories/GHSA-29rf-f4vv-pvq6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authorizerdev/authorizer/commit/66fe488fd2a4e7acf1e517334344d5e8f3ddd296"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authorizerdev/authorizer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authorizerdev/authorizer/releases/tag/2.4.0-rc.16"
    }
  ],
  "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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts"
}

GHSA-29VJ-QPHH-JWR9

Vulnerability from github – Published: 2022-05-02 03:54 – Updated: 2022-05-02 03:54
VLAI
Details

Jax Guestbook 3.5.0 allows remote attackers to bypass authentication and modify administrator settings via a direct request to admin/guestbook.admin.php.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-4447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-12-29T20:41:00Z",
    "severity": "HIGH"
  },
  "details": "Jax Guestbook 3.5.0 allows remote attackers to bypass authentication and modify administrator settings via a direct request to admin/guestbook.admin.php.",
  "id": "GHSA-29vj-qphh-jwr9",
  "modified": "2022-05-02T03:54:51Z",
  "published": "2022-05-02T03:54:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4447"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/55077"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/61299"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/37921"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/10626"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/37466"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2C3W-HJXH-5RQG

Vulnerability from github – Published: 2022-05-04 00:27 – Updated: 2022-05-04 00:27
VLAI
Details

Red Hat JBoss Operations Network (JON) before 2.4.2 and 3.0.x before 3.0.1 allows remote attackers to hijack agent sessions via an agent registration request without a security token.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-0062"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-02-14T15:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Red Hat JBoss Operations Network (JON) before 2.4.2 and 3.0.x before 3.0.1 allows remote attackers to hijack agent sessions via an agent registration request without a security token.",
  "id": "GHSA-2c3w-hjxh-5rqg",
  "modified": "2022-05-04T00:27:49Z",
  "published": "2022-05-04T00:27:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0062"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=783008"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0089.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2012-0406.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2C4W-43W5-H44Q

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

Ingate Firewall and SIParator before 4.5.2 allow remote attackers to bypass SIP authentication via a certain maddr parameter.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-3177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-06-11T22:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Ingate Firewall and SIParator before 4.5.2 allow remote attackers to bypass SIP authentication via a certain maddr parameter.",
  "id": "GHSA-2c4w-43w5-h44q",
  "modified": "2022-05-01T18:11:05Z",
  "published": "2022-05-01T18:11:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-3177"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/34887"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/36708"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/25420"
    },
    {
      "type": "WEB",
      "url": "http://www.ingate.com/relnote-452.php"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/1973"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2C69-R2JH-XJVM

Vulnerability from github – Published: 2023-04-20 18:30 – Updated: 2026-04-20 21:31
VLAI
Details

This vulnerability allows remote attackers to bypass authentication on affected installations of PaperCut NG PaperCut NG 22.0.5 (Build 63914). Authentication is not required to exploit this vulnerability. The specific flaw exists within the SecurityRequestFilter class. The issue results from improper implementation of the authentication algorithm. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19226.

Severity
8.2 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-27351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-20T16:15:07Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows remote attackers to bypass authentication on affected installations of PaperCut NG PaperCut NG 22.0.5 (Build 63914). Authentication is not required to exploit this vulnerability. The specific flaw exists within the SecurityRequestFilter class. The issue results from improper implementation of the authentication algorithm. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19226.",
  "id": "GHSA-2c69-r2jh-xjvm",
  "modified": "2026-04-20T21:31:37Z",
  "published": "2023-04-20T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27351"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-27351"
    },
    {
      "type": "WEB",
      "url": "https://www.papercut.com/kb/Main/PO-1216-and-PO-1219"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-232"
    }
  ],
  "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"
    }
  ]
}

GHSA-2C8C-2RMR-9RRP

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-07-23 00:00
VLAI
Details

A local authentication bypass vulnerability was discovered in some Aruba Instant Access Point (IAP) products in version(s): Aruba Instant 6.4.x: 6.4.4.8-4.2.4.18 and below; Aruba Instant 6.5.x: 6.5.4.15 and below; Aruba Instant 8.3.x: 8.3.0.11 and below; Aruba Instant 8.4.x: 8.4.0.5 and below; Aruba Instant 8.5.x: 8.5.0.6 and below; Aruba Instant 8.6.x: 8.6.0.2 and below. Aruba has released patches for Aruba Instant that address this security vulnerability.

Severity
6.8 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-5317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-29T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A local authentication bypass vulnerability was discovered in some Aruba Instant Access Point (IAP) products in version(s): Aruba Instant 6.4.x: 6.4.4.8-4.2.4.18 and below; Aruba Instant 6.5.x: 6.5.4.15 and below; Aruba Instant 8.3.x: 8.3.0.11 and below; Aruba Instant 8.4.x: 8.4.0.5 and below; Aruba Instant 8.5.x: 8.5.0.6 and below; Aruba Instant 8.6.x: 8.6.0.2 and below. Aruba has released patches for Aruba Instant that address this security vulnerability.",
  "id": "GHSA-2c8c-2rmr-9rrp",
  "modified": "2022-07-23T00:00:23Z",
  "published": "2022-05-24T17:45:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5317"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-723417.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-007.txt"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2C9Q-C2Q9-QGQV

Vulnerability from github – Published: 2026-08-19 18:55 – Updated: 2026-08-19 18:55
VLAI
Summary
langgraph-api: Relative webhook targets in LangGraph Server can reach in-process routes without authentication
Details

Summary

In affected versions of langgraph-api (the LangGraph Server runtime), a run or cron could be created with a relative webhook target. When the server later delivers such a webhook, it routes the request back into the same application through an in-process loopback transport that the authentication middleware treats as internal and does not authenticate. As a result, a relative webhook target could reach the server's own routes that operate on threads and runs without the authentication context that applies to ordinary external requests.

In deployments that scope threads and runs by owner, this could allow a request associated with one user to reach routes operating on another user's thread, resulting in creation of a run on (or modification of the state of) a thread owned by another user, even where the corresponding direct external requests were correctly denied. Limited metadata from the targeted thread may be incorporated into the created run record.

We have no evidence of this behavior occurring in the wild.

Affected users / systems

You may be affected if you:

  • run langgraph-api (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart),
  • allow runs or crons to specify webhook targets, and
  • rely on per-user authorization to separate threads and runs between users.

Impact

  • Integrity: creation of a run on, or modification of the state of, a thread owned by another user, beyond the requesting user's authorization scope.
  • Confidentiality: limited exposure of another user's thread metadata, incorporated into the created run record.

Patches / mitigation

The webhook URL policy now denies loopback delivery by default: the webhooks.url.disable_loopback policy defaults to enabled. This covers relative webhook targets routed through the in-process transport, as well as localhost-style hostnames, loopback address ranges, and hostnames that resolve into the loopback range. Deployments that legitimately deliver webhooks to a route hosted on the same process can opt back in by setting webhooks.url.disable_loopback: false in langgraph.json (or the equivalent LANGGRAPH_WEBHOOKS configuration); do so only when you control the routes those webhooks reach, as they are delivered without authentication. Fixed in langgraph-api 0.10.0.

Operational guidance

  • Upgrade to a release containing this change and keep loopback webhook delivery disabled unless required.
  • If loopback delivery is enabled, restrict it to routes you control and apply authorization within those routes.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langgraph-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T18:55:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIn affected versions of `langgraph-api` (the LangGraph Server runtime), a run or cron could be created with a relative webhook target. When the server later delivers such a webhook, it routes the request back into the same application through an in-process loopback transport that the authentication middleware treats as internal and does not authenticate. As a result, a relative webhook target could reach the server\u0027s own routes that operate on threads and runs without the authentication context that applies to ordinary external requests.\n\nIn deployments that scope threads and runs by owner, this could allow a request associated with one user to reach routes operating on another user\u0027s thread, resulting in creation of a run on (or modification of the state of) a thread owned by another user, even where the corresponding direct external requests were correctly denied. Limited metadata from the targeted thread may be incorporated into the created run record.\n\nWe have no evidence of this behavior occurring in the wild.\n\n## Affected users / systems\n\nYou may be affected if you:\n\n- run `langgraph-api` (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart),\n- allow runs or crons to specify webhook targets, and\n- rely on per-user authorization to separate threads and runs between users.\n\n## Impact\n\n- Integrity: creation of a run on, or modification of the state of, a thread owned by another user, beyond the requesting user\u0027s authorization scope.\n- Confidentiality: limited exposure of another user\u0027s thread metadata, incorporated into the created run record.\n\n## Patches / mitigation\n\nThe webhook URL policy now denies loopback delivery by default: the `webhooks.url.disable_loopback` policy defaults to enabled. This covers relative webhook targets routed through the in-process transport, as well as localhost-style hostnames, loopback address ranges, and hostnames that resolve into the loopback range. Deployments that legitimately deliver webhooks to a route hosted on the same process can opt back in by setting `webhooks.url.disable_loopback: false` in `langgraph.json` (or the equivalent `LANGGRAPH_WEBHOOKS` configuration); do so only when you control the routes those webhooks reach, as they are delivered without authentication. Fixed in `langgraph-api` 0.10.0.\n\n## Operational guidance\n\n- Upgrade to a release containing this change and keep loopback webhook delivery disabled unless required.\n- If loopback delivery is enabled, restrict it to routes you control and apply authorization within those routes.",
  "id": "GHSA-2c9q-c2q9-qgqv",
  "modified": "2026-08-19T18:55:57Z",
  "published": "2026-08-19T18:55:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/helm/security/advisories/GHSA-2c9q-c2q9-qgqv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langchain-ai/helm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "langgraph-api: Relative webhook targets in LangGraph Server can reach in-process routes without authentication"
}

GHSA-2CGW-C87G-WW8Q

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-10-27 19:00
VLAI
Details

OpenVPN 3 Core Library version 3.6 and 3.6.1 allows a man-in-the-middle attacker to bypass the certificate authentication by issuing an unrelated server certificate using the same hostname found in the verify-x509-name option in a client configuration.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3547"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-12T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "OpenVPN 3 Core Library version 3.6 and 3.6.1 allows a man-in-the-middle attacker to bypass the certificate authentication by issuing an unrelated server certificate using the same hostname found in the verify-x509-name option in a client configuration.",
  "id": "GHSA-2cgw-c87g-ww8q",
  "modified": "2022-10-27T19:00:41Z",
  "published": "2022-05-24T19:07:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3547"
    },
    {
      "type": "WEB",
      "url": "https://community.openvpn.net/openvpn/wiki/CVE-2021-3547"
    },
    {
      "type": "WEB",
      "url": "https://community.openvpn.net/openvpn/wiki/SecurityAnnouncements"
    }
  ],
  "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"
    }
  ]
}

GHSA-2CH2-JW27-C5R3

Vulnerability from github – Published: 2023-10-30 18:30 – Updated: 2023-11-06 18:30
VLAI
Details

In Bluetooth, there is a possible way for a paired Bluetooth device to access a long term identifier for an Android device due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.

Severity
5.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-21307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-30T17:15:48Z",
    "severity": "MODERATE"
  },
  "details": "In Bluetooth, there is a possible way for a paired Bluetooth device to access a long term identifier for an Android device due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.",
  "id": "GHSA-2ch2-jw27-c5r3",
  "modified": "2023-11-06T18:30:17Z",
  "published": "2023-10-30T18:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21307"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/android-14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list