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.

1903 vulnerabilities reference this CWE, most recent first.

GHSA-WFQV-66VQ-46RM

Vulnerability from github – Published: 2026-02-19 22:09 – Updated: 2026-02-20 16:43
VLAI
Summary
Cosign considered signatures valid with expired intermediate certificates when transparency log verification is skipped
Details

Summary

When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.

Impact

No impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.

Workarounds

Upgrade to the latest release, or verify the certificate chain out of band.

Example to Reproduce

  • Root CA certificate is valid from 12pm-2pm
  • Intermediate CA certificate is valid from 12:30pm-1:30pm
  • Leaf certificate is valid from 1pm-3pm - Note that this is unlikely to happen in practice, as a CA shouldn't issue a certificate that would be valid after the issuing CA certificate expires
  • Signature generated at 2:30pm with a signed timestamp
  • During verification, the leaf certificate's not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates
  • The timestamp's time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf
  • Even though the root and intermediate would be expired at 2:30pm, verification succeeds
Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24122"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T22:09:12Z",
    "nvd_published_at": "2026-02-19T23:16:24Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nWhen verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate\u0027s \"not before\" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate\u0027s validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.\n\n## Impact\n\nNo impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.\n\n## Workarounds\n\nUpgrade to the latest release, or verify the certificate chain out of band.\n\n## Example to Reproduce\n\n* Root CA certificate is valid from 12pm-2pm\n* Intermediate CA certificate is valid from 12:30pm-1:30pm\n* Leaf certificate is valid from 1pm-3pm - **Note that this is unlikely to happen in practice**, as a CA shouldn\u0027t issue a certificate that would be valid after the issuing CA certificate expires\n* Signature generated at 2:30pm with a signed timestamp\n* During verification, the leaf certificate\u0027s not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates\n* The timestamp\u0027s time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf\n* Even though the root and intermediate would be expired at 2:30pm, verification succeeds",
  "id": "GHSA-wfqv-66vq-46rm",
  "modified": "2026-02-20T16:43:55Z",
  "published": "2026-02-19T22:09:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/security/advisories/GHSA-wfqv-66vq-46rm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24122"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/commit/3c9a7363f563db76d78e2de2cabd945450f3781e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/cosign"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/releases/tag/v3.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cosign considered signatures valid with expired intermediate certificates when transparency log verification is skipped"
}

GHSA-WFR5-454P-MJC2

Vulnerability from github – Published: 2026-05-08 20:48 – Updated: 2026-06-08 23:34
VLAI
Summary
OpenTelemetry.Exporter.Instana bypasses TLS certificate validation when a proxy is configured
Details

Summary

The OpenTelemetry.Exporter.Instana NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the INSTANA_ENDPOINT_PROXY environment variable.

If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.

Details

The Transport.ConfigureBackendClient() method creates an HttpClient instance that completely disables TLS server certificate validation if the INSTANA_ENDPOINT_PROXY is configured with a valid proxy URL with no ability to re-enable it.

Impact

If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for INSTANA_ENDPOINT_PROXY then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.

Mitigation

The proxy configured by the INSTANA_ENDPOINT_PROXY environment variable must be malicious or be possible to be subject to a MitM attack.

Workarounds

Do not configure the INSTANA_ENDPOINT_PROXY environment variable.

Remediation

#4153 refactors HttpClient creation so that TLS certificate validation is no longer disabled by default when using a proxy.

In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:

builder.AddInstanaExporter((options) =>
{
    options.HttpClientFactory = () =>
    {
        var handler = new HttpClientHandler()
        {
#if NET
            ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
#else
            ServerCertificateCustomValidationCallback = static (_, _, _, _) => true,
#endif
        };
        return new HttpClient(handler, disposeHandler: true);
    };
});

