I have a website which is managed through CPanel. I know that remote database connections are disabled by default and I have tested that it is indeed disabled.

I know that many people have some of my database passwords, but they cannot connect to it. Should I be worried about it? I know they should not know the passwords, but CPanel doesn't let them connect to the database remotely, so is this really a problem? Can they connect to the database in any way?

  • 1
    Hello Jake, unfortunately this question is off topic. This question is more a configuration question than security question. – Lucas Kauffman Jun 5 '13 at 7:27
  • I don't think so, because it could explain the remote access technics to mysql. – user13934 Jun 5 '13 at 7:29
  • IMO it's still a configuration question better suited for SU or SF – Lucas Kauffman Jun 5 '13 at 7:42
  • I don't want to config some thing sir, i want to know the attacker tecknics.I think i can get more useful answer here. – user13934 Jun 5 '13 at 8:03
  • Change the passwords. – schroeder Jun 5 '13 at 17:24

If Mysql is only accepting local connections (as configured through CPanel), and the people who know the passwords don't have any shell access to your machine, nor any other way to open a local network connection, then they cannot connect to your database and therefore their knowledge of the password doesn't make a difference.

Nonetheless, you are taking the risk that one of these assumptions is violated.

If at some point you accidentally misconfigure the database authorizations in CPanel, or if you decide you need remote connections from some purpose (e.g. because you want to split your service and put the frontend and the backend on different machines), then at this point your data will become exposed. You'll have to change the passwords at that time, and the more you wait, the more places you'll likely have to update, and the higher the risk that you'll forget that the passwords are known.

If at some point the people with the passwords gain access to your machine, they'll be able to access your data. This can obviously happen if they get shell access, but that's only one way. Even if you grant them some restricted access for a different purpose, it may allow them to open local network connections. The most obvious way is if you let them use that server as a relay, but it could also come through less obvious interactions. It's also possible that one of the applications running on your server is partially broken, for example allowing an SQL injection. You might have a low-importance application that only accesses some unimportant table and has an SQL injection vulnerability; if someone exploits that vulnerability and they know some database passwords then they can access all these other databases and not just the unimportant one.

As those people know your passwords, you don't only need to trust them not to misuse them. You also need to trust them not to expose them. Even if they're perfectly honest, if they store your passwords in a file and their machine is compromised then your passwords will be compromised.

| improve this answer | |

Remote MySQL connections are disabled by default in cPanel servers because they are considered a potential security threat. Using the tools in the Web Host Manager (WHM) and the domain-level cPanel interface (usually http://domainname.com/cpanel) remote hosts can be added, which the server allows to connect to the MySQL service. But which needs access to your CPanel.

So normally its safe, but its better to make sure that your CPanel has only access to your authenticated users.

| improve this answer | |

CPanel can be exploited by someone reading your e-mail or intercepting an e-mail on your phone when the account is setup (if you've not changed the passwords provided).

Additionally if the password is weak and the attacker knows the naming convention for user accounts (and potentially host created passwords) they may be able to get into your C-Panel.

At this point, if someone gets the passwords to an SSH account (or if for some reason you're host is using the same Username/Password combination for SSH as they are for the Cpanel) they can get into the box with an application like MySQL Workbench through an SSH tunnel. (It's one of the security options in MySQL).


  1. User gets your SSH account login.
  2. User cats your config.php for your website.
  3. They add the username and password from that file to their MySQL Workbench profile.
  4. They gain access username has rights for on localhost.

If someone gets your SSH password your MySQL server is likely not to be their next attack vector, but it is possible.

It's also possible for them at this point to install their own scripts which connect to a remote MySQL server for exploits (if the server is blocking remote URL opening).

This does happen, but it's a right place at the right time scenario. It sounds difficult, but I had a corporate client register a hosting account, they forwarded the logins to their IT guy (and a couple of higher up managers) and to myself through e-mail once they came over the server firewall initially from the host. All of the corporate guys get copies of their e-mails on their smart phones (some of them use public networks for checking their e-mails like coffee shops and airports). One of the information streams was compromised and within an hour (I was at lunch when the e-mail came through), someone else had already configured the box and exploited it by the time I tried the logins. It was a new VPS install, so it didn't take too long to fix it. When the host sent the new logins for another different VPS I had them only send them to me. I changed the accesses, encrypted, burned to disc, and mailed the logins to my corporate counterparts (for logging purposes) after I altered all of the host-provided logins and credentials (I also killed c-panel on the machine).

We thought about trying to track down the leak, but it was much easier to implement new corporate policies about logging into foreign networks, password strengths, and chain of custody for logins. A lesson for all.

| improve this answer | |