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.

2268 vulnerabilities reference this CWE, most recent first.

GHSA-8988-9CW3-XX77

Vulnerability from github – Published: 2026-09-30 14:46 – Updated: 2026-09-30 14:46
VLAI
Summary
urllib3: HTTPS proxy TLS configuration may be ignored or overridden
Details

Impact

urllib3 supports configuring TLS independently for an HTTPS proxy and the target server.

proxy_ssl_context, proxy_assert_hostname, and proxy_assert_fingerprint configure the TLS connection to the proxy. ssl_context and the other target-specific TLS parameters configure the connection to the target server.

In urllib3 versions 1.26.0 through 2.7.0, these configurations were not consistently separated. Depending on the proxy mode, urllib3 could:

  1. Ignore proxy_ssl_context and use the target server's SSL context for the TLS connection to an HTTPS forwarding proxy.
  2. Override the HTTPS proxy's certificate-verification policy with the target server's certificate-verification policy.
  3. Apply target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials to the TLS connection to an HTTPS forwarding proxy.

In particular, configuring cert_reqs="CERT_NONE" for a target server could overwrite the verify_mode of the SSL context configured for the HTTPS proxy. This modification occurred in place and persisted on the context object, potentially disabling proxy certificate verification for later connections that reused the same context.

An attacker able to intercept the connection to an HTTPS proxy may be able to impersonate the proxy when the effective proxy TLS configuration disables certificate verification or otherwise accepts the attacker's certificate. This may occur, for example, when the target server's trust or identity policy is incorrectly applied to the proxy connection.

When HTTPS forwarding is enabled, an impersonated proxy can observe or modify forwarded requests and responses, potentially exposing credentials, authentication tokens, request bodies, response data, and other sensitive information.

A TLS client certificate intended for the target server may also be presented to the proxy or to an attacker impersonating it. This can disclose the client's identity and provide proof of possession of the corresponding private key. The private key itself is not transmitted during the TLS handshake.

In CONNECT tunneling mode, impersonating the HTTPS proxy does not by itself defeat the separate end-to-end TLS connection between the client and the target server.

Affected Usages

Code using urllib3 versions 1.26.0 through 2.7.0 may be affected in any of the following cases.

1. The target SSL context is used for an HTTPS forwarding proxy

HTTPS requests are forwarded through an HTTPS proxy with use_forwarding_for_https=True, and proxy_ssl_context is configured for the proxy.

urllib3 may ignore proxy_ssl_context and use the target server's ssl_context for the proxy TLS handshake. The proxy may therefore be verified using the target server's trust and certificate policy instead of the policy explicitly configured for the proxy.

2. The target verification policy overrides the proxy policy

An HTTPS proxy is configured with proxy_ssl_context, while the target server uses a different certificate-verification policy.

urllib3 may apply the target server's cert_reqs value to the proxy SSL context. For example, setting cert_reqs="CERT_NONE" for the target server may also disable certificate verification for the HTTPS proxy, even when proxy_ssl_context was configured to require verification.

This issue can affect the TLS connection to an HTTPS proxy in both forwarding and CONNECT tunneling configurations.

3. A mutated proxy SSL context is reused

The same SSL context is reused as proxy_ssl_context across multiple connections, and certificate verification is disabled for one target server.

urllib3 may modify the proxy SSL context's verify_mode in place. Later connections that reuse the same context may therefore connect to the HTTPS proxy without certificate verification.

4. Target-specific TLS identity or credentials are applied to the proxy

HTTPS requests are forwarded through an HTTPS proxy with use_forwarding_for_https=True, and target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials are configured.

urllib3 may apply these target-specific settings to the proxy TLS handshake. This may cause urllib3 to:

  • send SNI intended for the target server to the proxy;
  • verify the proxy using a hostname or certificate fingerprint intended for the target server; or
  • present a TLS client certificate intended for the target server to the proxy.

Code connecting through a plain HTTP proxy does not establish a TLS connection to the proxy and is not affected by this issue.

Remediation

Upgrade to urllib3 2.8.0 or later.

