Category: Products & Platform

On 11 July 2026, an attacker published several malicious versions of our public jscrambler npm package, the command-line tool used with our Code Integrity product. The attacker had gained write access to the package’s GitHub repository and used a GitHub Actions workflow to exfiltrate the npm token we use to publish the package. They then used that token to publish their own modified versions directly to the npm registry.

We detected the unauthorized publication within seconds, through automated notifications to our package maintainers, and began our incident response immediately. The malicious versions were deprecated straight away to stop further installation through normal dependency resolution, and we published a verified-clean version the same evening. We then worked with the npm security team, who removed the malicious versions from the registry.

What Happened

A Jscrambler developer’s machine got compromised, and it contained the developer’s GitHub SSH key, as well as their npm publication credentials. The attacker then used these to publish a malicious version of our public jscrambler npm package, the open-source command-line client used to interact with Code Integrity, and the four helper packages that depend on it.

The malicious versions of the jscrambler package were:

• 8.14.0
• 8.16.0
• 8.17.0
• 8.18.0
• 8.20.0

The helper packages had one version published referencing the compromised 8.18.0:

• jscrambler-webpack-plugin 8.6.2
• gulp-jscrambler 8.6.2
• grunt-jscrambler 8.5.2
• jscrambler-metro-plugin 9.0.2

The attacker’s malicious code executed during package installation in the earlier versions (preinstall hook code), and on running the CLI in the later ones (attackers pivoted to changing the package code).

The current published version, 8.22.0, is verified clean and safe to use. Please see the end of this report for a full timeline of events.

Why Several Versions Appeared

Over a short period during our response, further malicious versions appeared after we had already published clean ones. When we first responded, we revoked the developer’s npm credentials we believed the attacker was using. In fact, they were publishing with the npm token they had exfiltrated through the GitHub Actions workflow, not the developer’s credential, so each time we released a clean version, the attacker published a new malicious one. Once we identified that token as the credential actually in use, we revoked it and enforced the additional publishing controls described below. From that point, the attacker had no further access and no new malicious versions were published.

What Was Not Affected

1. No Jscrambler product was affected.
2. No customer data was affected.

As of the time of writing, npm reports 1,614 downloads across all affected packages. However, that doesn’t mean 1,614 people were affected. On average, we see approximately ~1,837 downloads of the Jscrambler cli package a day. However, on an average Saturday, this drops significantly – we saw an average of only ~391 downloads each Saturday in the 8 weeks leading up to the incident. This suggests that most of the downloads were probably security researchers investigating this incident, rather than affected installations, especially as some of these versions were the latest version for only a matter of minutes. We have not received a single report that any customer was impacted.

To reiterate a point that matters: the jscrambler package is the open-source command-line client used to interact with Code Integrity, and it is not the Code Integrity product or service itself. Only that CLI tool was affected. The Code Integrity platform was not compromised, and there are many ways of using Code Integrity that never involved the affected package versions at all.

Webpage Integrity and Iframe Integrity are separate products and were never at risk.

The jscrambler package sits outside our product infrastructure, and our investigation has found no evidence that our production or customer-facing systems, or customer data, were affected.

Attackers in this situation sometimes change the code itself. Using a forced push, they can even insert very old changes to the code. For that reason, we have also reviewed the full commit history of the package’s repository and confirmed that our source code was not altered. The malicious versions were artifacts published with the stolen token, not changes to the code in our repository.

What You Should Do

If you use the Code Integrity jscrambler package, check whether you or any automated process installed one of the affected versions:

• If you installed jscrambler at version 8.14.0, 8.16.0, 8.17.0, 8.18.0 or 8.20.0, treat it as an affected install.
• If you installed any of the helper packages at the versions listed above, treat those as affected too, because they resolved to the compromised 8.18.0.

If you are affected, we recommend that you update to jscrambler 8.22.0 (or the current fixed versions of the dependent packages), reinstall from a clean state, and rotate any credentials that were available in the environment where the affected version ran, as a precaution.

