Recently, a security issue regarding the Ledger front-end library was discovered. The hacker obtained the publishing rights of the library, planted malicious code in the ledgerhq/connect-kit library, and subsequently released a new version. Typically, this does not pose an immediate security concern, as only those users who have updated their version of the library and integrated the new version of the code into their websites will be affected by the malicious code.
However, there is a special point of risk here. Due to the version update policy of the ledgerhq/connect-kit library, any website that relies on the ledgerhq/connect-kit-loader library and uses the loadConnectKit function will automatically get the latest code whenever a new 1.xx version appears. This is because many websites reference these libraries through the @1 tag of the CDN address. This approach will pull the latest code of version 1.xx by default. This is a common practice for third-party CDN front-end resource version control.
Hackers can exploit this mechanism to initiate deceptive transactions through dynamically loaded code. This kind of npm package that relies on third-party CDN sources will become a new supply chain attack channel. What's more serious is that after the attacker releases a new version, users may be attacked without actively updating.
Taking premint as an example, many front-end websites rely on external CDNs to reference packages on npm, such as unpkg or cdnjs. As shown in the figure below, premint directly depends on the latest version. This introduces a risk: an attacker only needs to release a new version without requiring users to update, and users may be vulnerable to attacks. Therefore, when using external CDN resources, you must be highly vigilant about security risks. This method may become a new form of CDN poisoning attack.