Which versions of Cloudflare Universal SSL are affected by CVE-2026-14440?

Cloudflare's Universal SSL service contains a vulnerability enabling attackers with compromised Certificate Authority credentials to issue fraudulent SSL certificates for customer domains,…

How to fix or mitigate CVE-2026-14440?

Within 24 hours: Identify all Cloudflare Universal SSL-protected domains and document which rely on Cloudflare's auto-managed CAA configuration. Within 7 days: Contact Cloudflare support for mitigation guidance; audit Certificate Transparency logs for unexpected certificate issuance against your domains; migrate affected domains from auto-managed CAA records to customer-controlled restrictive CAA policies. Within 30 days: Deploy automated Certificate Transparency monitoring with alerts on domain certificates; audit all CA account access and disable unnecessary integrations; enforce multi-factor authentication on all CA account credentials.

Cloudflare Universal SSL CVE-2026-14440

Q: What is the CVSS score of CVE-2026-14440?

CVE-2026-14440 has a CVSS 4.0 base score of 7.6 (High). CVSS vector: CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/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. EPSS exploitation probability: 0.1%.

EUVD-2026-41207 HIGH

Improperly Implemented Security Check for Standard (CWE-358)

2026-07-01 cloudflare

GHSA-vrv9-rjp4-w93c

Information Disclosure Universal Ssl

7.6

CVSS 4.0 · Vendor: cloudflare

Severity by source

Vendor (cloudflare) PRIMARY

7.6 HIGH

CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/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

vuln.today AI

7.4 HIGH

Attack is over the network/ACME but demands an ACME account and defeating multi-perspective DCV (AC:H); no target privileges (PR:N); misissued cert enables MITM decryption/tampering (C:H/I:H) with no availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (cloudflare).

CVSS VectorVendor: cloudflare

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 23:20 vuln.today

DescriptionCVE.org

Description:

To issue and renew TLS certificates on behalf of customers, Cloudflare's Universal SSL feature automatically manages the CAA RRset for the customer's zone. This auto-managed RRset is permissive by design (e.g. 'issue "letsencrypt.org"' without parameters). On Universal SSL zones, Cloudflare's authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.

Exploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.

Mitigation:

Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.

Universal SSL's automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.

Certificate Transparency monitoring is recommended for all customers as a general detection control.

Credits:

David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher

AnalysisAI

TLS certificate misissuance affecting Cloudflare Universal SSL zones lets an attacker who controls an ACME account at a CA in the auto-managed CAA RRset obtain a browser-trusted certificate for a victim domain, because Cloudflare's authoritative DNS serves a permissive auto-managed CAA RRset that supersedes customer-set records and drops RFC 8657 accounturi/validationmethods bindings. The result is a bypass of account-binding and validation-method-binding protections end-to-end, enabling MITM against the affected domain. Reported by Cloudflare (researcher David Osipov) with no public exploit identified at time of analysis; CVSS 4.0 base score is 7.6 with high attack complexity and a present attack requirement.

Technical ContextAI

The issue sits at the intersection of RFC 8659 (CAA record semantics) and RFC 8657 (CAA extensions: accounturi for account binding and validationmethods for restricting how domain control is proven). To automate issuance/renewal for Universal SSL, Cloudflare auto-manages the zone's CAA RRset and serves a deliberately permissive record (e.g. 'issue "letsencrypt.org"' with no parameters) from its anycast authoritative DNS at query time. Because this served RRset overrides any customer-published CAA record, a customer's stricter RFC 8657 parameters never reach the CA under RFC 8659 evaluation, so the CA sees only the permissive record. The affected product per CPE is cpe:2.3:a:cloudflare:universal_ssl (all versions). No CWE was assigned, but functionally this is an authorization/enforcement gap where a security control (CAA account/method binding) is silently not enforced - an access-control weakness rather than a memory-safety or injection bug.

RemediationAI

There is no vendor-released code patch and no in-product workaround, because Universal SSL's automatic CAA management and customer-enforced RFC 8657 account/method binding are mutually exclusive by design; customers who require strict RFC 8657 enforcement must disable Universal SSL on the affected zone and manage certificates/CAA records themselves, accepting the trade-off of losing Cloudflare's automatic edge certificate issuance and renewal. As a general detection control for all customers, enable and actively monitor Certificate Transparency logs (per https://developers.cloudflare.com/ssl/edge-certificates/caa-records/ and the limitations page https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/) so that any misissued browser-trusted certificate for your domains is caught quickly; the side effect is that CT monitoring is detective rather than preventive, so it reduces dwell time but does not stop issuance. Where feasible, high-value domains should combine disabling Universal SSL with strict externally managed CAA records containing accounturi/validationmethods so the CA actually observes the binding.