Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not validate, or incorrectly validates, a certificate.

1917 vulnerabilities reference this CWE, most recent first.

GHSA-7943-82JG-WMW5

Vulnerability from github – Published: 2022-07-12 22:05 – Updated: 2022-07-21 15:54
VLAI
Summary
Argo CD certificate verification is skipped for connections to OIDC providers
Details

Impact

All versions of Argo CD starting with v0.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider.

(Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.)

You are impacted if 1) have SSO enabled and 2) insecure mode is not enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have not set the --dex-server flag on the API server to an HTTPS address, then certificate verification is not being skipped (because TLS is not enabled by default for the bundled Dex instance).

Argo CD sends requests to the configured OIDC provider (either the bundled Dex instance or an external provider) to 1) retrieve the OpenID configuration, 2) to retrieve the OIDC provider's key set (at the location determined by the OIDC provider's configured jwks_uri), and 3) (during an SSO login) to exchange an authorization code for a token.

(Note: Starting with v2.3.0, certificate verification is not skipped when handling an SSO login flow if 1) you are not using the bundled Dex OIDC provider and 2) you have set oidc.config.rootCA in the argocd-cm ConfigMap. Certificate verification is still skipped when verifying tokens on API calls.)

Skipping certificate verification when communicating with the OIDC provider opens Argo CD to a variety of risks. For example, if an attacker can successfully intercept, decrypt, and respond to requests bound for the configured OIDC provider (a machine-in-the-middle attack), they could theoretically issue a "valid" admin token. Verifying the OIDC provider's certificate provides an extra layer of protection against such an attack.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

  • v2.4.5
  • v2.3.6
  • v2.2.11

Note:

To preserve backwards compatibility, this patch adds a oidc.tls.insecure.skip.verify option to the argocd-cm ConfigMap. The default is "false". Before resorting to setting this, you should try to get certificate verification to work. If you are using the bundled Dex instance, user your Argo CD API server's TLS configuration since the API server acts as a reverse proxy to Dex. If you are using an external OIDC provider, set the rootCA config.

If these fail, be sure you are aware of the risks before setting oidc.tls.insecure.skip.verify: "true".

Workarounds

There is no complete workaround besides upgrading.

Partial mitigation when using an external OIDC provider

If you are using an external OIDC provider (not the bundled Dex instance), then you can mitigate the issue by setting the oidc.config.rootCA field in the argocd-cm ConfigMap. If your OIDC provider's certificate is self-signed or otherwise invalid, you must set the rootCA to a certificate that enables verification. If the OIDC provider's certificate passes without an additional root CA, then you can set oidc.config.rootCA to a bogus non-empty string such as "force cert verification". The API server will log a warning, but otherwise things should work fine.

Example:

metadata:
  name: argocd-cm
data:
  oidc.config: |
    ...
    rootCA: |
      force cert verification

This mitigation only forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls. To fully resolve the vulnerability, you must upgrade.

References

Credits

@jannfis and @crenshaw-dev discovered the vulnerability when reviewing notes from ADA Logics' security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.

