Search
Find a vulnerability
Search criteria
3 vulnerabilities found for Universal Ssl by Cloudflare
GCVE-1988-2026-0339
Vulnerability from gna-1988 – Published: 2026-09-11 07:55 – Updated: 2026-09-11 07:55
VLAI
EPSS
VEX
Title
[NotCVE-2026-0001] Cloudflare Universal SSL CAA augmentation weakens RFC 8657 account binding — CVE-2026-14440 assigned 163 days after public no-CVE disclosure
Summary
----------------------------------------------------------------------------
NotCVE Disclosure Update — NotCVE-2026-0001 / CVE-2026-14440
----------------------------------------------------------------------------
[-] Summary:
On 2026-01-19 the issue described below was published as NotCVE-2026-0001
after no CVE identifier was assigned for it. On 2026-07-01 — 163 days
later — Cloudflare assigned CVE-2026-14440 to the same issue, now rated
CVSS 9.1. This message documents the disclosure timeline for the public
record.
[-] Affected:
Cloudflare Universal SSL (managed CAA record augmentation) — service-side
behaviour; no customer-side patch applicable.
[-] Technical Description:
Cloudflare Universal SSL automatically adds CAA issue/issuewild records
when a customer has Universal SSL enabled and publishes any CAA records
for the zone. These auto-added records are not shown in the Cloudflare
dashboard but are returned in DNS responses, and can include permissive
authorizations such as:
CAA 0 issue "letsencrypt.org"
CAA 0 issuewild "letsencrypt.org"
When a domain owner uses RFC 8657 CAA extensions (accounturi and/or
validationmethods) to restrict certificate issuance to a specific
authorized ACME account or validation method, the presence of an
auto-added CAA issue property WITHOUT those RFC 8657 constraints broadens
authorization: per RFC 8657, a CAA property without an accounturi
parameter matches any account. This weakens the domain owner's intended
account binding and may enable unauthorized DV certificate issuance.
[-] Disclosure Timeline:
[19/01/2026] - Public record published as NotCVE-2026-0001; no CVE
identifier assigned at that time
[01/07/2026] - Cloudflare assigns CVE-2026-14440 (CVSS 9.1) for the same
issue, 163 days after the public record
[-] CVE Reference:
CVE-2026-14440
[-] References:
https://notcve.org/notcve/NotCVE-2026-0001 (full technical record,
preserved since day one)
https://notcve.org/cve/CVE-2026-14440
[-] About NotCVE:
NotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to
vulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?
Request a NotCVE: https://notcve.org/form/ · Contributors:
https://notcve.org/hall/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
9 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cloudflare | Universal Ssl |
Affected:
unknown
|
Relationships
reference
GCVE-1988-2026-0339 (this record)
- related CVE-2026-14440
{
"containers": {
"cna": {
"affected": [
{
"product": "Universal Ssl",
"vendor": "Cloudflare",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "NotCVE Advisories"
}
],
"descriptions": [
{
"lang": "en",
"value": "----------------------------------------------------------------------------\nNotCVE Disclosure Update \u2014 NotCVE-2026-0001 / CVE-2026-14440\n----------------------------------------------------------------------------\n\n[-] Summary:\n\nOn 2026-01-19 the issue described below was published as NotCVE-2026-0001\nafter no CVE identifier was assigned for it. On 2026-07-01 \u2014 163 days\nlater \u2014 Cloudflare assigned CVE-2026-14440 to the same issue, now rated\nCVSS 9.1. This message documents the disclosure timeline for the public\nrecord.\n\n[-] Affected:\n\nCloudflare Universal SSL (managed CAA record augmentation) \u2014 service-side\nbehaviour; no customer-side patch applicable.\n\n[-] Technical Description:\n\nCloudflare Universal SSL automatically adds CAA issue/issuewild records\nwhen a customer has Universal SSL enabled and publishes any CAA records\nfor the zone. These auto-added records are not shown in the Cloudflare\ndashboard but are returned in DNS responses, and can include permissive\nauthorizations such as:\n\n CAA 0 issue \"letsencrypt.org\"\n CAA 0 issuewild \"letsencrypt.org\"\n\nWhen a domain owner uses RFC 8657 CAA extensions (accounturi and/or\nvalidationmethods) to restrict certificate issuance to a specific\nauthorized ACME account or validation method, the presence of an\nauto-added CAA issue property WITHOUT those RFC 8657 constraints broadens\nauthorization: per RFC 8657, a CAA property without an accounturi\nparameter matches any account. This weakens the domain owner\u0027s intended\naccount binding and may enable unauthorized DV certificate issuance.\n\n[-] Disclosure Timeline:\n\n[19/01/2026] - Public record published as NotCVE-2026-0001; no CVE\n identifier assigned at that time\n[01/07/2026] - Cloudflare assigns CVE-2026-14440 (CVSS 9.1) for the same\n issue, 163 days after the public record\n\n[-] CVE Reference:\n\nCVE-2026-14440\n\n[-] References:\n\nhttps://notcve.org/notcve/NotCVE-2026-0001 (full technical record,\n preserved since day one)\nhttps://notcve.org/cve/CVE-2026-14440\n\n[-] About NotCVE:\n\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ \u00b7 Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T07:55:56Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Jul/22"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://notcve.org"
},
{
"url": "https://notcve.org/cve/CVE-2026-14440"
},
{
"url": "https://notcve.org/form/"
},
{
"url": "https://notcve.org/hall/"
},
{
"url": "https://notcve.org/notcve/NotCVE-2026-0001"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Jul/22"
],
"discovery": "EXTERNAL"
},
"title": "[NotCVE-2026-0001] Cloudflare Universal SSL CAA augmentation weakens RFC 8657 account binding \u2014 CVE-2026-14440 assigned 163 days after public no-CVE disclosure",
"x_gcve": [
{
"recordType": "reference",
"relationships": [
{
"destId": "CVE-2026-14440",
"type": "related"
}
],
"vulnId": "GCVE-1988-2026-0339",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/22",
"automated": true,
"contentSha256": "74c32742b1845f9d69c269583c1496d4b7bcc719376171964a308397dc9fea62",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/22",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-07-13T13:10:43Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0339"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-11T07:55:56Z",
"dateUpdated": "2026-09-11T07:55:56Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0339"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-14440 (GCVE-0-2026-14440)
Vulnerability from nvd – Published: 2026-07-01 22:35 – Updated: 2026-07-02 19:22
VLAI
EPSS
VEX
Title
Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records
Summary
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
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-02 19:22 UTC
CWE
- CWE-693 - Protection Mechanism Failure
Assigner
References
8 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cloudflare | Universal SSL |
Affected:
0 , ≤ current
(custom)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2026-14440",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-02T19:22:08.681269Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-693",
"description": "CWE-693 Protection Mechanism Failure",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-02T19:22:18.404Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/"
},
{
"tags": [
"related"
],
"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": [
"technical-description",
"exploit"
],
"url": "https://zenodo.org/records/18330221"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"platforms": [
"Cloud Service"
],
"product": "Universal SSL",
"vendor": "Cloudflare",
"versions": [
{
"lessThanOrEqual": "current",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cb\u003eDescription:\u003c/b\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003eTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s 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.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eExploitation 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.\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation:\u0026nbsp;\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eUniversal SSL\u0027s 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.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eCredits:\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "Description:\n\n\n\n\nTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s 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\u0027s 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"
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "ADJACENT",
"baseScore": 7.6,
"baseSeverity": "HIGH",
"exploitMaturity": "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",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-01T22:35:10.353Z",
"orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
"shortName": "cloudflare"
},
"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"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cb\u003e\u003cp\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/p\u003e\u003cp\u003eUniversal SSL\u0027s 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.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e"
}
],
"value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records",
"x_generator": {
"engine": "Vulnogram 1.0.2"
}
}
},
"cveMetadata": {
"assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
"assignerShortName": "cloudflare",
"cveId": "CVE-2026-14440",
"datePublished": "2026-07-01T22:35:10.353Z",
"dateReserved": "2026-07-01T22:20:45.895Z",
"dateUpdated": "2026-07-02T19:22:18.404Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-14440 (GCVE-0-2026-14440)
Vulnerability from cvelistv5 – Published: 2026-07-01 22:35 – Updated: 2026-07-02 19:22
VLAI
EPSS
VEX
Title
Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records
Summary
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
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-02 19:22 UTC
CWE
- CWE-693 - Protection Mechanism Failure
Assigner
References
8 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Cloudflare | Universal SSL |
Affected:
0 , ≤ current
(custom)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2026-14440",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-02T19:22:08.681269Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-693",
"description": "CWE-693 Protection Mechanism Failure",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-02T19:22:18.404Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/"
},
{
"tags": [
"related"
],
"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": [
"technical-description",
"exploit"
],
"url": "https://zenodo.org/records/18330221"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"platforms": [
"Cloud Service"
],
"product": "Universal SSL",
"vendor": "Cloudflare",
"versions": [
{
"lessThanOrEqual": "current",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cb\u003eDescription:\u003c/b\u003e\u003c/p\u003e\u003cbr\u003e\u003cp\u003eTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s 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.\u003c/p\u003e\u003cbr\u003e\u003cp\u003eExploitation 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.\u003c/p\u003e\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eMitigation:\u0026nbsp;\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eUniversal SSL\u0027s 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.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003e\u003cb\u003eCredits:\u003c/b\u003e\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cspan\u003eDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher\u003c/span\u003e\u003c/p\u003e\u003cp\u003e\u003cb\u003e\u003c/b\u003e\u003cbr\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "Description:\n\n\n\n\nTo issue and renew TLS certificates on behalf of customers, Cloudflare\u0027s Universal SSL feature automatically manages the CAA RRset for the customer\u0027s zone. This auto-managed RRset is permissive by design (e.g. \u0027issue \"letsencrypt.org\"\u0027 without parameters). On Universal SSL zones, Cloudflare\u0027s 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\u0027s 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"
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "ADJACENT",
"baseScore": 7.6,
"baseSeverity": "HIGH",
"exploitMaturity": "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",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-01T22:35:10.353Z",
"orgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
"shortName": "cloudflare"
},
"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"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cb\u003e\u003cp\u003eCustomers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\u003c/p\u003e\u003cp\u003eUniversal SSL\u0027s 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.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCertificate Transparency monitoring is recommended for all customers as a general detection control.\u003c/p\u003e\u003c/b\u003e\u003cbr\u003e"
}
],
"value": "Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.\n\n\n\nUniversal SSL\u0027s 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."
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Cloudflare Universal SSL automatically managed CAA RRset supersedes customer-configured CAA records",
"x_generator": {
"engine": "Vulnogram 1.0.2"
}
}
},
"cveMetadata": {
"assignerOrgId": "a22f1246-ba21-4bb4-a601-ad51614c1513",
"assignerShortName": "cloudflare",
"cveId": "CVE-2026-14440",
"datePublished": "2026-07-01T22:35:10.353Z",
"dateReserved": "2026-07-01T22:20:45.895Z",
"dateUpdated": "2026-07-02T19:22:18.404Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}