urllib3 2.8.0 independently applies the explicitly configured proxy_ssl_context and proxy-specific certificate assertions to the HTTPS proxy connection. Target-specific SNI, certificate assertions, and TLS client certificate parameters are no longer applied to the HTTPS proxy handshake.

For backward compatibility, when an HTTPS proxy is used with use_forwarding_for_https=True and proxy_ssl_context is not provided, urllib3 2.8.0 continues to use ssl_context for the TLS connection to the proxy. This configuration emits a FutureWarning. In urllib3 3.0, passing ssl_context with use_forwarding_for_https=True for an HTTPS proxy will raise an error. Applications should use proxy_ssl_context to configure TLS for an HTTPS forwarding proxy.

The fixes were implemented in commits b6447295fff7b38fdffc67e0df9712d60cef3cc3 and 07408cec79d1856d81bb42c74a904a24fdb9e465.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.26.0"
            },
            {
              "fixed": "2.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-97687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-440"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T14:46:04Z",
    "nvd_published_at": "2026-09-29T16:17:18Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nurllib3 supports configuring TLS independently for an HTTPS proxy and the target server.\n\n`proxy_ssl_context`, `proxy_assert_hostname`, and `proxy_assert_fingerprint` configure the TLS connection to the proxy. `ssl_context` and the other target-specific TLS parameters configure the connection to the target server.\n\nIn urllib3 versions 1.26.0 through 2.7.0, these configurations were not consistently separated. Depending on the proxy mode, urllib3 could:\n\n1. Ignore `proxy_ssl_context` and use the target server\u0027s SSL context for the TLS connection to an HTTPS forwarding proxy.\n2. Override the HTTPS proxy\u0027s certificate-verification policy with the target server\u0027s certificate-verification policy.\n3. Apply target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials to the TLS connection to an HTTPS forwarding proxy.\n\nIn particular, configuring `cert_reqs=\"CERT_NONE\"` for a target server could overwrite the `verify_mode` of the SSL context configured for the HTTPS proxy. This modification occurred in place and persisted on the context object, potentially disabling proxy certificate verification for later connections that reused the same context.\n\nAn attacker able to intercept the connection to an HTTPS proxy may be able to impersonate the proxy when the effective proxy TLS configuration disables certificate verification or otherwise accepts the attacker\u0027s certificate. This may occur, for example, when the target server\u0027s trust or identity policy is incorrectly applied to the proxy connection.\n\nWhen HTTPS forwarding is enabled, an impersonated proxy can observe or modify forwarded requests and responses, potentially exposing credentials, authentication tokens, request bodies, response data, and other sensitive information.\n\nA TLS client certificate intended for the target server may also be presented to the proxy or to an attacker impersonating it. This can disclose the client\u0027s identity and provide proof of possession of the corresponding private key. The private key itself is not transmitted during the TLS handshake.\n\nIn CONNECT tunneling mode, impersonating the HTTPS proxy does not by itself defeat the separate end-to-end TLS connection between the client and the target server.\n\n## Affected Usages\n\nCode using urllib3 versions 1.26.0 through 2.7.0 may be affected in any of the following cases.\n\n### 1. The target SSL context is used for an HTTPS forwarding proxy\n\nHTTPS requests are forwarded through an HTTPS proxy with `use_forwarding_for_https=True`, and `proxy_ssl_context` is configured for the proxy.\n\nurllib3 may ignore `proxy_ssl_context` and use the target server\u0027s `ssl_context` for the proxy TLS handshake. The proxy may therefore be verified using the target server\u0027s trust and certificate policy instead of the policy explicitly configured for the proxy.\n\n### 2. The target verification policy overrides the proxy policy\n\nAn HTTPS proxy is configured with `proxy_ssl_context`, while the target server uses a different certificate-verification policy.\n\nurllib3 may apply the target server\u0027s `cert_reqs` value to the proxy SSL context. For example, setting `cert_reqs=\"CERT_NONE\"` for the target server may also disable certificate verification for the HTTPS proxy, even when `proxy_ssl_context` was configured to require verification.\n\nThis issue can affect the TLS connection to an HTTPS proxy in both forwarding and CONNECT tunneling configurations.\n\n### 3. A mutated proxy SSL context is reused\n\nThe same SSL context is reused as `proxy_ssl_context` across multiple connections, and certificate verification is disabled for one target server.\n\nurllib3 may modify the proxy SSL context\u0027s `verify_mode` in place. Later connections that reuse the same context may therefore connect to the HTTPS proxy without certificate verification.\n\n### 4. Target-specific TLS identity or credentials are applied to the proxy\n\nHTTPS requests are forwarded through an HTTPS proxy with `use_forwarding_for_https=True`, and target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials are configured.\n\nurllib3 may apply these target-specific settings to the proxy TLS handshake. This may cause urllib3 to:\n\n- send SNI intended for the target server to the proxy;\n- verify the proxy using a hostname or certificate fingerprint intended for the target server; or\n- present a TLS client certificate intended for the target server to the proxy.\n\nCode connecting through a plain HTTP proxy does not establish a TLS connection to the proxy and is not affected by this issue.\n\n## Remediation\n\nUpgrade to urllib3 2.8.0 or later.\n\nurllib3 2.8.0 independently applies the explicitly configured `proxy_ssl_context` and proxy-specific certificate assertions to the HTTPS proxy connection. Target-specific SNI, certificate assertions, and TLS client certificate parameters are no longer applied to the HTTPS proxy handshake.\n\nFor backward compatibility, when an HTTPS proxy is used with `use_forwarding_for_https=True` and `proxy_ssl_context` is not provided, urllib3 2.8.0 continues to use `ssl_context` for the TLS connection to the proxy. This configuration emits a `FutureWarning`. In urllib3 3.0, passing `ssl_context` with `use_forwarding_for_https=True` for an HTTPS proxy will raise an error. Applications should use `proxy_ssl_context` to configure TLS for an HTTPS forwarding proxy.\n\nThe fixes were implemented in commits b6447295fff7b38fdffc67e0df9712d60cef3cc3 and 07408cec79d1856d81bb42c74a904a24fdb9e465.",
  "id": "GHSA-8988-9cw3-xx77",
  "modified": "2026-09-30T14:46:04Z",
  "published": "2026-09-30T14:46:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/security/advisories/GHSA-8988-9cw3-xx77"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97687"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/pull/5093"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/commit/07408cec79d1856d81bb42c74a904a24fdb9e465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/commit/b6447295fff7b38fdffc67e0df9712d60cef3cc3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/releases/tag/2.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "urllib3: HTTPS proxy TLS configuration may be ignored or overridden"
}

