Showing all 1 blog posts

Blog Navigation Instructions

Cybersecurity Briefing

The 2023 jabber.ru Attack Exposes a Critical Cloudflare Flaw in 2026

• •
A wounded knight in armor slumped in defeat, holding a large shield with the Cloudflare logo that has been pierced by a bullet hole.

Print Metadata Summary

Document Information

Published:
Modified:
Language:
EN
Digital Object Identifier (DOI):
10.5281/zenodo.18201412
License:
CC BY 4.0

Author Information

Author:

Academic Identifiers

ISNI:
0000 0005 1802 960X
ORCID:
0009-0005-2713-9242
VIAF:
139173726847611590332
ResearcherID:
LPQ-0554-2024

Knowledge Graphs

Wikidata:
Q130604188

Other Identifiers

Google Scholar:
ZCoKxAQAAAAJ
MusicBrainz:
345819dd-e878-4a1a-8544-e3c75a110e4f
LinkedIn:
david-osipov
GitHub:
DavidOsipov

Citation Information

APA Style

Osipov, D. (2025) The 2023 jabber.ru attack exposes a critical Cloudflare flaw in 2026. Retrieved from https://doi.org/10.5281/zenodo.18201412.

BibLaTeX

              @article{osipov-2025-the-2023-jabber-ru-attack-expose2025-12-31,
  author = {David Osipov},
  author+an:orcid = {1="https://orcid.org/0009-0005-2713-9242"},
  author+an:isni = {1="https://isni.org/isni/000000051802960X"},
  author+an:wikidata = {1="https://www.wikidata.org/wiki/Q130604188"},
  author+an:viaf = {1="https://viaf.org/viaf/139173726847611590332"},
  title = {The 2023 jabber.ru Attack Exposes a Critical Cloudflare Flaw in 2026},
  date = {2025-12-31},
  doi = {10.5281/zenodo.18201412},
  url = {https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/}
}

Abstract

This article analyzes a critical security vulnerability in Cloudflare's Universal SSL, where the automatic injection of permissive CAA records actively nullifies the IETF standard RFC 8657. By overriding user-defined account binding parameters, this configuration re-opens the exact security gap exploited in the 2023 jabber.ru MitM attack, leaving millions of domains vulnerable to BGP hijacking and unauthorized TLS certificate issuance. The analysis demonstrates that this is not a technical oversight but a design choice that neutralizes the `accounturi` and `validationmethods` security controls, and argues that Cloudflare must implement strict ACME account binding to mitigate this risk.

Backstory

This investigation began after my own failed attempt to implement RFC 8657 CAA records on my Cloudflare-hosted domains. When I discovered that Cloudflare was silently *overwriting* my security-hardened CAA records, I realized millions of free-tier users were unknowingly vulnerable to the same MitM attack that compromised jabber.ru in 2023. After a month of silence from Cloudflare's community team, followed by a dismissive response citing 'standard adoption timelines,' I knew this issue needed broader exposure. My subsequent article on Habr.com became the week's top post, confirming the community's concern about this artificial security gap.

Audio Overview

Audio Presentation: The 2023 jabber.ru Attack Exposes a Critical Cloudflare Flaw in 2026 by David Osipov is licensed under CC BY 4.0 .
Audio overview of how Cloudflare's Universal SSL weakens RFC 8657 protections. Download audio file

Video Overview

Cloudflare Security Gap: How the 2023 jabber.ru Attack Exposes a Critical Flaw in 2026 by David Osipov is licensed under CC BY 4.0 .
Video walkthrough of the Cloudflare CAA validation gap and resulting MitM exposure.

TL;DR

The Mechanism

Cloudflare’s Universal SSL injects permissive CAA records that override user DNS constraints, causing certificate authorities to ignore strict account-binding checks.

The Risk

This enables BGP hijacking and network interception to obtain unauthorized TLS certificates by bypassing accounturi and validationmethods.

The Precedent

The configuration replicates the gap exploited in the 2023 jabber.ru MitM, where intercepted traffic satisfied http-01 validation challenges.

The Mitigation

Cloudflare must stop overriding user DNS records or fully implement RFC 8657 to restrict certificate issuance to the domain owner’s authorized ACME account.

Introduction: A Critical Security Gap in Cloudflare’s Universal SSL

I have identified a significant, yet easily fixable security weakness in Cloudflare’s Universal SSL that affects millions of users, and my attempts to address it directly with Cloudflare [1a] have been… well, let’s call it “unsuccessful.”

