A downloaded landing page is third-party code you didn’t write. And it’s sitting on your domain, in front of traffic you paid for. It came from a spy tool, a forum pack, a marketplace, or a contractor who built it in a week for a flat fee.
Somewhere in those files may be a script doing exactly what its author intended, just not what you intended. That is the problem with malware in landing page templates: the page can look and work perfectly while traffic or data quietly goes somewhere else.
Cleaning up third-party pages is already part of the affiliate routine. Some tools even market “clean” downloads as a feature.
There is a reason for that: a page pack can carry the same tricks security researchers keep finding in the wild, from hidden form recipients and invisible link blocks to code that runs only for certain visitors. What matters is knowing where to look, and in what order, before you pay for the first click.
This article walks through the checks worth doing before launch, from the files themselves to the things no scanner can catch.
Key Takeaways
- Where the page came from tells you what to look for first. A ripped page, a forum pack, and a contractor build carry different risks.
- The costliest leftovers are often the hardest to notice. A script can redirect a small share of visitors, or copy form submissions elsewhere, without breaking the page.
- A remote script is part of your template too. A domain serving a harmless library today can serve different code tomorrow, as the polyfill.io case showed across more than 100,000 sites.
- Fifteen minutes is enough to catch many common problems: review the files, search the source, trace every form, check network requests, and test the page on a real phone.
- No external check can tell you everything. Knowing what a scanner cannot see is just as important as running the scan.
Where the Template on Your Server Came From
Downloaded landing page templates usually reach your server in one of four ways:
- Ripped from a live page. The template copy may include the original owner’s tracking, offer links, remote scripts, and redirect logic.
- Downloaded from a forum or marketplace. You often have no way to know who assembled the pack, what they changed, or how many people handled it before you.
- Built by a contractor. The code may be original, but you are still relying on the contractor’s packages, third-party scripts, machine, and accounts.
- Made with a modified or redistributed builder. Because the software was modified before it reached you, there is no reliable way to know what was added.
Each route gives you a different starting point.
With a ripped page, check links, tracking, and redirects first. With a template pack, look for files and code that do not belong. With a contractor build, pay close attention to dependencies and external requests. And if the page came from cracked software, rebuilding it from a clean source is usually safer than trying to repair it.
| Where the template came from | What it leaves behind | What to search for |
|---|---|---|
| 01Ripped from a live pageLast touched by the original page owner | The owner’s redirect, offer links and tracking, still pointing at their funnel | <scriptwindow.locationhref= |
| 02Forum or marketplace packLast touched by a pack author you cannot identify | A second recipient on the form, or a block hidden from the visitor but readable by a crawler | action=atob(display: none |
| 03Contractor buildLast touched by a freelancer, their machine and their accounts | Dependencies loaded at runtime from a domain you never chose and cannot see change | script src=//cdn.fetch( |
| 04Modified builderLast touched by whoever altered and re-packaged the files | A backdoor added during redistribution, with no clean copy left to compare against | *.phpeval(include( |
Where a Ripped Page Can Still Send Your Traffic
Some leftovers are really a no-brainer to spot: the previous owner’s affiliate ID, a Meta pixel, an analytics tag, or an old offer URL. You replace them, test the buttons, and the page appears clean.
The more crucial artifacts and code “leftovers” are harder to see. What you should remember is that a redirect does not have to fire on every visit. A few lines of JavaScript can send one visitor in ten somewhere else and let the other nine continue to your offer. If you decide to run paid traffic through it, you might see that a campaign is performing slightly worse than expected.
Not all of this code starts out as malware. Some scripts are added to stop other affiliates from copying a page. They may check the domain or other parameters before showing the real content.
Replacing the visible links is therefore not enough. Check any script that generates random numbers, reads the referrer or hostname, looks for a token, or builds a destination URL at runtime.
When One Lead Goes to Two Places
Forms need their own check. A page can send every lead to you and quietly send the same details somewhere else.
While analyzing thousands of phishing kits, Netcraft found extra recipient addresses hidden in places most people would never inspect.
In one kit, PHP code disguised as a button.gif sent stolen credentials to three additional email addresses. The code was concealed behind several layers of obfuscation, including Base64 and ROT13. In other kits, extra recipients were tucked into access-control and encryption scripts.
A standard lead-gen page is not a phishing kit. But the technical lesson carries over: when you deploy someone else’s form handler, a successful test proves that you received the lead. It does not prove that nobody else received it too.
For a lead page, that second copy may include a name, phone number, email address, or delivery address. The UK Information Commissioner’s Office treats disclosure to an incorrect or unauthorized recipient as a personal data breach. What must happen next depends on the market, the data involved, and the risk to the people affected.
When you audit a template, follow the form action, read the JavaScript that runs on submit, and inspect any server-side handler included in the pack. Submit a dummy lead as well, but don’t treat its arrival in your system as proof it went nowhere else.
Third-Party Scripts Are Part of the Template Too
A template is not just the files in the ZIP. It also includes every script the page loads from another domain. Those scripts can change without touching a single file on your server.
Polyfill.io showed how much damage one remote script can do. The domain and its associated GitHub account changed hands in February 2024. In June 2024, Sansec found malicious JavaScript being served from the domain, which was embedded on more than 100,000 sites.
The payload did not redirect everyone. It targeted mobile devices, ran only at certain times, checked for admin users, and delayed execution when it detected analytics tools. That made it less likely to appear during a routine desktop check.
Cloudflare later confirmed that the service was redirecting some visitors and began replacing Polyfill.io links on sites using its network.
That is why checking a template once, just before launch, isn’t enough. Unless Subresource Integrity is in place, a remote <script> gives that URL permission to send new code to your visitors every time the page loads. The file you approved initially may not be the file the browser receives later on.
The Freelancer’s Laptop Is Part of Your Stack
Hiring someone to build the page does not remove the supply-chain risk. It moves that risk to the contractor’s machine, development accounts, and the tools used to assemble the project.
In 2026, ADEX investigated an active XCSSET infection on a workstation used by an iOS development studio. The malware was hidden inside Xcode project files and ran when a developer started a build. Once active, it infected more than 20 other projects on the same machine within a minute and gained access to credentials, browser sessions, and development tokens.
This was not a landing-page infection, but the route is the same: a developer can pass malicious code from one project to another without knowingly installing or writing it.
The same risk exists in the web development stack. In September 2025, CISA reported that the Shai-Hulud campaign had compromised more than 500 npm packages. The malware searched development environments for GitHub tokens and cloud API keys, then used compromised developer accounts to publish infected versions of more packages.
All in all, it doesn’t make contractor-built pages unsafe by default. But what it means is that “custom-built” is not the same as “independently checked.”
If the page has a build step, ask for its dependency manifest, lockfile, and build instructions. For any page, get the original source files and a list of external scripts and services it uses. Server-side code may be needed for forms, tracking, or routing, but anything that does not match the page’s actual features needs an explanation.
What Happens When a Bad Template Goes Live
Sometimes the first sign of a bad template is not a missing lead or a strange redirect. It is a rejected campaign.
Ad platforms look at the destination as well as the creative. Google’s malicious software policy covers software that an advertiser’s site hosts or links to, even when that software is not the product being advertised. Google also warns that accounts may be suspended without prior notice when it detects a serious violation.
PropellerAds also checks landing pages during moderation. Its landing page rules prohibit malware, browser exploits, automatic downloads, specified phishing messages, and pages that users cannot easily close. A remote script or redirect inherited from a template can therefore become your campaign problem even if you did not add it yourself.
A rejection alone does not tell you which part of the page triggered it. If the notice mentions malicious software or a compromised destination, opening the page once in your own browser is not enough. Check the files and runtime requests before appealing or submitting the campaign again.
The cost grows if the page passes moderation and the problem appears later. Paid traffic can keep reaching a compromised page until someone notices the redirect, stolen data, or unexpected download. In its Q2 2025 client-side attack report, c/side said it identified 72,740 compromised websites across several campaigns, including mobile redirects, full-screen page hijacks, and malicious downloads. That is a vendor’s detection dataset, not an estimate for the whole web, but it shows how quickly the same injected code can spread across unrelated sites.
The Pre-Launch Check to Run Before You Send Traffic
You don’t really need a security toolkit to check your landing page template.
Here’s what you can do: keep the original archive untouched, make a working copy, and inspect the files before opening the page in a browser.
- Start with the file list. A static lander will usually contain HTML, CSS, JavaScript, and media assets. PHP without server-side features, executables, multiple entry pages, or files whose contents do not match their extensions need an explanation.
- Map the links and scripts. Search for http://, https://, src=, href=, and action=, followed by request and redirect methods such as fetch(, XMLHttpRequest, sendBeacon, location, and window.open. Check encoded or dynamically executed code around eval(, atob(, String.fromCharCode, and document.write. These functions are not malicious by themselves, but you should understand what they do and where they send data.
- Trace every form. Check the form’s action and its submit handlers, then send a dummy lead with the Network panel open. Multiple requests may be genuine, but every recipient should be familiar. The browser will not show copies forwarded later by server-side code.
- Watch what the page loads. Use a fresh browser profile with extensions disabled and Developer Tools open. Reload the page, list every domain it contacts, and check which script initiated any request you do not recognize.
- Test it on a real phone. Use mobile data and follow the entire flow, including forms, redirects, and back-button behavior. This can expose mobile-only code, although one device cannot reproduce every GEO, carrier, or time-based condition.
- Use external scanners last. urlscan.io records the page’s requests, redirects, DOM, and screenshot, but public scans are searchable. VirusTotal adds reputation and security-vendor verdicts, while standard submissions may be shared with its community and partners. Sucuri SiteCheck checks browser-visible code and blocklist status but cannot inspect server-side files.
Do not upload a private template, customer data, credentials, or unpublished campaign URLs to a public scanning service. A clean result means that the service found nothing in that particular scan. It does not prove that the page is safe.
Which Check Finds What?
| Check | What it can reveal | What it can miss |
| File list | Unexpected server-side code, executables, duplicate entry pages, mismatched file types | Malicious code hidden inside files that belong there |
| Source search | Hardcoded endpoints, remote scripts, redirects, tracking IDs, encoded blocks | Code assembled or downloaded at runtime; server-side behavior |
| Form trace | Client-side recipients, extra requests, submit handlers | Copies forwarded by server-side code or a third-party form service |
| Network panel | Requests, redirects, iframes, and domains loaded during that session | Code that activates only for another device, GEO, carrier, referrer, or time |
| Real phone | Mobile-only redirects, prompts, and differences in page behavior | Conditions that do not match that specific phone or connection |
| External scanners | Known reputation signals and behavior visible during the scan | Fresh infrastructure, selective payloads, and anything hidden on the server |
Start with the files and finish with the scanners. The source tells you what is in your copy; the scanners add outside reputation and another execution environment. Neither is enough on its own.
If You Find Something
If the page is already live, stop sending traffic to it. Keep the original archive untouched and make any changes in a separate copy.
If you know which builder, theme, or template the page came from, download the same version from the official source and compare the files. Some differences will be expected: your copy, links, and tracking. Check the rest.
If you cannot identify the original version, or the suspicious code is obfuscated or spread across several files, rebuilding the page from a trusted source is safer than deleting one line and assuming the rest is clean.
Revoke or rotate any password, private key, or access token exposed in the files. Removing a secret from the code is not enough, as GitHub’s guidance on leaked credentials also makes clear. If you uploaded or ran untrusted server-side code, check the logs and replace any hosting, FTP, database, or API credentials it could access.
Run the full check again before launching the page or putting it back into rotation.
External Pages and Scripts
Some parts of the funnel cannot be checked from the files on your server.
If the offer page belongs to the advertiser or the pre-lander sits on a partner’s domain, you cannot inspect its code. Test the entire path on desktop and mobile, from the GEOs you plan to target, and write down every redirect and domain along the way. This is also the approach described in PropellerAds’ guide to checking traffic and campaign infrastructure.
External scripts are another problem. The copy you inspect before launch can be replaced later without any change to your own files. Where possible, keep a reviewed copy on your server. If a script has to stay external, Subresource Integrity can stop the browser from running it after its contents change. It protects only that file, however, not anything the script loads or calls afterward.
Some code also runs only under certain conditions. The malicious code in the polyfill.io attack, for example, checked the visitor’s device, referrer, location, and time before acting. It could behave normally during your test and do something else for campaign traffic.
A completed check means you found nothing under the conditions you tested. Keep watching the numbers after launch. An unexplained difference between lander visits and offer visits is not proof of malware, but if it keeps appearing for one device, GEO, carrier, or traffic source, check that part of the funnel again.
Template Questions That Come Up Mid-Campaign
No. A clean result means the scanner found nothing in that particular run. A new domain, an unfamiliar script, or a redirect that appears only for some visitors may still go unnoticed.
Only if the page still works without them. Remove scripts one at a time in a local copy, then test the buttons, forms, redirects, tracking, and any quiz or countdown. If the page depends on a script you cannot explain, replace that function instead of putting the script back.
Sometimes, but you do not have to choose between coding from scratch and downloading an unknown page pack. ProPush Constructor gives you a ready-made HTML template that you can adapt to your audience, download, and host on your own server. The flow and monetization are already set up, and you have full access to the files before launch.
What’s Next?
Once you publish a template, its behavior becomes your responsibility. If an old tracker fires, a lead is copied, or a redirect sends visitors elsewhere, the problem sits on your domain and comes out of your budget. Where the zip came from will not change that.
By the end of the check, you should be able to account for every file, script, and destination on the page. Keep that copy, record any later changes, and use it as the base for your next campaign. Future updates will be easier to check, and if something does go wrong, you will have a clean place to start looking.
Join our Telegram for more insights and share your ideas with fellow affiliates!
