Fighting Through an Open Redirect Compromise
In mid November of 2025, a web property I manage had the distinction of being compromised. Locking this site down had been difficult because of how many had permission over the installation. Too many things change, too often. None of these things I could control, but when it broke, they came to me for the fix. In I.T., this is usually not a position we want to be in, but sometimes I relish this kind of challenge.
In today’s case, a user sent in a notification with a screenshot of a Google search. It appeared as if this site had its code base modified with a call to the PHP $_SERVER[‘HTTP_REFERER’] array and then an installed script tested for https://www.google.com1. If a positive result returns, the script would push a meta redirection into the loading home page with the following:
<html><head><meta http-equiv="refresh" content="0; url=https://bad.site"></head></html>This then sends the user to a site selling pills for tooth products – nothing to do with my client’s website. Since the ‘bad.site’ changes on reloading, it was clear it was a script at work. This article does a good job of pointing out the essence of this hack. The problem is, how to find out where this is on the file system or in the database. When searching from Google, it already reflected the tile and content of the redirection target:
I then quickly enabled a “coming soon” page, this is an under construction feature on the hosting side to test a theory. The redirect appears to still be there, mainly because coming soon page was still inside of the WordPress installation, loading all the base files and plugins still. That wasn’t going to work. Looking closer, I found and deleted a file in the web root named txejednn.php that contained a bunch of variable references and a huge eval() statement2:
eval($zxdoimwbb .$mriqpfgu . $utrkqy['0'].$kkaedahm['2']. $mvtiknue['4']. $fgqzjdbd['1'] .$fgqzjdbd['1']. $mvtiknue['4'] .$jdgafnc[1].$mvtiknue['3'] .$fgqzjdbd['2'] .$sfoheynw['5'] .$fgqzjdbd['1'].$woyakwlzb['1'] .$sfoheynw['5'] .$kkwkpvxa[1])...
When you start going through the stupid scavenger hunt of all these variables, the above stuff starts to take shape as a script3:
$i=@array_merge(....
Next, it was important to rule out the database, so I went through some SQL statements to see anything referenced that PHP file:
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%txejednn.php%';
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%base64_decode%';
SELECT * FROM `wp_options` WHERE `option_name` LIKE '%txejednn.php%';
SELECT * FROM `wp_options` WHERE `option_value` LIKE '%txejednn.php%';
SELECT * FROM `wp_postmeta` WHERE `meta_value` LIKE '%txejednn.php%';
SELECT * FROM `wp_posts` WHERE `post_content` LIKE '%eval\\(%';
SELECT * FROM `wp_options` WHERE `option_value` LIKE '%eval\\(%';
SELECT * FROM `wp_postmeta` WHERE `meta_value` LIKE '%eval\\(%'; None of these yielded any real results.
I had an older backup of the site, so it was something. I started looking at the obvious culprit, the .htaccess file. Replacing that risked compromising the site, but what was there seemed to be fine.
Turning to plugins, I started to disable them and one by one, did not see a fix. Then there was one plugin I don’t recognize, “Creative Mail by Newfold Digital” – I removed that. Things then started to improve. This plugin must have been compromised or installed somehow. Afterwards, it was just a matter of continued testing to ensure this compromise had been removed. The curious thing to me is the point of compromise. It’s likely this happened because of a stale theme, but it’s hard to know. Did a plugin get attacked before it was updated? WordPress can be like wack-a-mole without tight controls over what plugins are installed4.
The next step was to ensure that all updates were happening regularly and all unneeded services were off. Any themes that were of no use: disabled. Passwords: Changed. It was also important to remove any unusual accounts and double-check the database for users added there and change every password of existing ones. I took a quick look at the file system for any plugins that might have been placed there outside of the dashboard.
Within a day, Google has returned its main search results to normal and the root redirect was gone. It would still take another few days for Google clean all these links up:
This could all be improved with security best practices, good and regular backups and a decent firewall or unified threat management device in front of it. It’s something I push for in the hopes of avoiding a complete meltdown at this web property.