Is it possible that a compromised WordPress database could somehow be used to re-infect a website?

I'm not talking about the hacker decoding user passwords and login into WP.

I'm talking about the hacker making use of a compromised database to re-infect a website WITHOUT having to login thru WP Admin.


EDIT: I have a friend whose website was hacked. The hacker injected encoded javascript codes in a number of files that call for more external JS files from another compromised site.

Despite updating the WP core + plugins + cleaning the infected files, and changing all the passwords (server, database, WP salt, etc.), the site was re-infected.

So I suspect the database could have been tampered with. Instead of hard-coding the malicious javascript code in a file, could the hacker embedded it into the database so when WP loads the database contents dynamically onto a page, the malicious code is also loaded?

  • 2
    If the db was compromised the attacker could have added records for a persistent admin account.
    – KDEx
    Dec 26, 2014 at 15:42
  • 1
    Yes, the malicious code could easily be injected directly in the database. However, it's also possible the attacker got in however they got in the first place. e.g. vulnerable code. Dec 29, 2014 at 6:12

4 Answers 4


As a former hacker and now an advanced user of WP I can say the last thing that I would care about is keeping your DB connection. There is just nothing there that is that useful to me. I can create WP scripts to download user info once I am in the admin area. You shouldn't be keeping credit card info or payment stuff in the WP database so if you are just stop.

That means hacker just wants user info or to mess with you. And for these things, like I said he would just need admin access.

The easiest way to do this is create a function or php file that logs in user as first scanned admin. I have a file on all of my internal WP sites that basically scans WP database and logs me in with the first user that has full rights. I do this because I maintain the sites and the people at my work think they own them after so they delete my account but then call me for help a week later.

I could also create a function that I could secretly call on any page too if I were really trying to hide it.

If you get hacked everything including salts in your config should be changed, your DB should get a new username and password, but most important you need to start with a clean WP install.

The fact that WP has a good file editor built into it allows people to easily do anything once in so you have to make sure they didn't leave themselves a back door - which if they are smart enough to hack you they would definitely leave something to get in later.


You need to be sure of checking the directories that hackers target usually to install a backdoor such as the deactivated themes and uploads directory. Also check the source code of your sensible files such as wp_config.php file.

There may be a shell hidden somewhere on your server that can generate the malware whenever you delete it.

You need a careful and complete scan of your website (plugins, themes, different other directories). After the full scan, you need to change your password.

  • "php shellcode"? I don't think you are using the word shellcode properly.
    – rook
    Dec 26, 2014 at 15:32
  • @Rook yes, more likely using a shellcode, but not necessarily in PHP
    – Dnakki
    Dec 26, 2014 at 15:33
  • shellcode is the payload for a memory corruption vulnerability, we are talking about a PHP application here. A backdoor that gives you a shell is not shellcode.
    – rook
    Dec 26, 2014 at 15:33
  • @rook yes, alteratively you can use any language as a vector of a shellcode. in PHP you can run it with string shell_exec ( string $cmd )
    – Dnakki
    Dec 26, 2014 at 15:38
  • This is shellcode: exploit-db.com/shellcode . It is always a binary payload, usually written in Assembler, although it could also be written in C, and then turned into a binary payload, it can never be written in an interpreted language.
    – rook
    Dec 26, 2014 at 15:39

Once an attacker has obtained remote code execution on the server, the first step is to setup persistent access. Two common ways this is done is by modifying a php file, or by adding a new .php file to the web root.

If the infection is creating spam blog posts, or other unauthorized database modifications then it maybe possible the attacker has persistent access to the database. Believe it or not, there are still a lot of hosting companies that permit anyone on the internet to login to your database. To make matters worse, database credentials are almost always stored in plaintext in the wp-config.php file. Database access must always be limited to trusted hosts using a firewall or some other network-based access control.

Reinstall from scratch, change all passwords, keep everything updated.

  • You are right about backdoor on file but WP database is really useless.
    – blankip
    Dec 26, 2014 at 19:48
  • @blankip you maybe surprised. The OP didn't describe their infection, but there are bots that just compromise WP databases to post spam, and gain a kind of persistent-xss to deliver drive-by exploits.
    – rook
    Dec 26, 2014 at 19:49
  • Yea but those bots go away once you change the config file. I guess another thing would be to turn off remote access to database period. There is no reason anyone other than localhost needs to add data.
    – blankip
    Dec 26, 2014 at 19:55
  • @lankip Honey Badger don't care about changing passwords.
    – rook
    Dec 26, 2014 at 20:03

Absolutely yes.

As others have mentioned, the code could easily be compromised. So you need to reinstall all the code. Someone else mentioned the user accounts, so you need to check the user accounts, reset passwords, etc.

But there's another potential vulnerability as well. XSS (Cross site scripting). If you replace all the code with fresh installs you still have the data itself that an attacker could have tampered with. If an attacker can inject scripts (javascript for one) into your WP site, they can steal authentication tokens when someone is logged in. That's normally game over.

Other than XSS, you'd have to be a wordpress expert to understand all the security implications of compromising the database, and I'm not. My instinct would be to start looking at any plugins you have, and any interaction with the database.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .