Backdoored art-template npm package delivered iOS browser exploit kit through watering-hole attacks

A compromised version of the popular JavaScript templating package art-template was used to turn websites into watering holes for an iOS browser exploit kit. The attack targeted users who visited pages that loaded the browser-side bundle from affected package versions.

The Socket report said the compromised package delivered a Coruna-like iOS Safari exploit framework through a supply chain attack. Instead of attacking developers at install time, the malicious code targeted site visitors through injected browser-side JavaScript.

The incident shows why front-end dependencies can create risk far beyond the build system. A poisoned browser bundle can silently reach users of every website that ships it, even when developers see no obvious change in their own application code.

What happened to art-template

art-template is a JavaScript template engine used in web projects, especially in the Chinese developer community. The last known clean release cited by researchers was version 4.13.2, published in 2018 by the original maintainer.

Newer releases later appeared under different npm publisher accounts. According to SafeDep’s analysis, versions 4.13.3 through 4.13.6 contained suspicious or unauthorized activity, while 4.13.5 and 4.13.6 carried clear plaintext script injections in the browser bundle.

The injected code was placed in lib/template-web.js, not in the normal Node.js entry point. That means the main danger came from applications that loaded or bundled the client-side browser version, rather than server-only Node.js usage.

Version	Researcher finding	Risk summary
4.13.2	Last known clean version cited by researchers	Recommended rollback target
4.13.3	Obfuscated String.fromCharCode injection reported	Suspicious browser-side loader behavior
4.13.4	No injection detected in SafeDep’s analysis	Still part of the suspicious publishing timeline
4.13.5	Plaintext script loader added	Loads external JavaScript from v3.jiathis.com
4.13.6	Plaintext script loader added	Loads an updated external JavaScript payload

GitHub advisory marks two versions as malware

The GitHub Advisory Database lists art-template 4.13.5 and 4.13.6 as affected by malware and says there is no patched version. GitHub also classifies the issue under CWE-506, which covers embedded malicious code.

The advisory recommends treating any computer that installed or ran the affected package as compromised. That advice is strict because malware in development dependencies can expose tokens, secrets, build systems, and downstream application users.

In this case, researchers found no install hooks in the compromised package. However, that does not make the incident harmless. The browser bundle was enough to create a watering-hole delivery chain for users visiting affected sites.

How the browser-side injection worked

Versions 4.13.5 and 4.13.6 appended a loadScript function to the browser bundle. That function created a script element and loaded JavaScript from v3.jiathis.com, a domain that no longer appears to represent the original JiaThis social sharing service.

The payload behaved differently depending on how it was requested. SafeDep found that a plain command-line request returned almost nothing, while browser-like requests with a Referer header triggered a multi-stage response. This filtering can help attackers hide from basic scanners.

The injected chain eventually redirected eligible visitors toward a watering-hole page that loaded an iOS exploit framework. The Socket analysis linked that framework to Coruna-like delivery patterns, including target checks, anti-bot logic, and server-gated payload modules.

Why this was a watering-hole attack

A watering-hole attack compromises a trusted website or software path so attackers can reach visitors who already trust that environment. Here, the poisoned npm package made legitimate websites potential delivery points for the exploit chain.

Developers who shipped the affected browser bundle may have unknowingly delivered malicious JavaScript to their own users. The victim did not need to install a malicious app or open an email attachment. Visiting a page that loaded the compromised bundle could start the targeting process.

This makes the attack especially serious for consumer-facing web applications. A single dependency can sit deep inside a build chain, yet still execute in every visitor’s browser once deployed.

The exploit kit focused on iOS Safari users

The malicious framework performed browser and device checks before continuing. It targeted Safari on vulnerable iOS versions and exited when the device or browser did not match the expected profile.

Google previously described Coruna as an iOS exploit kit with five exploit chains and 23 exploits, targeting iPhone models running iOS 13.0 through 17.2.1. Google also said the kit was not effective against the latest iOS version at the time of its report.

That targeting pattern matters because it points to browser-level exploitation rather than ordinary credential phishing. The exploit chain attempted to identify eligible devices, pass anti-bot checks, and fetch modules only when the target matched the attacker’s requirements.

CVE-2024-23222 explains the iOS 17.3 cutoff