The issue is best understood through the lens of the jabber.ru MitM attack [2], that took place in . Back then, government-backed attackers were able to intercept traffic for jabber.ru at the network level. By doing this, they could satisfy the http-01 domain validation challenge from Let’s Encrypt and were issued a valid TLS certificate for the domain. They did not need to compromise the server itself.

RFC 8659 vs RFC 8657: The CAA Standards Explained

To understand the problem, you need to understand the solution. The defense against this attack is built on two IETF standards.

1. The Basic Standard: RFC 8659 (CAA)

First, there’s the basic CAA standard, [3], which updates the original [4]. This is what you can call “brand-level trust.” It lets you put a record in your DNS that says:

david-osipov.vision. IN CAA 0 issue “letsencrypt.org”

This record tells all Certificate Authorities (CAs): “Only Let’s Encrypt can issue a certificate for my domain.”

This is good, but it’s not enough. It means anyone who can pass Let’s Encrypt’s validation challenge can get a cert. If an attacker hijacks your web server or (as in the jabber.ru case) your network traffic, they can pass the challenge and get a valid cert from your authorized CA.

2. The Real Standard: RFC 8657 (The ACME Extensions)

This is where [5] comes in. It was published in and was designed specifically to prevent this kind of attack. It’s an upgrade from “brand-level trust” to a “process-level trust.” It adds two critical parameters: accounturi and validationmethods.

The accounturi parameter is your “second factor.”

It’s a record that says: “Only Let’s Encrypt, using my specific account, can issue a certificate for my domain.”

david-osipov.vision. IN CAA 0 issue “letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY_ACCOUNT_ID”

If this had been in place for jabber.ru, the attackers’ request from their own Let’s Encrypt account would have been rejected by the CA, and the attack would have failed. The author of RFC 8657 (Hugo Landau) himself confirmed this in his paper Mitigating the Hetzner/Linode XMPP.ru MitM interception incident[6].

The validationmethods parameter is your “attack vector shield.”

This parameter lets you specify how the CA is allowed to validate your domain. This is the part that would have directly blocked the jabber.ru attack.

Technical Deep Dive: http-01 vs. dns-01

  • http-01 challenge: The CA asks you to put a specific file on your web server at http://your.domain/.well-known/acme-challenge/. This proves you control the web server, but it’s vulnerable to network-level BGP hijacking. Attackers don’t need to touch your server; they just need to intercept the CA’s request, which is exactly what happened to jabber.ru.
  • dns-01 challenge: The CA asks you to put a specific TXT record in your DNS. This proves you control the DNS, which is almost always a more secure and separate asset from your web server.

By setting this record, you forbid the CA from using the vulnerable http-01 method entirely:

david-osipov.vision. IN CAA 0 issue “letsencrypt.org; validationmethods=dns-01”

If jabber.ru had either of these RFC 8657 records, the attack would have been dead on arrival.

The Cloudflare Problem: A “Feature Collision”

Now, the core issue. As a B2B Product Manager, I don’t see this as a “bug”—I see it as a feature collision where the needs of a (badly designed) product feature are actively destroying user security.

Here is the problem: When you use Cloudflare’s free Universal SSL, Cloudflare automatically adds its own CAA records for its partner CAs (Let’s Encrypt, Google Trust Services, etc.) [7a]. These records do not use the accounturi or validationmethods parameters.

Worse, if you try to add your own secure CAA record (like the ones above, that I showed you), Cloudflare’s system sees it and says, “Oh, the user is adding a CAA record! I should ‘helpfully’ add my own permissive ones too! And if user’s records conflict with mine, I’ll just replace them with mine to make sure my system works smoothly.”

So the final DNS response looks like this:

  1. ... IN CAA 0 issue "letsencrypt.org; accounturi=.../MY_ACCOUNT_ID" (Your secure record is being replaced by…)
  2. ... IN CAA 0 issue "letsencrypt.org" (…this one. Cloudflare’s “helpful” insecure record)

According to the rules, a CA is allowed to issue a certificate if any matching record permits it. Your secure record (1) correctly blocks the attacker, but Cloudflare’s injected record (2) replaces your own and it explicitly permits an malicious actor to undertake an attack.

Cloudflare’s “feature” actively and silently nullifies the IETF-standard security control. It recreates the exact vulnerability that jabber.ru suffered from for millions of its users.

Now look at practical exploit:

  • Setup: A user delegates their dns-01 challenge using a CNAME to an acme-dns server they don’t fully control (a common, secure pattern).
  • Intended Security: The user sets an accounturi record to ensure only their own ACME account can use this delegation.
  • The Cloudflare Flaw: Cloudflare replaces user’s records with its permissive issue “letsencrypt.org” record.
  • The Attack: The (untrusted) admin of the acme-dns server can now use their own Let’s Encrypt account to get a valid certificate for the user’s domain, completely bypassing the user’s accounturi “second factor.”