GHSA-89MF-FVH4-9CGQ

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

EMC RSA BSAFE Micro Edition Suite (MES) 4.0.x before 4.0.8 and 4.1.x before 4.1.3, RSA BSAFE Crypto-J before 6.2, RSA BSAFE SSL-J before 6.2, and RSA BSAFE SSL-C 2.8.9 and earlier do not enforce certain constraints on certificate data, which allows remote attackers to defeat a fingerprint-based certificate-blacklist protection mechanism by including crafted data within a certificate's unsigned portion, a similar issue to CVE-2014-8275.

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

{
  "affected": [],
  "aliases": [
    "CVE-2015-0534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-08-20T10:59:00Z",
    "severity": "HIGH"
  },
  "details": "EMC RSA BSAFE Micro Edition Suite (MES) 4.0.x before 4.0.8 and 4.1.x before 4.1.3, RSA BSAFE Crypto-J before 6.2, RSA BSAFE SSL-J before 6.2, and RSA BSAFE SSL-C 2.8.9 and earlier do not enforce certain constraints on certificate data, which allows remote attackers to defeat a fingerprint-based certificate-blacklist protection mechanism by including crafted data within a certificate\u0027s unsigned portion, a similar issue to CVE-2014-8275.",
  "id": "GHSA-89mf-fvh4-9cgq",
  "modified": "2022-05-13T01:04:38Z",
  "published": "2022-05-13T01:04:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0534"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/bugtraq/2015/Aug/84"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/76377"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1033297"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1033298"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89XV-5CJ4-39M4

Vulnerability from github – Published: 2026-06-08 12:30 – Updated: 2026-06-08 12:30
VLAI
Details

A weakness in the certificate validation logic of the deprecated IKEv1 key exchange may allow an unauthenticated attacker positioned as a man-in-the-middle to bypass certificate validation in VPN site-to-site connections that use certificate-based authentication. Successful exploitation could allow interception or modification of traffic traversing the VPN tunnel.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-50752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-08T12:16:32Z",
    "severity": "HIGH"
  },
  "details": "A weakness in the certificate validation logic of the deprecated IKEv1 key exchange may allow an unauthenticated attacker positioned as a man-in-the-middle to bypass certificate validation in VPN site-to-site connections that use certificate-based authentication. Successful exploitation could allow interception or modification of traffic traversing the VPN tunnel.",
  "id": "GHSA-89xv-5cj4-39m4",
  "modified": "2026-06-08T12:30:29Z",
  "published": "2026-06-08T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50752"
    },
    {
      "type": "WEB",
      "url": "https://support.checkpoint.com/results/sk/sk185035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CGH-W254-67RW

Vulnerability from github – Published: 2026-01-28 21:31 – Updated: 2026-01-29 21:30
VLAI
Details

FunJSQ, a third-party module integrated on some NETGEAR routers and Orbi WiFi Systems, does not properly validate TLS certificates when downloading update packages through its auto-update mechanism. An attacker (suitably positioned on the network) could intercept the update request and deliver a malicious update package in order to gain arbitrary code execution on affected devices. This affects R6230 before 1.1.0.112, R6260 before 1.1.0.88, R7000 before 1.0.11.134, R8900 before 1.0.5.42, R9000 before 1.0.5.42, and XR300 before 1.0.3.72 and Orbi RBR20 before 2.7.2.26, RBR50 before 2.7.4.26, RBS20 before 2.7.2.26, and RBS50 before 2.7.4.26.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-40620"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-28T19:16:19Z",
    "severity": "HIGH"
  },
  "details": "FunJSQ, a third-party module integrated on some NETGEAR routers and Orbi WiFi Systems, does not properly validate TLS certificates when downloading update packages through its auto-update mechanism. An attacker (suitably positioned on the network) could intercept the update request and deliver a malicious update package in order to gain arbitrary code execution on affected devices. This affects R6230 before 1.1.0.112, R6260 before 1.1.0.88, R7000 before 1.0.11.134, R8900 before 1.0.5.42, R9000 before 1.0.5.42, and XR300 before 1.0.3.72 and Orbi RBR20 before 2.7.2.26, RBR50 before 2.7.4.26, RBS20 before 2.7.2.26, and RBS50 before 2.7.4.26.",
  "id": "GHSA-8cgh-w254-67rw",
  "modified": "2026-01-29T21:30:29Z",
  "published": "2026-01-28T21:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40620"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000065132/Security-Advisory-for-Vulnerabilities-in-FunJSQ-on-Some-Routers-and-Orbi-WiFi-Systems-PSV-2022-0117"
    },
    {
      "type": "WEB",
      "url": "https://www.onekey.com/resource/security-advisory-netgear-routers-funjsq-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CGW-QH4H-CF58

Vulnerability from github – Published: 2024-08-13 21:31 – Updated: 2024-08-13 21:31
VLAI
Details

Improper certificate validation in Ivanti ITSM on-prem and Neurons for ITSM Versions 2023.4 and earlier allows a remote attacker in a MITM position to craft a token that would allow access to ITSM as any user.

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": [],
  "aliases": [
    "CVE-2024-7570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T19:15:16Z",
    "severity": "HIGH"
  },
  "details": "Improper certificate validation in Ivanti ITSM on-prem and Neurons for ITSM Versions 2023.4 and earlier allows a remote attacker in a MITM position to craft a token that would allow access to ITSM as any user.",
  "id": "GHSA-8cgw-qh4h-cf58",
  "modified": "2024-08-13T21:31:55Z",
  "published": "2024-08-13T21:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7570"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Neurons-for-ITSM-CVE-2024-7569-CVE-2024-7570"
    }
  ],
  "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"
    }
  ]
}