Resources

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.7"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Exporter.Instana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T20:48:02Z",
    "nvd_published_at": "2026-05-26T22:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `OpenTelemetry.Exporter.Instana` NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the `INSTANA_ENDPOINT_PROXY` environment variable.\n\nIf a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker.\n\n### Details\n\nThe [`Transport.ConfigureBackendClient()`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/b53b6a74fde21a4cee344e584b51a0fe5bf1f337/src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs#L132-L158) method creates an `HttpClient` instance that completely disables TLS server certificate validation if the `INSTANA_ENDPOINT_PROXY` is configured with a valid proxy URL with no ability to re-enable it.\n\n### Impact\n\nIf the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process\u0027 configuration to be changed to add an attacker-provided value for `INSTANA_ENDPOINT_PROXY` then all Instana telemetry could be read by an unauthorized party and the service\u0027s Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address.\n\n### Mitigation\n\nThe proxy configured by the `INSTANA_ENDPOINT_PROXY` environment variable must be malicious or be possible to be subject to a MitM attack.\n\n### Workarounds\n\nDo not configure the `INSTANA_ENDPOINT_PROXY` environment variable.\n\n### Remediation\n\n[#4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153) refactors `HttpClient` creation so that TLS certificate validation is no longer disabled by default when using a proxy.\n\nIn environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option:\n\n```csharp\nbuilder.AddInstanaExporter((options) =\u003e\n{\n    options.HttpClientFactory = () =\u003e\n    {\n        var handler = new HttpClientHandler()\n        {\n#if NET\n            ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,\n#else\n            ServerCertificateCustomValidationCallback = static (_, _, _, _) =\u003e true,\n#endif\n        };\n        return new HttpClient(handler, disposeHandler: true);\n    };\n});\n```\n\n### Resources\n\n- [PR #4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153)",
  "id": "GHSA-wfr5-454p-mjc2",
  "modified": "2026-06-08T23:34:50Z",
  "published": "2026-05-08T20:48:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib/security/advisories/GHSA-wfr5-454p-mjc2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44213"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet-contrib"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry.Exporter.Instana bypasses TLS certificate validation when a proxy is configured"
}

GHSA-WG96-RRCF-J3MH

Vulnerability from github – Published: 2025-05-20 15:30 – Updated: 2025-05-20 15:30
VLAI
Details

IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-33861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T15:15:52Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.",
  "id": "GHSA-wg96-rrcf-j3mh",
  "modified": "2025-05-20T15:30:41Z",
  "published": "2025-05-20T15:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33861"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7233972"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WGR2-97VR-J8X2

Vulnerability from github – Published: 2023-07-06 15:30 – Updated: 2024-04-04 05:26
VLAI
Details

A misconfiguration vulnerability exists in the urvpn_client functionality of Milesight UR32L v32.3.0.5. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23546"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-06T15:15:11Z",
    "severity": "HIGH"
  },
  "details": "A misconfiguration vulnerability exists in the urvpn_client functionality of Milesight UR32L v32.3.0.5. A specially-crafted man-in-the-middle attack can lead to increased privileges. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.",
  "id": "GHSA-wgr2-97vr-j8x2",
  "modified": "2024-04-04T05:26:47Z",
  "published": "2023-07-06T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23546"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1705"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WH57-PFPG-3FFF

Vulnerability from github – Published: 2022-05-14 01:37 – Updated: 2022-05-14 01:37
VLAI
Details

Multiple +Message Apps (Softbank +Message App for Android prior to version 10.1.7, Softbank +Message App for iOS prior to version 1.1.23, NTT DOCOMO +Message App for Android prior to version 42.40.2800, NTT DOCOMO +Message App for iOS prior to version 1.1.23, KDDI +Message App for Android prior to version 1.0.6, and KDDI +Message App for iOS prior to version 1.1.23) do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Severity
5.9 (Medium)
CVSS:3.0/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-2018-0691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-15T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple +Message Apps (Softbank +Message App for Android prior to version 10.1.7, Softbank +Message App for iOS prior to version 1.1.23, NTT DOCOMO +Message App for Android prior to version 42.40.2800, NTT DOCOMO +Message App for iOS prior to version 1.1.23, KDDI +Message App for Android prior to version 1.0.6, and KDDI +Message App for iOS prior to version 1.1.23) do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
  "id": "GHSA-wh57-pfpg-3fff",
  "modified": "2022-05-14T01:37:00Z",
  "published": "2022-05-14T01:37:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0691"
    },
    {
      "type": "WEB",
      "url": "https://www.au.com/information/notice_mobile/service/2018-002"
    },
    {
      "type": "WEB",
      "url": "https://www.nttdocomo.co.jp/info/notice/page/180927_00.html"
    },
    {
      "type": "WEB",
      "url": "https://www.softbank.jp/mobile/info/personal/news/service/20180927a"
    },
    {
      "type": "WEB",
      "url": "http://jvn.jp/en/jp/JVN37288228/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WHX9-2VF8-4HVM

Vulnerability from github – Published: 2024-06-29 06:31 – Updated: 2025-11-04 00:30
VLAI
Details

IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, and 12.0.2 is vulnerable to improper certificate validation when using the IBM Planning Analytics Data Source Connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between IBM Planning Analytics server and IBM Cognos Analytics server. IBM X-Force ID: 283364.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-25053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-28T19:15:04Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics 11.2.0, 11.2.1, 11.2.2, 11.2.3, 11.2.4, 12.0.0, 12.0.1, and 12.0.2 is vulnerable to improper certificate validation when using the IBM Planning Analytics Data Source Connection. This could allow an attacker to spoof a trusted entity by interfering in the communication path between IBM Planning Analytics server and IBM Cognos Analytics server.  IBM X-Force ID:  283364.",
  "id": "GHSA-whx9-2vf8-4hvm",
  "modified": "2025-11-04T00:30:50Z",
  "published": "2024-06-29T06:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25053"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/283364"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241108-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7156941"
    }
  ],
  "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"
    }
  ]
}

