Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

2266 vulnerabilities reference this CWE, most recent first.

GHSA-5FW8-5JWX-QWH6

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

An Improper Certificate Validation weakness in the SRX Series Application Identification (app-id) signature update client of Juniper Networks Junos OS allows an attacker to perform Man-in-the-Middle (MitM) attacks which may compromise the integrity and confidentiality of the device. This issue affects: Juniper Networks Junos OS 15.1X49 versions prior to 15.1X49-D120 on SRX Series devices. No other versions of Junos OS are affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-0054"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-09T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An Improper Certificate Validation weakness in the SRX Series Application Identification (app-id) signature update client of Juniper Networks Junos OS allows an attacker to perform Man-in-the-Middle (MitM) attacks which may compromise the integrity and confidentiality of the device. This issue affects: Juniper Networks Junos OS 15.1X49 versions prior to 15.1X49-D120 on SRX Series devices. No other versions of Junos OS are affected.",
  "id": "GHSA-5fw8-5jwx-qwh6",
  "modified": "2024-04-04T02:12:13Z",
  "published": "2022-05-24T16:58:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0054"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA10952"
    },
    {
      "type": "WEB",
      "url": "https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-application-identification-overview.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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5H4F-9XQG-F36M

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

When libvirtd is configured by OSP director (tripleo-heat-templates) to use the TLS transport it defaults to the same certificate authority as all non-libvirtd services. As no additional authentication is configured this allows these services to connect to libvirtd (which is equivalent to root access). If a vulnerability exists in another service it could, combined with this flaw, be exploited to escalate privileges to gain control over compute nodes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-15114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-27T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "When libvirtd is configured by OSP director (tripleo-heat-templates) to use the TLS transport it defaults to the same certificate authority as all non-libvirtd services. As no additional authentication is configured this allows these services to connect to libvirtd (which is equivalent to root access). If a vulnerability exists in another service it could, combined with this flaw, be exploited to escalate privileges to gain control over compute nodes.",
  "id": "GHSA-5h4f-9xqg-f36m",
  "modified": "2022-05-13T01:43:37Z",
  "published": "2022-05-13T01:43:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15114"
    },
    {
      "type": "WEB",
      "url": "https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=994922a8ba996fe68d047df0e1486fa805dbea31"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101971"
    }
  ],
  "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-5H6X-M52P-23PH

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2025-07-01 21:15
Withdrawn 2025-07-01 VLAI
Summary
Withdrawn Advisory: Improper Certificate Validation in Apache Qpid Proton
Details

Withdrawn Advisory

This advisory has been withdrawn because the vulnerability only affects the Qpid Proton C library and not org.apache.qpid:proton-j. This link has been maintained to preserve external references.

Original Description

While investigating bug PROTON-2014, we discovered that under some circumstances Apache Qpid Proton versions 0.9 to 0.27.0 (C library and its language bindings) can connect to a peer anonymously using TLS even when configured to verify the peer certificate while used with OpenSSL versions before 1.1.0. This means that an undetected man in the middle attack could be constructed if an attacker can arrange to intercept TLS traffic.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.qpid:proton-j"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9"
            },
            {
              "fixed": "0.27.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-0223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-02T00:05:42Z",
    "nvd_published_at": "2019-04-23T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "## Withdrawn Advisory\nThis advisory has been withdrawn because the vulnerability only affects the **Qpid Proton C library** and not `org.apache.qpid:proton-j`. This link has been maintained to preserve external references.\n\n## Original Description\n\nWhile investigating bug PROTON-2014, we discovered that under some circumstances Apache Qpid Proton versions 0.9 to 0.27.0 (C library and its language bindings) can connect to a peer anonymously using TLS *even when configured to verify the peer certificate* while used with OpenSSL versions before 1.1.0. This means that an undetected man in the middle attack could be constructed if an attacker can arrange to intercept TLS traffic.",
  "id": "GHSA-5h6x-m52p-23ph",
  "modified": "2025-07-01T21:15:27Z",
  "published": "2022-05-24T16:44:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0223"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/PROTON-2014?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/008ee5e78e5a090e1fcc5f6617f425e4e51d59f03d3eda2dd006df9f@%3Cusers.qpid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/3adb2f020f705b4fd453982992a68cd10f9d5ac728b699efdb73c1f5@%3Cdev.qpid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/49c83f0acce5ceaeffca51714ec2ba0f0199bcb8f99167181bba441b@%3Cdev.qpid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/914424e4d798a340f523b6169aaf39b626971d9bb00fcdeb1d5d6c0d@%3Ccommits.qpid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/d9c9a882a292e2defaed1f954528c916fb64497ce57db652727e39b0@%3Cannounce.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/04/23/4"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108044"
    }
  ],
  "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": "Withdrawn Advisory: Improper Certificate Validation in Apache Qpid Proton",
  "withdrawn": "2025-07-01T21:15:27Z"
}

