Common Weakness Enumeration

CWE-303

Allowed

Incorrect Implementation of Authentication Algorithm

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.

190 vulnerabilities reference this CWE, most recent first.

GHSA-WCM6-243C-86F3

Vulnerability from github – Published: 2026-02-04 00:30 – Updated: 2026-07-10 15:31
VLAI
Details

EspoCRM 5.8.5 contains an authentication vulnerability that allows attackers to access other user accounts by manipulating authorization headers. Attackers can decode and modify Basic Authorization and Espo-Authorization tokens to gain unauthorized access to administrative user information and privileges.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-37094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-03T22:16:25Z",
    "severity": "HIGH"
  },
  "details": "EspoCRM 5.8.5 contains an authentication vulnerability that allows attackers to access other user accounts by manipulating authorization headers. Attackers can decode and modify Basic Authorization and Espo-Authorization tokens to gain unauthorized access to administrative user information and privileges.",
  "id": "GHSA-wcm6-243c-86f3",
  "modified": "2026-07-10T15:31:34Z",
  "published": "2026-02-04T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37094"
    },
    {
      "type": "WEB",
      "url": "https://github.com/espocrm/espocrm/commit/b299220dd0c7acdaa1ed8be8ffd79c7985093c7a"
    },
    {
      "type": "WEB",
      "url": "https://www.espocrm.com"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/48376"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/espocrm-privilege-escalation"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/espocrm-two-factor-auth-bypass-via-auth-token-reuse-between-accounts-with-identical-passwords"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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-WHX2-QJXV-4VR9

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

D-Link DIR-2150 HNAP Incorrect Implementation of Authentication Algorithm Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2150 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the SOAP API interface, which listens on TCP port 80 by default. A crafted authentication header can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-20910.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-34282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:27Z",
    "severity": "HIGH"
  },
  "details": "D-Link DIR-2150 HNAP Incorrect Implementation of Authentication Algorithm Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2150 routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the SOAP API interface, which listens on TCP port 80 by default. A crafted authentication header can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-20910.",
  "id": "GHSA-whx2-qjxv-4vr9",
  "modified": "2024-05-03T03:30:51Z",
  "published": "2024-05-03T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34282"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-628"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WMPM-9R6P-RPWW

Vulnerability from github – Published: 2024-01-24 21:30 – Updated: 2025-06-20 21:31
VLAI
Details

An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. DTLS servers allow remote attackers to reuse the same epoch number within two times the TCP maximum segment lifetime, which is prohibited in RFC6347. This vulnerability allows remote attackers to obtain sensitive application (data of connected clients).

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-42146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-24T19:15:08Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. DTLS servers allow remote attackers to reuse the same epoch number within two times the TCP maximum segment lifetime, which is prohibited in RFC6347. This vulnerability allows remote attackers to obtain sensitive application (data of connected clients).",
  "id": "GHSA-wmpm-9r6p-rpww",
  "modified": "2025-06-20T21:31:54Z",
  "published": "2024-01-24T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42146"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2024/Jan/19"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jan/19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WRHW-J3F9-8VC6

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36
VLAI
Summary
[mcp-atlassian] Authentication bypass in HTTP transport: AtlassianOpaqueTokenVerifier accepts any non-empty token
Details

Description

mcp-atlassian deploys in two common patterns:

Pattern A (single-user, server-side credentials): operator sets JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN) in environment variables. Server uses these to call Jira/Confluence. This is the documented quickstart pattern.

Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth proxy or accepts per-user tokens via Authorization or service headers.

The authentication mechanism in HTTP transport has two issues that combine to permit unauthenticated access to Pattern A deployments:

  1. AtlassianOpaqueTokenVerifier.verify_token() at src/mcp_atlassian/utils/token_verifier.py accepts any non-empty string as a valid token:

    async def verify_token(self, token: str) -> AccessToken | None: if not token: return None scopes = self.required_scopes or [] return AccessToken( token=token, client_id="atlassian", scopes=scopes, expires_at=int(time.time()) + 86400 * 30, )