GHSA-WJ7Q-322R-2RRC

Vulnerability from github – Published: 2025-11-25 06:33 – Updated: 2025-11-25 06:33
VLAI
Details

Clients may successfully perform a TLS handshake with a MongoDB server despite presenting a client certificate not aligning with the documented Extended Key Usage (EKU) requirements. A certificate that specifies extendedKeyUsage but is missing extendedKeyUsage = clientAuth may still be successfully authenticated via the TLS handshake as a client. This issue is specific to MongoDB servers running on Windows or Apple as the expected validation behavior functions correctly on Linux systems.

Additionally, MongoDB servers may successfully establish egress TLS connections with servers that present server certificates not aligning with the documented Extended Key Usage (EKU) requirements. A certificate that specifies extendedKeyUsage but is missing extendedKeyUsage = serverAuth may still be successfully authenticated via the TLS handshake as a server. This issue is specific to MongoDB servers running on Apple as the expected validation behavior functions correctly on both Linux and Windows systems.

This vulnerability affects MongoDB Server v7.0 versions prior to 7.0.26, MongoDB Server v8.0 versions prior to 8.0.16 and MongoDB Server v8.2 versions prior to 8.2.2

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-12893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T05:15:59Z",
    "severity": "LOW"
  },
  "details": "Clients may successfully perform a TLS handshake with a MongoDB server despite presenting a client certificate not aligning with the documented Extended Key Usage (EKU) requirements. A certificate that specifies extendedKeyUsage but is missing extendedKeyUsage = clientAuth may still be successfully authenticated via the TLS handshake as a client. This issue is specific to MongoDB servers running on Windows or Apple as the expected validation behavior functions correctly on Linux systems.\n\nAdditionally, MongoDB servers may successfully establish egress TLS connections with servers that present server certificates not aligning with the documented Extended Key Usage (EKU) requirements. A certificate that specifies extendedKeyUsage but is missing extendedKeyUsage = serverAuth may still be successfully authenticated via the TLS handshake as a server. This issue is specific to MongoDB servers running on Apple as the expected validation behavior functions correctly on both Linux and Windows systems. \n\nThis vulnerability affects MongoDB Server v7.0 versions prior to 7.0.26, MongoDB Server v8.0 versions prior to 8.0.16 and MongoDB Server v8.2 versions prior to 8.2.2",
  "id": "GHSA-wj7q-322r-2rrc",
  "modified": "2025-11-25T06:33:11Z",
  "published": "2025-11-25T06:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12893"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-105783"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/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-WJX2-6XJC-WP8W

Vulnerability from github – Published: 2022-05-24 16:57 – Updated: 2024-04-04 02:06
VLAI
Details

An issue was discovered in JetBrains TeamCity 2018.2.4. It had no SSL certificate validation for some external https connections. This was fixed in TeamCity 2019.1.

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-2019-15042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-01T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in JetBrains TeamCity 2018.2.4. It had no SSL certificate validation for some external https connections. This was fixed in TeamCity 2019.1.",
  "id": "GHSA-wjx2-6xjc-wp8w",
  "modified": "2024-04-04T02:06:26Z",
  "published": "2022-05-24T16:57:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15042"
    },
    {
      "type": "WEB",
      "url": "https://blog.jetbrains.com/blog/2019/09/26/jetbrains-security-bulletin-q2-2019"
    }
  ],
  "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-WJXJ-F8RG-99WX

Vulnerability from github – Published: 2019-01-17 13:56 – Updated: 2024-03-04 20:36
VLAI
Summary
Improper Input Validation in Apache Thrift
Details

