Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

2085 vulnerabilities reference this CWE, most recent first.

GHSA-6QRF-F2G2-Q6W9

Vulnerability from github – Published: 2022-06-03 00:01 – Updated: 2022-06-12 00:00
VLAI
Details

Specific BD Pyxis™ products were installed with default credentials and may presently still operate with these credentials. There may be scenarios where BD Pyxis™ products are installed with the same default local operating system credentials or domain-joined server(s) credentials that may be shared across product types. If exploited, threat actors may be able to gain privileged access to the underlying file system and could potentially exploit or gain access to ePHI or other sensitive information.

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-2022-22767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Specific BD Pyxis\u2122 products were installed with default credentials and may presently still operate with these credentials. There may be scenarios where BD Pyxis\u2122 products are installed with the same default local operating system credentials or domain-joined server(s) credentials that may be shared across product types. If exploited, threat actors may be able to gain privileged access to the underlying file system and could potentially exploit or gain access to ePHI or other sensitive information.",
  "id": "GHSA-6qrf-f2g2-q6w9",
  "modified": "2022-06-12T00:00:47Z",
  "published": "2022-06-03T00:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22767"
    },
    {
      "type": "WEB",
      "url": "https://cybersecurity.bd.com/bulletins-and-patches/bd-pyxis-products-default-credentials"
    }
  ],
  "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-6QXP-VCCF-F47H

Vulnerability from github – Published: 2026-10-06 15:35 – Updated: 2026-10-06 15:35
VLAI
Summary
MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server
Details

Summary

In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to.

A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:

  • the refresh_token and client_secret stored from an earlier sign-in
  • the client_secret or signed assertion configured on a bundled provider

Am I affected?

Yes, if both of these hold:

  • your application uses the SDK's OAuth client over HTTP, through any of:
    • an authProvider on a transport
    • the withOAuth() middleware
    • direct calls to auth() or fetchToken()
  • it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server

Affected versions:

  • @modelcontextprotocol/sdk 1.12.0 through 1.30.1
  • @modelcontextprotocol/client 2.0.0 through 2.1.0, only for:
    • bundled providers without expectedIssuer
    • credentials stored or supplied without issuer
    • direct calls to fetchToken()
    • providers that read storage back through OAuthTokensSchema or OAuthClientInformationSchema

Not affected:

  • MCP servers built with the SDK
  • stdio clients

Fix

Upgrade to:

  • 1.x: @modelcontextprotocol/sdk 1.31.0 or later
  • 2.x: @modelcontextprotocol/client 2.2.0 or later, and @modelcontextprotocol/core 2.2.0 or later if you import it directly

The client now records the authorization server as issuer on saved credentials and does not send them to a different one. The user signs in again, or the call throws.

In the following cases, upgrading to the patched version is not enough. You also need to make a change:

  • Bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider): pass expectedIssuer, for example expectedIssuer: 'https://auth.example.com'. Without it they still use whichever authorization server the MCP server names.
  • Credentials saved without issuer: tokens and client information your OAuthClientProvider persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add issuer to them, or clear them so users sign in again.
  • Your own OAuthClientProvider: save exactly what saveTokens() and saveClientInformation() are given, including issuer. For pre-registered credentials, include issuer in what clientInformation() returns.

Not covered by this fix:

  • a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.
  • refreshAuthorization() and exchangeAuthorization() called directly
  • 2.x with skipIssuerMetadataValidation: true

If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.

