Common Weakness Enumeration

CWE-798

Allowed-with-Review

Use of Hard-coded Credentials

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product contains hard-coded credentials, such as a password or cryptographic key.

2185 vulnerabilities reference this CWE, most recent first.

GHSA-F4FP-GRGF-CRCX

Vulnerability from github – Published: 2024-09-30 21:02 – Updated: 2024-09-30 21:02
VLAI
Details

An issue was discovered in Infinera hiT 7300 5.60.50. A hidden SSH service (on the local management network interface) with hardcoded credentials allows attackers to access the appliance operating system (with highest privileges) via an SSH connection.

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-2024-28812"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-30T19:15:04Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Infinera hiT 7300 5.60.50. A hidden SSH service (on the local management network interface) with hardcoded credentials allows attackers to access the appliance operating system (with highest privileges) via an SSH connection.",
  "id": "GHSA-f4fp-grgf-crcx",
  "modified": "2024-09-30T21:02:13Z",
  "published": "2024-09-30T21:02:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28812"
    },
    {
      "type": "WEB",
      "url": "https://www.cvcn.gov.it/cvcn/cve/CVE-2024-28812"
    }
  ],
  "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-F4JG-785X-37X7

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:13
VLAI
Details

Arlo Basestation firmware 1.12.0.1_27940 and prior contain a hardcoded username and password combination that allows root access to the device when an onboard serial interface is connected to.

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-2019-3950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-09T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Arlo Basestation firmware 1.12.0.1_27940 and prior contain a hardcoded username and password combination that allows root access to the device when an onboard serial interface is connected to.",
  "id": "GHSA-f4jg-785x-37x7",
  "modified": "2024-04-04T01:13:30Z",
  "published": "2022-05-24T16:49:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3950"
    },
    {
      "type": "WEB",
      "url": "https://kb.arlo.com/000062274/Security-Advisory-for-Networking-Misconfiguration-and-Insufficient-UART-Protection-Mechanisms"
    }
  ],
  "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-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-F52G-MQVX-JMJP

Vulnerability from github – Published: 2023-12-01 15:31 – Updated: 2023-12-06 21:30
VLAI
Details

The password for access to the debugging console of the PoWer Controller chip (PWC) of the MIB3 infotainment is hard-coded in the firmware. The console allows attackers with physical access to the MIB3 unit to gain full control over the PWC chip.

Vulnerability found on Škoda Superb III (3V3) - 2.0 TDI manufactured in 2022.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-28895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-259",
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-01T14:15:07Z",
    "severity": "LOW"
  },
  "details": "The password for access to the debugging console of the PoWer Controller chip (PWC) of the MIB3 infotainment is hard-coded in the firmware. The console allows attackers with physical access to the MIB3 unit to gain full control over the PWC chip.\n\nVulnerability found on\u00a0\u0160koda Superb III (3V3) - 2.0 TDI manufactured in 2022.",
  "id": "GHSA-f52g-mqvx-jmjp",
  "modified": "2023-12-06T21:30:58Z",
  "published": "2023-12-01T15:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28895"
    },
    {
      "type": "WEB",
      "url": "https://asrg.io/security-advisories/hard-coded-password-for-access-to-power-controller-chip-memory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F537-M327-RQRG

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

An issue was discovered in PTC ThingWorx Platform 6.5 through 8.2. There is a hardcoded encryption key.

Severity
7.5 (High)
CVSS:3.0/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-2018-17217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-01T01:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in PTC ThingWorx Platform 6.5 through 8.2. There is a hardcoded encryption key.",
  "id": "GHSA-f537-m327-rqrg",
  "modified": "2022-05-14T01:58:50Z",
  "published": "2022-05-14T01:58:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17217"
    },
    {
      "type": "WEB",
      "url": "https://www.ptc.com/en/support/article?n=CS291004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F572-W4J4-F6R5

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2024-04-04 02:54
VLAI
Details

The password for the safety PLC is the default and thus easy to find (in manuals, etc.). This allows a manipulated program to be uploaded to the safety PLC, effectively disabling the emergency stop in case an object is too close to the robot. Navigation and any other components dependent on the laser scanner are not affected (thus it is hard to detect before something happens) though the laser scanner configuration can also be affected altering further the safety of the device.

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-2020-10276"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-24T05:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The password for the safety PLC is the default and thus easy to find (in manuals, etc.). This allows a manipulated program to be uploaded to the safety PLC, effectively disabling the emergency stop in case an object is too close to the robot. Navigation and any other components dependent on the laser scanner are not affected (thus it is hard to detect before something happens) though the laser scanner configuration can also be affected altering further the safety of the device.",
  "id": "GHSA-f572-w4j4-f6r5",
  "modified": "2024-04-04T02:54:31Z",
  "published": "2022-05-24T17:21:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10276"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aliasrobotics/RVD/issues/2558"
    }
  ],
  "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-F58R-QGWQ-JFXV

Vulnerability from github – Published: 2023-12-28 00:30 – Updated: 2024-01-05 18:30
VLAI
Details

