Formjacking on Landing Pages: Is Malware Copying Your Leads?

Say a landing page brings in 200 leads a day. Someone adds a few lines of code that copy every name, phone number, and email address entered into the form. The next day, the page still brings in 200 leads. The advertiser still receives all 200. 

As far as the campaign report is concerned, everything looks completely fine, and nothing has changed.

This is formjacking. The extra code reads the form and sends the data elsewhere while the real submission continues as normal. Breaking the form would draw attention. Copying the data is much harder to notice.

And the problem seems to get even bigger.

Media buyers often think that the advertiser or its security team has to take care of leads and security, but if you built the landing page, chose the hosting, installed the plugins, and added the tracking scripts, the leak may be happening on your side.

---

Key Takeaways

• Your conversion rate can stay exactly the same while someone copies the leads.
• Skimmers often get in through code the page already trusts: a plugin, tag manager, vendor script, or compromised CMS.
• Malware is not the only concern. Analytics and tracking tools may read form fields too.
• Ten minutes in the browser’s Network panel will show you the requests the page makes during your test. A clean log does not prove the page is clean
• Your visibility ends when the lead leaves your lander. The offer owner needs to explain what happens after that.

---

How Formjacking Works

A skimmer may copy each value as it is entered or wait until the visitor clicks Submit. Some versions replace the real form with a fake one that looks much the same. The normal submission may still go through, so the copying will not necessarily affect campaign metrics.

The code may be added directly after an attacker breaks into the CMS or hosting account. It may also arrive through a compromised plugin, theme, tag manager, CDN library, or vendor script. Once loaded, it can interact with the page like any other script.

Skimmers are best known for stealing card numbers, but the same code can collect any other fields on the page. 

In January 2026, Silent Push reported on a campaign that had been active since at least 2022. Its code monitored every input on the checkout page and recorded partially completed fields. It collected names, email addresses, phone numbers, and billing and shipping addresses. On a lead-gen page, that information is the lead.

The code may also look like part of the normal tracking setup. For example, in February 2025, Sucuri investigated a Magento infection disguised as Google Tag Manager and Google Analytics code. The malware was hidden in the site’s database, and the same Google Tag Manager ID appeared on at least six infected sites. A quick look at the page source would not necessarily make it stand out.

---

Why Your Conversion Rate Will Not Tell You

Campaign tracking records the submission you expect: the visitor completes the form, the lead reaches the CRM, and the conversion fires. It does not record every other request made by scripts on the page. If a skimmer sends the same data somewhere else, CR and cost per lead may not change at all.

A badly written skimmer might slow the page down or cause an error. But it can also copy the fields without disrupting the form or changing the numbers in your campaign report (and that’s how it usually works). Stable metrics do not mean the page is clean.

However, the copied leads can be resold, used for fraud, or handed to someone who contacts the person before the advertiser does.

---

The Scripts You Installed Matter Too

Looking only for malware misses part of the problem. Analytics tags and session replay tools may also collect data from a form. They are not malware, but they still give another company access to information entered on the page.

The 2022 study Leaky Forms tested forms on the top 100,000 websites without submitting them. The researchers found email addresses being sent to tracking, marketing, and analytics domains on 1,844 sites in the EU crawl and 2,950 in the US crawl. On 52 sites, session replay scripts also collected passwords.

A 2025 study of 40,150 websites looked specifically at Google Tag and Meta Pixel. Among sites where the trackers were installed, the researchers observed form-data collection on 11.6% of sites with Google Tag and 62.3% of sites with Meta Pixel. The collection was often enabled through the tracker’s normal settings, not through malicious code.

In 2025, MarinHealth agreed to a $3 million settlement over claims that tracking tools on its website had sent visitor information to third parties without authorization. The alleged data collection ran from August 2019 to May 2025. MarinHealth denied wrongdoing and liability.

So do not stop after checking for scripts you do not recognize. Check the ones you installed as well: what they can read, what they collect, and where they send it.

---

Check Where Your Form Sends Data

You can do a first check in the browser. Use a clean profile with extensions disabled, and enter test data rather than anyone’s real name, email address, or phone number. If submitting the form creates a live lead, use a staging page or an approved test record.

• Open DevTools before loading the page. In the Network panel, select All, turn on Preserve log, clear the list, and reload the page. Do not limit the view to Fetch/XHR, since scripts can send data in other ways.
• Enter a unique test value and pause before submitting. Use something easy to recognize, such as form-audit-0921@example.com. Look at any new requests, but do not assume that every request is reading the form. Open the request and check its destination, Payload, and Initiator.
• Search the network log for your test value. If it appears in a request before submission, some part of the page has already sent it. No match does not rule out collection, since data may be hashed or encoded before it leaves the browser.
• Submit the form and check the log again. Preserve log keeps the requests visible if the form opens a thank-you page. Find the expected request to your endpoint, then inspect any other requests made at the same time.
• Check which scripts the page loads. Filter the Network panel by JS and note the source domain of each external script. The Initiator column can show which file caused another script or request to load. If the page uses a tag manager, review the tags inside the container as well. The container ID alone does not show what it runs.
• Match each domain to a tool or vendor. An unfamiliar domain is not proof of malware, but it needs an explanation. Known vendors still need checking: the question is not only who sent the request, but whether it contained form data.

Run the same check after adding a plugin, changing a theme, publishing a new tag, or moving the page to different hosting. Test the mobile version too. 

