GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-757

Allowed

Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.

60 vulnerabilities reference this CWE, most recent first.

GHSA-6V9V-H9V4-6XM8

Vulnerability from github – Published: 2025-07-01 15:31 – Updated: 2025-07-01 15:31
VLAI
Details

Dell NetWorker, versions 19.12.0.1 and prior, contains a Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-36582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-01T14:15:37Z",
    "severity": "MODERATE"
  },
  "details": "Dell NetWorker, versions 19.12.0.1 and prior, contains a Selection of Less-Secure Algorithm During Negotiation (\u0027Algorithm Downgrade\u0027) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure.",
  "id": "GHSA-6v9v-h9v4-6xm8",
  "modified": "2025-07-01T15:31:09Z",
  "published": "2025-07-01T15:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36582"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000338757/dsa-2025-268-security-update-for-dell-networker-selection-of-less-secure-algorithm-during-negotiation-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9F77-473J-CJG2

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 15:32
VLAI
Details

psPAS PowerShell module does not explicitly enforce TLS 1.2 within the 'Get-PASSAMLResponse' function during the SAML authentication process. An unauthenticated attacker in a 'Man-in-the-Middle' position could manipulate the TLS handshake and downgrade TLS to a deprecated protocol. Fixed in 7.0.209.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-59270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T15:15:46Z",
    "severity": "LOW"
  },
  "details": "psPAS PowerShell module does not explicitly enforce TLS 1.2 within the \u0027Get-PASSAMLResponse\u0027 function during the SAML authentication process. An unauthenticated attacker in a \u0027Man-in-the-Middle\u0027 position could manipulate the TLS handshake and downgrade TLS to a deprecated protocol. Fixed in 7.0.209.",
  "id": "GHSA-9f77-473j-cjg2",
  "modified": "2025-09-16T15:32:37Z",
  "published": "2025-09-16T15:32:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59270"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pspete/psPAS/commit/2a8b1b4bc001bec9969ea512ed83386ed3e0b8f8#diff-e40bf02e86c8a8babbb20529ecaef6a069d8b5ea21701dca429dce78181109a7L37-R75"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pspete/psPAS/releases/tag/v7.0.209"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2025/va-25-258-01.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-59270"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/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-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-C4Q9-2WFM-WJ48

Vulnerability from github – Published: 2024-06-03 03:31 – Updated: 2024-08-01 15:31
VLAI
Details

In modem, there is a possible selection of less-secure algorithm during the VoWiFi IKE due to a missing DH downgrade check. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: MOLY01286330; Issue ID: MSV-1430.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-20069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-03T02:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In modem, there is a possible selection of less-secure algorithm during the VoWiFi IKE due to a missing DH downgrade check. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: MOLY01286330; Issue ID: MSV-1430.",
  "id": "GHSA-c4q9-2wfm-wj48",
  "modified": "2024-08-01T15:31:46Z",
  "published": "2024-06-03T03:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20069"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/June-2024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C9WM-H66H-5R4V

Vulnerability from github – Published: 2023-10-07 00:30 – Updated: 2024-04-04 08:23
VLAI
Details

IBM Security Directory Suite 8.0.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 228568.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-33160"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-327",
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-06T22:15:11Z",
    "severity": "HIGH"
  },
  "details": "IBM Security Directory Suite 8.0.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.  IBM X-Force ID:  228568.",
  "id": "GHSA-c9wm-h66h-5r4v",
  "modified": "2024-04-04T08:23:51Z",
  "published": "2023-10-07T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33160"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/228568"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7047071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CFFX-9Q2G-R6HP

Vulnerability from github – Published: 2026-07-17 21:31 – Updated: 2026-07-17 21:31
VLAI
Details

IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to send a specifically crafted message and downgrade the Transport Layer Security (TLS) protocol to a version disabled in the server configuration.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T20:17:23Z",
    "severity": "MODERATE"
  },
  "details": "IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to send a specifically crafted message and downgrade the Transport Layer Security (TLS) protocol to a version disabled in the server configuration.",
  "id": "GHSA-cffx-9q2g-r6hp",
  "modified": "2026-07-17T21:31:44Z",
  "published": "2026-07-17T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4942"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7278992"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GXXJ-4C9F-HRVW