GHSA-8F23-48GC-8RGJ

Vulnerability from github – Published: 2022-05-17 00:36 – Updated: 2025-04-20 03:45
VLAI
Details

A vulnerability exists in Schneider Electric's PowerSCADA Anywhere v1.0 redistributed with PowerSCADA Expert v8.1 and PowerSCADA Expert v8.2 and Citect Anywhere version 1.0 that allows the use of outdated cipher suites and improper verification of peer SSL Certificate.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-7971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-26T01:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability exists in Schneider Electric\u0027s PowerSCADA Anywhere v1.0 redistributed with PowerSCADA Expert v8.1 and PowerSCADA Expert v8.2 and Citect Anywhere version 1.0 that allows the use of outdated cipher suites and improper verification of peer SSL Certificate.",
  "id": "GHSA-8f23-48gc-8rgj",
  "modified": "2025-04-20T03:45:53Z",
  "published": "2022-05-17T00:36:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7971"
    },
    {
      "type": "WEB",
      "url": "https://www.citect.schneider-electric.com/safety-and-security-central/36-security-notifications/9071-security-notification-citect-anywhere"
    },
    {
      "type": "WEB",
      "url": "http://www.schneider-electric.com/en/download/document/SEVD-2017-173-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99913"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8F6J-263M-G72X

Vulnerability from github – Published: 2026-07-13 23:49 – Updated: 2026-07-13 23:49
VLAI
Summary
Apple App Store Server Python Library: SignedDataVerifier accepts stale OCSP GOOD responses and can bypass certificate revocation checks
Details

Summary

SignedDataVerifier attempts to perform online revocation checking when enable_online_checks=True, but its OCSP validation logic accepts stale GOOD responses as valid indefinitely. In appstoreserverlibrary/signed_data_verifier.py, _ChainVerifier.check_ocsp_status() verifies the OCSP response signature and CertID match, but never validates the freshness window carried by producedAt, thisUpdate, or nextUpdate.

As a result, a previously valid signed OCSP GOOD response can be replayed after it is expired, and the library will still treat the certificate as good. If an App Store signing certificate or intermediate is ever revoked, applications using this library with online checks enabled can continue accepting JWS objects signed with the revoked key as long as a stale signed OCSP response is replayed.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "app-store-server-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-299"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T23:49:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n`SignedDataVerifier` attempts to perform online revocation checking when `enable_online_checks=True`, but its OCSP validation logic accepts stale `GOOD` responses as valid indefinitely. In `appstoreserverlibrary/signed_data_verifier.py`, `_ChainVerifier.check_ocsp_status()` verifies the OCSP response signature and CertID match, but never validates the freshness window carried by `producedAt`, `thisUpdate`, or `nextUpdate`.\n\nAs a result, a previously valid signed OCSP `GOOD` response can be replayed after it is expired, and the library will still treat the certificate as good. If an App Store signing certificate or intermediate is ever revoked, applications using this library with online checks enabled can continue accepting JWS objects signed with the revoked key as long as a stale signed OCSP response is replayed.",
  "id": "GHSA-8f6j-263m-g72x",
  "modified": "2026-07-13T23:49:14Z",
  "published": "2026-07-13T23:49:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apple/app-store-server-library-python/security/advisories/GHSA-8f6j-263m-g72x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apple/app-store-server-library-python"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apple App Store Server Python Library: SignedDataVerifier accepts stale OCSP GOOD responses and can bypass certificate revocation checks"
}