GHSA-5H7R-WRWV-5RJ5

Vulnerability from github – Published: 2026-08-11 21:33 – Updated: 2026-08-12 00:31
VLAI
Details

An insufficient certificate validation in a privileged communication workflow, was identified in a GMS application 9.5.1 (Build 9510.1044) and earlier versions which, under a successful MitM attack and controlled network conditions, could permit unauthorized changes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-66154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T21:17:49Z",
    "severity": "HIGH"
  },
  "details": "An insufficient certificate validation in a privileged communication workflow, was identified in a GMS application 9.5.1 (Build 9510.1044) and earlier versions which, under a successful MitM attack and controlled network conditions, could permit unauthorized changes.",
  "id": "GHSA-5h7r-wrwv-5rj5",
  "modified": "2026-08-12T00:31:09Z",
  "published": "2026-08-11T21:33:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66154"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5HHF-XMFX-4VVR

Vulnerability from github – Published: 2026-05-15 18:29 – Updated: 2026-06-08 23:35
VLAI
Summary
epa4all-client: TLS Certificate Validation Disabled in Production
Details

Impact

An attacker on the network path between the ePA service and the Konnektor can present any TLS certificate (self-signed, expired, wrong CN) and intercept all SOAP traffic. This includes patient identifiers (KVNR), SMC-B card operations (authentication, signing), document content, and credential exchanges.

Patches

#36

Workarounds

Use the library directly instead of the REST wrapper.

Resources

  • MS-OVIVA-EPA4ALL-771a78

Credits

Machine Spirits (contact@machinespirits.de)

  • Dr. rer. nat. Simon Weber
  • Dipl.-Inf. Volker Schönefeld
  • Chiara Fliegner
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.oviva.telematik:epa4all-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T18:29:31Z",
    "nvd_published_at": "2026-05-26T22:16:43Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAn attacker on the network path between the ePA service and the Konnektor can present any TLS certificate (self-signed, expired, wrong CN) and intercept all SOAP traffic. This includes patient identifiers (KVNR), SMC-B card operations (authentication, signing),\ndocument content, and credential exchanges.\n\n### Patches\n[#36](https://github.com/oviva-ag/epa4all-client/pull/36)\n\n### Workarounds\nUse the library directly instead of the REST wrapper.\n\n### Resources\n- MS-OVIVA-EPA4ALL-771a78\n\n### Credits\n[Machine Spirits](https://machinespirits.com/) ([contact@machinespirits.de](mailto:contact@machinespirits.de))\n\n- Dr. rer. nat. Simon Weber\n- Dipl.-Inf. Volker Sch\u00f6nefeld\n- Chiara Fliegner",
  "id": "GHSA-5hhf-xmfx-4vvr",
  "modified": "2026-06-08T23:35:18Z",
  "published": "2026-05-15T18:29:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oviva-ag/epa4all-client/security/advisories/GHSA-5hhf-xmfx-4vvr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45574"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oviva-ag/epa4all-client/pull/36"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oviva-ag/epa4all-client/commit/9111d6fbb939007036a7f74b2a93bb278cb5af32"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oviva-ag/epa4all-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oviva-ag/epa4all-client/releases/tag/v1.2.2"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "epa4all-client: TLS Certificate Validation Disabled in Production"
}

GHSA-5J88-3PCX-MP3F

Vulnerability from github – Published: 2022-04-22 00:24 – Updated: 2024-04-03 23:05
VLAI
Details

dirmngr before 2.1.0 improperly handles certain system calls, which allows remote attackers to cause a denial of service (DOS) via a specially-crafted certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-2207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-27T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "dirmngr before 2.1.0 improperly handles certain system calls, which allows remote attackers to cause a denial of service (DOS) via a specially-crafted certificate.",
  "id": "GHSA-5j88-3pcx-mp3f",
  "modified": "2024-04-03T23:05:52Z",
  "published": "2022-04-22T00:24:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-2207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2011-2207"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627377"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2207"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2011-2207"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2011/06/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:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5J9F-5WMP-7F8H

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-12-06 21:49
VLAI
Summary
Jenkins Cadence vManager Plugin disables SSL/TLS and hostname verification
Details

