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, oreval - 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
- Open VS Code
- Go to File → Open Folder
- 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:
How to Upload the Cleaned Files Safely
Once the local files are clean:
- Reconnect to the server using SFTP
- Upload the cleaned versions over the infected files
- Test the site immediately afterward
- 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.
Top comments (0)