CVE-2026-14440

Full vulnerability record from the local CVENow database.

Description

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

HIGH

CVSS score

7.6 (v4.0)

Vulnerability status

Awaiting Analysis

Source identifier

[email protected]

Published

2026-07-01 23:16:52.007000

Last modified

2026-10-25 21:10:00.770000

View original CVE JSON

{
  "id": "CVE-2026-14440",
  "sourceIdentifier": "[email protected]",
  "published": "2026-07-01T23:16:52.007",
  "lastModified": "2026-10-25T21:10:00.770",
  "vulnStatus": "Awaiting Analysis",
  "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: \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. \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ón:\n\nPara emitir y renovar certificados TLS en nombre de los clientes, la función Universal SSL de Cloudflare gestiona automáticamente el RRset CAA para la zona del cliente. Este RRset autogestionado es permisivo por diseño (p. ej., ’issue “letsencrypt.org”’ sin parámetros). 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ás estricto utilizando los parámetros accounturi o validationmethods de RFC 8657, la Autoridad de Certificación no observa esos parámetros al evaluar el RRset servido bajo RFC 8659. Como resultado, las protecciones de enlace de cuenta y de enlace de método de validación de RFC 8657 no se aplican de extremo a extremo en las zonas Universal SSL. Una explotación exitosa podría resultar en la emisión de un certificado TLS de confianza para el navegador a un atacante, permitiendo MitM contra el dominio afectado.\n\nLa explotación no es trivial en la práctica: un atacante necesitaría tener una cuenta ACME en una de las Autoridades de Certificación en el RRset CAA servido y satisfacer simultáneamente la validación de control de dominio a través de las múltiples Perspectivas de Red geográficamente distintas en las que la CA confía para la Corroboración de Emisión Multi-Perspectiva. Los prefijos de Cloudflare se anuncian por anycast desde cientos de ubicaciones a nivel mundial, elevando el listón contra los secuestros BGP de un solo punto de vista. Cualquier emisión incorrecta resultante de un certificado de confianza para el navegador está sujeta al registro de Transparencia de Certificados requerido por los principales navegadores, y sería visible para la monitorización de CT.\n\nMitigación:\n\nLos clientes que requieren una aplicación estricta de RFC 8657 necesitan deshabilitar Universal SSL en la zona afectada.\n\nLa gestión automática de CAA de Universal SSL y la aplicación de los parámetros 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ón alternativa en el producto que preserve ambos.\n\nSe recomienda la monitorización de Transparencia de Certificados para todos los clientes como un control de detección general.\n\nCréditos:\n\nDavid Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), investigador independiente"
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "Cloudflare",
          "product": "Universal SSL",
          "defaultStatus": "unaffected",
          "platforms": [
            "Cloud Service"
          ],
          "versions": [
            {
              "version": "0",
              "lessThanOrEqual": "current",
              "versionType": "custom",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV40": [
      {
        "source": "[email protected]",
        "type": "Secondary",
        "cvssData": {
          "version": "4.0",
          "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",
          "baseScore": 7.6,
          "baseSeverity": "HIGH",
          "attackVector": "ADJACENT",
          "attackComplexity": "HIGH",
          "attackRequirements": "PRESENT",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "subAvailabilityImpact": "NONE",
          "exploitMaturity": "NOT_DEFINED",
          "confidentialityRequirement": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "availabilityRequirement": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "valueDensity": "NOT_DEFINED",
          "vulnerabilityResponseEffort": "NOT_DEFINED",
          "providerUrgency": "NOT_DEFINED"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "baseScore": 6.8,
          "baseSeverity": "MEDIUM",
          "attackVector": "ADJACENT_NETWORK",
          "attackComplexity": "HIGH",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "availabilityImpact": "NONE"
        },
        "exploitabilityScore": 1.6,
        "impactScore": 5.2
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-07-02T19:22:08.681269Z",
          "id": "CVE-2026-14440",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-693"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/",
      "source": "[email protected]"
    },
    {
      "url": "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/",
      "source": "[email protected]"
    },
    {
      "url": "https://www.rfc-editor.org/rfc/rfc8657",
      "source": "[email protected]"
    },
    {
      "url": "https://www.rfc-editor.org/rfc/rfc8659",
      "source": "[email protected]"
    },
    {
      "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",
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
    }
  ]
}