The hard cutoff around iOS 17.3 aligns with Apple’s patching timeline for CVE-2024-23222, a WebKit type confusion issue. Apple said processing maliciously crafted web content could lead to arbitrary code execution and noted that it was aware of a report that the issue may have been exploited.

Apple addressed the issue in iOS 17.3 and iPadOS 17.3, along with related WebKit fixes. The Coruna research and the art-template campaign both show why users should keep iPhones updated, especially when browser exploits can run through ordinary web content.

For users, the practical lesson is direct. If an iPhone still runs an older iOS build in the vulnerable range, a malicious website can create more risk than a suspicious app download.

What data and activity were at risk

The public reports do not prove every exposed visitor was successfully exploited. The risk came from the attack chain’s ability to load an iOS browser exploit kit through websites that used the compromised browser bundle.

Google’s earlier work on Coruna said later-stage payloads were tied to financial theft activity, including modules that searched for cryptocurrency wallet-related data. The Google analysis also warned that advanced exploit capabilities had moved across different threat actors.

For developers and site owners, the exposure depends on whether affected versions reached production, whether the browser bundle was used, whether visitors matched the targeting rules, and whether the attacker’s infrastructure served final payloads during those visits.

What developers should check immediately

Developers should audit package-lock.json, pnpm-lock.yaml, yarn.lock, build artifacts, CDN files, and deployed JavaScript bundles for art-template versions and external loader strings. The most urgent checks involve versions 4.13.5 and 4.13.6, while researchers also recommend reviewing 4.13.3.

• Search dependency locks for art-template 4.13.3, 4.13.5, and 4.13.6.
• Roll back to art-template 4.13.2 or remove the package if possible.
• Search browser bundles for v3.jiathis.com and git.youzzjizz.com references.
• Review CDN caches and previously deployed static assets.
• Check web server logs for requests to compromised script paths.
• Rotate secrets if affected versions ran in development or CI environments.
• Notify users if production pages served the malicious browser bundle.

Why lockfiles and bundle review matter

JavaScript projects often pin dependencies through lockfiles, but teams may still pull malicious versions during updates, rebuilds, CI runs, or image creation. A package compromise can also persist in compiled bundles after the dependency itself gets removed.

The SafeDep report advised users to pin art-template to 4.13.2 or earlier and check build artifacts for references to malicious external domains. That guidance matters because production bundles can outlive the package version that created them.

Security teams should also review subresource integrity, dependency review policies, package provenance, npm maintainer changes, and any browser bundle that unexpectedly loads third-party scripts at runtime.

Area to inspect	What to look for	Why it matters
Lockfiles	art-template 4.13.3, 4.13.5, or 4.13.6	Shows whether builds pulled suspicious versions
Static bundles	External script loaders and suspicious domains	Malicious code may remain after dependency cleanup
CDN caches	Old JavaScript files served to users	Cached assets can keep the attack alive
Web logs	Requests linked to malicious loader domains	Helps estimate possible user exposure
CI systems	Package install timing and exposed tokens	Build systems often hold sensitive credentials

iPhone users should update and consider extra protections

Users who keep iPhones updated have a much stronger defense against this type of browser exploit chain. The exploit kit targeted older iOS versions and lost effectiveness after Apple patched the relevant WebKit flaws.

Apple’s iOS 17.3 security notes list CVE-2024-23222 as a WebKit issue that could allow arbitrary code execution through malicious web content. Users who cannot update should consider stronger browsing protections and avoid unknown links, especially from sites that may have been compromised.

High-risk users, including journalists, activists, executives, crypto holders, and people targeted by spyware operators, should also consider Lockdown Mode where appropriate. It reduces some browser and web content attack surfaces, although it may limit certain features.

Why this incident matters

This attack shows that software supply chain compromises do not always focus on stealing developer secrets during installation. Some compromises poison the code that developers ship to users.

That changes the blast radius. One package update can turn many legitimate websites into delivery points for a browser exploit, especially when the malicious code sits inside a front-end bundle that runs automatically for visitors.

The GitHub advisory gives teams a clear signal to treat the affected releases seriously. The safest response is to remove the compromised versions, rebuild and redeploy clean assets, review logs, rotate exposed secrets where needed, and check whether users may have received the malicious bundle.

The broader lesson is simple: dependency security must include the browser output, not just package install behavior. Front-end code runs on user devices, and a compromised package can turn that trust into an attack channel.

FAQ