WP Engine: 2024 Nov 18 - Security & Plugin Vulnerability Notices

Support
, ,
1

WP Engine has recently started sending out emails to all customers that are hosted on their platform who have the MainWP Child plugin installed, regardless of version at this time, with the following messaging:

Hello,

At WP Engine we take the security of your sites very seriously, and make every effort to keep our customers aware of any potential security risks. We are reaching out to you today because we identified resources that may be utilizing a vulnerable version of the mainwp-child plugin.

This vulnerability’s information has been verified by WPScan. Please note that questions related to this notification should be directed to WPScan, the plugin Author or the 3rd-party researcher for the most accurate information.

Resources providing further information on this vulnerability:

CVE - CVE-2024-10783
MainWP Child <= 5.2 – Authentication Bypass | CVE 2024-10783 | Plugin Vulnerabilities
MainWP Refuses to Patch Critical Flaw Leaving Sites Vulnerable to Takeover

There does not appear to be a fix for this update at this moment and we recommend updating when one becomes available.

We always suggest making a backup before making any changes. You can learn how to do this in this article: https://wpengine.com/support/restore/.

Would you like to avoid doing these updates manually in the future? Add the Smart Plugin Manager: https://my.wpengine.com/products/smart_plugin_manager to your plan today!

Finally, feel free to reach out to our Support team if you need assistance with backing up or updating your website!

Thanks,
-WP Engine Security Team

Looking at the kernelmode article, the author outlines very clear reasons why MainWP should be taking action to fix this (by enforcing the use of the Unique Security ID instead of making it optional) but that the MainWP engineers have elected to argue against this change vs simply doing the work to have a rollout plan to notify the users of the MainWP management ecosystem on their servers to employ the mandatory user of Unique Security IDs moving forward.

I’m in the unfortunate position where my superiors aren’t convinced that MainWPs stance is “good enough” and I am also attempting to avoid having to use a competitor product to achieve the same functionality.

What does everyone else think?

1 Like
2

Don’t worry and read the article from @dennis that he posted last week:

This is not a security issue, because it’s working as designed. However, there will be some improvements in version 5.3 tht will be available soon, so in this CVE publication there are a few things that aren’t true.

If you need to explain this to non-technical people you can compare it to: there’s only a security risk if you leave the door to your house wide open and go away. As long as you stay near the door and close it as soon as you can, there’s no issue.

3

Thank you for that article, and the advice.

This post is here as well for anyone who might be coming to the same place for answers (I came here first because this is my preferred source for support, from the community and MainWP specialists).

You also might want to pin this to the top until the update is released.

Lastly, a projected release date would be nice too, but understandably difficult considering the factors in play here.

4

The article was posted here too, so a search would have showed it.

I’m not an admin/mod on this platform, so I can’t pin anything. As a regular user I just can answer questions as much as I can.
The beta test of 5.3 was announced yesterday, should start within 33 hours and you can still sign up for that if you want.

5

Thanks for posting this @smartstartllc and for jumping in @josklever. As of my last discussion with the Security Companies CTO, they have dropped this as not a vulnerability, and we are just waiting for final confirmation from another person on their team to consider this fully closed.

Addressing Misleading Claims and WP Engine’s Actions

Recently, we’ve seen some unfortunate and misleading claims circulating about MainWP’s connection process, compounded by WP Engine’s decision to send out emails warning their customers about a supposed vulnerability in our plugin. We want to take a moment to clarify the situation and address these concerns directly.

A Reserved CVE is Not a Published CVE

The CVE referenced in WP Engine’s email is currently reserved, not published. A reserved CVE does not mean it’s valid, confirmed, or actionable. It may never be published or could be reassigned to something completely unrelated. WP Engine’s reliance on a reserved CVE, alongside an unverified blog post, seems both premature and irresponsible.

Hosting providers, particularly those serving professionals, have a responsibility to share accurate, verified information, not to alarm users based on speculation. If you’re a WP Engine customer, we encourage you to reach out to their support team to express concerns about their handling of this issue. We encourage the same for WP-Scan customers

CVE-Reserved
CVE-Reserved1467Ă—835 108 KB

A Documented Feature, Not a Vulnerability

The process in question has been a documented feature of MainWP since its inception. It was intentionally designed to balance security and usability for agencies managing multiple sites, with safeguards like public-private key encryption and dashboard warnings built in. This design decision has reliably served professionals for over a decade.

While feedback from the community and security experts has prompted us to add new security options, it’s important to stress that this is not about patching a vulnerability. These updates, such as a one-time password for the first connection and a time-limited connection window, are about providing additional user control and evolving with modern security expectations, not addressing a flaw.

Addressing the Researcher’s Actions

It’s also worth noting that the security researcher behind these claims has been temporarily banned from the Security Companies bug bounty program they reported through due to their actions, including publishing premature and misleading disclosure. This behavior goes against responsible security practices and has caused unnecessary confusion in the community.

Moving Forward

We’re committed to transparency and responsible development. If you’d like to see a detailed timeline of events and our perspective on the issue, you can read our response here: Addressing Misguided Security Reports: Why MainWP is Updating Its Connection Process.

We hope this clears up any confusion. If you have questions or need further clarification, please don’t hesitate to reach out and as @josklever pointed out you can see our response at that post.