This Isn’t Just Cloudflare: A Pattern of “Platform vs. Provider”

To be fair (and to be more “academic”), Cloudflare isn’t the only one with this problem. This is a systemic flaw in any “integrated platform” that bundles “magic” automated SSL with hosting. The magic must override your security to function.

Provider behavior comparison
Provider TypeProviderThe “Product” vs. “Security” Conflict
Integrated PlatformCloudflareInjects permissive records that nullify user-defined accounturi records. [8]
Integrated PlatformVercelAlso injects permissive records of Let’s Encrypt. [9]
Integrated PlatformAWS (ACM)Requires you to add a permissive issue “amazon.com” record for its own managed certificates to work. [10]
Integrated PlatformGoogle Cloud (Cert Manager)Requires a permissive issue “pki.goog” record to be present. No info about RFC8657 support [11]
DNS-Only ProviderDNSimpleNo conflict. As a pure DNS provider, they should have full support for all CAA parameters without interference [12], but no definitive information of full RFC8657 support
DNS-Only ProviderAWS (Route 53)No conflict. As a DNS-only service, it fully supports custom CAA records without interference. [13]

This shows a clear, industry-wide divide. “DNS-Only” providers sell you security and control. “Integrated Platforms” sell you convenience, often at the expense of security.

The Industry’s Answer: Multi-Perspective Issuance Corroboration (MPIC)

While many platforms continued to ignore or override RFC 8657, the CA/Browser Forum moved to address the root cause at the validation layer. In the Forum approved Ballot SC-067 v3, which requires Certificate Authorities to use Multi-Perspective Issuance Corroboration (MPIC) instead of relying on a single, local vantage point for domain validation.

The Princeton connection

The CA/Browser Forum specifically cites the 2018 Princeton paper Bamboozling Certificate Authorities with BGP [14a] as a primary motivation — the attack model described there is the exact threat MPIC is designed to mitigate.[15]

The vote record shows unusually broad agreement: major issuers and major platform consumers supported the change.

Ballot SC067v3 Voting Results (July 2024)
CategoryVotes CastApproval RateKey Voters
Certificate Issuers22100% (22 Yes, 0 No)Let’s Encrypt, DigiCert, Sectigo, GlobalSign
Certificate Consumers4100% (4 Yes, 0 No)Google, Apple, Mozilla, Opera

Implementation timeline

According to the updated TLS Baseline Requirements and the ballot text, the rollout was staged:

  • : MPIC becomes RECOMMENDED for all CAs.
  • : MPIC becomes MANDATORY (minimum 2 independent perspectives required).
  • : Requirement tightens to a minimum of 3 independent perspectives.

Why MPIC doesn’t replace RFC 8657

MPIC and RFC 8657 are complementary controls:

MPIC vs RFC 8657 — Comparison
ControlPrimary purposeThreats addressed
MPIC (Multi-Perspective Issuance Corroboration)Require corroborated validation from multiple independent network vantage points before issuance.Network-level interception / BGP hijack; prevents issuance based on a single, compromised vantage point.
RFC 8657 (Account binding)Bind issuance to a specific ACME account and restrict allowed validation methods.Rogue administrators, compromised sub-accounts, and abuse by delegated/third-party DNS operators.

In short: MPIC significantly reduces the risk of mass or opportunistic BGP-based issuance attacks, but it does not remove the need for account-level locks (the protection RFC 8657 provides) when multi-tenant or delegated DNS operators are involved.

Cloudflare’s refusal to honour accounturi and validationmethods therefore remains a meaningful gap in defense-in-depth, even though MPIC should eliminate the easiest network-only attacks by 2025.

But… Is This Really a Problem? (Yes, It Is)

The jabber.ru incident is the primary, powerful case study, but the Web PKI is a graveyard of similar incidents that these standards were built to prevent.

  • - DigiNotar Breach: A complete CA compromise led to fraudulent certificates for Google, Yahoo, and more, used for state-level MitM attacks. [16] [17a] accounturi (or even basic CAA) would have been a defense.
  • - - WoSign & StartCom: These CAs were distrusted for numerous failures, including issuing certs without proper validation. [18] [17b] validationmethods would have prevented issuance via non-standard, weaker methods.
  • - Chaining Web Vulnerabilities: A researcher showed how a simple path traversal vulnerability on a web server could be used to satisfy an http-01 challenge. [19] A validationmethods=dns-01 policy would have rendered this entire attack class useless.
  • - Princeton BGP Hijacking Study: A foundational paper from Princeton University, [14b], demonstrated how BGP hijacking could be weaponized to defeat http-01 validation. The jabber.ru attack was a real-world execution of this exact threat model (network-level interception).

