CWE-287

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.9"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0-rc.0"
            },
            {
              "fixed": "3.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-31T00:21:56Z",
    "nvd_published_at": "2020-08-06T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Vulnerability type\nCryptography\n\n### Workarounds\nRefer to the [gateway documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md). The vulnerability was spotted due to unclear documentation of how the gateway handles endpoints validation.\n\n### Detail\nWhen starting a gateway, TLS authentication will only be attempted on endpoints identified in DNS SRV records for a given domain, which occurs in the discoverEndpoints function. No authentication is performed against endpoints provided in the --endpoints flag. The auditors has noted that appropriate documentation of this validation functionality plus deprecation of this misleading functionality is an acceptable path forward.\n \n### References\nFind out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committee-psc)",
  "id": "GHSA-wr2v-9rpq-c35q",
  "modified": "2024-01-31T00:21:56Z",
  "published": "2024-01-31T00:21:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/security/advisories/GHSA-wr2v-9rpq-c35q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15136"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/L6B6R43Y7M3DCHWK3L3UVGE2K6WWECMP"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Etcd Gateway TLS authentication only applies to endpoints detected in DNS SRV records"
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-16590"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-06T23:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "FURUNO FELCOM 250 and 500 devices use only client-side JavaScript in login.js for authentication.",
  "id": "GHSA-wr3w-7fj6-qvcr",
  "modified": "2022-05-14T01:59:36Z",
  "published": "2022-05-14T01:59:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16590"
    },
    {
      "type": "WEB",
      "url": "https://cyberskr.com/blog/furuno-felcom.html"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/CyberSKR/34a8d6be7646a4bfd4df455f9f52500f"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-41751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Sensitive information disclosure due to improper token expiration validation. The following products are affected: Acronis Agent (Windows) before build 32047.",
  "id": "GHSA-wr59-7jhh-rq3q",
  "modified": "2023-08-31T21:32:41Z",
  "published": "2023-08-31T21:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41751"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-5615"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-32570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper authentication in the Intel(R) Quartus Prime Pro and Standard edition software may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-wr75-9gvh-9gh6",
  "modified": "2023-03-06T21:30:18Z",
  "published": "2023-02-16T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32570"
    },
    {
      "type": "WEB",
      "url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00714.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-45511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-26T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Certain NETGEAR devices are affected by authentication bypass. This affects AC2100 before 2021-08-27, AC2400 before 2021-08-27, AC2600 before 2021-08-27, D7000 before 2021-08-27, R6220 before 2021-08-27, R6230 before 2021-08-27, R6260 before 2021-08-27, R6330 before 2021-08-27, R6350 before 2021-08-27, R6700v2 before 2021-08-27, R6800 before 2021-08-27, R6850 before 2021-08-27, R6900v2 before 2021-08-27, R7200 before 2021-08-27, R7350 before 2021-08-27, R7400 before 2021-08-27, and R7450 before 2021-08-27.",
  "id": "GHSA-wr8v-6jgr-244v",
  "modified": "2022-07-13T00:01:51Z",
  "published": "2021-12-27T00:01:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45511"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000063961/Security-Advisory-for-Authentication-Bypass-Vulnerability-on-the-D7000-and-Some-Routers-PSV-2021-0133"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-7042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-26T22:17:31Z",
    "severity": "MODERATE"
  },
  "details": "A flaw has been found in 666ghj MiroFish up to 0.1.2. This affects the function create_app of the file backend/app/__init__.py of the component REST API Endpoint. Executing a manipulation can lead to missing authentication. It is possible to launch the attack remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-wr9f-cr47-6784",
  "modified": "2026-04-27T00:30:27Z",
  "published": "2026-04-27T00:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/666ghj/MiroFish/issues/487"
    },
    {
      "type": "WEB",
      "url": "https://github.com/666ghj/MiroFish"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/798583"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359621"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359621/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-28940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-01T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "On Western Digital My Cloud OS 5 devices before 5.06.115, the NAS Admin dashboard has an authentication bypass vulnerability that could allow an unauthenticated user to execute privileged commands on the device.",
  "id": "GHSA-wrfx-v3mv-pvww",
  "modified": "2022-05-24T17:35:14Z",
  "published": "2022-05-24T17:35:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28940"
    },
    {
      "type": "WEB",
      "url": "https://support.wdc.com/downloads.aspx?g=907\u0026lang=en#downloads"
    },
    {
      "type": "WEB",
      "url": "https://www.westerndigital.com/support/productsecurity/wdc-20009-os5-firmware-5-06-115"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-20-1445"
    }
  ],
  "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"
    }
  ]
}

{
  "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"
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-35758"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-03T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered on Libre Wireless LS9 LS1.5/p7040 devices. There is a Authentication Bypass in the Web Interface. This interface does not properly restrict access to internal functionality. Despite presenting a password login page on first access, authentication is not required to access privileged functionality. As such, it\u0027s possible to directly access APIs that should not be exposed to an unauthenticated user.",
  "id": "GHSA-wrjg-pj2x-pfw3",
  "modified": "2022-06-29T00:00:32Z",
  "published": "2022-05-24T17:49:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35758"
    },
    {
      "type": "WEB",
      "url": "https://www.iot-inspector.com/blog/advisory-multiple-issues-libre-wireless-ls9"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-38119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-10T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "UPSMON Pro login function has insufficient authentication. An unauthenticated remote attacker can exploit this vulnerability to bypass authentication and get administrator privilege to access, control system or disrupt service.",
  "id": "GHSA-wrjq-c6h8-5hjq",
  "modified": "2022-11-10T19:01:09Z",
  "published": "2022-11-10T19:01:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38119"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-6678-e9fbe-1.html"
    }
  ],
  "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"
    }
  ]
}