The docstring documents this: "we accept non-empty tokens and attach the required scopes."

  1. The default deployment does NOT enable the OAuth proxy auth provider (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When _build_auth_provider() returns None, FastMCP HTTP transport accepts requests with no authentication challenge.

  2. UserTokenMiddleware._parse_auth_header (main.py:601-664) extracts tokens from Authorization headers and stores them in scope state. If NO Authorization header is present (main.py:584-595), the middleware does not reject the request — it simply does not populate user_atlassian_token.

  3. JiraFetcher / ConfluenceFetcher fall back to JiraConfig.from_env() when no user-supplied token is in scope state. from_env() reads JIRA_API_TOKEN and JIRA_USERNAME from environment and uses them as the API credentials.

Composition: an attacker who reaches the HTTP transport (e.g., server exposed on a port reachable from attacker — direct bind, Docker port mapping, reverse proxy without auth, container in a network the attacker joined) can:

  • Send no Authorization header at all, OR
  • Send any garbage Bearer token

Either request reaches tool handlers. The tool handlers, finding no user-supplied token, use the server's env-var credentials to call Jira / Confluence. The attacker has full operator-level access to the operator's Atlassian instance.

This is the same vulnerability class as CVE-2026-27825 (Arctic Wolf, unauthenticated RCE+SSRF in Atlassian MCP). The previous CVE was for a different code path; this report concerns the auth verifier and middleware behavior present in the current main branch. ``` Steps to Reproduce

Source-level demonstration:

  1. Verify the verifier accepts arbitrary tokens:

    cd src/ python -c " import asyncio from mcp_atlassian.utils.token_verifier import AtlassianOpaqueTokenVerifier v = AtlassianOpaqueTokenVerifier(required_scopes=['read:jira-work']) result = asyncio.run(v.verify_token('anything-at-all')) print('Accepted:', result is not None) print('Token stored:', result.token if result else None) print('Scopes granted:', result.scopes if result else None) "

Expected: Accepted: True Token stored: anything-at-all Scopes granted: ['read:jira-work']

End-to-end (researcher's own Atlassian sandbox):

  1. Start mcp-atlassian in HTTP mode against a researcher-owned Atlassian Cloud instance with JIRA_API_TOKEN configured:

    export JIRA_URL=https://researcher.atlassian.net export JIRA_USERNAME=researcher@example.com export JIRA_API_TOKEN= export MCP_TRANSPORT=streamable-http export PORT=3000 # Do NOT set OAUTH_PROXY_ENABLE_ENV — leave it default (false) mcp-atlassian

  2. From another machine (or curl on localhost), with no auth:

    curl -X POST http://localhost:3000/mcp \ -H "content-type: application/json" \ -H "accept: application/json, text/event-stream" \ -d '{ "jsonrpc":"2.0", "id":1, "method":"tools/call", "params":{ "name":"jira_get_issue", "arguments":{"issue_key":"PROJ-1"} } }'

Expected: returns the Jira issue payload — using the server's JIRA_API_TOKEN to authenticate to Atlassian. No client-side token provided.

  1. Optional: same call with a garbage Bearer for completeness:

    curl ... -H "Authorization: Bearer anything-at-all" ...

Same result.

Impact:

Attacker profile: any party with network reach to the HTTP transport. No credentials, no prior account, no privileged position required.

Typical deployment patterns at risk:

  • Docker compose with port exposed (very common in mcp-atlassian's docs and community deployments)
  • Cloud-deployed MCP server behind a load balancer where the LB doesn't enforce auth (delegates to the application)
  • Internal corporate network where any employee can reach the server
  • Misconfigured Kubernetes ingress
  • Tunneled MCP server via ngrok / Cloudflare Tunnel for development that gets left exposed

Security impact after exploitation:

  1. Full Jira read access. Every project, every issue, every comment, every attachment, every user — using the operator's API token.

  2. Full Jira write access. Create, edit, delete issues. Add comments under the operator's identity. Move issues across boards. Bulk-edit.

  3. Full Confluence read/write access. Same surface — pages, spaces, attachments, permissions, restricted spaces visible to the operator's identity.

  4. Audit trail names the operator. Every API call is signed with the operator's token. From Atlassian's logging side, the operator is the actor — covering the attacker's tracks and shifting blame.

  5. Pivot. Attachments often contain credentials, infrastructure diagrams, customer data. Confluence pages often store secrets in plaintext under the assumption of access control.

  6. Persistence. Attacker can create new Jira webhooks, automation rules, or Confluence integrations that survive beyond the MCP session.

CVE-2026-27825 (Arctic Wolf, May 2026) was scored CVSS 9.8 Critical for unauth RCE+SSRF in this same code surface. This report is the auth-bypass component of the same class against the current main branch.

Suggested Fix

The most direct fix is the standard MCP-server-with-env-creds pattern:

  1. When OAUTH_PROXY_ENABLE_ENV is not set, REFUSE to start the HTTP transport unless an explicit "single-user mode" flag is set:

    SINGLE_USER_MODE = is_env_truthy("MCP_ATLASSIAN_SINGLE_USER") if MCP_TRANSPORT == "streamable-http" and not auth_provider and not SINGLE_USER_MODE: raise SystemExit( "HTTP transport requires either OAUTH_PROXY_ENABLE=true " "or MCP_ATLASSIAN_SINGLE_USER=true (acknowledges that env " "credentials will be used for any incoming request)." )

  2. Even with SINGLE_USER_MODE, bind the HTTP transport to 127.0.0.1 by default unless the operator overrides with an explicit MCP_ATLASSIAN_BIND_PUBLIC=true.

  3. Document the multi-tenant pattern as requiring OAuth proxy or per-request user-token middleware with a verifier that actually verifies (not the opaque-accept-anything stub).

  4. Replace AtlassianOpaqueTokenVerifier with a verifier that performs a token-info or whoami call to Atlassian. The fact that Atlassian tokens are opaque does not preclude verification — a /rest/api/3/myself call validates the token and returns the associated user, which the verifier can attach to the AccessToken's scopes and user_id fields.

Defense in depth: the README quickstart should not encourage exposing the HTTP transport without auth. The docker-compose.yml in the repo should bind to 127.0.0.1 only by default.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-303",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:26Z",
    "nvd_published_at": "2026-09-22T18:17:17Z",
    "severity": "CRITICAL"
  },
  "details": "**Description**\n\nmcp-atlassian deploys in two common patterns:\n\n  Pattern A (single-user, server-side credentials): operator sets\n    JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN)\n    in environment variables. Server uses these to call Jira/Confluence.\n    This is the documented quickstart pattern.\n\n  Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth\n    proxy or accepts per-user tokens via Authorization or service headers.\n\nThe authentication mechanism in HTTP transport has two issues that combine\nto permit unauthenticated access to Pattern A deployments:\n\n1. AtlassianOpaqueTokenVerifier.verify_token() at\n   `src/mcp_atlassian/utils/token_verifier.py` accepts any non-empty string\n   as a valid token:\n\n       async def verify_token(self, token: str) -\u003e AccessToken | None:\n           if not token:\n               return None\n           scopes = self.required_scopes or []\n           return AccessToken(\n               token=token,\n               client_id=\"atlassian\",\n               scopes=scopes,\n               expires_at=int(time.time()) + 86400 * 30,\n           )\n\n   The docstring documents this: \"we accept non-empty tokens and attach\n   the required scopes.\"\n\n2. The default deployment does NOT enable the OAuth proxy auth provider\n   (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When\n   `_build_auth_provider()` returns None, FastMCP HTTP transport accepts\n   requests with no authentication challenge.\n\n3. `UserTokenMiddleware._parse_auth_header` (main.py:601-664) extracts\n   tokens from Authorization headers and stores them in scope state. If\n   NO Authorization header is present (main.py:584-595), the middleware\n   does not reject the request \u2014 it simply does not populate\n   `user_atlassian_token`.\n\n4. JiraFetcher / ConfluenceFetcher fall back to `JiraConfig.from_env()`\n   when no user-supplied token is in scope state. `from_env()` reads\n   `JIRA_API_TOKEN` and `JIRA_USERNAME` from environment and uses them\n   as the API credentials.\n\nComposition: an attacker who reaches the HTTP transport (e.g., server\nexposed on a port reachable from attacker \u2014 direct bind, Docker port\nmapping, reverse proxy without auth, container in a network the attacker\njoined) can:\n\n  - Send no Authorization header at all, OR\n  - Send any garbage Bearer token\n\nEither request reaches tool handlers. The tool handlers, finding no\nuser-supplied token, use the server\u0027s env-var credentials to call\nJira / Confluence. The attacker has full operator-level access to the\noperator\u0027s Atlassian instance.\n\nThis is the same vulnerability class as CVE-2026-27825 (Arctic Wolf,\nunauthenticated RCE+SSRF in Atlassian MCP). The previous CVE was for a\ndifferent code path; this report concerns the auth verifier and middleware\nbehavior present in the current main branch.\n```\n**Steps to Reproduce**\n\nSource-level demonstration:\n\n1. Verify the verifier accepts arbitrary tokens:\n\n       cd src/\n       python -c \"\n       import asyncio\n       from mcp_atlassian.utils.token_verifier import AtlassianOpaqueTokenVerifier\n       v = AtlassianOpaqueTokenVerifier(required_scopes=[\u0027read:jira-work\u0027])\n       result = asyncio.run(v.verify_token(\u0027anything-at-all\u0027))\n       print(\u0027Accepted:\u0027, result is not None)\n       print(\u0027Token stored:\u0027, result.token if result else None)\n       print(\u0027Scopes granted:\u0027, result.scopes if result else None)\n       \"\n\n   Expected:\n       Accepted: True\n       Token stored: anything-at-all\n       Scopes granted: [\u0027read:jira-work\u0027]\n\nEnd-to-end (researcher\u0027s own Atlassian sandbox):\n\n1. Start mcp-atlassian in HTTP mode against a researcher-owned Atlassian\n   Cloud instance with JIRA_API_TOKEN configured:\n\n       export JIRA_URL=https://researcher.atlassian.net\n       export JIRA_USERNAME=researcher@example.com\n       export JIRA_API_TOKEN=\u003cresearcher\u0027s-real-token\u003e\n       export MCP_TRANSPORT=streamable-http\n       export PORT=3000\n       # Do NOT set OAUTH_PROXY_ENABLE_ENV \u2014 leave it default (false)\n       mcp-atlassian\n\n2. From another machine (or curl on localhost), with no auth:\n\n       curl -X POST http://localhost:3000/mcp \\\n            -H \"content-type: application/json\" \\\n            -H \"accept: application/json, text/event-stream\" \\\n            -d \u0027{\n              \"jsonrpc\":\"2.0\", \"id\":1, \"method\":\"tools/call\",\n              \"params\":{\n                \"name\":\"jira_get_issue\",\n                \"arguments\":{\"issue_key\":\"PROJ-1\"}\n              }\n            }\u0027\n\n   Expected: returns the Jira issue payload \u2014 using the server\u0027s\n   JIRA_API_TOKEN to authenticate to Atlassian. No client-side token\n   provided.\n\n3. Optional: same call with a garbage Bearer for completeness:\n\n       curl ... -H \"Authorization: Bearer anything-at-all\" ...\n\n   Same result.\n   \n   \n   **Impact**:\n   \n   Attacker profile: any party with network reach to the HTTP transport.\nNo credentials, no prior account, no privileged position required.\n\nTypical deployment patterns at risk:\n\n  - Docker compose with port exposed (very common in mcp-atlassian\u0027s\n    docs and community deployments)\n  - Cloud-deployed MCP server behind a load balancer where the LB\n    doesn\u0027t enforce auth (delegates to the application)\n  - Internal corporate network where any employee can reach the server\n  - Misconfigured Kubernetes ingress\n  - Tunneled MCP server via ngrok / Cloudflare Tunnel for development\n    that gets left exposed\n\nSecurity impact after exploitation:\n\n1. Full Jira read access. Every project, every issue, every comment,\n   every attachment, every user \u2014 using the operator\u0027s API token.\n\n2. Full Jira write access. Create, edit, delete issues. Add comments\n   under the operator\u0027s identity. Move issues across boards. Bulk-edit.\n\n3. Full Confluence read/write access. Same surface \u2014 pages, spaces,\n   attachments, permissions, restricted spaces visible to the operator\u0027s\n   identity.\n\n4. Audit trail names the operator. Every API call is signed with the\n   operator\u0027s token. From Atlassian\u0027s logging side, the operator is the\n   actor \u2014 covering the attacker\u0027s tracks and shifting blame.\n\n5. Pivot. Attachments often contain credentials, infrastructure\n   diagrams, customer data. Confluence pages often store secrets in\n   plaintext under the assumption of access control.\n\n6. Persistence. Attacker can create new Jira webhooks, automation rules,\n   or Confluence integrations that survive beyond the MCP session.\n\nCVE-2026-27825 (Arctic Wolf, May 2026) was scored CVSS 9.8 Critical for\nunauth RCE+SSRF in this same code surface. This report is the auth-bypass\ncomponent of the same class against the current main branch.\n\n\n**Suggested Fix**\n\nThe most direct fix is the standard MCP-server-with-env-creds pattern:\n\n  1. When OAUTH_PROXY_ENABLE_ENV is not set, REFUSE to start the HTTP\n     transport unless an explicit \"single-user mode\" flag is set:\n\n       SINGLE_USER_MODE = is_env_truthy(\"MCP_ATLASSIAN_SINGLE_USER\")\n       if MCP_TRANSPORT == \"streamable-http\" and not auth_provider and not SINGLE_USER_MODE:\n           raise SystemExit(\n               \"HTTP transport requires either OAUTH_PROXY_ENABLE=true \"\n               \"or MCP_ATLASSIAN_SINGLE_USER=true (acknowledges that env \"\n               \"credentials will be used for any incoming request).\"\n           )\n\n  2. Even with SINGLE_USER_MODE, bind the HTTP transport to 127.0.0.1\n     by default unless the operator overrides with an explicit\n     MCP_ATLASSIAN_BIND_PUBLIC=true.\n\n  3. Document the multi-tenant pattern as requiring OAuth proxy or\n     per-request user-token middleware with a verifier that actually\n     verifies (not the opaque-accept-anything stub).\n\n  4. Replace AtlassianOpaqueTokenVerifier with a verifier that performs\n     a token-info or whoami call to Atlassian. The fact that Atlassian\n     tokens are opaque does not preclude verification \u2014 a\n     /rest/api/3/myself call validates the token and returns the\n     associated user, which the verifier can attach to the AccessToken\u0027s\n     scopes and user_id fields.\n\nDefense in depth: the README quickstart should not encourage exposing\nthe HTTP transport without auth. The docker-compose.yml in the repo\nshould bind to 127.0.0.1 only by default.",
  "id": "GHSA-wrhw-j3f9-8vc6",
  "modified": "2026-09-22T20:36:26Z",
  "published": "2026-09-22T20:36:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wrhw-j3f9-8vc6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "[mcp-atlassian] Authentication bypass in HTTP transport: AtlassianOpaqueTokenVerifier accepts any non-empty token"
}