For more information

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "2.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31105"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-12T22:05:11Z",
    "nvd_published_at": "2022-07-12T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAll versions of Argo CD starting with v0.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider.\n\n(Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.)\n\nYou are impacted if 1) have SSO enabled and 2) insecure mode is _not_ enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have _not_ set the `--dex-server` flag on the API server to an HTTPS address, then certificate verification is not being skipped (because [TLS is not enabled by default for the bundled Dex instance](https://github.com/argoproj/argo-cd/issues/9424)).\n\nArgo CD sends requests to the configured OIDC provider (either the bundled Dex instance or an external provider) to 1) retrieve the [OpenID configuration](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig), 2) to retrieve the OIDC provider\u0027s key set (at the location determined by the [OIDC provider\u0027s configured `jwks_uri`](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)), and 3) (during an SSO login) to exchange an authorization code for a token.\n\n(Note: Starting with v2.3.0, certificate verification is _not_ skipped when handling an SSO login flow if 1) you are not using the bundled Dex OIDC provider and 2) you have set `oidc.config.rootCA` in the `argocd-cm` ConfigMap. Certificate verification is still skipped when verifying tokens on API calls.)\n\nSkipping certificate verification when communicating with the OIDC provider opens Argo CD to a variety of risks. For example, if an attacker can successfully intercept, decrypt, and respond to requests bound for the configured OIDC provider (a machine-in-the-middle attack), they could theoretically issue a \"valid\" admin token. Verifying the OIDC provider\u0027s certificate provides an extra layer of protection against such an attack.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.4.5\n* v2.3.6\n* v2.2.11\n\n**Note:**\n\nTo preserve backwards compatibility, this patch adds a `oidc.tls.insecure.skip.verify` option to the `argocd-cm` ConfigMap. The default is `\"false\"`. Before resorting to setting this, you should try to get certificate verification to work. If you are using the bundled Dex instance, user your Argo CD API server\u0027s [TLS configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/) since the API server acts as a reverse proxy to Dex. If you are using an external OIDC provider, [set the `rootCA` config](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#configuring-a-custom-root-ca-certificate-for-communicating-with-the-oidc-provider).\n\nIf these fail, be sure you are aware of the risks before setting `oidc.tls.insecure.skip.verify: \"true\"`.\n\n### Workarounds\n\nThere is no complete workaround besides upgrading.\n\n#### Partial mitigation when using an external OIDC provider\n\nIf you are using an external OIDC provider (not the bundled Dex instance), then you can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. If your OIDC provider\u0027s certificate is self-signed or otherwise invalid, you must set the rootCA to a certificate that enables verification. If the OIDC provider\u0027s certificate passes _without_ an additional root CA, then you can set `oidc.config.rootCA` to a bogus non-empty string such as `\"force cert verification\"`. The API server will log a warning, but otherwise things should work fine.\n\nExample:\n\n```yaml\nmetadata:\n  name: argocd-cm\ndata:\n  oidc.config: |\n    ...\n    rootCA: |\n      force cert verification\n```\n\nThis mitigation _only_ forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls. To fully resolve the vulnerability, you must upgrade.\n\n### References\n\n* [Argo CD SSO configuration documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sso)\n\n### Credits\n\n@jannfis and @crenshaw-dev discovered the vulnerability when reviewing notes from ADA Logics\u0027 security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n",
  "id": "GHSA-7943-82jg-wmw5",
  "modified": "2022-07-21T15:54:19Z",
  "published": "2022-07-12T22:05:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31105"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Argo CD certificate verification is skipped for connections to OIDC providers"
}

GHSA-796P-J2GH-9M2Q

Vulnerability from github – Published: 2026-01-26 18:55 – Updated: 2026-01-29 03:22
VLAI
Summary
dcap-qvl has Missing Verification for QE Identity
Details

Impact

This vulnerability involves a critical gap in the cryptographic verification process within the dcap-qvl.

The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report.

Consequences

An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes.

Who is impacted

All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected.

Patches

The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report.

Users of the @phala/dcap-qvl-node and @phala/dcap-qvl-web packages should switch to the pure JavaScript implementation, @phala/dcap-qvl.

Workarounds

There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified.

Credit

