# TLS peer certificate or hostname verification failure

Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.

**Candidate CWE:** [CWE-295](https://cwe.mitre.org/data/definitions/295.html) · [CWE-297](https://cwe.mitre.org/data/definitions/297.html)

## Test hypothesis

In an owned endpoint fixture, compare a valid certificate, an untrusted issuer and a wrong-host certificate while keeping the release, trust store and synthetic application request fixed. The valid control must connect. Observe the actual client decision and application exchange rather than treating a diagnostic command that continues after an error as proof.

## Evidence required

Record release provenance, expected hostname, certificate SANs, trust-store context, handshake decision and whether the protected request was transmitted. Preserve matched valid/invalid controls and all changes to lab CA, proxy and trust configuration.

## Rule out false positives

Missing pinning, intentional trust in a lab CA, debug overrides, instrumentation that disables checks, or a diagnostic client configured to continue after verification errors is not a release validation defect.

## Playbook and command references

- [Client storage, logs, backup and transport trust](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/client-storage-transport.html) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [DNS, TLS and email trust boundaries](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/dns-tls-mail.html) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/commands.html?q=Client%20storage%2C%20logs%2C%20backup%20and%20transport%20trust)

## Referenced by these target playbooks

[Mobile](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/mobile.html) · [Desktop & extensions](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/desktop.html) · [Network services](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/network.html) · [Cloud & containers](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cloud.html) · [OSS & self-hosted](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/oss.html)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/attack.html).

## Primary references

- [Unsafe X509TrustManager](https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager)
- [Android network security configuration](https://developer.android.com/privacy-and-security/security-config)
- [OpenSSL verification controls](https://docs.openssl.org/3.5/man1/openssl-s_client/)
- [CWE-297 definition](https://cwe.mitre.org/data/definitions/297.html)

[Back to the complete vulnerability catalog](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities.html)