If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept expectedIssuer.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "1.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@modelcontextprotocol/client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T15:35:44Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nIn affected versions, the SDK\u0027s OAuth client let the MCP server decide which authorization server received the client\u0027s OAuth credentials. Credentials were not tied to the authorization server they belong to.\n\nA malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:\n\n- the `refresh_token` and `client_secret` stored from an earlier sign-in\n- the `client_secret` or signed assertion configured on a bundled provider\n\n### Am I affected?\nYes, if both of these hold:\n\n- your application uses the SDK\u0027s OAuth client over HTTP, through any of:\n    - an `authProvider` on a transport\n    - the `withOAuth()` middleware\n    - direct calls to `auth()` or `fetchToken()`\n- it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1\n- `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for:\n    - bundled providers without `expectedIssuer`\n    - credentials stored or supplied without `issuer`\n    - direct calls to `fetchToken()`\n    - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema`\n\nNot affected:\n\n- MCP servers built with the SDK\n- stdio clients\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later\n- 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly\n\nThe client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws.\n\nIn the following cases, upgrading to the patched version is not enough. You also need to make a change:\n\n- **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: \u0027https://auth.example.com\u0027`. Without it they still use whichever authorization server the MCP server names.\n- **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again.\n- **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns.\n\nNot covered by this fix:\n\n- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.\n- `refreshAuthorization()` and `exchangeAuthorization()` called directly\n- 2.x with `skipIssuerMetadataValidation: true`\n\nIf an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.\n\nIf you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.",
  "id": "GHSA-6qxp-vccf-f47h",
  "modified": "2026-10-06T15:35:44Z",
  "published": "2026-10-06T15:35:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-6qxp-vccf-f47h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/pull/2887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/commit/edd12e282620ebf770d67316f19cf91d4112a1bd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/v2.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server"
}

GHSA-6R5W-JJR5-QVGR

Vulnerability from github – Published: 2023-12-13 18:31 – Updated: 2024-11-15 22:26
VLAI
Summary
Password stored in a recoverable format by Jenkins OpenId Connect Authentication Plugin
Details

Jenkins OpenId Connect Authentication Plugin stores a password of a local user account used as an anti-lockout feature in a recoverable format, allowing attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:oic-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.229.vf736b"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-50770"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-13T19:34:24Z",
    "nvd_published_at": "2023-12-13T18:15:44Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins OpenId Connect Authentication Plugin stores a password of a local user account used as an anti-lockout feature in a recoverable format, allowing attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins.",
  "id": "GHSA-6r5w-jjr5-qvgr",
  "modified": "2024-11-15T22:26:42Z",
  "published": "2023-12-13T18:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50770"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/oic-auth-plugin/issues/259"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkins-infra/update-center2/pull/773"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/oic-auth-plugin/pull/287"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/oic-auth-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-12-13/#SECURITY-3168"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/12/13/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Password stored in a recoverable format by Jenkins OpenId Connect Authentication Plugin "
}

GHSA-6RQ3-PXGH-FW4X

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-10-25 12:00
VLAI
Details

Dell EMC Unity, Unity XT, and UnityVSA versions prior to 5.1.0.0.5.394 contain a plain-text password storage vulnerability. A local malicious user with high privileges may use the exposed password to gain access with the privileges of the compromised user.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-21591"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-12T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell EMC Unity, Unity XT, and UnityVSA versions prior to 5.1.0.0.5.394 contain a plain-text password storage vulnerability. A local malicious user with high privileges may use the exposed password to gain access with the privileges of the compromised user.",
  "id": "GHSA-6rq3-pxgh-fw4x",
  "modified": "2022-10-25T12:00:15Z",
  "published": "2022-05-24T19:07:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21591"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000189204"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6RXP-6G9V-64V8

Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-03-29 15:30
VLAI
Details

OpenClaw before 2026.3.12 embeds long-lived shared gateway credentials directly in pairing setup codes generated by /pair endpoint and OpenClaw qr command. Attackers with access to leaked setup codes from chat history, logs, or screenshots can recover and reuse the shared gateway credential outside the intended one-time pairing flow.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-33575"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-29T13:17:03Z",
    "severity": "HIGH"
  },
  "details": "OpenClaw before 2026.3.12 embeds long-lived shared gateway credentials directly in pairing setup codes generated by /pair endpoint and OpenClaw qr command. Attackers with access to leaked setup codes from chat history, logs, or screenshots can recover and reuse the shared gateway credential outside the intended one-time pairing flow.",
  "id": "GHSA-6rxp-6g9v-64v8",
  "modified": "2026-03-29T15:30:20Z",
  "published": "2026-03-29T15:30:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7h7g-x2px-94hj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33575"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-long-lived-credential-exposure-in-pairing-setup-codes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6W4J-5CMH-9J58

Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-07-09 18:30
VLAI
Details

