{
  "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",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-14440",
      "date": "2026-10-30",
      "epss": "0.00198",
      "percentile": "0.0965"
    },
    "nvd": {
      "cve": {
        "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\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"
          },
          {
            "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"
          }
        ]
      }
    },
    "vulnrichment": {
      "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-02T13:13:33.214Z",
              "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"
    }
  }
}