Found filefuns.php on Your WordPress or Joomla Website? Your Site May Be Compromised
If you've recently found a file named filefuns.php hiding inside a WordPress or Joomla website, you should take it seriously.
I've been seeing reports of this particular filename appearing on compromised PHP websites, and it isn't something that belongs in a normal WordPress or Joomla installation.
More importantly, deleting filefuns.php and moving on is not enough.
If the file exists, the more important question is:
How did someone get permission to put it there?
What Is filefuns.php?
filefuns.php appears to be associated with malicious PHP backdoors or webshell activity.
A webshell is a PHP script placed on a web server that can give an attacker a way to interact with the server remotely.
Depending on the particular malware involved, a backdoor may allow an attacker to:
- Create or modify files
- Upload additional malware
- Modify
.htaccess - Create administrator accounts
- Execute PHP code
- Redirect visitors
- Inject spam pages
- Access configuration information
- Reinstate malware after you've removed it
- Potentially move into other websites hosted under the same account
The important point is that filefuns.php is probably a symptom of the compromise, not the original vulnerability.
Simply finding that filename doesn't tell you exactly how the attacker got in.
This Isn't Just a WordPress Problem
It's tempting to see a suspicious PHP file inside WordPress and conclude:
“WordPress was hacked.”
The same thing happens with Joomla.
But that isn't necessarily what happened.
The same filefuns.php filename has been observed across different PHP applications. In 2026 there have been reports involving WordPress, Joomla, and Magento installations.
That strongly suggests that the filename belongs to a malware toolset or attack campaign rather than being part of one particular CMS.
In other words:
Finding filefuns.php tells you that the website may have been compromised. It does not, by itself, tell you which vulnerability was exploited.
Recent Joomla Attacks Are Particularly Interesting
There has been significant security activity around Joomla extensions during 2026.
In June 2026, JoomShaper released SP Page Builder 6.6.2, specifically noting a security fix involving its upload endpoints. Around the same time, Joomla administrators reported active attacks involving PHP file uploads.
One Joomla administrator reported discovering Filefuns.php inside the site's /media directory after a compromise. Akeeba support specifically advised checking vulnerable extensions and noted that multiple Joomla extensions had received emergency security updates at the time.
Source: Akeeba Support — Advice After Hacking
That's important because directories such as:
/media//images//tmp/
and similar locations normally contain media, temporary files, or generated content.
A random executable PHP script appearing there should immediately get your attention.
WordPress Sites Are Seeing It Too
WordPress administrators have also reported filefuns.php.
One July 2026 DirectAdmin community report described a compromised WordPress installation where the attacker had modified .htaccess, created additional WordPress users, and placed filefuns.php outside the normal public website directory.
Source: DirectAdmin Community — Security Discussion
There are also older reports showing the same filename included among groups of malicious PHP files associated with compromised WordPress installations.
So this isn't necessarily a brand-new piece of malware.
What may be new is the vulnerability being used to distribute it.
Look for More Than filefuns.php
This part is extremely important.
If you find filefuns.php, do not assume that's the only malicious file.
A successful attacker may leave several methods of getting back into the site.
I've seen compromised PHP websites where removing one obvious file accomplished almost nothing because there were several additional backdoors hidden elsewhere.
Look for recently created or modified PHP files, particularly in directories that shouldn't normally contain executable PHP.
On Joomla, investigate locations such as:
/media//images//tmp//cache/- Upload directories
- Extension-specific media directories
On WordPress, inspect areas including:
/wp-content/uploads//wp-content/cache/- Plugin directories
- Theme directories
- The WordPress root
- Unexpected directories underneath
wp-content
A PHP file inside an uploads directory is particularly suspicious.
Images don't need PHP scripts to display themselves.
Check .htaccess Carefully
Another recurring characteristic of PHP malware infections is modification of .htaccess.
Attackers sometimes add rules designed to accomplish seemingly contradictory things.
They may block access to most PHP files while explicitly permitting their own malicious scripts.
That can make cleanup confusing because legitimate parts of the website suddenly return:
403 Forbidden
or:
500 Internal Server Error
while the attacker's own scripts continue working perfectly.
If your .htaccess suddenly contains a long list of strange PHP filenames, don't assume it's some obscure Joomla or WordPress configuration.
Compare it against a known-good copy.
Check for Administrator Accounts You Didn't Create
File-system access isn't the only persistence mechanism.
Check your CMS users.
In WordPress
Look at:
Users → All Users
Pay particular attention to users with the Administrator role.
In Joomla
Check:
Users → Manage
and investigate any unexpected accounts with Super User privileges.
Don't only look for obviously suspicious names.
An attacker doesn't have to call their account evil-hacker-123.
Something resembling support, system, administrator, sysupdate, or another plausible system account may attract less attention.
If an administrator account appeared without your knowledge, assume the compromise extends beyond one PHP file.
Update Everything — But Understand What Updating Does
If your website has been compromised through a vulnerable plugin, Joomla extension, template, theme, or other component, updating it is critical.
But updating a vulnerable extension does not remove malware that was already installed.
Think of it this way:
If somebody breaks into your house through a damaged door, repairing the door prevents someone from using that same hole again.
It does not remove the person already hiding in the basement.
So the correct sequence isn't simply:
Update Joomla or WordPress → Done
You need to both:
close the vulnerability
and:
remove the compromise.
What I Would Do After Finding filefuns.php
1. Preserve a Copy of the Compromised Site
Before tearing things apart, make a copy of the files and database.
Yes, you're deliberately backing up an infected website.
That's useful.
Logs, timestamps, unfamiliar files, database records, and modified configuration files may help determine what happened.
2. Check File Modification Times
Look for files created or modified around the same time as filefuns.php.
Attackers frequently upload several files within seconds or minutes of each other.
Modification timestamps aren't perfect evidence because they can be manipulated, but they're still extremely useful.
3. Search for Unexpected PHP Files
Look especially closely at PHP files inside directories that normally contain:
- Images
- Documents
- Cache files
- Temporary files
- User uploads
Don't blindly delete everything that looks unfamiliar.
Some extensions legitimately use unusual directory structures.
Investigate first.
4. Inspect .htaccess
Search for unexpected FilesMatch rules, rewrites, redirects, and lists of PHP filenames.
Also check for .htaccess files buried in subdirectories.
5. Check CMS Users
Look for unexpected:
- WordPress administrators
- Joomla Super Users
Also check when those accounts were created when that information is available.
6. Update the CMS and Every Extension
Update:
- WordPress or Joomla
- Plugins
- Components
- Modules
- Templates
- Themes
- Frameworks
And remove abandoned software you're no longer using.
A disabled vulnerable extension is not necessarily something I want sitting on a production server.
7. Replace Core Files With Known-Good Copies
Instead of trying to visually determine whether every WordPress or Joomla core PHP file is legitimate, replace core files with clean copies from the official distribution where practical.
Don't overwrite configuration files without understanding what you're doing.
8. Change Credentials
After gaining confidence that the server is clean, rotate credentials including:
- CMS administrator passwords
- Hosting control-panel passwords
- FTP/SFTP passwords
- SSH credentials
- Database passwords
- API keys
- SMTP credentials
If an attacker could read your configuration file, assume credentials contained in that file could have been exposed.
9. Check Other Websites on the Hosting Account
This is a big one.
If you host six websites under one hosting account and discover filefuns.php on one of them, check the other five.
Depending on the server's permission structure, one compromised website may allow malware to modify neighboring sites.
Cleaning only the website where you first noticed the problem can turn into a frustrating game of malware whack-a-mole.
You delete it.
It comes back.
You delete it again.
It comes back again.
Sometimes that's because another compromised application on the same account is simply reinfecting it.
Don't Immediately Restore an Old Backup
Backups are extremely useful, but there's a trap here.
Suppose you discover the infection on August 20 and restore your August 15 backup.
Great.
Except the attacker originally compromised the website on August 3.
You just restored the malware.
Before trusting a backup, try to determine approximately when the compromise occurred.
Then restore a version from before that date and immediately patch whatever vulnerability allowed the intrusion.
Otherwise you're restoring the unlocked door along with everything else.
Joomla Administrators Should Restrict PHP Execution Where Possible
One defense I particularly like is preventing PHP execution in directories where PHP has no reason to execute.
Akeeba's Admin Tools, for example, provides server-protection functionality designed to block direct access to PHP files in locations such as Joomla's media, images, temporary, cache, and log directories. Akeeba specifically noted that this kind of protection could prevent an uploaded Filefuns.php from being executed even if an attacker managed to place it in one of those directories.
That's defense in depth.
The upload vulnerability still needs to be fixed.
But turning an uploaded PHP file into an inert file instead of executable code can dramatically change the outcome of an attack.
WordPress Administrators Can Apply the Same Principle
WordPress sites can benefit from the same basic strategy.
Your /wp-content/uploads/ directory needs to accept things like .jpg, .png, .webp, .pdf, and other legitimate uploads.
It generally does not need to execute random PHP scripts uploaded there.
Server configuration can restrict PHP execution in appropriate content directories.
Exactly how you implement that depends on whether the server uses Apache, LiteSpeed, nginx, or another configuration.
The principle is what matters:
A directory intended to contain user-uploaded images should not also function as a convenient application server for an attacker.
Finding filefuns.php Means You Need to Find the Original Vulnerability
This is the part I can't emphasize enough.
Deleting filefuns.php may remove one malicious file.
It doesn't answer:
How did filefuns.php get there?
Maybe it was:
- A vulnerable WordPress plugin
- A vulnerable Joomla extension
- An insecure file-upload endpoint
- Stolen administrator credentials
- Stolen FTP credentials
- A compromised hosting account
- Another infected website under the same account
- An outdated application
- Incorrect file permissions
- A vulnerable custom PHP script
Until you identify and close the path the attacker used, you can't be confident that the website is clean.
The Bottom Line
If you find filefuns.php on a WordPress or Joomla website, treat the server as potentially compromised.
Don't panic.
But don't simply delete the file either.
The existence of the file is useful information.
It's your clue that something happened.
The real troubleshooting work is determining:
- When the file appeared.
- How it was uploaded.
- What else changed at the same time.
- Whether additional backdoors exist.
- Whether administrator accounts were created.
- Whether credentials were exposed.
- Which vulnerability needs to be patched.
- Whether other websites on the server were affected.
That's the difference between removing malware and actually cleaning a compromised website.
And with attacks like this, that distinction matters.