The Avalara for Salesforce CPQ app before 7.0 for Salesforce allows attackers to read an API key. NOTE: the current version is 11 as of mid-2024.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-38453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-03T06:15:04Z",
    "severity": "HIGH"
  },
  "details": "The Avalara for Salesforce CPQ app before 7.0 for Salesforce allows attackers to read an API key. NOTE: the current version is 11 as of mid-2024.",
  "id": "GHSA-6w4j-5cmh-9j58",
  "modified": "2024-07-09T18:30:43Z",
  "published": "2024-07-03T18:48:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38453"
    },
    {
      "type": "WEB",
      "url": "https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FKAoOUAX"
    },
    {
      "type": "WEB",
      "url": "https://deneyed.com/blog/avalara"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6W7R-4V6H-JJQ5

Vulnerability from github – Published: 2022-12-12 18:30 – Updated: 2022-12-15 18:30
VLAI
Details

A cleartext storage of sensitive information vulnerability exists in PcVue versions 8.10 through 15.2.3. This could allow an unauthorized user with access the email and short messaging service (SMS) accounts configuration files to discover the associated simple mail transfer protocol (SMTP) account credentials and the SIM card PIN code. Successful exploitation of this vulnerability could allow an unauthorized user access to the underlying email account and SIM card.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-4312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A cleartext storage of sensitive information vulnerability exists in PcVue versions 8.10 through 15.2.3. This could allow an unauthorized user with access the email and short messaging service (SMS) accounts configuration files to discover the associated simple mail transfer protocol (SMTP) account credentials and the SIM card PIN code. Successful exploitation of this vulnerability could allow an unauthorized user access to the underlying email account and SIM card.",
  "id": "GHSA-6w7r-4v6h-jjq5",
  "modified": "2022-12-15T18:30:24Z",
  "published": "2022-12-12T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4312"
    },
    {
      "type": "WEB",
      "url": "https://www.pcvuesolutions.com/support/index.php/en/security-bulletin/1171-security-bulletin-2022-7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6X35-H74F-24J6

Vulnerability from github – Published: 2026-06-29 09:30 – Updated: 2026-06-29 09:30
VLAI
Details

Information exposure vulnerability in Hitachi Storage Navigator.

This issue affects Hitachi Virtual Storage Platform 5100, 5200, 5500, 5600, 5100H, 5200H, 5500H, 5600H, VX8: before DKCMAIN Ver. 90-09-24-00/00, SVP Ver. 90-09-24/00, before DKCMAIN Ver. 90-08-86-00/00, SVP Ver. 90-08-86/00; Hitachi Virtual Storage Platform G1000, G1500, F1500, VX7: before DKCMAIN Ver. 80-06-96-00/00, SVP Ver. 80-06-91/00.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-7386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-29T07:16:23Z",
    "severity": "MODERATE"
  },
  "details": "Information exposure vulnerability in Hitachi Storage Navigator.\n\nThis issue affects Hitachi Virtual Storage Platform 5100, 5200, 5500, 5600, 5100H, 5200H, 5500H, 5600H, VX8: before DKCMAIN Ver. 90-09-24-00/00, SVP Ver. 90-09-24/00, before DKCMAIN Ver. 90-08-86-00/00, SVP Ver. 90-08-86/00; Hitachi Virtual Storage Platform G1000, G1500, F1500, VX7: before DKCMAIN Ver. 80-06-96-00/00, SVP Ver. 80-06-91/00.",
  "id": "GHSA-6x35-h74f-24j6",
  "modified": "2026-06-29T09:30:28Z",
  "published": "2026-06-29T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7386"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi.com/products/it/storage-solutions/sec_info/2026/2026_301.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6X6C-W9W9-HV4H

Vulnerability from github – Published: 2026-09-08 18:14 – Updated: 2026-09-08 18:14
VLAI
Summary
Infracost: Terraform Cloud and registry token disclosure via unvalidated hostname
Details

Impact

Sensitive information exposure in the Infracost Terraform Cloud/Enterprise integration. Several code paths attached a configured secret token to a request whose host was taken straight from the scanned Terraform, with no check that the host was the trusted endpoint.

