Out of curiosity, could this have been a vector for a supply chain attack?

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

▲

theallan 2 days ago | parent [-]

> Out of curiosity, could this have been a vector for a supply chain attack?

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

	▲	Arbortheus 2 days ago \| parent \| next [-]
		Thanks for the pleasant reply! 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.
	▲	privatelypublic 2 days ago \| parent \| prev [-]
		I seem to recall enjoying using datatables. You, or somebody else associated helped me on the forums. Not sure what I asked but I remember two things: positive dev interaction, and the pain of figuring out how to make the OOX/Excel export not lose proceeding zeros. (Had to write my own handler to change the xml)