This bug was reported by Rahul Saxena saxenism@bluethroatlabs.com.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "dcap-qvl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@phala/dcap-qvl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@phala/dcap-qvl-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@phala/dcap-qvl-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "dcap-qvl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-26T18:55:13Z",
    "nvd_published_at": "2026-01-26T22:15:55Z",
    "severity": "CRITICAL"
  },
  "details": "## Impact\nThis vulnerability involves a critical gap in the cryptographic verification process within the dcap-qvl.\n\nThe library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report.\n\n## Consequences\nAn attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes.\n\n## Who is impacted\nAll deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected.\n\n## Patches\nThe vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report.\n\nUsers of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`.\n\n## Workarounds\nThere are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified.\n\n## Credit\nThis bug was reported by Rahul Saxena \u003csaxenism@bluethroatlabs.com\u003e.",
  "id": "GHSA-796p-j2gh-9m2q",
  "modified": "2026-01-29T03:22:29Z",
  "published": "2026-01-26T18:55:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Phala-Network/dcap-qvl/security/advisories/GHSA-796p-j2gh-9m2q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22696"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Phala-Network/dcap-qvl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "dcap-qvl has Missing Verification for QE Identity"
}

GHSA-799X-QP47-8QWQ

Vulnerability from github – Published: 2026-06-01 09:31 – Updated: 2026-07-09 21:11
VLAI
Summary
Apache Airflow has no certificate validation on SMTP STARTTLS connections
Details

Apache Airflow's EmailOperator and the underlying airflow.utils.email helpers established SMTP STARTTLS connections without verifying the remote certificate when the deployment used [email] smtp_starttls=True without [email] smtp_ssl. An attacker positioned between the worker and the configured SMTP server (network MITM — typical hostile-network attack-surface for environments where the SMTP relay sits outside the worker's trust boundary) could present a self-signed certificate, have the worker complete the STARTTLS handshake silently, and capture the SMTP AUTH credentials and message contents the worker forwarded.

This CVE covers the core apache-airflow side of the same root cause already covered for the SMTP provider by CVE-2026-41016 (published 2026-04-27, covering apache-airflow-providers-smtp). Users who already applied the SMTP-provider fix from CVE-2026-41016 should additionally upgrade apache-airflow to 3.2.2 or later to cover the core-side path through airflow.utils.email. Affects deployments configured with smtp_starttls=True and smtp_ssl=False where the SMTP relay is reachable across a less-trusted network segment than the worker.

Users are advised to upgrade to apache-airflow 3.2.2 or later.

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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T21:11:45Z",
    "nvd_published_at": "2026-06-01T09:16:20Z",
    "severity": "MODERATE"
  },
  "details": "Apache Airflow\u0027s EmailOperator and the underlying `airflow.utils.email` helpers established SMTP STARTTLS connections without verifying the remote certificate when the deployment used `[email] smtp_starttls=True` without `[email] smtp_ssl`. An attacker positioned between the worker and the configured SMTP server (network MITM \u2014 typical hostile-network attack-surface for environments where the SMTP relay sits outside the worker\u0027s trust boundary) could present a self-signed certificate, have the worker complete the STARTTLS handshake silently, and capture the SMTP AUTH credentials and message contents the worker forwarded.\n\nThis CVE covers the **core apache-airflow side** of the same root cause already covered for the SMTP provider by `CVE-2026-41016` (published 2026-04-27, covering `apache-airflow-providers-smtp`). Users who already applied the SMTP-provider fix from CVE-2026-41016 should additionally upgrade `apache-airflow` to 3.2.2 or later to cover the core-side path through `airflow.utils.email`. Affects deployments configured with `smtp_starttls=True` and `smtp_ssl=False` where the SMTP relay is reachable across a less-trusted network segment than the worker.\n\nUsers are advised to upgrade to `apache-airflow` 3.2.2 or later.",
  "id": "GHSA-799x-qp47-8qwq",
  "modified": "2026-07-09T21:11:45Z",
  "published": "2026-06-01T09:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49267"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/65346"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/6v2ds757000msmjmovnnqryqzks83ps0"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Airflow has no certificate validation on SMTP STARTTLS connections"
}

GHSA-7C2M-VWXW-5QWW

Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2023-02-15 22:08
VLAI
Summary
Improper Certificate Validation in Apache Netbeans
Details

