Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

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

2177 vulnerabilities reference this CWE, most recent first.

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"
}

GHSA-5MC7-JWXC-9M39

Vulnerability from github – Published: 2026-03-11 21:31 – Updated: 2026-03-11 21:31
VLAI
Details

An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to obtain sensitive user data from the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T21:16:14Z",
    "severity": "MODERATE"
  },
  "details": "An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to obtain sensitive user data from the application.",
  "id": "GHSA-5mc7-jwxc-9m39",
  "modified": "2026-03-11T21:31:04Z",
  "published": "2026-03-11T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1068"
    },
    {
      "type": "WEB",
      "url": "https://www.filez.com/securityPolicy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/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-5MMH-84PF-34P6

Vulnerability from github – Published: 2023-09-19 18:30 – Updated: 2024-04-04 07:44
VLAI
Details

MiniTool Partition Wizard 12.8 contains an insecure update mechanism that allows attackers to achieve remote code execution through a man in the middle attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-38352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-19T16:15:11Z",
    "severity": "HIGH"
  },
  "details": "MiniTool Partition Wizard 12.8 contains an insecure update mechanism that allows attackers to achieve remote code execution through a man in the middle attack.",
  "id": "GHSA-5mmh-84pf-34p6",
  "modified": "2024-04-04T07:44:23Z",
  "published": "2023-09-19T18:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38352"
    },
    {
      "type": "WEB",
      "url": "https://0dr3f.github.io/cve"
    }
  ],
  "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-5MQ7-RWHJ-4FH9

Vulnerability from github – Published: 2026-09-17 20:30 – Updated: 2026-09-17 20:30
VLAI
Summary
Steeltoe: Header-forwarded client cert lacks proof of private-key possession
Details

Summary

When Steeltoe's certificate-based authorization (UseCertificateAuthorization) is configured, the default configuration of the middleware relies on the X-Client-Cert HTTP header to identify the client certificate, without verifying private-key possession. This header is not stripped by common Cloud Foundry routers (like Gorouter or Envoy) on inbound requests.

Impact

An attacker who obtains the public certificate of an application instance in the target organization or space can spoof the X-Client-Cert header. This allows the attacker to bypass SameOrg and SameSpace authorization policies, granting unauthorized access to protected endpoints for the duration of the certificate's validity period.

Affected configuration

  • The application uses AddOrgAndSpacePolicies() and UseCertificateAuthorization() for inter-service authorization.
  • Inbound requests are not restricted to a known trusted proxy source IP.
  • The application's endpoints are network-accessible to the attacker (e.g., exposed to the internet via a public Cloud Foundry route, or the attacker has access to the internal Cloud Foundry network).

Mitigations

