CVE-2019-16263

An attacker with a valid certificate for any domain, issued by one of the pinned CAs (VeriSign, DigiCert, GeoTrust), can perform a man-in-the-middle attack against apps using TwitterKit for iOS to communicate with api.twitter.com [ref_id=1]. Because the framework's `evaluateServerTrust` method only checks whether the certificate chain contains a certificate whose public key hash matches the pinned list — without verifying the domain name — any valid chain from those CAs is accepted [ref_id=1]. The matching public key can appear at any position in the chain (leaf, intermediate, or root), further widening the attack surface [ref_id=1]. The attacker redirects traffic for api.twitter.com to their own server, presenting their legitimate certificate, and the app accepts it, allowing interception of all API communications [ref_id=1].

The vulnerability resides in the TwitterKit framework's custom TLS validation method `evaluateServerTrust` (up to version 3.4.2). The framework implements its own server trust evaluation delegate method for public key pinning, overriding iOS's default certificate validation. The code maintains an array of 21 public key hashes for trusted root CAs (VeriSign, GeoTrust, DigiCert) and a "TWITTER1" entry, but does not verify the domain name of the leaf certificate [ref_id=1].

No patch or fixed version exists — TwitterKit for iOS is an end-of-life product and Twitter has not released a remediation [ref_id=1]. The advisory notes that a simple fix would have been to additionally call iOS's `SecTrustEvaluate` method and use its result to reject certificates that do not match the expected domain name [ref_id=1]. The only recommended mitigation is for app developers to migrate away from TwitterKit and switch to alternative APIs [ref_id=1].