Improper Certificate Validation

Most disclosed reports in this category are bugs in specific libraries or desktop clients rather than in a web application's own code: curl's OCSP handling, Acronis True Image, Node's TLS stack accepting an unset rejectUnauthorized option, OpenSSL's certificate verification internals, Undici's proxy CONNECT handling, IDN wildcard matching in curl, and the Nextcloud desktop client have all had reported issues. Because the bug lives inside a specific version of a specific library, detection is largely a matter of identifying which version a target ships and checking it against known CVEs, rather than probing behavior directly.

• curl / libcurl
• Node.js TLS / Undici
• OpenSSL
• Desktop sync clients (Nextcloud, Acronis)

• Match library/version against known cert-validation CVEs
• MITM the connection if client is a desktop binary

• See CVE references

CVE-marker only - compose with Nuclei for the curl / Node / OpenSSL CVEs listed in the corpus.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Out-of-scope for direct probing.
• Limit to version-fingerprint findings.

Manual Testing Methodology

Here is a systematic approach to identifying Improper Certificate Validation vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Improper Certificate Validation specifically, attempt the connection against an endpoint presenting an invalid certificate — self-signed, expired, wrong hostname, or signed by an untrusted CA — using a controlled test proxy, and observe whether the client accepts the connection anyway.

Compare the response against your baseline, looking specifically for a successful connection or data exchange despite an invalid certificate being presented — any of expired, wrong-hostname, or untrusted-issuer should each independently cause the connection to fail.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Improper Certificate Validation, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Improper certificate validation defeats the entire point of TLS: if a client accepts any certificate, an expired one, one for the wrong hostname, or one from an untrusted issuer, without complaint, an attacker positioned on the network path can present their own certificate and transparently intercept traffic the application believes is encrypted end-to-end. This is a textbook man-in-the-middle setup, and it's disproportionately common in mobile apps, IoT firmware, and internal service-to-service clients, where "just disable cert checking, it was blocking local testing" is a change that sometimes ships to production by accident.

Once interception is possible, everything the connection carries is exposed — credentials, session tokens, API keys, and any sensitive data in either direction — with no indication to the user or the application that anything is wrong, since the connection still reports as using HTTPS.

Hostname mismatch specifically (accepting a validly-signed certificate for the wrong domain) is a narrower but equally serious variant: the certificate chain is legitimate, but the client never checked that the certificate actually belongs to the host it's talking to.

Prevention and Secure Coding

Preventing Improper Certificate Validation takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Never disable certificate validation, even temporarily. A validation bypass added for local development or debugging is one of the most common ways this ends up in production — gate it behind a build flag that's impossible to ship enabled, not a comment saying to remember to remove it.

Validate the full chain and the hostname, not just chain trust. Confirm both that the certificate chains to a trusted root and that its subject/SAN actually matches the hostname being connected to — chain validity alone isn't enough.

Use the platform's standard TLS library, not a custom implementation. Standard libraries handle chain building, revocation, and hostname matching correctly by default; custom or simplified TLS handling is where these bugs are introduced.

Certificate pinning for high-value connections. For a mobile app talking to its own backend, pinning the expected certificate or public key adds a layer beyond standard CA-trust validation, at the cost of needing a plan for certificate rotation.

Monitor certificate expiry actively. An expired certificate that gets "fixed" by disabling validation instead of renewing it is a common path into this bug — alert on expiry well before it happens.