Jenkins Cadence vManager Plugin prior to version 2.7.1 disables SSL/TLS and hostname verification globally for the Jenkins master JVM. This issue is patched in 2.7.1

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:vmanager-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-06T21:49:12Z",
    "nvd_published_at": "2019-10-16T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Cadence vManager Plugin prior to version 2.7.1 disables SSL/TLS and hostname verification globally for the Jenkins master JVM. This issue is patched in 2.7.1",
  "id": "GHSA-5j9f-5wmp-7f8h",
  "modified": "2022-12-06T21:49:12Z",
  "published": "2022-05-24T16:58:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/vmanager-plugin/commit/639aa135ab57d9e23c5bedeb0a5e9518eb0f486e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/vmanager-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-10-16/#SECURITY-1615"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Cadence vManager Plugin disables SSL/TLS and hostname verification "
}

GHSA-5JC8-8XHV-G8QM

Vulnerability from github – Published: 2022-05-17 01:38 – Updated: 2024-02-14 21:29
VLAI
Summary
Improper Input Validation in XFire
Details

Codehaus XFire 1.2.6 and earlier, as used in the Amazon EC2 API Tools Java library and other products, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.codehaus.xfire:xfire-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2012-5817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-12T22:17:46Z",
    "nvd_published_at": "2012-11-04T22:55:00Z",
    "severity": "HIGH"
  },
  "details": "Codehaus XFire 1.2.6 and earlier, as used in the Amazon EC2 API Tools Java library and other products, does not verify that the server hostname matches a domain name in the subject\u0027s Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.",
  "id": "GHSA-5jc8-8xhv-g8qm",
  "modified": "2024-02-14T21:29:45Z",
  "published": "2022-05-17T01:38:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5817"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/79934"
    },
    {
      "type": "WEB",
      "url": "http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf"
    }
  ],
  "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": "Improper Input Validation in XFire"
}

GHSA-5JR8-VJMP-FP54

Vulnerability from github – Published: 2025-01-10 18:31 – Updated: 2025-01-13 21:30
VLAI
Details

An issue in CP Plus CP-VNR-3104 B3223P22C02424 allows attackers to obtain the EC private key and access sensitive data or execute a man-in-the-middle attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-10T17:15:16Z",
    "severity": "MODERATE"
  },
  "details": "An issue in CP Plus CP-VNR-3104 B3223P22C02424 allows attackers to obtain the EC private key and access sensitive data or execute a man-in-the-middle attack.",
  "id": "GHSA-5jr8-vjmp-fp54",
  "modified": "2025-01-13T21:30:52Z",
  "published": "2025-01-10T18:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15522"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54846"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yashodhanvivek/CP-VNR-3104-NVR-Vulnerabilties/blob/main/CPPlus_CP-VNR-3104_Security_Assessment.pdf"
    },
    {
      "type": "WEB",
      "url": "https://payatu.com/blog/solving-the-problem-of-encrypted-firmware"
    }
  ],
  "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"
    }
  ]
}

GHSA-5M9F-RPHJ-C435

Vulnerability from github – Published: 2026-08-18 16:32 – Updated: 2026-08-18 16:32
VLAI
Summary
RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM
Details

Vulnerability Summary

com.rabbitmq.client.TrustEverythingTrustManager accepts ANY TLS certificate (including null chains) and is used as the default trust manager when calling ConnectionFactory.useSslProtocol() without arguments. Combined with hostname verification being disabled by default, this enables trivial man-in-the-middle attacks.

Affected Components

  • com.rabbitmq.client.TrustEverythingTrustManager — accepts any certificate
  • com.rabbitmq.client.ConnectionFactory.useSslProtocol() — uses TrustEverythingTrustManager
  • Hostname verification disabled by default (enableHostnameVerification() must be called explicitly)
  • com.rabbitmq.client.ConnectionFactory.getPassword() — returns plaintext with no redaction
  • Default port 5672 (plaintext) with PLAIN SASL — credentials sent unencrypted

POC (Verified on Java 21, amqp-client 5.25.0)

// TrustEverythingTrustManager accepts ANY certificate including null
TrustEverythingTrustManager tm = new TrustEverythingTrustManager();
tm.checkServerTrusted(null, "RSA");  // No exception — accepts null cert chain
tm.getAcceptedIssuers();  // Returns empty array — trusts all CAs

// ConnectionFactory defaults
ConnectionFactory factory = new ConnectionFactory();
factory.useSslProtocol();  // Uses TrustEverythingTrustManager internally
// enableHostnameVerification() NOT called by default