GHSA-8F6W-7M2H-MFWG

Vulnerability from github – Published: 2026-10-04 18:30 – Updated: 2026-10-04 18:30
VLAI
Details

gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go, allowing man-in-the-middle attackers to impersonate payment provider APIs. Attackers can present any certificate to read merchant credentials, signatures and transaction data, and modify payment, refund and order query responses.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-105218"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-04T18:16:34Z",
    "severity": "CRITICAL"
  },
  "details": "gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go, allowing man-in-the-middle attackers to impersonate payment provider APIs. Attackers can present any certificate to read merchant credentials, signatures and transaction data, and modify payment, refund and order query responses.",
  "id": "GHSA-8f6w-7m2h-mfwg",
  "modified": "2026-10-04T18:30:21Z",
  "published": "2026-10-04T18:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105218"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-pay/gopay/issues/540"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-pay/gopay/commit/f6df04fd4f64a2ad2c303ba063b6502bfdd259fd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-pay/gopay"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-pay/gopay/blob/v1.5.118/pkg/xhttp/client.go#L15-L37"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/gopay-before-1.5.119-disabled-tls-certificate-verification-in-xhttp-client"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/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-8F8H-RQ9J-VXQG

Vulnerability from github – Published: 2022-04-29 01:27 – Updated: 2022-04-29 01:27
VLAI
Details