Phlox com.phlox.simpleserver.plus (aka Simple HTTP Server PLUS) 1.8.1-plus has an Android manifest file that contains an entry with the android:allowBackup attribute set to true. This could be leveraged by an attacker with physical access to the device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-46918"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-27T22:15:16Z",
    "severity": "MODERATE"
  },
  "details": "Phlox com.phlox.simpleserver.plus (aka Simple HTTP Server PLUS) 1.8.1-plus has an Android manifest file that contains an entry with the android:allowBackup attribute set to true. This could be leveraged by an attacker with physical access to the device.",
  "id": "GHSA-f58r-qgwq-jfxv",
  "modified": "2024-01-05T18:30:24Z",
  "published": "2023-12-28T00:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46918"
    },
    {
      "type": "WEB",
      "url": "https://github.com/actuator/com.phlox.simpleserver/blob/main/CWE-321.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F5CX-J2CW-PGFG

Vulnerability from github – Published: 2025-12-18 21:31 – Updated: 2026-01-29 18:31
VLAI
Details

Default credentials in Dify thru 1.5.1. PostgreSQL username and password specified in the docker-compose.yaml file included in its source code.

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-2025-56157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T19:16:26Z",
    "severity": "CRITICAL"
  },
  "details": "Default credentials in Dify thru 1.5.1. PostgreSQL username and password specified in the docker-compose.yaml file included in its source code.",
  "id": "GHSA-f5cx-j2cw-pgfg",
  "modified": "2026-01-29T18:31:31Z",
  "published": "2025-12-18T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56157"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langgenius/dify/issues/15285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langgenius/dify/pull/15286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langgenius/dify/pull/15286.diff"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Cristliu/216ddbadaf3258498c93d408683ecabd"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Cristliu/298f51cbc72c45d91632cd0d65aa8161"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langgenius/dify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langgenius/dify/releases/tag/1.0.1"
    },
    {
      "type": "WEB",
      "url": "http://dify.com"
    }
  ],
  "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-F5HG-XWHP-3GJ9

Vulnerability from github – Published: 2024-08-16 18:30 – Updated: 2024-09-11 15:31
VLAI
Details

H3C Magic B1ST v100R012 was discovered to contain a hardcoded password vulnerability in /etc/shadow, which allows attackers to log in as root.

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-2024-42638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-16T18:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "H3C Magic B1ST v100R012 was discovered to contain a hardcoded password vulnerability in /etc/shadow, which allows attackers to log in as root.",
  "id": "GHSA-f5hg-xwhp-3gj9",
  "modified": "2024-09-11T15:31:11Z",
  "published": "2024-08-16T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42638"
    },
    {
      "type": "WEB",
      "url": "https://palm-vertebra-fe9.notion.site/H3C-Magic-B1STV100R012-was-discovered-to-contain-a-hardcoded-2a648569ee7f4df8b570632d11032337?pvs=74"
    },
    {
      "type": "WEB",
      "url": "https://www.h3c.com/cn/d_201609/956059_30005_0.htm"
    }
  ],
  "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-F5RH-XQJC-3GC6

Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41
VLAI
Details

An issue was discovered on FiberHome HG6245D devices through RP2613. Credentials in /fhconf/umconfig.txt are obfuscated via XOR with the hardcoded j7a(L#yZ98sSd5HfSgGjMj8;Ss;d)(&^#@$a2s0i3g key. (The webs binary has details on how XOR is used.)

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-27141"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-10T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered on FiberHome HG6245D devices through RP2613. Credentials in /fhconf/umconfig.txt are obfuscated via XOR with the hardcoded *j7a(L#yZ98sSd5HfSgGjMj8;Ss;d)(*\u0026^#@$a2s0i3g key. (The webs binary has details on how XOR is used.)",
  "id": "GHSA-f5rh-xqjc-3gc6",
  "modified": "2022-05-24T17:41:48Z",
  "published": "2022-05-24T17:41:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27141"
    },
    {
      "type": "WEB",
      "url": "https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0day-vulnerabilities.html#httpd-decryption-algorithm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation
Architecture and Design
  • For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible [REF-7].
  • In Windows environments, the Encrypted File System (EFS) may provide some protection.
Mitigation
Architecture and Design

For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

Mitigation
Architecture and Design

If the product must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection.

Mitigation
Architecture and Design
  • For inbound authentication using passwords: apply strong one-way hashes to passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When handling an incoming password during authentication, take the hash of the password and compare it to the saved hash.
  • Use randomly assigned salts for each separate hash that is generated. This increases the amount of computation that an attacker needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.
Mitigation
Architecture and Design
  • For front-end to back-end connections: Three solutions are possible, although none are complete.
  • The first suggestion involves the use of generated passwords or keys that are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.
  • Next, the passwords or keys should be limited at the back end to only performing actions valid for the front end, as opposed to having full access.
  • Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay-style attacks.
CAPEC-191: Read Sensitive Constants Within an Executable

An adversary engages in activities to discover any sensitive constants present within the compiled code of an executable. These constants may include literal ASCII strings within the file itself, or possibly strings hard-coded into particular routines that can be revealed by code refactoring methods including static and dynamic analysis.

CAPEC-70: Try Common or Default Usernames and Passwords

An adversary may try certain common or default usernames and passwords to gain access into the system and perform unauthorized actions. An adversary may try an intelligent brute force using empty passwords, known vendor default credentials, as well as a dictionary of common usernames and passwords. Many vendor products come preconfigured with default (and thus well-known) usernames and passwords that should be deleted prior to usage in a production environment. It is a common mistake to forget to remove these default login credentials. Another problem is that users would pick very simple (common) passwords (e.g. "secret" or "password") that make it easier for the attacker to gain access to the system compared to using a brute force attack or even a dictionary attack using a full dictionary.

← Back to the CWE list