The "Apache NetBeans" autoupdate system does not validate SSL certificates and hostnames for https based downloads. This allows an attacker to intercept downloads of autoupdates and modify the download, potentially injecting malicious code. "Apache NetBeans" versions up to and including 11.2 are affected by this vulnerability. NetBeans releases before the Apache transition started may also be affected.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.codehaus.mevenide:netbeans"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-17560"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-14T22:26:00Z",
    "nvd_published_at": "2020-03-30T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The \"Apache NetBeans\" autoupdate system does not validate SSL certificates and hostnames for https based downloads. This allows an attacker to intercept downloads of autoupdates and modify the download, potentially injecting malicious code. \"Apache NetBeans\" versions up to and including 11.2 are affected by this vulnerability. NetBeans releases before the Apache transition started may also be affected.",
  "id": "GHSA-7c2m-vwxw-5qww",
  "modified": "2023-02-15T22:08:43Z",
  "published": "2022-05-24T22:28:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17560"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r354d7654efa1050539fe56a3257696d1faeea4f3f9b633c29ec89609%40%3Cdev.netbeans.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Certificate Validation in Apache Netbeans"
}

GHSA-7C9H-GJ9V-X83C

Vulnerability from github – Published: 2022-04-21 01:48 – Updated: 2022-04-21 01:48
VLAI
Details

A flaw in Mozilla's embedded certificate code might allow web sites to install root certificates on devices without user approval.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-5967"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-17T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw in Mozilla\u0027s embedded certificate code might allow web sites to install root certificates on devices without user approval.",
  "id": "GHSA-7c9h-gj9v-x83c",
  "modified": "2022-04-21T01:48:50Z",
  "published": "2022-04-21T01:48:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5967"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla-dev.allizom.org/show_bug.cgi?id=406724"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7CCV-RP6M-RFFR

Vulnerability from github – Published: 2026-04-21 17:26 – Updated: 2026-04-27 16:35
VLAI
Summary
OpenBao's Certificate Authentication Allows Token Renewal With Different Certificate
Details

Background

OpenBao's Certificate authentication method, when a token renewal is requested and disable_binding=true is set, attempts to verify the current request's presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information.

Impact

Due to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor.

This vulnerability is originally from HashiCorp Vault.

Patches

This has been addressed in v2.5.3.

Workarounds

Ensure privileged roles are tightly scoped to single certificates.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260420160924-abe84e1af4c3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T17:26:42Z",
    "nvd_published_at": "2026-04-21T01:16:06Z",
    "severity": "LOW"
  },
  "details": "### Background\n\nOpenBao\u0027s Certificate authentication method, when a token renewal is requested and `disable_binding=true` is set, attempts to verify the current request\u0027s presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information.\n\n### Impact\n\nDue to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor. \n\nThis vulnerability is originally from HashiCorp Vault.\n\n### Patches\n\nThis has been addressed in v2.5.3.\n\n### Workarounds\n\nEnsure privileged roles are tightly scoped to single certificates.",
  "id": "GHSA-7ccv-rp6m-rffr",
  "modified": "2026-04-27T16:35:57Z",
  "published": "2026-04-21T17:26:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/security/advisories/GHSA-7ccv-rp6m-rffr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39388"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/pull/2932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/9ab7a066826cc544c30e8b203f8f472076f366e1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openbao/openbao"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/releases/tag/v2.5.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenBao\u0027s Certificate Authentication Allows Token Renewal With Different Certificate"
}

GHSA-7CP4-W7Q7-W394

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