If you only use Webpage Integrity or Iframe Integrity, no action is required.

Looking ahead, because the malicious versions were live only briefly before we replaced them with a clean release, teams that do not install brand-new versions the moment they are published would not have been exposed. Most package managers now support a minimum release age, sometimes called a cooldown, which holds back a newly published version until it has been available for a set number of days. npm supports this through its min-release-age setting and pnpm through minimumReleaseAge. Enabling it is a simple and effective way to reduce exposure to this class of supply chain issues, and we recommend it.

What We Have Changed

Things that we started implementing immediately:

• Enabled multi-factor authentication for automated npm release – A release produced by automation now requires a manual verification step before it is published, so no version can reach the public registry without a human check. Note this is different and on top of the existing MFA used by developers to access GitHub, npm etc.
• Rotated all relevant publishing credentials – whether compromised or not, and hardened the surrounding processes.
• Changed npm config to use set ignore-scripts true – Prevents preinstall and postinstall scripts from executing automatically, blocking one of the most common malware execution vectors in the npm ecosystem.
• Scanned for malicious packages and VS Code extensions – Continuously scans developers’ machines for known malicious packages and VS Code extensions, enabling early detection of compromised software.
• Removed unnecessary keys and tokens from developer machines – Minimizes the number of credentials available on developer workstations, reducing the impact of credential theft.
• Used min-release-age with pnpm – Delays the installation of newly published package versions, reducing exposure to freshly released malicious packages.

In addition, we are also planning the rollout of the following security controls:

• Add dual control to critical release operations – Require two independent approvals for sensitive release actions, reducing the risk of unauthorized or malicious package publication.
• Hardening existing multi-factor authentication processes – Use hardware tokens instead of time-based one-time passwords.
• Pairing npm publishing with OIDC – Uses short-lived, identity-based credentials instead of long-lived npm tokens for package publishing, eliminating a high-value secret from developer machines and significantly reducing the risk of token theft and unauthorized releases.
• Canary tokens – Deploy decoy credentials that trigger an alert if accessed, providing early detection of malware searching for secrets.
• Dev Containers – Isolate the development environment inside a container, limiting the ability of malicious dependencies to access the host system and developer credentials.
• Further Container Hardening – Further remove permissions from our products containers, using read-only containers where applicable.

Closing

We hold ourselves to a high standard on security, and we know an incident like this affects the trust our customers place in us. We are sharing this openly because that is the right thing to do, and because it helps anyone who may have pulled an affected version take the right steps.

We would also encourage other package maintainers on GitHub and npm to take this as a prompt to review the controls protecting their own publishing pipelines. npm and GitHub have introduced a number of supply-chain security features over the past year, including trusted publishing with OIDC and two-factor authentication on publishing that also covers automated, token-based releases.

This kind of attack has become disturbingly common this year; barely a week goes by without another company disclosing something similar. It’s a systemic problem right now: with AI coding tools in daily use, a developer’s device has become a far more valuable target than it used to be, because it now holds more tokens, cached credentials, and standing access than ever before. Attackers know this, and are going after these targets aggressively across the industry. We were not an isolated case.

If you have questions or need help assessing your exposure, please contact us at [email protected].

We will update this report if there is further information our customers need.

Timeline

11 July 2026

Time (Portugal Time, UTC+1)	Event
15:51 & 15:53	Two failed GitHub “Release” automation runs on the employee’s account – the first visible signs.
16:12	Malicious 8.14.0 published directly to npm.
16:50	SSH key removed from GitHub; 8.14.0 deprecated.
18:10	Clean 8.15.0 published.
18:37	Attacker publishes 8.16.0 and 8.17.0; malware removed from the laptop; email passwords and SSH keys rotated.
18:45	8.18.0 collision: our clean publish and the attacker’s malicious publish happened together; the attacker’s landed first.
18:50	Attacker publishes 8.20.0.
18:55	Two-factor authentication enforced on npm publishing.
19:12	Stolen npm token identified and removed; clean 8.22.0 published. No attacker activity after this point.

13 July 2026

Time (Portugal Time, UTC+1)	Event
09:37	npm removed the malicious package versions.
12:56	Public reports that 8.18.0 is also infected.
13:23	The four dependent packages pinned to 8.18.0 identified.

At a Glance

• Affected package: jscrambler
• Affected products: Code Integrity
• Affected versions: 8.14/8.16/8.17/8.18/8.20
• Safe version: 8.22
• Other affected packages and versions:
  • jscrambler-webpack-plugin 8.6.2
  • gulp-jscrambler 8.6.2
  • grunt-jscrambler 8.5.2
  • jscrambler-metro-plugin 9.0.2
• Safe versions:
  • jscrambler-webpack-plugin 8.6.3
  • gulp-jscrambler 8.6.3
  • grunt-jscrambler 8.5.3
  • jscrambler-metro-plugin 9.0.3

• Time of publication: 11 July 2026, 16:12:40 BST (London) / 11:12:40 EDT (US Eastern)
• Status: Deprecated and no longer available through normal npm dependency resolution.
• Known downloads: npm reported 1479 downloads across all affected versions, all already removed by npm
• Recommended action: Do not install the affected version. If you have already installed it, remove it immediately and upgrade to a safe version (8.22 or later).
• Investigation status: Closed. Postmortem here.

Update 13th July 4 pm London time: updated number of known downloads of malicious package versions, as reported by npm

Update 13th July 2 pm London time: added dependent packages that pinned version 8.18.

Today, we identified the unauthorized publication of a malicious version of our jscrambler npm package, which is used with our Code Integrity product. This incident was limited to that package and did not affect any other Jscrambler products, including Webpage Integrity.

The published package contained malware that executed during the npm preinstall lifecycle hook. As soon as we became aware of the unauthorized publication, we activated our incident response process and immediately took steps to contain the issue.

The unauthorized publication occurred at 16:12:40 London Time (11:12:40 EDT). The publication itself immediately triggered unexpected notifications to our package maintainers, allowing us to detect the incident within seconds and begin our response without delay.

The malicious version was immediately deprecated to prevent further installations through normal npm dependency resolution. Npm reported a total of 1479 across all affected packages during that 2h window. That includes downloads that were triggered by other packages that used the affected package.

We recommend that all customers and users update their version to make sure that they are using version 8.22 or later. This version was published today at 18:12 London time (13:12 EDT).

Our investigation indicates that the attacker was able to publish the package using an npm publishing credential. We have revoked and rotated all relevant credentials, passwords, and secrets, and have implemented additional security controls around our publishing process while the investigation continues.

The affected package is a dependency of 4 other Jscrambler packages. Those versions are identified above and were also equally deprecated, and new versions were issued.

Our response has included:

• Immediate deprecation of the malicious package version.
• Revocation and rotation of publishing credentials.
• Rotation of related secrets and passwords.
• Additional hardening of our package publishing pipeline.
• A full forensic investigation to determine the root cause and confirm the scope of the incident.

Our investigation is ongoing. We are working to establish the complete sequence of events and verify whether any systems beyond the package publication process were affected.

We will continue to update this advisory as additional verified information becomes available.

We sincerely apologize for this incident. Protecting our users and maintaining the integrity of our software distribution process are responsibilities we take extremely seriously, and we are committed to being transparent throughout this investigation.

Porto, Portugal

Jscrambler, the pioneering platform for client-side protection, today announced that it has been named an Innovator for Client-Side Protection by Cyber Defense Magazine (CDM), the industry’s leading electronic information security magazine. 

“Client-side risks like digital skimming attacks and third-party data leakage continue to rise, with businesses relying on outdated defenses simply being outmatched,” said Rui Ribeiro, CEO and Co-founder of Jscrambler. “Mitigating these risks requires a solution that not only supports and enables PCI DSS v4 compliance but comprehensively protects the entire website. This award affirms the strength of our client-side protection platform, which delivers on both fronts, extending security beyond the payment page to safeguard the entire digital experience.”

Businesses continue struggling with threats targeting the client side, including Magecart attacks, which, according to Recorded Future’s Insikt Group, grew by 103% in just six months in late 2024.

Jscrambler’s comprehensive client-side protection platform allows companies to effectively defend against data leaks, intellectual property theft, current and emerging client-side cyber threats, and misconfigurations. Every year, the company’s client-side protection platform blocks more than 8 million sensitive data access attempts.

The Jscrambler platform provides comprehensive first- and third-party JavaScript protection, along with sweeping security and compliance policies, all without sacrificing performance. In addition, the company offers industry-leading JavaScript and PCI DSS expertise, including expert advisory services. Visit our solution page for more information about Jscrambler and its client-side protection platform.

“We scoured the globe looking for cybersecurity innovators that could make a huge difference and potentially help turn the tide against the exponential growth in cybercrime. Jscrambler is absolutely worthy of this coveted award and consideration for deployment in your environment,” said Yan Ross, Global Editor of Cyber Defense Magazine.

Check out the full list of Global InfoSec 2025 Award winners.

About Jscrambler

Jscrambler is the leader in Client-Side Protection and Compliance. Jscrambler is the first to merge advanced polymorphic JavaScript obfuscation with fine-grained third-party tag protection in a unified Client-Side Protection and Compliance Platform.

Jscrambler’s integrated solution ensures a robust defense against current and emerging client-side cyber threats, data leaks, misconfigurations, and IP theft, empowering software development and digital teams to innovate securely online with JavaScript. Jscrambler’s Code Integrity product safeguards first-party JavaScript through state-of-the-art obfuscation and exclusive runtime protection. Jscrambler’s Webpage Integrity product mitigates threats and risks posed by third-party tags, all while ensuring compliance with the new version 4 of PCI DSS. With Jscrambler, businesses adopt a unified, future-proof client-side security policy, all while achieving compliance with emerging security standards. 

Jscrambler serves a diverse range of customers, including top Fortune 500 companies, online retailers, airlines, media outlets, and financial services firms whose success depends on safely engaging with their customers online.

About Cyber Defense Magazine

Cyber Defense Magazine is the premier source of cybersecurity news and information for InfoSec professionals in business and government. We are managed and published by and for ethical, honest, passionate information security professionals. Our mission is to share cutting-edge knowledge, real-world stories and awards on the best ideas, products, and services in the information technology industry.  We deliver electronic magazines every month online for free, and special editions exclusively for the RSAC Conferences. CDM is a proud member of the Cyber Defense Media Group. Visit Cyber Defense TV and Cyber Defense Radio to see and hear some of the most informative interviews of many of these winning company executives.  Join a webinar at Cyber Defense and realize that infosec knowledge is power. 

MINNEAPOLIS & PORTO, Portugal

Elavon, a global leader in payment processing, and Jscrambler, a pioneer in client-side protection and compliance, today announced a partnership to help merchants comply with PCI DSS requirements 6.4.3 and 11.6.1. Through this agreement, Elavon’s network of more than 400 merchants can leverage Jscrambler’s Client-Side Protection and Compliance Platform to safeguard their business from escalating web skimming attacks.

The client-side protection market is growing rapidly due to significant rises in web skimming attacks, including Magecart attacks, that target payment pages and cardholder data. According to a report from Recorded Future’s Insikt Group, Magecart infections surged by 103% over the first half of 2024. As a result, the e-commerce and payment industries face increasing pressure to secure client-side environments, driven by the escalating attacks and also PCI DSS requirements 6.4.3 and 11.6.1, which mandate script inventory management and tamper detection.

Using Jscrambler’s Client-Side Protection and Compliance Platform and PCI DSS solution, merchants can meet PCI DSS requirements while preventing web skimming attacks, securing payment pages, and maintaining compliance efficiently. Now, through this collaboration, the two companies combine Elavon’s extensive experience as a global leader in payment processing with Jscrambler’s innovative technologies to address the critical need for robust payment security.

“Our vast network of merchants is increasingly aware of the growing threats targeting payment pages and the growing urgency to take action by following the guidance set forth by PCI DSS and specifically requirements 6.4.3 and 11.6.1,” said Andrew McCarroll, PCIP Customer Payment Security Executive, Elavon. “By partnering with Jscrambler, Elavon is offering merchants easy access to Jscrambler’s PCI DSS solution. Built on Jscrambler’s decade of client-side security experience and its role as a trusted PCI SSC advisor, the solution secures payment environments so merchants can fend off skimming attacks and ensure ongoing customer trust.”

Jscrambler’s PCI DSS solution delivers the following capabilities: 

• Script Management: Auto-discovers and authorizes payment page scripts, reducing manual approvals by grouping vendor behaviors.

• Skimming Prevention: Blocks unauthorized data access in real-time, protecting against web skimming and formjacking.

• Tamper Detection: Monitors HTTP headers and page content, alerting on unauthorized changes via email, SIEM, or Slack.

• Hybrid Architecture: Supports agentless and agent-based deployment for flexibility, enabling rapid compliance for complex or acquired payment pages.

• PCI DSS Expertise: Provides direct access to former PCI Security Standards Council members and a strong bench of PCI DSS experts.

• QSA Alliance Program: Provides access to enablement sessions, assessor forums, and inventory reports to streamline audits.

“As attackers increase their focus on merchants’ payment pages, Elavon is not only raising awareness, it’s taking action to help deliver solutions to mitigate these damaging attacks,” said Carlos Gonçalves, VP of Partnerships & Growth at Jscrambler. “Their trust in our PCI DSS compliance expertise and our innovative platform will enable us to bring Jscrambler’s industry-leading client-side protection to Elavon’s merchants, strengthening their payment security and the larger digital payment ecosystem.”

On May 20, Jscrambler and Elavon will be hosting a webinar titled “Mastering PCI DSS Requirements 6.4.3 and 11.6.1: Practical Solutions for Merchant Compliance”, where executives will delve into the value of the partnership in greater detail while providing additional insights on PCI DSS v4.0.1 requirements and Jscrambler’s PCI DSS solution. The session will feature John Elliott (Jscrambler Security Advisor), Gareth Bowker (Jscrambler Technical Advisor), and Andrew McCarroll (Elavon PCIP Customer Payment Security Executive) and include a Q&A session for all attendees. Explore more about the webinar.

About Elavon

Elavon is wholly owned by U.S. Bank (NYSE: USB), the fifth-largest bank in the United States, and provides end-to-end payment processing solutions and services to more than 2 million customers in the United States, Europe, and Canada. As the leading provider for airlines and a top five provider in hospitality, healthcare, retail, and public sector/education, Elavon’s innovative payment solutions are designed to solve pain points for businesses from small to the largest global enterprises.

About Jscrambler

Jscrambler is the leader in Client-Side Protection and Compliance. Jscrambler is the first to merge advanced polymorphic JavaScript obfuscation with fine-grained third-party tag protection in a unified Client-Side Protection and Compliance Platform.

Jscrambler’s integrated solution ensures a robust defense against current and emerging client-side cyber threats, data leaks, misconfigurations, and IP theft, empowering software development and digital teams to innovate securely online with JavaScript. Jscrambler’s Code Integrity product safeguards first-party JavaScript through state-of-the-art obfuscation and exclusive runtime protection. Jscrambler’s Webpage Integrity product mitigates threats and risks posed by third-party tags, all while ensuring compliance with the new version 4 of PCI DSS.

Jscrambler’s Iframe Integrity empowers PSPs to deliver seamless protection, PCI DSS compliance, and SAQ A eligibility to merchants.

With Jscrambler, businesses adopt a unified, future-proof client-side security policy, all while achieving compliance with emerging security standards.  Jscrambler serves a diverse range of customers, including top Fortune 500 companies, online retailers, airlines, media outlets, and financial services firms whose success depends on safely engaging with their customers online.

At Jscrambler, innovation often starts with a simple conversation, and the story of our latest product, Iframe Integrity, is no different.

It was October 2023, and I was attending the PCI SSC Community Meeting in Dublin. Between presentations and panels, I found myself in conversation with QSAs and PSPs, discussing one of the industry’s emerging challenges: how can small merchants (Level 3 and Level 4) realistically comply with PCI DSS 4.0 requirements 6.4.3 and 11.6.1? Many of these merchants lack the resources, expertise, or even the interest to manage the complexity of script management and security monitoring. Yet, the threat of skimming attacks was more present than ever.

As we shared ideas and concerns over coffee, one suggestion emerged: could Payment Service Providers, Payment Processors, and Ecommerce Gateways (from now on, I’ll refer to these as PSPs, to simplify) step in to help, just as they did in previous PCI DSS versions with the introduction of the iframed payment page? But this time, there was a significant catch. Maintaining script inventories and responding to alerts for thousands of merchants would be unmanageable for PSPs.

This challenge became the seed for what would grow into Iframe Integrity.

Understanding the Threat Landscape

We set out with a clear goal: design a solution that requires no involvement from the merchant and that addresses iframe skimming attacks using a risk-based, highly effective approach.

We began by methodically identifying every known attack vector against iframed payment pages — silent skimming, double-entry attacks, iframe hijacking, overlays, fake iframes, fake forms, and function hijacking. Ultimately, these attacks fall into three main categories:

1. Direct interference with the payment iframe, such as iframe hijacking or tampering to redirect it to an attacker-controlled endpoint.

2. Indirect interference, where attackers overlay fake iframes or forms to deceive users or tamper with the payment flow.

3. Interference with security controls, attempting to weaken or bypass detection mechanisms through techniques like function hijacking.

Launching Iframe Integrity

Our solution combined the best of Jscrambler’s technology. We leveraged our Webpage Integrity agent with a configuration designed to detect and block any code behavior that could compromise the integrity of the iframe. But we knew this wouldn’t be enough. We also needed Code Integrity to protect privileged scripts, such as the PSP’s script responsible for creating the payment iframe, from tampering and monkey patching. Together, these components formed a robust, multi-layered defense that could meet the intent of 6.4.3 and 11.6.1 without imposing a heavy operational burden on merchants and PSPs.

The product beta was called Armored Iframe, and throughout the past year, we tested and refined it with key industry players while bringing on happy customers.  Then came the industry confirmation: changes to SAQ A eligibility criteria and the clarifications in PCI SSC’s FAQ 1588 that PSPs and PayFacs would need to help their merchants confirm that they are not susceptible to attacks from merchant-side scripts. This is when we knew there would be a momentous shift in the market. This industry shift made it crystal clear that iframe hardening was no longer optional — it was essential.

Today, we are proud to officially launch Iframe Integrity as a core component of the Jscrambler product suite. Iframe Integrity allows PSPs to offer PCI DSS compliance (requirements 6.4.3 and 11.6.1) and SAQ A eligibility to their merchants, shielding their payment pages from sophisticated skimming attacks and ensuring trust and security at every transaction.

Built on Foresight and Expertise

At Jscrambler, we’ve always taken pride in seeing around corners. Before PCI DSS 4 even existed, we had already built and launched Webpage Integrity, anticipating that the industry would demand tighter client-side controls. When requirements 6.4.3 and 11.6.1 were introduced, adding a PCI DSS module was a natural extension, validating that we were already ahead of the curve.

The same story repeated itself with Iframe Integrity. Long before SAQ A changes and FAQ 1588 were published, we had already envisioned and built the solution. What started as Armored Iframe is now officially launched as Iframe Integrity — the industry’s first comprehensive iframe hardening product.

This is more than a product launch. It’s another clear demonstration of Jscrambler’s leadership and vision. We don’t just react to changes in the payments and security industry — we anticipate them, build for them, and help shape the future. With Iframe Integrity, we’re once again leading from the front, redefining what security looks like in the web payments ecosystem.