// Credential exposure
factory.setPassword("secret_password_123");
factory.getPassword();  // Returns "secret_password_123" — no redaction

// Default plaintext port
factory.getPort();  // 5672 (plaintext, not 5671/TLS)

// PLAIN SASL sends cleartext credentials
PlainMechanism pm = new PlainMechanism();
// handleChallenge() sends username+password in cleartext

Attack Scenarios

  1. MITM: Attacker presents self-signed cert → TrustEverythingTrustManager accepts it → all RabbitMQ traffic intercepted
  2. Credential theft: Default plaintext port (5672) + PLAIN SASL = credentials readable on network
  3. DNS rebinding: No hostname verification → attacker DNS record → MITM without cert
  4. Logging exposure: getPassword() returns plaintext → credentials in logs/stack traces

Suggested Fix

  1. Deprecate TrustEverythingTrustManager — it should never be used in production
  2. useSslProtocol() should use the JVM default trust store, not TrustEverything
  3. Enable hostname verification by default
  4. Redact password in getPassword() or remove the public getter
  5. Warn when using PLAIN SASL without TLS
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.rabbitmq:amqp-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63336"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T16:32:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Vulnerability Summary\n\n`com.rabbitmq.client.TrustEverythingTrustManager` accepts ANY TLS certificate (including null chains) and is used as the default trust manager when calling `ConnectionFactory.useSslProtocol()` without arguments. Combined with hostname verification being disabled by default, this enables trivial man-in-the-middle attacks.\n\n## Affected Components\n\n- `com.rabbitmq.client.TrustEverythingTrustManager` \u2014 accepts any certificate\n- `com.rabbitmq.client.ConnectionFactory.useSslProtocol()` \u2014 uses TrustEverythingTrustManager\n- Hostname verification disabled by default (`enableHostnameVerification()` must be called explicitly)\n- `com.rabbitmq.client.ConnectionFactory.getPassword()` \u2014 returns plaintext with no redaction\n- Default port 5672 (plaintext) with PLAIN SASL \u2014 credentials sent unencrypted\n\n## POC (Verified on Java 21, amqp-client 5.25.0)\n\n```java\n// TrustEverythingTrustManager accepts ANY certificate including null\nTrustEverythingTrustManager tm = new TrustEverythingTrustManager();\ntm.checkServerTrusted(null, \"RSA\");  // No exception \u2014 accepts null cert chain\ntm.getAcceptedIssuers();  // Returns empty array \u2014 trusts all CAs\n\n// ConnectionFactory defaults\nConnectionFactory factory = new ConnectionFactory();\nfactory.useSslProtocol();  // Uses TrustEverythingTrustManager internally\n// enableHostnameVerification() NOT called by default\n\n// Credential exposure\nfactory.setPassword(\"secret_password_123\");\nfactory.getPassword();  // Returns \"secret_password_123\" \u2014 no redaction\n\n// Default plaintext port\nfactory.getPort();  // 5672 (plaintext, not 5671/TLS)\n\n// PLAIN SASL sends cleartext credentials\nPlainMechanism pm = new PlainMechanism();\n// handleChallenge() sends username+password in cleartext\n```\n\n## Attack Scenarios\n\n1. **MITM**: Attacker presents self-signed cert \u2192 `TrustEverythingTrustManager` accepts it \u2192 all RabbitMQ traffic intercepted\n2. **Credential theft**: Default plaintext port (5672) + PLAIN SASL = credentials readable on network\n3. **DNS rebinding**: No hostname verification \u2192 attacker DNS record \u2192 MITM without cert\n4. **Logging exposure**: `getPassword()` returns plaintext \u2192 credentials in logs/stack traces\n\n## Suggested Fix\n1. Deprecate `TrustEverythingTrustManager` \u2014 it should never be used in production\n2. `useSslProtocol()` should use the JVM default trust store, not TrustEverything\n3. Enable hostname verification by default\n4. Redact password in `getPassword()` or remove the public getter\n5. Warn when using PLAIN SASL without TLS",
  "id": "GHSA-5m9f-rphj-c435",
  "modified": "2026-08-18T16:32:59Z",
  "published": "2026-08-18T16:32:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-5m9f-rphj-c435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/1999"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2001"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/1e7deb2e6020c9793a81385a53ea378ec63b9339"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/a4bf571dd368765baaa9cecfae68ce09f1bdcc01"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.33.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM"
}

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.