If your site uses YOOtheme Pro, check its version today. A webshell attack against versions 5.0.0 through 5.0.52 is already happening, and the fix is in 5.0.53. This isn’t a case where updating next month is probably fine. I’m Andrei, and my advice is simple: update first, then look for signs that someone got in before you updated. The second part matters because a theme update won’t remove a file an attacker has already planted.
What happened with YOOtheme Pro?
YOOtheme Pro is a premium theme and page builder for WordPress and Joomla. Its image handler has a flaw tracked as CVE-2026-102785. The YOOtheme changelog says version 5.0.53 fixed unauthenticated remote code execution through that handler; the update came out on 21 October 2026. The CVE was published the next day, and proof-of-concept exploits were available from 23 October. Its CVSS 4.0 score is 10.0, the maximum, and the CVE record calls it automatable.
In plain English, the handler signs image URLs, but the signature didn’t cover every extra image operation or the place where the result gets saved. An attacker can take a signed image URL already published on your site, add operations, and make the handler write a .php file into wp-content/uploads. No login needed.
There’s an odd trap here: the server can return an HTTP 500 error and still write the file. If you spot failed requests in a log, don’t assume they failed to do damage. The planted file can be a valid JPEG with PHP code tucked into its image metadata, so it may look like a picture at first glance.
Palo Alto Networks Unit 42 observed automated attacks in the wild. The first webshell was written two days after the patch came out. Their report describes a scanner checking a dropped shell within about three seconds; roughly two minutes later, a human operator uploaded a second webshell, wrote files into wp-content/uploads/ALFA_DATA/, and tried to install a remote access tool called gsocket. That’s why I’d treat an unexpected PHP file here as urgent, not as housekeeping for later.
Do this today
- Check your version. In WordPress, look under
Appearance > Themesor in the YOOtheme customizer. Joomla users can check the extensions manager. If you have 5.0.0 through 5.0.52, update to 5.0.53 or newer. - Confirm the update actually landed. YOOtheme Pro is premium software, so updates depend on your YOOtheme account and API key. An expired key can leave a site on an old version while everything else seems normal. Check the version number again after updating.
- Inspect files and logs. If your site ran an affected version after about 23 October, do this even if it now shows 5.0.53. Updating closes the opening; it doesn’t remove an existing webshell.
If you’re paying for WordPress maintenance, ask the person handling it to confirm both the installed version and the uploads check. A message saying “updates done” doesn’t answer the second question.
Check your uploads folder for PHP files
On a WordPress site, wp-content/uploads normally shouldn’t contain PHP files. If you have file manager or SSH access, start there. Ask your host or developer to run these checks if you don’t. Don’t open a suspicious PHP file in your browser to see what it does.
find wp-content/uploads -name "*.php"
find wp-content/uploads -name "yt*.php"
ls -la wp-content/uploads/ALFA_DATA
grep -rl "<?php" wp-content/uploads --include="*.jpg" --include="*.jpeg" --include="*.png"
find wp-content/uploads -type f -newermt 2026-10-21Unit 42 reported first-stage names following yt plus seven hexadecimal characters plus .php, directly inside uploads - something like yt3a9f0c1.php. Don’t check only that pattern. A different name, a PHP file deeper in a dated folder, or an unexpected ALFA_DATA directory deserves a closer look too. The last command gives you a wider view of recently changed files; recent doesn’t automatically mean malicious.
Check the access logs, including the errors
Ask your host for web access logs covering the period since 21 October, particularly if the site was on an affected version after about 23 October. Look for requests containing yootheme= together with FromFile or Save in the query, and for requests to .php files under uploads. A single matching request isn’t a complete diagnosis. It is a reason to investigate, especially if file checks also turn up something strange.
Don’t filter out HTTP 500 responses. Remember, the vulnerable handler could report an error after writing the file. If the logs are hard to get or have already rotated away, say so to whoever is checking the site; don’t quietly mark the investigation complete.
Block PHP execution in uploads as a safety net
Uploads are for media, not executable scripts. On an Apache setup that permits .htaccess rules, a file at wp-content/uploads/.htaccess can deny requests to PHP files:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>On Nginx, your host needs to set the equivalent rule in the server configuration; an .htaccess file won’t do it. Ask them to verify the rule works. This is a safety net, not a substitute for the YOOtheme update or a cleanup if someone already got in. It won’t undo commands that ran before the block was added.
Use a scan, but don’t let it end the investigation
Run your usual malware scan after the file and log checks. It can help find other changes, but a file that’s a valid JPEG with PHP hidden in its metadata may slip past a scan that judges it by its image content. I wouldn’t accept a clean scan alone as proof the site is clean. I explain that gap in what a malware scan checks and misses.
If you use Joomla instead
The affected YOOtheme Pro versions and the 5.0.53 fix apply to Joomla too. Check your version in the extensions manager, then inspect your site’s media and images folders for PHP files. Joomla’s folder layout isn’t the WordPress wp-content/uploads path, so don’t copy the WordPress commands without changing the path.
If you find a webshell
Don’t just delete that one file and carry on. The first webshell can run commands and offers a file upload form. Once it’s been used, you need to treat the whole site and server account as potentially compromised. Preserve what you’ve found, contact your host, and get help checking what else changed. Review admin users, change passwords, and restore from a backup you know was clean or arrange a proper cleanup.
For the order of the recovery work, use this step-by-step hacked WordPress site guide. If you’d rather have someone handle the investigation, our hacked site cleanup service is there for that. My take: don’t spend the afternoon guessing which single file was the problem when the first one could have uploaded another.
Start with the version number. Then check uploads, even if the update was succesful. Those are two separate jobs.