Your CMDB Ends at the Server. The Magecart Attack Started in the Browser
Introduction
On January 13, 2026, threat intelligence firm Silent Push published a disclosure that deserved more attention than it received. Researchers had uncovered a Magecart network — a web-skimming operation injecting malicious JavaScript into e-commerce checkout pages — that had been running continuously since January 2022. Four years. The scripts were active across hundreds of merchants, targeting cardholders using six of the world’s major payment networks: American Express, Diners Club, Discover, JCB, Mastercard, and UnionPay.
The attack itself was not particularly sophisticated. The JavaScript intercepted card data as shoppers typed it into checkout forms, then exfiltrated it to attacker-controlled domains. What made it effective was one design detail: the script checked whether the site’s admin user was logged in. If it detected a WordPress Admin Bar — the toolbar visible only to the site owner — it deleted itself. When the administrator left, it reappeared. The campaign ran for four years not because it was technically undetectable, but because no one was watching the payment page consistently enough to catch a script that knew when to hide.
That detail is the operational problem this article is about. Not the sophistication of the attack. The absence of a baseline.
What the System Looked Like While It Was Being Robbed
The Silent Push researchers did not find this campaign because a merchant raised an alarm. They found it while investigating a separate set of infrastructure indicators — a domain flagged on threat intelligence feeds that pointed to an IP address operated by a sanctioned hosting provider. Following that thread led to a network of domains, which led to obfuscated scripts, which led to a skimming operation that had been running continuously since January 2022.
That discovery path matters. The infrastructure signals existed. A flagged domain. A suspicious IP. A sanctioned hosting provider. What was missing was an owner on the other end — no organization had a CI record for the payment page environment that a threat intelligence feed could be compared against. The signal was present. The asset record it needed to trigger a review did not exist. That is a CMDB problem.
The merchants whose checkout pages were carrying those scripts did not know. The cardholders whose data was being intercepted did not know. The payment networks whose brands were being spoofed in the fake checkout forms were not the ones who found it.
Four years is a long time for an attack to run undetected. It is less surprising when you understand the detection condition it required. Someone needed to be watching the payment page — not the application server, not the network perimeter, not the database — the page itself, in the browser, where the scripts load and execute. Specifically, they needed a known-good baseline of what scripts were authorized to be there, and a mechanism that compared the live state against that baseline often enough to catch a change.
That baseline did not exist for the merchants in this campaign. It does not exist for most merchants today. Not because they lack security tooling — but because the payment page was never added to the inventory that security tooling monitors against. It was not defined as a configuration item. It was not scoped into the environment that gets discovered, catalogued, and watched.
That is the operational gap. Everything that follows is about why closing it is now a requirement, not a recommendation.
The Standard That Was Written for Exactly This
PCI DSS v4.0.1 is the only active version of the standard in 2026. Every assessment conducted this year is against the full requirement set. There is no transition window remaining, no grace period to invoke, no future-dated requirement still marked optional.
Two of those requirements are directly relevant to what Silent Push found in January.
Requirement 6.4.3 states that all scripts permitted to load and execute on the consumer-facing payment page must be managed. Specifically: each script must be authorized, with a written justification for why it is necessary. The integrity of each script must be confirmed — meaning the organization must be able to detect if a script has been modified. And an inventory of all authorized scripts must be maintained, with a method to confirm each is legitimate.
Requirement 11.6.1 states that a change-detection mechanism must be in place that alerts personnel to unauthorized modifications to the HTTP headers and script contents of payment pages as received by the consumer browser. The monitoring must run at a frequency defined by a targeted risk analysis — but it must run, continuously, and it must alert.
Read those two requirements against the mechanics of the Silent Push campaign. The skimmer was a script. It was not authorized. It was not in any inventory. It modified what loaded in the consumer’s browser at checkout. It ran for four years without triggering an alert because no alert mechanism existed to compare the live payment page against a known baseline.
Requirements 6.4.3 and 11.6.1 describe, precisely, the gap that was open. Script inventory plus change detection — those two controls, operating together, are what the January 2026 campaign exploited the absence of.
What makes 2026 the inflection point is enforcement reality. Organizations that validated compliance in 2024 under transitional allowances are now walking into assessments where these are hard pass/fail line items. Assessors are not looking for evidence that a script inventory was created in March 2025. They are looking for twelve months of continuous operational evidence — logs, alerts, documented reviews — that the inventory exists, is current, and is being monitored. A control switched on at the deadline and never operated does not pass a 2026 assessment.
The gap is not theoretical and it is not small. QSAs conducting 2026 assessments have consistently flagged the absence of a payment page script inventory as a primary finding heading into this cycle. The merchants who built their compliance programs around server-side CDE controls and assumed a hosted checkout page put them out of scope are now discovering that assumption does not hold under v4.0.1. The browser is in scope. The scripts are in scope. The inventory is required.
And the inventory has to come from somewhere.
Why the Inventory Has to Start with Discovery
An authorized script inventory sounds like a security problem. It is, operationally, an asset management problem — and it has two distinct layers that most compliance programs conflate.
The first layer is browser runtime. What scripts actually execute in the customer’s browser at checkout, in real time, as the page renders. This is where the Magecart skimmer lived. Detecting changes at this layer requires specialist client-side monitoring tools — Content Security Policy enforcement, Subresource Integrity validation, or dedicated platforms built specifically to observe JavaScript behavior in live browser sessions. This is a separate technical capability that operates at the browser layer. Virima does not replace it.
The second layer is infrastructure. What servers host the payment page. What third-party systems connect to it. Who owns it as a managed asset. What change process governs it. This layer is where most organizations’ compliance programs have the structural gap — and it is the layer that determines whether the browser-runtime monitoring above it can function at all.
Here is why that sequence matters. A client-side monitoring tool compares what is executing in the browser against an authorized baseline. But that baseline — the authoritative record of what integrations, CDN providers, and third-party systems are permitted to serve content into the payment page environment — has to come from somewhere. If it was assembled manually, from memory, or from a previous audit cycle, it reflects what someone believed was connected to the payment page, not what was actually discovered to be connected to it.
The January 2026 campaign exploited exactly this gap at the infrastructure layer. The scripts reached customer browsers through third-party domains — CDN providers, tag management systems, analytics platforms — that merchants had not formally inventoried as part of the payment page’s dependency surface. The browser-runtime layer had no authorized baseline to compare against because the infrastructure layer had never been formally mapped.
A CMDB that treats the payment page environment as a managed scope — with its hosting infrastructure, third-party integrations, and server-layer dependencies catalogued as configuration items — is what makes that baseline real. Not assembled from memory. Discovered, source-attributed, and maintained on a governed schedule. That infrastructure record is what gives the browser-runtime monitoring layer something authoritative to enforce against.
Where Virima Fits
Virima operates at the infrastructure layer — the foundation beneath the browser tools that do the live detection.
Virima’s agentless discovery identifies the servers hosting the payment page environment and the network-connected systems communicating with it — the infrastructure layer beneath where scripts are delivered and executed. Each component enters the CMDB as a source-attributed configuration item — not manually entered, not inherited from a previous audit cycle, but discovered and recorded on a governed schedule. Virima operates at the network and infrastructure layer; it does not scan browser DOM content or detect client-side JavaScript tags delivered by CDNs. What it provides is the authoritative infrastructure record that makes everything downstream governable.
That discovery output is what makes the Requirement 6.4.3 authorization workflow operational. The requirement asks organizations to maintain a script inventory with a written justification for each authorized script and a method to confirm its integrity. The workflow looks like this in practice: Virima’s discovery produces a source-attributed record of every third-party system connected to the payment page environment. That record becomes the starting inventory. Each discovered dependency is reviewed, assigned an owner, and either authorized with a written justification or flagged for removal. The authorization and integrity confirmation process is not automatic — but without the discovery layer, it is guesswork built on assumptions about what is connected, not evidence of what was found.
Virima’s ViVID service mapping makes the infrastructure dependency surface visible at a level manual inventory cannot sustain. ViVID is not a static diagram — it reflects the live state of the CMDB, which Virima Discovery continuously updates. It maps what is connected to what, what changed, and who owns it, at the server and network layer. When a previously unrecorded system appears in the network — a host communicating with the payment environment that has no formal CI record — it surfaces as a change against a known baseline. That is infrastructure-layer governance: the signal that triggers a security review before an unvetted system’s content ever reaches a customer’s browser.
The continuous reconciliation Virima runs between discovery cycles supports the Requirement 11.6.1 change-detection mandate at the layer beneath the browser. The organizations best positioned to act on browser-layer alerts are the ones who already know, from an authoritative infrastructure record, what is supposed to be connected to the payment page and what is not. Virima provides that record. The browser-runtime monitoring tools provide the alert. Together they close the gap. Neither closes it alone.
The January 2026 campaign ran for four years because the infrastructure layer was unmanaged — no authoritative record of what was connected to the payment page, no change signal when new dependencies appeared, no owned CI that security could govern against. The browser-runtime detection that would have caught the skimmer had no foundation to stand on.
The Fragility the Attack Revealed
CMDB adoption has not kept pace with the sophistication of payment security tooling. In financial services and payment processing, the CMDB is often treated as an IT operations tool — useful for change management, relevant during audits, maintained by the infrastructure team. It is not typically framed as a payment security asset. The security stack gets the investment. The asset inventory underneath it gets the spreadsheet.
The January 2026 campaign exposed what that gap looks like in practice. The attack did not break through a firewall. It did not exploit a zero-day vulnerability. It placed a JavaScript file on a checkout page and waited. It waited for four years because nobody had a current, authoritative, continuously maintained record of what was supposed to be running on that page. The security tools were present. The inventory those tools needed to operate against was not.
That is the fragility the campaign revealed — not a weakness in any single technology, but a structural gap between how payment organizations think about their security perimeter and where the actual attack surface lives. The perimeter ends at the server. The checkout page renders in the customer’s browser, assembled at runtime from scripts, dependencies, and third-party resources that change without formal review, without change tickets, without anyone updating a configuration record.
In an industry where a single undetected script can run silently across six payment networks for four years, knowing what exists — completely, continuously, and with enough authority to detect a one-line change in a JavaScript file — is not an operational nicety. It is the condition that every other security and compliance control depends on.