curl before 7.53.0 has an incorrect TLS Certificate Status Request extension feature that asks for a fresh proof of the server's certificate's validity in the code that checks for a test success or failure. It ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. This flaw also exists in the command line tool (--cert-status).

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-2629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-27T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "curl before 7.53.0 has an incorrect TLS Certificate Status Request extension feature that asks for a fresh proof of the server\u0027s certificate\u0027s validity in the code that checks for a test success or failure. It ends up always thinking there\u0027s valid proof, even when there is none or if the server doesn\u0027t support the TLS extension in question. This could lead to users not detecting when a server\u0027s certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. This flaw also exists in the command line tool (--cert-status).",
  "id": "GHSA-7cp4-w7q7-w394",
  "modified": "2022-05-13T01:36:53Z",
  "published": "2022-05-13T01:36:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2629"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2629"
    },
    {
      "type": "WEB",
      "url": "https://curl.haxx.se/docs/adv_20170222.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201703-04"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/tns-2017-09"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96382"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037871"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7F2C-FJ5R-9F75

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

Missing validation of server certificates for out-going connections in Nextcloud Social < 0.4.0 allowed a man-in-the-middle attack.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-8279"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-19T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "Missing validation of server certificates for out-going connections in Nextcloud Social \u003c 0.4.0 allowed a man-in-the-middle attack.",
  "id": "GHSA-7f2c-fj5r-9f75",
  "modified": "2022-05-24T17:34:46Z",
  "published": "2022-05-24T17:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8279"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/915585"
    },
    {
      "type": "WEB",
      "url": "https://nextcloud.com/security/advisory/?id=NC-SA-2020-043"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7F2C-VP52-GMFW

Vulnerability from github – Published: 2022-05-17 03:45 – Updated: 2024-09-27 18:23
VLAI
Summary
OpenStack keystonemiddleware does not verify certificate
Details

OpenStack keystonemiddleware (formerly python-keystoneclient) 0.x before 0.11.0 and 1.x before 1.2.0 disables certification verification when the "insecure" option is set in a paste configuration (paste.ini) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystonemiddleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystonemiddleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-keystoneclient"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-keystoneclient"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2014-7144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-16T23:05:33Z",
    "nvd_published_at": "2014-10-02T14:55:00Z",
    "severity": "HIGH"
  },
  "details": "OpenStack keystonemiddleware (formerly python-keystoneclient) 0.x before 0.11.0 and 1.x before 1.2.0 disables certification verification when the \"insecure\" option is set in a paste configuration (`paste.ini`) file regardless of the value, which allows remote attackers to conduct man-in-the-middle attacks via a crafted certificate.",
  "id": "GHSA-7f2c-vp52-gmfw",
  "modified": "2024-09-27T18:23:46Z",
  "published": "2022-05-17T03:45:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-7144"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/python-keystoneclient/+bug/1353315"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/ossa/blob/23e15de721f4a6890374a231d93524e02965a97f/ossa/OSSA-2014-030.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystonemiddleware/PYSEC-2014-26.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/python-keystoneclient/PYSEC-2014-71.yaml"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200228053850/http://www.securityfocus.com/bid/69864"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200228060511/https://www.securityfocus.com/bid/69864"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-1783.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-1784.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2015-0020.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2014/09/25/51"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2705-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenStack keystonemiddleware does not verify certificate"
}

GHSA-7F3M-MQM5-5X2C

Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-07-14 21:31
VLAI
Details

If a user visited a webpage with an invalid TLS certificate, and granted an exception, the webpage was able to provide a WebAuthn challenge that the user would be prompted to complete. This is in violation of the WebAuthN spec which requires "a secure transport established without errors". This vulnerability affects Firefox < 140.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-6433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-24T13:15:24Z",
    "severity": "CRITICAL"
  },
  "details": "If a user visited a webpage with an invalid TLS certificate, and granted an exception, the webpage was able to provide a WebAuthn challenge that the user would be prompted to complete.  This is in violation of the WebAuthN spec which requires \"a secure transport established without errors\". This vulnerability affects Firefox \u003c 140.",
  "id": "GHSA-7f3m-mqm5-5x2c",
  "modified": "2025-07-14T21:31:44Z",
  "published": "2025-06-26T21:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6433"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1954033"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-51"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-54"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.

← Back to the CWE list