Vulnerability from github – Published: 2021-12-01 00:00 – Updated: 2021-12-02 00:01
VLAI
Details

Dell EMC Streaming Data Platform, versions prior to 1.3 contain an SSL Strip Vulnerability in the User Interface (UI). A remote unauthenticated attacker could potentially exploit this vulnerability, leading to a downgrade in the communications between the client and server into an unencrypted format.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36326"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-30T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell EMC Streaming Data Platform, versions prior to 1.3 contain an SSL Strip Vulnerability in the User Interface (UI). A remote unauthenticated attacker could potentially exploit this vulnerability, leading to a downgrade in the communications between the client and server into an unencrypted format.",
  "id": "GHSA-gxxj-4c9f-hrvw",
  "modified": "2021-12-02T00:01:05Z",
  "published": "2021-12-01T00:00:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36326"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-in/000193697/dsa-2021-205-dell-emc-streaming-data-platform-security-update-for-third-party-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H92M-42H4-82F6

Vulnerability from github – Published: 2019-07-05 21:06 – Updated: 2024-10-21 20:07
VLAI
Summary
postfix-mta-sts-resolver Algorithm Downgrade vulnerability
Details

Incorrect query parsing

Impact

All users of versions prior to 0.5.1 can receive incorrect response from daemon under rare conditions, rendering downgrade of effective STS policy.

Patches

Problem has been patched in version 0.5.1

Workarounds

Users may remediate this vulnerability without upgrading by applying these patches to older suppoorted versions.

For more information

If you have any questions or comments about this advisory: * Open an issue in postfix-mta-sts-resolver repo * Email me at vladislav at vm-0 dot com

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "postfix-mta-sts-resolver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-16791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:39:43Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Incorrect query parsing\n\n### Impact\nAll users of versions prior to 0.5.1 can receive incorrect response from daemon under rare conditions, rendering downgrade of effective STS policy.\n\n### Patches\nProblem has been patched in version 0.5.1\n\n### Workarounds\nUsers may remediate this vulnerability without upgrading by applying [these patches](https://gist.github.com/Snawoot/b9da85d6b26dea5460673b29df1adc6b) to older suppoorted versions.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [postfix-mta-sts-resolver repo](https://github.com/Snawoot/postfix-mta-sts-resolver)\n* Email me at [vladislav at vm-0 dot com](mailto:vladislav-ex-gh-advisory@vm-0.com)",
  "id": "GHSA-h92m-42h4-82f6",
  "modified": "2024-10-21T20:07:58Z",
  "published": "2019-07-05T21:06:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Snawoot/postfix-mta-sts-resolver/security/advisories/GHSA-h92m-42h4-82f6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16791"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Snawoot/b9da85d6b26dea5460673b29df1adc6b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Snawoot/postfix-mta-sts-resolver"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/postfix-mta-sts-resolver/PYSEC-2020-174.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "postfix-mta-sts-resolver Algorithm Downgrade vulnerability"
}

GHSA-J92G-9F8W-J867

Vulnerability from github – Published: 2026-07-21 17:47 – Updated: 2026-07-21 17:47
VLAI
Summary
PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms
Details

Impact

channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms.