This check can show that data is going somewhere unexpected. Run it more than once, since some skimmers only appear on certain devices or in certain locations.

---

Limit What the Page Can Load and Send

Once you know which scripts and domains the page needs, you can restrict everything else.

• Add a Content Security Policy. A CSP limits what a page can load and where it can send data. script-src controls scripts, connect-src covers requests such as fetch, XHR, WebSocket, and sendBeacon, and form-action controls form submissions. Other directives, including default-src and img-src, may also be needed. Test the policy in report-only mode, review the violations, and then enforce it. CSP can block unapproved connections, but it cannot tell whether an allowed script is safe.
• Subresource Integrity lets you specify the expected hash of a script in its integrity attribute. The browser checks the downloaded file before running it and blocks it if the hash does not match. SRI works best for versioned files that do not change without a new URL. Cross-origin files must also be served with the required CORS headers. SRI does not automatically cover other files loaded by the script, and it is unsuitable for vendor scripts that change in place. It also cannot help if an attacker can edit both the page and the hash. A matching hash proves that the file has not changed, not that the file is safe.
• Restrict access to the tag manager. Require two-factor authentication, limit publishing rights, and review each container version before it goes live. Audit the tags inside the container as well. The ID visible in the page source does not tell you what the container currently loads.
• Host stable libraries yourself. If a library rarely changes, keep a reviewed copy on your own server instead of loading it from a vendor or CDN. This prevents the external provider from changing the file without your knowledge. You will need to update the library yourself, and this will not help if your own hosting is compromised.
• Keep a script inventory. For each lander, record the script, its owner, why it is needed, and which domains it should contact. When the page changes, compare the new list with the old one.

Payment pages already have formal rules for this. 

Since March 2025, businesses covered by PCI DSS v4.0.1 must keep a list of scripts running on payment pages, approve each one, explain why it is needed, and detect unauthorized changes.

Those requirements were written for payment pages. A skimmer, though, reads whatever fields it finds, and OWASP recommends the same checks for any page that loads third-party JavaScript.

---

What Happens After the Lead Leaves Your Page

In DevTools, you can follow the lead only as far as the receiving endpoint. Once it reaches the server, the advertiser may store it, add information from other databases, or pass it to a CRM, call center, or another company. None of this will appear in the Network panel, so you need to ask what happens next.

• Where does the form send the lead? Record the endpoint, its domain, and the company that operates it. If it belongs to the advertiser, your technical check ends when the request reaches that endpoint.
• Ask who is responsible for the data. If you built the lander and chose its tracking scripts, don’t assume the advertiser answers for everything on it. Where personal data is involved, the agreement between you and the advertiser sets out the parties’ data-protection roles. Start there, then take what those roles mean for you to your own data-protection contact. The European Commission explains the possible roles here.
• Know who to contact. If you find a suspicious request, send the lander URL and destination domain to your account manager or the offer owner. If nobody can explain the request, stop using that lander until you know where the data is going.

A partner should be able to explain where the lead goes, who receives it, and how long they keep it. If those answers are missing, the risk is still unresolved.

---

Why You Need to Check Again

Some skimmers do not run on every visit. They may activate only for visitors from a target country or traffic source, or for a small random share of sessions. Everyone else sees the normal page. If your test falls into that group, the Network log will look clean.

The page can also change after the test. A new tag, plugin update, or change to a vendor script may add code without changing the visible lander.

Check the page before launch, after any change to its plugins or tags, and during long-running campaigns. When possible, test both desktop and mobile from the GEOs you are targeting.

---

FAQ

Does HTTPS protect form data from formjacking?

No. HTTPS encrypts data while it travels between the browser and a server. A script running on the page can read the form before that data is sent. It can then forward a copy through its own encrypted connection, so the page may still appear secure in the browser.

My lander is a single static HTML file with no plugins. Is it safe?

It has fewer possible entry points, but it is not automatically safe. Check whether the page loads analytics tags, chat widgets, or JavaScript libraries from external domains. A third-party script can change without any change to your HTML file. The page itself can also be altered if someone gains access to your hosting account or deployment process.

A standard vulnerability scan may not catch this. You still need to check which scripts the page loads and where it sends data.

Would formjacking show up in my campaign stats?

Usually not. If the original form submission still works, CR, CPL, and lead quality may remain unchanged. A poorly written skimmer could slow the page down or cause errors, but the absence of those problems proves nothing.

The clearest sign is an unexpected request leaving the page. Check the Network panel using test data, and repeat the test under different conditions because malicious code may not run for every visitor.

What should I do if the form sends data to a domain I do not recognize?

Do not assume that an unfamiliar domain is malicious. It may belong to an analytics tool, verification service, or another vendor used by the page. Check the request payload and its initiator, then trace the domain back to a script or tag.

If nobody involved with the lander can explain why the request is there, remove or disable the script before sending more traffic.

---

Check the Form Before You Send More Traffic

A form can submit every lead correctly and still send the same data somewhere else. CR, CPL, and approval rate will not show you that it is happening.

Keep a simple list of the scripts and domains that belong on the page. Check it again after adding a plugin, changing a tag, updating the lander, or increasing spend. If test data appears in a request you cannot explain, pause and find out where it is going before sending more leads through the page.

You may not control what happens after the lead reaches the advertiser, but you can control the code running on your lander. That is where the check starts.