GHSA-WV4W-6QV2-QQFG

Vulnerability from github – Published: 2025-10-09 17:08 – Updated: 2025-10-13 15:40
VLAI
Summary
Python Social Auth - Django has unsafe account association
Details

Impact

Upon authentication, the user could be associated by e-mail even if the associate_by_email pipeline was not included. This could lead to account compromise when a third-party authentication service does not validate provided e-mail addresses or doesn't require unique e-mail addresses.

Patches

  • https://github.com/python-social-auth/social-app-django/pull/803

Workarounds

Review the authentication service policy on e-mail addresses; many will not allow exploiting this vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "social-auth-app-django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-303"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-09T17:08:05Z",
    "nvd_published_at": "2025-10-09T21:15:40Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nUpon authentication, the user could be associated by e-mail even if the `associate_by_email` pipeline was not included. This could lead to account compromise when a third-party authentication service does not validate provided e-mail addresses or doesn\u0027t require unique e-mail addresses.\n\n### Patches\n\n* https://github.com/python-social-auth/social-app-django/pull/803\n\n### Workarounds\n\nReview the authentication service policy on e-mail addresses; many will not allow exploiting this vulnerability.",
  "id": "GHSA-wv4w-6qv2-qqfg",
  "modified": "2025-10-13T15:40:00Z",
  "published": "2025-10-09T17:08:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/security/advisories/GHSA-wv4w-6qv2-qqfg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61783"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/issues/220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/issues/231"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/issues/634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/pull/803"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-social-auth/social-app-django/commit/10c80e2ebabeccd4e9c84ad0e16e1db74148ed4c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-social-auth/social-app-django"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Python Social Auth - Django has unsafe account association "
}

