Datatables Cdn Outage – Post Incident Review
Posted4 months agoActive4 months ago
datatables.netTechstory
calmnegative
Debate
60/100
Supply Chain SecurityDomain SecurityOpen Source Software
Key topics
Supply Chain Security
Domain Security
Open Source Software
The DataTables CDN outage was caused by a domain takeover attack, sparking discussions on domain security and supply chain risks in open source software.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
14h
Peak period
26
12-24h
Avg / period
13.5
Comment distribution27 data points
Loading chart...
Based on 27 loaded comments
Key moments
- 01Story posted
Sep 16, 2025 at 3:27 PM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 5:54 AM EDT
14h after posting
Step 02 - 03Peak activity
26 comments in 12-24h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 22, 2025 at 6:48 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45266771Type: storyLast synced: 11/20/2025, 1:45:02 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The trouble is that that is the way most way modern small print is worded.
Read the small print in any contract of the last 10 years. Almost all of them when speaking about delivery of notices will apply $n days to emails.
Everyone in the tech world knows why it's a horrible idea, but sadly most lawyers who draft these things either don't care, or their client doesn't care and that's how the lawyer has been instructed to draft.
[1] <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://datatables.net/feeds/releases.xml">
[0] https://bsky.app/profile/spinda.net/post/3lx3xkzbc622t
[1] https://datatables.net/supporters/
Using it in another personal project this year.
Seriously, no idea what could motivate this, unless a paid datatables vendor felt you were undercutting their business. We all like to think that attacks are beneath them, but stuff like that has happened before.
> They used an email address intentionally crafted to look like it could be mine and submitted a fake driver's license and utility bill with information that could only have been from leaked WHOIS data. The registrar accepted this as proof of identity and started the transfer process. That included sending an email to me to confirm the transfer, an email which I never saw due to the flood of emails (which it is now easy to say was the start of the attack).
Edit: Cloudflare blocking the attackers code with a 1000 error is interesting. Could you share some information about it?
Regarding the 1000 error - I didn't have any 1:1 support contact with CloudFlare - the first I knew was they were returning 1000 errors, which I presume they were doing due to a blacklisted IP being used for the DNS resolving. I'm really not sure though.
I am currently running an fairly outdated version of datatables on a personal project, v1.11.3 from 2021. I'm not too worried about running this older version, because according to dependency scanning software there's no CVEs for it [1]. Also, upgrading this package is too tricky as there's been some pretty huge breaking changes, so I'm stuck at this older version.
I am _not_ using the datatables CDN but instead self-hosting the static files. However, I did not notice until recently that in v1.11.3 it comes with a CSS stylesheet [2] that loads a static resource from that CDN: `url("https://www.datatables.net/examples/resources/details_open.p...")`
It looks like newer versions of datatables don't import static files from the datatables CDN like this.
Presumably if this domain was hijacked as stated in this incident review, users on affect datatables version could have had their site compromised?
Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
[1] https://security.snyk.io/package/npm/datatables.net/1.11.3
[2] https://cdn.datatables.net/1.11.3/css/jquery.dataTables.css
If you were using the CDN without SRIs, then yes, that would have been the most obvious channel. However, I don't believe the attacker ever set up for that and the URLs never resolved due to CloudFlare blocking it.
> there's been some pretty huge breaking changes
Unless you were using the legacy API, there shouldn't be any major impediment [1]. I intentionally tried to keep backwards compatibility as I hate doing library upgrades myself! Drop me an email - allan at the domain in question if you have any questions about doing an upgrade.
> It looks like newer versions of datatables don't import static files from the datatables CDN like this.
I rewrote aspects to use CSS styled elements in place of images, so there were less resources to load.
> Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
Per the above, if you were using the CDN without SRI for the resources, then any version could have been susceptible. However, I've seen no evidence that the attack took that vector.
[1] https://datatables.net/upgrade/2
I thought I was not using the CDN as I had self-hosted the static sources, but some image sources seemed to be imported from the CDN in stylesheets in the version of data tables I linked.
I just updated my application from v1.11 to v1.13 without any trouble (aside from some minor aesthetic changes to padding), so at the very least I now benefit from your styled elements.
Thanks for your dedication on this package, I’ve used it for years and it works very well.
If your registrar does not expose the functionality, move to one that does.
N.B. Ideally you want Domain Lock == REGISTRY-LOCK, there is also REGISTRAR-LOCK which is similar in concept but not quite as secure because REGISTRAR-LOCK is implemented at Registrar not Registry level.