3 Likes
6

Quick Update: Due to this morning’s WP Engine and WPScan emails and posts, we have released MainWP Child plugin 5.2.1.

This update to the MainWP Child plugin pre-checks the Unique Security ID as a requirement for adding a child site to your Dashboard. This update was necessary to address challenges stemming from WP Engine and WPScan.

We appreciate your understanding as we implemented this change ahead of the MainWP 5.3 testing and release timeline to mitigate any issues. If you have any questions or need assistance, our support team is here to help.

1 Like
7

The article was posted here too, so a search would have showed it.

Easy there. Different people have different ways of getting to a solution. I’m not always confident in my search capabilities or results when performed.

As such, I didn’t see that forum post in initial searches, however I was also driven to scan the top-most posts first, as it seemed something that might have made some headline (pinning status).

I also wanted to make sure to raise awareness that WP Engine is sending out notifications, which I now see being addressed in the timeline of the article as well.

8

Thank you for hopping on for a quick response Dennis.

I also noticed that the article was updated with timeline details as of early this morning based on the latest actions by WP Engine, and follow ups with the respective parties reporting this CVE.

This is welcome due diligence needed that will squash any potential concerns.

In what little effort I can contribute, I will reach out to the WP Engine team on their support chat (we have upper tier priority) to ask them to review this page and to ask to further update their notifications with new information that includes your patch in the messaging.

Hopefully they will alter their position/communications.

1 Like
9

Thank you, Mike. I really appreciate you taking the time to reach out to the WP Engine team, that kind of effort truly helps.

Regarding notifications, I recommend signing up if you’re not already subscribed to our weekly update emails. That is really our most efficient way to get information out to as many users as possible.

You can do so easily at the top of the My Account page. These updates are where we share important information like this, and I believe we’ve sent a couple of emails on this topic to those who are subscribed.

We keep it light, typically one weekly email focused on plugin updates, issues, and everything happening in the MainWP ecosystem. No spam, just relevant info. :blush:

1 Like
10

With respect I completely disagree with your analogy and defense of this feature.

First, it absolutely is a security issue. Just because something was “designed” a certain way does not magically mean it isn’t a security issue. I don’t understand that logic at all. Things can and are designed poorly.

Second, your house analogy completely fails. Sticking with it though, in that scenario a burglar would be invisible and could walk right in while you’re standing there.

People are always the weakest link in security, and that is exactly why this needs to be changed. What if you are connecting a MainWP site, and spill some hot coffee on your lap, and completely forget about it? The site could be easily exploited during that window.

That said, I do love MainWP but am glad that they are changing this behavior.

11

Thank you for sharing your perspective! I appreciate the feedback and understand where you’re coming from.

To be crystal clear, we’re not arguing against making changes to improve the connection process. In fact, we recognize the value of these updates ourselves, as highlighted by the results of our Facebook poll among MainWP users. I think these updates are 100% positive and I am excited about them. That’s why we’re introducing the enhancements in the 5.3 version, such as one-time passwords and time-limited connection windows. By the way if you have not joined the Early Release of 5.3 to help us test the new connections jump on over to MainWP Early Release - MainWP WordPress Management and install and let us know your thoughts!

What we’re challenging, however, is the classification of this as a security incident that qualifies for a CVE. The connection process has always been an intentional, documented feature designed to balance usability and security, with safeguards like public-private key encryption and dashboard warnings already in place. While we agree updates will help meet evolving expectations, we do not believe this scenario fits the established criteria for a CVE.

Additionally, I want to ensure that this discussion doesn’t devolve into a heated debate among MainWP users, especially since the security company involved has yet to definitively answer whether this will be formally released as a CVE. Until we have clarity on that front (hopefully today), we believe the focus should remain on understanding the facts and supporting each other as a community.

Thanks again for the constructive discussion, it’s these kinds of conversations that help us continue to grow and improve!

1 Like
12

Thanks Dennis! Understood about the nuances between whether or not it should be a CVE or not which is why I used the term, “security issue” which I personally do consider it be, and didn’t comment on validity of it being a CVE or not. Defer to you / others on that!

That said, I did read your blog post and have really appreciated your tone and approach to this. Didn’t mean to start a fight :slight_smile:

Lastly I am signing up now for the early release list. happy to help!

2 Likes
13

Now that the feature for the Unique security ID is set as default, may I suggest that in a future version of MainWP you add a setting option on the Manage Sites dashboard that will identify if a Unique security ID has been set (without identifying the ID). This way we can easily see the sites that do and don’t have this set since running through multiple sites individually is quite time consuming. Just a thought…

14

Once the sites are connected the unique security key is no longer used so I may be missing your use case here but I would recommend testing the early release version it has different connnection features for pre-connection.

Once your site is connected the rest of the communication between your MainWP Dashboard and Child Sites is performed over the OpenSSL encrypted connection. Find more on that here MainWP connection security - MainWP Knowledgebase

15

Thank you, Dennis. I was unaware that the Unique security ID was only used for the initial connection and could not be retro to any site already connected. I realize now from your response, that I’d need to disconnect and then reconnect any site where I wish to use the Unique security ID, and of course, with any new site conection going forward. Thank you for that clarification!