GHSA-X4HF-M6GP-2M3X

Vulnerability from github – Published: 2026-09-17 09:33 – Updated: 2026-09-17 09:33
VLAI
Details

Incorrect Implementation of Authentication Algorithm Vulnerability in Mitsubishi Electric GX Works3 and Motion Control Setting allows a local attacker to successfully authenticate even with an invalid block password by executing the affected product and modifying part of the executable module in memory, and thereby may be able to view, tamper with, destroy, or delete control programs.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-15688"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T09:16:39Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect Implementation of Authentication Algorithm Vulnerability in Mitsubishi Electric GX Works3 and Motion Control Setting allows a local attacker to successfully authenticate even with an invalid block password by executing the affected product and modifying part of the executable module in memory, and thereby may be able to view, tamper with, destroy, or delete control programs.",
  "id": "GHSA-x4hf-m6gp-2m3x",
  "modified": "2026-09-17T09:33:01Z",
  "published": "2026-09-17T09:33:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15688"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU99700314"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/psirt/vulnerability/pdf/2026-007_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:H/SA:H/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-X527-X647-Q7GG

Vulnerability from github – Published: 2026-06-25 22:23 – Updated: 2026-07-17 15:32
VLAI
Summary
golang.org/x/crypto: Invoking VerifiedPublicKeyCallback permissions skip enforcement
Details

Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "golang.org/x/crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.52.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T22:23:16Z",
    "nvd_published_at": "2026-05-22T04:16:25Z",
    "severity": "CRITICAL"
  },
  "details": "Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.",
  "id": "GHSA-x527-x647-q7gg",
  "modified": "2026-07-17T15:32:15Z",
  "published": "2026-06-25T22:23:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46595"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45337"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46595.json"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-5023"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/a082jnz-LvI"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/79570"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/781642"
    },
    {
      "type": "PACKAGE",
      "url": "https://cs.opensource.google/go/x/crypto"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480689"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-46595"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41036"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41019"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40945"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40118"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37387"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37275"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36820"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36808"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36797"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36796"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36651"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36648"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33531"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33524"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30651"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30650"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26547"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26546"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23264"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23262"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "golang.org/x/crypto: Invoking VerifiedPublicKeyCallback permissions skip enforcement"
}