The condition that matters is whether a Terraform Cloud/Enterprise (or registry) token is present in the run: if one is, the injected hostname can disclose it. Impact therefore depends on the trigger. Under on: pull_request (the only configuration in Infracost's documentation) fork pull requests run without secrets, so no token is present. It only reaches token disclosure under pull_request_target, a same-repository pull request, or another CI setup that provides the token alongside untrusted Terraform, and exploiting an untrusted fork pull request also typically needs a maintainer to approve the workflow run. The patch scopes the token to the trusted host regardless of trigger.

Patches

Fixed in v0.10.45 (#3590) by attaching a token only when the destination host matches the configured trusted host; otherwise Infracost refuses to send it and skips remote variable loading - Installed via the official script, a package manager, or the latest Docker tag: upgrade to v0.10.45 (or later) to receive the fix. - Pinned to a specific version or image digest: bump to v0.10.45.

Workarounds

No full fix without upgrading. To limit exposure: use on: pull_request rather than pull_request_target, pin organization, workspace, and host in Infracost config so the .tf hostname is ignored, and keep Terraform Cloud and registry tokens out of runs that process untrusted pull request content.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/infracost/infracost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T18:14:12Z",
    "nvd_published_at": "2026-08-21T18:16:50Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nSensitive information exposure in the Infracost Terraform Cloud/Enterprise integration. Several code paths attached a configured secret token to a request whose host was taken straight from the scanned Terraform, with no check that the host was the trusted endpoint. \n\nThe condition that matters is whether a Terraform Cloud/Enterprise (or registry) token is present in the run: if one is, the injected hostname can disclose it. Impact therefore depends on the trigger. Under `on: pull_request` (the only configuration in Infracost\u0027s documentation) fork pull requests run without secrets, so no token is present. It only reaches token disclosure under `pull_request_target`, a same-repository pull request, or another CI setup that provides the token alongside untrusted Terraform, and exploiting an untrusted fork pull request also typically needs a maintainer to approve the workflow run. The patch scopes the token to the trusted host regardless of trigger.\n\n### Patches\n\nFixed in `v0.10.45` ([#3590](https://github.com/infracost/infracost/pull/3590)) by attaching a token only when the destination host matches the configured trusted host; otherwise Infracost refuses to send it and skips remote variable loading\n  - Installed via the official script, a package manager, or the `latest` Docker tag: upgrade to `v0.10.45` (or later) to receive the fix.\n  - Pinned to a specific version or image digest: bump to `v0.10.45`.\n\n### Workarounds\n\nNo full fix without upgrading. To limit exposure: use `on: pull_request` rather than `pull_request_target`, pin `organization`, `workspace`, and `host` in Infracost config so the `.tf` hostname is ignored, and keep Terraform Cloud and registry tokens out of runs that process untrusted pull request content.",
  "id": "GHSA-6x6c-w9w9-hv4h",
  "modified": "2026-09-08T18:14:12Z",
  "published": "2026-09-08T18:14:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/infracost/infracost/security/advisories/GHSA-6x6c-w9w9-hv4h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infracost/infracost/pull/3590"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infracost/infracost/commit/3d24c757f5e4e60c7259f1b89ad7ceaabcfca86f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/infracost/infracost"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infracost/infracost/releases/tag/v0.10.45"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Infracost: Terraform Cloud and registry token disclosure via unvalidated hostname"
}

GHSA-6XW9-QQ9H-CR68

Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2022-12-06 21:44
VLAI
Summary
Jenkins Dynatrace Plugin vulnerable to Insufficiently Protected Credentials
Details

Jenkins Dynatrace Application Monitoring Plugin prior to 2.1.4 stores credentials unencrypted in its global configuration file on the Jenkins master where they could be viewed by users with access to the master file system.

NOTE: This plugin is marked as DEPRECATED

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/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.jenkins-ci.plugins:dynatrace-dashboard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-06T21:44:47Z",
    "nvd_published_at": "2019-10-23T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Dynatrace Application Monitoring Plugin prior to 2.1.4 stores credentials unencrypted in its global configuration file on the Jenkins master where they could be viewed by users with access to the master file system.\n\n##NOTE: This plugin is marked as DEPRECATED",
  "id": "GHSA-6xw9-qq9h-cr68",
  "modified": "2022-12-06T21:44:47Z",
  "published": "2022-05-24T16:59:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10461"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/dynatrace-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-10-23/#SECURITY-1477"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/10/23/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Dynatrace Plugin vulnerable to Insufficiently Protected Credentials"
}
Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-474: Signature Spoofing by Key Theft

An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.

CAPEC-50: Password Recovery Exploitation

An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.

← Back to the CWE list