Two issues combine in releases 42.7.4 through 42.7.11:

  1. The bundled com.ongres.scram:scram-client (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf.
  2. pgJDBC does not enforce channelBinding=require where it matters. ScramAuthenticator checks only that the server advertised a -PLUS mechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed scram-client, because the missing enforcement is in pgJDBC's own code.

Only connections that set channelBinding=require are affected. Under the default prefer policy, and under allow or disable, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.

Patches

Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the scram-client version:

  • Under channelBinding=require, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm.
  • After negotiation, it requires the selected mechanism to use channel binding (a -PLUS mechanism) whenever channelBinding=require is set, regardless of how negotiation resolved.

Upgrade to 42.7.12 or later.

Workarounds

No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.

If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set sslmode=verify-full with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on channelBinding=require in place of certificate verification have no equivalent workaround and should upgrade.

References

  • GHSA-p9jg-fcr6-3mhf — the related com.ongres.scram:scram-client issue (root cause of the empty channel-binding value).
  • scram-client 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3
  • pgJDBC fix in 42.7.12: commit
Severity
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.postgresql:postgresql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "42.7.4"
            },
            {
              "fixed": "42.7.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T17:47:39Z",
    "nvd_published_at": "2026-07-06T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`channelBinding=require` connections can be silently downgraded from `SCRAM-SHA-256-PLUS` (with channel binding) to plain `SCRAM-SHA-256` (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no `tls-server-end-point` channel-binding hash. Examples are `Ed25519`, `Ed448`, and post-quantum algorithms.\n\nTwo issues combine in releases 42.7.4 through 42.7.11:\n\n1. The bundled `com.ongres.scram:scram-client` (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf).\n2. pgJDBC does not enforce `channelBinding=require` where it matters. `ScramAuthenticator` checks only that the server *advertised* a `-PLUS` mechanism; it neither rejects the empty binding nor checks that the *negotiated* mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed `scram-client`, because the missing enforcement is in pgJDBC\u0027s own code.\n\nOnly connections that set `channelBinding=require` are affected. Under the default `prefer` policy, and under `allow` or `disable`, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.\n\n### Patches\n\nFixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the `scram-client` version:\n\n- Under `channelBinding=require`, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm.\n- After negotiation, it requires the selected mechanism to use channel binding (a `-PLUS` mechanism) whenever `channelBinding=require` is set, regardless of how negotiation resolved.\n\nUpgrade to 42.7.12 or later.\n\n### Workarounds\n\nNo pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.\n\nIf you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set `sslmode=verify-full` with a truststore that contains only your server\u0027s CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on `channelBinding=require` in place of certificate verification have no equivalent workaround and should upgrade.\n\n### References\n\n-  [GHSA-p9jg-fcr6-3mhf](https://github.com/ongres/scram/security/advisories/GHSA-p9jg-fcr6-3mhf) \u2014 the related `com.ongres.scram:scram-client` issue (root cause of the empty channel-binding value).\n- `scram-client` 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3\n- pgJDBC fix in 42.7.12: [commit](https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99)",
  "id": "GHSA-j92g-9f8w-j867",
  "modified": "2026-07-21T17:47:39Z",
  "published": "2026-07-21T17:47:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-j92g-9f8w-j867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54291"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgjdbc/pgjdbc/commit/77df98e4e66c12936ded3478a0954f6f580bad99"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ongres/scram/releases/tag/3.3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgjdbc/pgjdbc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms"
}

GHSA-JX4V-JF9C-3RH7

Vulnerability from github – Published: 2026-08-11 21:33 – Updated: 2026-08-11 21:33
VLAI
Details

An issue in MongoDB Server's intra-cluster connection setup could allow a party with suitable network access to influence which authentication mechanism is used when one replica set member connects to another. Under certain conditions, this could cause the cluster's shared internal credential to be transmitted in a less-protected form, potentially allowing that credential to be recovered. If recovered, the credential could be used to authenticate as the internal superuser to nodes in the deployment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-757"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T19:17:22Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in MongoDB Server\u0027s intra-cluster connection setup could allow a party with suitable network access to influence which authentication mechanism is used when one replica set member connects to another. Under certain conditions, this could cause the cluster\u0027s shared internal credential to be transmitted in a less-protected form, potentially allowing that credential to be recovered. If recovered, the credential could be used to authenticate as the internal superuser to nodes in the deployment.",
  "id": "GHSA-jx4v-jf9c-3rh7",
  "modified": "2026-08-11T21:33:06Z",
  "published": "2026-08-11T21:33:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18691"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-130264"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-220: Client-Server Protocol Manipulation

An adversary takes advantage of weaknesses in the protocol by which a client and server are communicating to perform unexpected actions. Communication protocols are necessary to transfer messages between client and server applications. Moreover, different protocols may be used for different types of interactions.

CAPEC-606: Weakening of Cellular Encryption

An attacker, with control of a Cellular Rogue Base Station or through cooperation with a Malicious Mobile Network Operator can force the mobile device (e.g., the retransmission device) to use no encryption (A5/0 mode) or to use easily breakable encryption (A5/1 or A5/2 mode).

CAPEC-620: Drop Encryption Level

An attacker forces the encryption level to be lowered, thus enabling a successful attack against the encrypted data.

← Back to the CWE list