GHSA-X7QH-XCF8-P6CQ

Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-06-28 00:30
VLAI
Details

Incorrect caching of authentication between different polkit methods in qSnapper before version 1.3.3 allowed a local attacker to use functions like "restore from snapshot" even if only allowed to do "delete snapshot".

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H
8.4 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-41048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T16:16:35Z",
    "severity": "HIGH"
  },
  "details": "Incorrect caching of authentication between different polkit methods in qSnapper before version 1.3.3 allowed a local attacker to use functions like \"restore from snapshot\" even if only allowed to do \"delete snapshot\".",
  "id": "GHSA-x7qh-xcf8-p6cq",
  "modified": "2026-06-28T00:30:56Z",
  "published": "2026-06-22T18:34:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41048"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1262218"
    },
    {
      "type": "WEB",
      "url": "https://github.com/presire/qSnapper/releases/tag/v1.3.3"
    },
    {
      "type": "WEB",
      "url": "https://security.opensuse.org/2026/05/26/qsnapper-dbus-issues.html#issue-auth-caching"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/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-XQ9G-8773-5HRQ

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

D-Link DIR-2640 HNAP LoginPassword Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the web management interface, which listens on TCP port 80 by default. A specially crafted login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19549.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-32152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:19Z",
    "severity": "MODERATE"
  },
  "details": "D-Link DIR-2640 HNAP LoginPassword Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the web management interface, which listens on TCP port 80 by default. A specially crafted login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-19549.",
  "id": "GHSA-xq9g-8773-5hrq",
  "modified": "2024-05-03T03:30:50Z",
  "published": "2024-05-03T03:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32152"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10323"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-544"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XXFQ-8CC9-RWX9

Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2024-08-01 15:32
VLAI
Details

Inappropriate implementation in Skia in Google Chrome prior to 115.0.5790.98 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-303"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T23:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "Inappropriate implementation in Skia in Google Chrome prior to 115.0.5790.98 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-xxfq-8cc9-rwx9",
  "modified": "2024-08-01T15:32:03Z",
  "published": "2024-07-17T00:32:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4860"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2023/07/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/40064341"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-90: Reflection Attack in Authentication Protocol

An adversary can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the adversary illegitimate access to the target system, without possessing the requisite credentials. Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An adversary can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication.

← Back to the CWE list