Fix for garbled WordPress admin screen

IMPORTANT: See update to this below after the image

After logging in, the admin screen (dashboard) of my WordPress installation was all jumbled (see screenshot below). It seemed like a CSS or JavaScript related problem. Developer tools on Google Chrome reported several issues with locating the ‘jQuery‘ variable and with the wp-admin/load-scripts.php file.

After several attempts at searching the WordPress site and googling around, I came across this forum post. Based on this forum post, I found that first configuring define(‘SCRIPT_DEBUG’, true); in wp-config.php and then refreshing my admin screen fixed the problem. Subsequently I removed this config line and refreshed my admin screen again and it stayed fixed.

It seems like in the default configuration, WordPress compresses or combines several JavaScript and/or CSS files into a single file and this compression/combination was somehow garbled. Turning on the SCRIPT_DEBUG flag turned off this compression and removing it again probably re-generated some files fixing my problem — I don’t know for sure what actually helped! But it worked.

This was with WordPress 3.3.1.

Fix for WordPress Admin Screen Garbled/Jumbled
WordPress Admin Screen Garbled


This happened a second time to me and doing the same thing as described above fixed the problem once again. But in the process, I noticed that the time-stamps on all files in my blog directory had been somehow updated to today’s date. Also *every* PHP file now had some additional code at the top within a php tag in the first line. The php code was eval‘ing a base64_encoded string via the base64_encode api. Apparently, evaluating this encoded string injected some JavaScript into every php based page on the site. It looked like some mal-ware had taken over my site. Having evaluate my site indicated there was some mal-ware (you provide your URL and they crawl your site and tell you whether your site has any mal-ware injected).

To fix my problem, I used the following shell scripts to detect files having the problem and to fix them.

Remember that I provide these scripts as an aid to anyone encountering the same problem and provide them as-is without any warranty. USE THEM AT YOUR OWN RISK. PLEASE MAKE BACKUPS OF YOUR FILES BEFORE RUNNING THESE SCRIPTS SINCE THEY WILL MODIFY FILES. The regular expression I used worked for me, but they may not necessarily work for you. BACKUP, BACKUP, BACKUP. Also the below may not be sufficient to rid your site of this mal-ware. I don’t know what else needs be done to completely rid your blog of the mal-ware.

To find all the files with this injected php code, I used the following script:

find . -name “*.php” | xargs awk ‘FNR == 1 && /<?php.*base64_.*?>/ {print FILENAME}{nextfile}’

To remove this line of injected php code, I used the following script:

find . -name “*.php” | xargs sed -i ‘1s/<?php \/\*\*\/ .val(base64.decode(“.*==”));?>//’

(In the above scripts, please fix the quotes and the double-quotes — pre-formatted code doesn’t wrap, so had to use regular formatting which messes with quotes and such)

Now I wait and watch to see if the problem re-surfaces, if it does, then I know there is more I need to do.


This happened yet another time and I cleaned up in the same manner. I also searched some more and found that someone had installed the infamous c99 shell to allow them backdoor access into my setup. They were using this backdoor access to periodically inject additional php code into my php scripts. I found the c99 shell by searching for the string “gzdef.ate.base.._encode” (I am using . instead of the actual character to prevent security tools from thinking this page has a security issue. Replace the dots with ‘l’, ‘6’ and ‘4’ in order). I removed the backdoor, but I am yet to find the vulnerability in the existing script that was exploited by someone to install the backdoor shell in the first place. Looking…