If an immediate upgrade to a patched version is not possible:

  • Restrict UseCertificateForwarding to trusted proxy source IPs using ForwardedHeadersOptions.KnownProxies and KnownNetworks.
  • Change the forwarding header to X-Forwarded-Client-Cert so that Cloud Foundry Gorouter and Envoy header stripping mechanisms apply to inbound untrusted requests.
  • Add a secondary authorization layer (e.g., a shared secret or mutual TLS at the proxy layer) for sensitive endpoints.
  • Ensure the application is not bound to a public route unless explicitly required. Use Cloud Foundry internal routes (e.g., .apps.internal) and container-to-container network policies to strictly limit network access to intended internal clients.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Steeltoe.Security.Authorization.Certificate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-81868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T20:30:58Z",
    "nvd_published_at": "2026-09-17T16:17:47Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen Steeltoe\u0027s certificate-based authorization (`UseCertificateAuthorization`) is configured, the default configuration of the middleware relies on the `X-Client-Cert` HTTP header to identify the client certificate, without verifying private-key possession. This header is not stripped by common Cloud Foundry routers (like Gorouter or Envoy) on inbound requests.\n\n### Impact\n\nAn attacker who obtains the public certificate of an application instance in the target organization or space can spoof the `X-Client-Cert` header. This allows the attacker to bypass `SameOrg` and `SameSpace` authorization policies, granting unauthorized access to protected endpoints for the duration of the certificate\u0027s validity period.\n\n### Affected configuration\n\n- The application uses `AddOrgAndSpacePolicies()` and `UseCertificateAuthorization()` for inter-service authorization.\n- Inbound requests are not restricted to a known trusted proxy source IP.\n- The application\u0027s endpoints are network-accessible to the attacker (e.g., exposed to the internet via a public Cloud Foundry route, or the attacker has access to the internal Cloud Foundry network).\n\n### Mitigations\n\nIf an immediate upgrade to a patched version is not possible:\n\n- Restrict `UseCertificateForwarding` to trusted proxy source IPs using `ForwardedHeadersOptions.KnownProxies` and `KnownNetworks`.\n- Change the forwarding header to `X-Forwarded-Client-Cert` so that Cloud Foundry Gorouter and Envoy header stripping mechanisms apply to inbound untrusted requests.\n- Add a secondary authorization layer (e.g., a shared secret or mutual TLS at the proxy layer) for sensitive endpoints.\n- Ensure the application is not bound to a public route unless explicitly required. Use Cloud Foundry internal routes (e.g., `.apps.internal`) and container-to-container network policies to strictly limit network access to intended internal clients.",
  "id": "GHSA-5mq7-rwhj-4fh9",
  "modified": "2026-09-17T20:30:58Z",
  "published": "2026-09-17T20:30:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-5mq7-rwhj-4fh9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/Steeltoe/commit/b626ef3d60aaf19c68eeeed5ee81045406c8c6d0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SteeltoeOSS/Steeltoe/releases/tag/4.3.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SteeltoeOSS/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Steeltoe: Header-forwarded client cert lacks proof of private-key possession"
}

GHSA-5P7C-48HH-G6M7

Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32
VLAI
Details

NETGEAR RAX30 Improper Certificate Validation Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to compromise the integrity of downloaded information on affected installations of NETGEAR RAX30 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the downloading of files via HTTPS. The issue results from the lack of proper validation of the certificate presented by the server. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-19589.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-51634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-22T20:15:06Z",
    "severity": "HIGH"
  },
  "details": "NETGEAR RAX30 Improper Certificate Validation Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to compromise the integrity of downloaded information on affected installations of NETGEAR RAX30  routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the downloading of files via HTTPS. The issue results from the lack of proper validation of the certificate presented by the server. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-19589.",
  "id": "GHSA-5p7c-48hh-g6m7",
  "modified": "2024-11-22T21:32:15Z",
  "published": "2024-11-22T21:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51634"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000065928/Security-Advisory-for-Multiple-Vulnerabilities-on-the-RAX30-PSV-2023-0139"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-583"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5P7C-7C2X-V2F8

Vulnerability from github – Published: 2023-11-22 18:30 – Updated: 2023-11-22 18:30
VLAI
Details

Dell Unity prior to 5.3 contains a 'man in the middle' vulnerability in the vmadapter component. If a customer has a certificate signed by a third-party public Certificate Authority, the vCenter CA could be spoofed by an attacker who can obtain a CA-signed certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-43082"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-22T17:15:18Z",
    "severity": "HIGH"
  },
  "details": "\nDell Unity prior to 5.3 contains a \u0027man in the middle\u0027 vulnerability in the vmadapter component. If a customer has a certificate signed by a third-party public Certificate Authority, the vCenter CA could be spoofed by an attacker who can obtain a CA-signed certificate.\n\n",
  "id": "GHSA-5p7c-7c2x-v2f8",
  "modified": "2023-11-22T18:30:57Z",
  "published": "2023-11-22T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43082"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000213152/dsa-2023-141-dell-unity-unity-vsa-and-unity-xt-security-update-for-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.