In each case, accounturi or validationmethods would have provided a critical, preventative layer of defense.

My Attempt to Engage Cloudflare

I’m not the first to notice this. I posted a detailed breakdown of this issue on the Cloudflare Community forum on .

Here is a verbatim summary in five acts from that thread [1b]:

Act 1 (): I submit the request “Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA”.

Act 2 (): A Cloudflare Team member (mmalden) finally responds. They claim the feature isn’t supported because RFC 8657 isn’t fully passed (incorrect) and suggest Certificate Transparency logs as an alternative. This response is marked as the “Solution.”

Act 3 (): I post a detailed rebuttal, citing Cloudflare’s history of adopting draft protocols (TLS 1.3, QUIC) years before finalization, and pointing out that RFC 8657 is already a proposed standard. I conclude: “The only logical conclusion… is that withholding RFC 8657 support is a business decision.”

Act 4 ():

grey: “I really love talking with myself in this thread :grinning_face:”
(My rebuttal remains unanswered. The “Solution” tag remains on the incorrect answer.)

Act 5 ():

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

A critical, user-reported security gap, with 1.3k views and 20 likes, was not properly “resolved.” It was auto-closed by a robot.

To bring more attention to this, I also published an article on the popular Russian tech site Habr.com [20] on , which became the top post of the week. This shows the community understands the issue, even if Cloudflare’s support process is designed to ignore it.

The Core Contradiction: A Business Decision, Not a Technical Lag

The a Cloudflare team member claimed this is not a vulnerability and that they would comply “should RFC 8657 be passed.”

This response is, as I perceive, disingenuous.

  1. RFC 8657 was published in . It’s been a standard for six years.
  2. Cloudflare has a long history of implementing critical security protocols like TLS 1.3 [21] and QUIC [22] while they were still in draft status.

To claim they must “wait” for this standard is inconsistent with their entire innovative culture. This isn’t technical lag; it’s a business decision.

When mmalden from the Cloudflare Team responded, they stated they would comply “should RFC 8657 be passed.” This response—which was officially marked as the “Solution” to the thread—is demonstrably false and contradicts Cloudflare’s own engineering history.

As I pointed out in my rebuttal to the team:

  1. The Standard is Already “Passed”: RFC 8657 is already a Proposed Standard on the IETF standards track.
  2. The “Draft” Status is not an Excuse: Cloudflare has a long history of implementing protocols years before they were finalized.
    • TLS 1.3: Cloudflare announced support on , before the RFC was finalized. [23]
    • QUIC: Cloudflare supported it on , nearly before the RFC was published. [24a]
    • ECH: They support it now since , despite it still being in draft status. [25] [26]

In their blog post on QUIC, Cloudflare explicitly bragged about this culture: “The Cloudflare Systems Engineering Team has a long history of investing time and effort to trial new technologies, often before these technologies are standardised or adopted elsewhere.” [24b]

Yet, for RFC 8657 standard that closes a critical security hole, they claim they must wait for bureaucracy?

Furthermore, the team suggested reliance on Certificate Transparency (CT) logs as a mitigation. As I explained to them, CT logs are a detection tool, not a prevention tool. They alert you after the attacker has already issued a fraudulent certificate and intercepted your traffic. This is a classic CWE-1188 weakness.

This confirms that the lack of support is not a technical oversight or a standards issue. It might be a conscious business decision to keep the “free” product vulnerable while gating secure CAA records behind paid plans.

What Should Be Done (The Fix is Not Complicated)

Cloudflare, which powers a massive portion of the web (20.4% of all sites) and holds a dominant 81.6% market share among reverse proxy providers, should do the following: [27] [28]

A Statista horizontal bar chart titled 'Cloudflare Provides Protection for One in Five Websites,' illustrating the share of worldwide websites using selected reverse proxy services as of November 19, 2025. The data shows that while 75.0% of websites utilize 'None,' Cloudflare is the dominant provider with a 20.4% websites using it. Other listed providers hold significantly smaller shares: Amazon CloudFront at 1.6%, Fastly at 0.9%, Akamai at 0.8%, and DDoS-Guard at 0.7%.

Source: Statista — Infographic. You will find more infographics at Statista.

  1. Secure Universal SSL by Default: Stop injecting permissive records. Instead, inject restrictive records using accounturi for Cloudflare’s own internal ACME accounts. This gives users the best of both worlds: they are protected by default, and if they add their own accounturi record, both are valid (theirs and Cloudflare’s), but an attacker’s is not.
  2. Enable Full User Control: Update the DNS logic. If a user defines a record for letsencrypt.org, do not inject a duplicate, permissive record for the same CA. Trust your user. This is a simple if (user_record_exists) { do_not_inject }
  3. Be Transparent: Update the documentation [7b] to explicitly explain this override behavior and the risks it creates, instead of hiding it in the fine print.

