Dennis Dornon
Hi, I'm Dennis Dornon! As the creator and co-founder of MainWP, my team has helped thousands of web professionals streamline their WordPress maintenance workflow.

In light of the recent article from WeWatchYourWebsite, WordPress Sites Attacked via Management Consoles, which is bringing attention to a new attack vector affecting WordPress websites via management systems, we at MainWP feel it’s necessary to address these concerns and ensure the WordPress community that we are committed to providing a secure platform for managing your WordPress sites.
The article highlighted a concerning issue: attackers exploited management consoles to modify files and install bogus plugins on WordPress websites.
The WordPress managers mentioned included ManageWP, WPUmbrella, and our very own MainWP. It’s crucial to reiterate the point made in the article that these malicious activities were not due to faulty programming by any of the mentioned companies but rather a sophisticated understanding of the WordPress ecosystem by malicious actors.
Here’s a breakdown of our analysis and the proactive steps you can take to help ensure the security of your MainWP Dashboard:
1. Understanding The Attack Vector: The attackers seemingly gained access to management consoles by logging in as legitimate users. The logs showed that these illegitimate activities were carried out from different servers, implying that the servers might have been compromised and used as a stepping stone by the attackers.
MainWP Note: Your Dashboard will never ask for your password to your other WordPress sites; your MainWP Dashboard communicates with your “Child” sites in a different way that you can read about in our MainWP Connection Security post. You can dive into more MainWP security articles over on our Security page.Also, since you self-host your MainWP Dashboard, no one at MainWP ever has access to your Dashboard. Because of that, this type of attack cannot target MainWP employees for access to your Dashboard.
2. User Education: We cannot stress enough the importance of following good security practices. As outlined in the article, simple measures such as avoiding open WiFi networks for managing your WordPress sites, always logging out of your sessions, and using 2-FA can significantly enhance your security posture.
MainWP Note: Since your MainWP Dashboard is run from WordPress, you can use your favorite 2-FA plugin. We use WP 2FA since MelaPress is a MainWP partner. We have a knowledge-based article to get you started on adding a 2-FA solution.Remember to ALWAYS logout of your MainWP Dashboard this kills the session cookie and stops this hack if you haven’t already been attacked.
3. Community Engagement: We believe in the collective power of the WordPress community in facing such security challenges. We encourage users and security researchers to report any suspicious activity they may come across. Your input is invaluable in making MainWP and the entire WordPress ecosystem safer.
We appreciate the vigilance of the WordPress security community, especially Thomas J Raef and WeWatchYourWebsite, in bringing such issues to light, and we remain committed to providing a proactive response to ensure the ongoing security and trust in our platform.
Thank you for your continued trust and support.
Dennis Dornon
Cofounder
MainWP
Manage Unlimited WordPress Sites from One Dashboard!
6 comments
Bogdan Rapaic
MainWP Child plugin needs to store the Dashboard site URL for proper functioning of certain plugin features. For example, when posting Posts and Pages from MainWP, images inserted in the content will originally have the URL from the MainWP Dashboard. After publishing content to Child sites, the plugin has to replace the Dashboard URL with the Child URL so images are loaded from the Child site instead of the Dashboard.
This is how the plugin worked from the beginning; this is not something that has been introduced recently.
However, we do understand your concerns, so we decided to encrypt this data. This change will be included in the next MainWP Child release.
Lee
Thank you Bogan
Lee
Sorry, I thought I’d typed ‘Bogdan’. My keyboard must be feeling under the weather.
Mike
I couldn’t agree more with Lee. The URL of the dashboard location should never be revealed in the child site’s database. It is up to MainWP users how much they want to protect the dashboard. But we have no control over the information that is stored in the child site’s database. Like many others I use a dedicated installation for the MainWP dashboard that has no frontend whatsoever. I use a minimum of plugins, and access is restricted to a specific range of IPs. It is hosted on it’s own server. I don’t use 2FA for practical reasons. It doesn’t seem necessary for this setup. This seems to me very hard to breach by automated attacks. However, storing the dashboard URL encrypted in the child site’s database is a great idea, in my opinion.
Lee
It would help if the dashboard site’s location were encrypted in each child site’s database. The last time I checked the dashboard site is listed in plain text in each child site’s database. We do not want a hacker of a child site to locate the dashboard site through inspection of the MainWP database tables. Better yet, do not list the dashboard site’s address in a child site’s database; use a key-pair to restrict interaction between the dashboard site and the child site.
My own dashboard sites are used only as dashboard sites. One is on my local server. The other is on a remote server. Like Ken Sim says in his comment, the login page is hidden and the WP dashboard is the only accessible area of the site.
I think it is important to install security plugins into each dashboard site, one that performs regular scans and monitors the login form for brute force attacks and invalid usernames.
Would the MainWP Team consider a different type of login process for the dashboard sites? One that completely removes the login form and instead requires a bookmark to login to the site? That bookmark link would contain a long hard to guess login key. No login URL key = No access to the site.
Ken Sim
I would also highly recommend using the Dashboard Lock extension. This way only your IP can access the dashboard. Then when you are traveling, use a VPN and add that VPN IP in the .htaccess file through your host portal or FTP.
There is no frontend to my dashboard, so I redirect any user trying to access the frontend to my primary website. Then just put in the rules to not redirect the login slug.
Comments are closed.