CVE-2026-14440

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-14440", "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513", "state": "PUBLISHED", "assignerShortName": "cloudflare", "dateReserved": "2026-07-01T22:20:45.895Z", "datePublished": "2026-07-01T22:35:10.353Z", "dateUpdated": "2026-07-02T19:22:18.404Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513", "shortName": "cloudflare", "dateUpdated": "2026-07-01T22:35:10.353Z"}, "title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records", "affected": [{"vendor": "Cloudflare", "product": "Universal SSL", "platforms": ["Cloud Service"], "versions": [{"status": "affected", "version": "0", "lessThanOrEqual": "current", "versionType": "custom"}], "defaultStatus": "unaffected"}], "descriptions": [{"lang": "en", "value": "Description:\n\n\n\n\nTo 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.\n\n\n\n\nExploitation 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.\n\n\n\n\n\n\n\n\nMitigation:\u00a0\n\n\n\nCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal 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.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.\n\n\n\n\n\n\n\n\nCredits:\n\n\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<p><b>Description:</b></p><br><p>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.</p><br><p>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.</p><p><br></p><p><span><b>Mitigation:&nbsp;</b></span></p><p><span>Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.</span></p><p><span>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.&nbsp;</span></p><p><span>Certificate Transparency monitoring is recommended for all customers as a general detection control.</span></p><p><b></b><br></p><p><span><b>Credits:</b></span></p><p><span>David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher</span></p><p><b></b><br></p><br>"}]}], "references": [{"url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/"}, {"url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/"}, {"url": "https://www.rfc-editor.org/rfc/rfc8657"}, {"url": "https://www.rfc-editor.org/rfc/rfc8659"}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}], "cvssV4_0": {"attackVector": "ADJACENT", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "userInteraction": "NONE", "vulnConfidentialityImpact": "HIGH", "subConfidentialityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "subIntegrityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subAvailabilityImpact": "NONE", "exploitMaturity": "NOT_DEFINED", "Safety": "NOT_DEFINED", "Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "valueDensity": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "version": "4.0", "baseSeverity": "HIGH", "baseScore": 7.6, "vectorString": "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"}}], "solutions": [{"lang": "en", "value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal 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.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "<b><p>Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.</p><p>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.&nbsp;</p><p>Certificate Transparency monitoring is recommended for all customers as a general detection control.</p></b><br>"}]}], "credits": [{"lang": "en", "value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher", "type": "reporter"}], "source": {"discovery": "UNKNOWN"}, "x_generator": {"engine": "Vulnogram 1.0.2"}}, "adp": [{"problemTypes": [{"descriptions": [{"type": "CWE", "cweId": "CWE-693", "lang": "en", "description": "CWE-693 Protection Mechanism Failure"}]}], "references": [{"url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/", "tags": ["technical-description", "exploit"]}, {"url": "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999/10", "tags": ["related"]}, {"url": "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930", "tags": ["related"]}, {"url": "https://zenodo.org/records/18330221", "tags": ["technical-description", "exploit"]}], "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.8, "attackVector": "ADJACENT_NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}}, {"other": {"type": "ssvc", "content": {"timestamp": "2026-07-02T19:22:08.681269Z", "id": "CVE-2026-14440", "options": [{"Exploitation": "poc"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-07-02T19:22:18.404Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.8, "attackVector": "ADJACENT_NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}}, {"other": {"type": "ssvc", "content": {"id": "CVE-2026-14440", "role": "CISA Coordinator", "options": [{"Exploitation": "poc"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "version": "2.0.3", "timestamp": "2026-07-02T19:22:08.681269Z"}}}], "references": [{"url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/", "tags": ["technical-description", "exploit"]}, {"url": "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999/10", "tags": ["related"]}, {"url": "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930", "tags": ["related"]}, {"url": "https://zenodo.org/records/18330221", "tags": ["technical-description", "exploit"]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-693", "description": "CWE-693 Protection Mechanism Failure"}]}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-07-02T13:13:33.214Z"}}], "cna": {"title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records", "source": {"discovery": "UNKNOWN"}, "credits": [{"lang": "en", "type": "reporter", "value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"}], "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 7.6, "Automatable": "NOT_DEFINED", "attackVector": "ADJACENT", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "vectorString": "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"vendor": "Cloudflare", "product": "Universal SSL", "versions": [{"status": "affected", "version": "0", "versionType": "custom", "lessThanOrEqual": "current"}], "platforms": ["Cloud Service"], "defaultStatus": "unaffected"}], "solutions": [{"lang": "en", "value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal 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.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.", "supportingMedia": [{"type": "text/html", "value": "<b><p>Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.</p><p>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.&nbsp;</p><p>Certificate Transparency monitoring is recommended for all customers as a general detection control.</p></b><br>", "base64": false}]}], "references": [{"url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/"}, {"url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/"}, {"url": "https://www.rfc-editor.org/rfc/rfc8657"}, {"url": "https://www.rfc-editor.org/rfc/rfc8659"}], "x_generator": {"engine": "Vulnogram 1.0.2"}, "descriptions": [{"lang": "en", "value": "Description:\n\n\n\n\nTo 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.\n\n\n\n\nExploitation 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.\n\n\n\n\n\n\n\n\nMitigation:\u00a0\n\n\n\nCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal 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.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.\n\n\n\n\n\n\n\n\nCredits:\n\n\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher", "supportingMedia": [{"type": "text/html", "value": "<p><b>Description:</b></p><br><p>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.</p><br><p>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.</p><p><br></p><p><span><b>Mitigation:&nbsp;</b></span></p><p><span>Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.</span></p><p><span>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.&nbsp;</span></p><p><span>Certificate Transparency monitoring is recommended for all customers as a general detection control.</span></p><p><b></b><br></p><p><span><b>Credits:</b></span></p><p><span>David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher</span></p><p><b></b><br></p><br>", "base64": false}]}], "providerMetadata": {"orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513", "shortName": "cloudflare", "dateUpdated": "2026-07-01T22:35:10.353Z"}}}, "cveMetadata": {"cveId": "CVE-2026-14440", "state": "PUBLISHED", "dateUpdated": "2026-07-02T19:22:18.404Z", "dateReserved": "2026-07-01T22:20:45.895Z", "assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513", "datePublished": "2026-07-01T22:35:10.353Z", "assignerShortName": "cloudflare"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "platforms": ["Cloud Service"], "product": "Universal SSL", "vendor": "Cloudflare", "versions": [{"lessThanOrEqual": "current", "status": "affected", "version": "0", "versionType": "custom"}]}], "source": "cna@cloudflare.com"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "Description:\n\n\n\n\nTo 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.\n\n\n\n\nExploitation 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.\n\n\n\n\n\n\n\n\nMitigation:\u00a0\n\n\n\nCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal 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.\u00a0\n\n\n\nCertificate Transparency monitoring is recommended for all customers as a general detection control.\n\n\n\n\n\n\n\n\nCredits:\n\n\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"}, {"lang": "es", "value": "Descripci\u00f3n:\n\nPara emitir y renovar certificados TLS en nombre de los clientes, la funci\u00f3n Universal SSL de Cloudflare gestiona autom\u00e1ticamente el RRset CAA para la zona del cliente. Este RRset autogestionado es permisivo por dise\u00f1o (p. ej., \u2019issue \u201cletsencrypt.org\u201d\u2019 sin par\u00e1metros). En las zonas Universal SSL, el DNS autoritativo de Cloudflare sirve este RRset autogestionado en el momento de la consulta, anulando cualquier registro CAA configurado por el cliente en la zona. Cuando un cliente publica un registro CAA m\u00e1s estricto utilizando los par\u00e1metros accounturi o validationmethods de RFC 8657, la Autoridad de Certificaci\u00f3n no observa esos par\u00e1metros al evaluar el RRset servido bajo RFC 8659. Como resultado, las protecciones de enlace de cuenta y de enlace de m\u00e9todo de validaci\u00f3n de RFC 8657 no se aplican de extremo a extremo en las zonas Universal SSL. Una explotaci\u00f3n exitosa podr\u00eda resultar en la emisi\u00f3n de un certificado TLS de confianza para el navegador a un atacante, permitiendo MitM contra el dominio afectado.\n\nLa explotaci\u00f3n no es trivial en la pr\u00e1ctica: un atacante necesitar\u00eda tener una cuenta ACME en una de las Autoridades de Certificaci\u00f3n en el RRset CAA servido y satisfacer simult\u00e1neamente la validaci\u00f3n de control de dominio a trav\u00e9s de las m\u00faltiples Perspectivas de Red geogr\u00e1ficamente distintas en las que la CA conf\u00eda para la Corroboraci\u00f3n de Emisi\u00f3n Multi-Perspectiva. Los prefijos de Cloudflare se anuncian por anycast desde cientos de ubicaciones a nivel mundial, elevando el list\u00f3n contra los secuestros BGP de un solo punto de vista. Cualquier emisi\u00f3n incorrecta resultante de un certificado de confianza para el navegador est\u00e1 sujeta al registro de Transparencia de Certificados requerido por los principales navegadores, y ser\u00eda visible para la monitorizaci\u00f3n de CT.\n\nMitigaci\u00f3n:\n\nLos clientes que requieren una aplicaci\u00f3n estricta de RFC 8657 necesitan deshabilitar Universal SSL en la zona afectada.\n\nLa gesti\u00f3n autom\u00e1tica de CAA de Universal SSL y la aplicaci\u00f3n de los par\u00e1metros accounturi y validationmethods de RFC 8657 configurados por el cliente son mutuamente excluyentes por la naturaleza del problema, por lo que no hay una soluci\u00f3n alternativa en el producto que preserve ambos.\n\nSe recomienda la monitorizaci\u00f3n de Transparencia de Certificados para todos los clientes como un control de detecci\u00f3n general.\n\nCr\u00e9ditos:\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), investigador independiente"}], "id": "CVE-2026-14440", "lastModified": "2026-10-25T21:10:00.770", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "NONE", "baseScore": 6.8, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 1.6, "impactScore": 5.2, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "ADJACENT", "availabilityRequirement": "NOT_DEFINED", "baseScore": 7.6, "baseSeverity": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "cna@cloudflare.com", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-14440", "options": [{"exploitation": "poc"}, {"automatable": "no"}, {"technicalImpact": "total"}], "role": "CISA Coordinator", "timestamp": "2026-07-02T19:22:08.681269Z", "version": "2.0.3"}}]}, "published": "2026-07-01T23:16:52.007", "references": [{"source": "cna@cloudflare.com", "url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/"}, {"source": "cna@cloudflare.com", "url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/"}, {"source": "cna@cloudflare.com", "url": "https://www.rfc-editor.org/rfc/rfc8657"}, {"source": "cna@cloudflare.com", "url": "https://www.rfc-editor.org/rfc/rfc8659"}, {"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "url": "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999/10"}, {"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "url": "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930"}, {"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/"}, {"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "url": "https://zenodo.org/records/18330221"}], "sourceIdentifier": "cna@cloudflare.com", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-693"}], "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": ["cloud_service"], "status": "affected", "versions": {"scheme": "generic", "value": "[0,current]"}}], "enrichment": {"confidence": 100.0, "confidence_source": "cna", "scores": [{"score": 100.0, "source": "cna"}]}, "original": {"product": "Universal SSL", "source": "cna", "vendor": "Cloudflare"}, "product": "universal_ssl", "vendor": "cloudflare"}], "created": "2026-07-02T05:00:13.876671+00:00", "updated": "2026-08-01T22:30:06.562807+00:00", "vendors": ["cloudflare", "cloudflare$PRODUCT$universal_ssl"]}