X509TrustManager in (1) Java Secure Socket Extension (JSSE) in SDK and JRE 1.4.0 through 1.4.0_01, (2) JSSE before 1.0.3, (3) Java Plug-in SDK and JRE 1.3.0 through 1.4.1, and (4) Java Web Start 1.0 through 1.2 incorrectly calls the isClientTrusted method when determining server trust, which results in improper validation of digital certificate and allows remote attackers to (1) falsely authenticate peers for SSL or (2) incorrectly validate signed JAR files.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2003-1229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2003-12-31T05:00:00Z",
    "severity": "HIGH"
  },
  "details": "X509TrustManager in (1) Java Secure Socket Extension (JSSE) in SDK and JRE 1.4.0 through 1.4.0_01, (2) JSSE before 1.0.3, (3) Java Plug-in SDK and JRE 1.3.0 through 1.4.1, and (4) Java Web Start 1.0 through 1.2 incorrectly calls the isClientTrusted method when determining server trust, which results in improper validation of digital certificate and allows remote attackers to (1) falsely authenticate peers for SSL or (2) incorrectly validate signed JAR files.",
  "id": "GHSA-8f8h-rq9j-vxqg",
  "modified": "2022-04-29T01:27:44Z",
  "published": "2022-04-29T01:27:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2003-1229"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/11182"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5883"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/bugtraq/2003-01/0334.html"
    },
    {
      "type": "WEB",
      "url": "http://java.sun.com/products/jsse/CHANGES.txt"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/7943"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1006007"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1007483"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-50081-1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/6682"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1006001"
    },
    {
      "type": "WEB",
      "url": "http://www1.itrc.hp.com/service/cki/docDisplay.do?docId=HPSBUX0301-239"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8G5P-JXP9-457C

Vulnerability from github – Published: 2026-06-10 15:31 – Updated: 2026-08-14 19:20
VLAI
Summary
Assisted Migration Agent: Hardcoded insecure Transport Layer Security (TLS) connections during vCenter communication
Details

A flaw was found in assisted-migration-agent. The application hardcodes insecure Transport Layer Security (TLS) connections when communicating with vCenter. This vulnerability allows a Man-in-the-Middle (MITM) attacker to intercept and harvest vCenter administrator credentials. This can lead to unauthorized access to vCenter.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubev2v/assisted-migration-agent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-14T19:20:31Z",
    "nvd_published_at": "2026-06-10T15:16:42Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in assisted-migration-agent. The application hardcodes insecure Transport Layer Security (TLS) connections when communicating with vCenter. This vulnerability allows a Man-in-the-Middle (MITM) attacker to intercept and harvest vCenter administrator credentials. This can lead to unauthorized access to vCenter.",
  "id": "GHSA-8g5p-jxp9-457c",
  "modified": "2026-08-14T19:20:31Z",
  "published": "2026-06-10T15:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53475"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubev2v/assisted-migration-agent/pull/268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubev2v/assisted-migration-agent/commit/b940fec9f5032a0801e994054d30e81d64b2942a"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-53475"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487232"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubev2v/assisted-migration-agent"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Assisted Migration Agent: Hardcoded insecure Transport Layer Security (TLS) connections during vCenter communication"
}
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