Apache Thrift Java client library versions 0.5.0 prior to 0.9.3-1 and 0.10.0 prior to 0.12.0 can bypass SASL negotiation isComplete validation in the org.apache.thrift.transport.TSaslTransport class. An assert used to determine if the SASL handshake had successfully completed could be disabled in production settings making the validation incomplete.

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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.thrift:libthrift"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.9.3-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.thrift:libthrift"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.0"
            },
            {
              "fixed": "0.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T22:00:45Z",
    "nvd_published_at": "2019-01-07T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "Apache Thrift Java client library versions 0.5.0 prior to 0.9.3-1 and 0.10.0 prior to 0.12.0 can bypass SASL negotiation isComplete validation in the org.apache.thrift.transport.TSaslTransport class. An assert used to determine if the SASL handshake had successfully completed could be disabled in production settings making the validation incomplete.",
  "id": "GHSA-wjxj-f8rg-99wx",
  "modified": "2024-03-04T20:36:08Z",
  "published": "2019-01-17T13:56:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1320"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/thrift/commit/7489ed6ac8bad64e72fa83ec9d53e1eeddca6c23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/thrift/commit/d973409661f820d80d72c0034d06a12348c8705e"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227094237/http://www.securityfocus.com/bid/106551"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K36361684"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/02/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4d3f1d3e333d9c2b2f6e6ae8ed8750d4de03410ac294bcd12c7eefa3@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3d71a6dbb063aa61ba81278fe622b20bfe7501bb3821c27695641ac3@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r261972a3b14cf6f1dcd94b1b265e9ef644a38ccdf0d0238fa0c4d459@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2278846f7ab06ec07a0aa31457235e0ded9191b216cba55f3f315f16@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1015eaadef8314daa9348aa423086a732cfeb998ceb5d42605c9b0b5@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r09c3dcdccf4b74ad13bda79b354e6b793255ccfe245cca1b8cee23f5@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f9bc3e55f4e28d1dcd1a69aae6d53e609a758e34d2869b4d798e13cc@%3Cissues.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/e825ff2f4e129c0ecdb6a19030b53c1ccdf810a8980667628d0c6a80@%3Cannounce.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/dfee89880c84874058c6a584d8128468f8d3c2ac25068ded91073adc@%3Cuser.storm.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/dbe3a39b48900318ad44494e8721f786901ba4520cd412c7698f534f@%3Cdev.storm.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/da5234b5e78f1c99190407f791dfe1bf6c58de8d30d15974a9669be3@%3Cuser.thrift.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b0656d359c7d40ec9f39c8cc61bca66802ef9a2a12ee199f5b0c1442@%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/8be5b16c02567fff61b1284e5df433a4e38617bc7de4804402bf62be@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/6b07f6f618155c777191b4fad8ade0f0cf4ed4c12a1a746ce903d816@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f@%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/3d3b6849fcf4cd1e87703b3dde0d57aabeb9ba0193dc0cf3c97f545d@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/187684ac8b94d55256253f5220cb55e8bd568afdf9a8a86e9bbb66c9@%3Cdevnull.infra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/07c3cd5a2953a4b253eee4437b1397b1603d0f886437e19b657d2c54@%3Ccommits.cassandra.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/THRIFT-4506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/thrift/releases/tag/0.9.3.1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/thrift"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2413"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/07/24/3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106551"
    }
  ],
  "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"
    }
  ],
  "summary": "Improper Input Validation in Apache Thrift"
}

GHSA-WM4R-WFXQ-54CF

Vulnerability from github – Published: 2024-04-23 21:30 – Updated: 2024-04-23 21:30
VLAI
Details

A vulnerability was found in Hualai Xiaofang iSC5 3.2.2_112 and classified as problematic. Affected by this issue is some unknown functionality. The manipulation leads to improper certificate validation. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The identifier of this vulnerability is VDB-261788. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

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-2024-4062"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-23T19:15:46Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in Hualai Xiaofang iSC5 3.2.2_112 and classified as problematic. Affected by this issue is some unknown functionality. The manipulation leads to improper certificate validation. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The identifier of this vulnerability is VDB-261788. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-wm4r-wfxq-54cf",
  "modified": "2024-04-23T21:30:33Z",
  "published": "2024-04-23T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4062"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kzLiu2017/CVE_Document/blob/main/Hualai_Xiaofang_camera.pdf"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.261788"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.261788"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.316407"
    }
  ],
  "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"
    }
  ]
}
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