What can be done now?

Until Cloudflare updates their Universal SSL logic to respect user-defined accounturi and validationmethods parameters, there is no easy configuration for Free or Pro plan users that guarantees protection against this specific MitM vector.

However, if your threat model requires strict CAA enforcement (RFC 8657), you can achieve it by taking full control of certificate issuance:

  1. Disable Universal SSL: Navigate to SSL/TLS > Edge Certificates in your Cloudflare dashboard and toggle Disable Universal SSL. This is the critical step that stops Cloudflare from automatically injecting the permissive CAA records that override your policies.
  • Warning: This will immediately break HTTPS on your site unless you have a Custom Certificate uploaded or an Advanced Certificate active.
  1. Upload Custom Certificates (Requires Business or Enterprise Plan): For complete control, you must manually issue your own certificates (e.g., using Certbot/Let’s Encrypt with your restricted ACME account) and upload them to Cloudflare.
  • Why this works: By managing the issuance yourself, you ensure that only your specific ACME account is used. Cloudflare’s systems effectively become a passive pipe for the certificate you provide, meaning they no longer need to inject permissive CAA records to validate the domain on your behalf.
  • Requirements: The ability to upload your own custom certificates is restricted to Business and Enterprise plans.
  • Note on Advanced Certificate Manager (ACM): While the paid ACM add-on allows you to order specific certificates on lower-tier plans, Cloudflare still manages the issuance process. Therefore, ACM may not strictly prevent the CAA override behavior described in this article.
  1. For Everyone Else (Free/Pro): Aggressive CT Monitoring: If you cannot upgrade to a Business plan to upload your own certificates, you must rely on detection rather than prevention. Set up rigorous Certificate Transparency (CT) monitoring (using tools like certstream or Cloudflare’s own alerts). If you see a certificate issued for your domain by a CA you use (like Let’s Encrypt) but without your authorization, treat it as an immediate security incident.

I hope that with enough community attention, we can persuade Cloudflare to close this gap for everyone, not just their paying customers.

Thank you for taking the time to read this! I hope it was useful.

Support My Work

If this material saved you time or sparked new ideas, consider supporting my work.

Tip me on Ko-fi

The quickest way to show your appreciation

For privacy-focused donations, you can support me using cryptocurrency. Click any address to copy.

Bitcoin (BTC)

Network: Bitcoin

bc1q99evmn80nmfk8vyxs2emc9t4a4k2pdmkjlwah4
Ethereum (ETH)

Network: Ethereum

0x81bF6f880D0010F47830cbF01c0F3C8a6E825Cc3
BNB (Binance Coin)

Network: BNB Smart Chain (BSC)

0x81bF6f880D0010F47830cbF01c0F3C8a6E825Cc3
USDT (Tether)

Network: TRON

TWnLLRVX9NgZAwD5LhrzvnEfg69jxEAGgA
Monero (XMR)

Network: Monero

88MbtU2R1ufG2BcnCrkqmn3oYxvvKKR1u2yb6YeZZrQV8akocEnrHrrhzoGowkijRpLsAzTjGczfEPdL9wyzrotLTSXbEg6
Solana (SOL)

Network: Solana

BBTdnfdojXzifJaV4CG8LcsNiZpfvva5o9cCpbS3Esmg
Bitcoin Cash (BCH)

Network: Bitcoin Cash

bitcoincash:qqhv3qtsldf0w8cjzzqyame35urs0cf2xg92s2chf0
Litecoin (LTC)

Network: Litecoin

ltc1qy6wkwtlmzt0kngx8wrgt6x5v5nn2s7wqyvh23m
TRX (TRON)

Network: TRON

TWnLLRVX9NgZAwD5LhrzvnEfg69jxEAGgA
Document version history with 5 versions. Click on any row to view detailed changes for that version.

Version History 5

VersionStatusDateActions

References

28 source(s)

References

28 source(s)
Portrait of David Osipov

David Osipov

Innovative Product Leader with in B2B SaaS, specializing in AI-driven solutions, data-powered enterprise IT products, and secure SaaS platforms. Alumnus of GSOM SPbU. Active OpenStreetMap cartographer in Georgia and citizen scientist. Wikidata: Q130604188, ISNI: 0000 0005 1802 960X.

David Osipov David Zurabovich Osipov MSc B2B Product Manager