Addressing Misguided Security Reports: Why MainWP is Updating Its Connection Process

TL;DR

MainWP is enhancing its initial connection process in response to potential concerns raised by a security company and feedback from our community.

What was flagged was part of the initial connection process, which we had always considered a documented feature designed for usability and security. We didn’t believe the issue warranted CVE classification, but we took user feedback seriously and made proactive updates.

We addressed the main concerns in version 5.2.1 by enabling the Unique Security ID by default. With the release of 5.3, we introduced additional security options, including a one-time password for the first connection, a time-limited connection window, and an explicit disconnect option. These updates reflect evolving security expectations, not a reactive fix.

After extensive communication with the security company, the CVSS score was reduced to 8.1 (High), and the published CVE now makes it clear that this only applied to unconnected sites running older versions of the plugin.

This process has underscored some of the challenges of developers navigating the CVE system and highlighted the importance of collaboration between developers, CNAs, and researchers. Despite hurdles like unverified information being shared publicly and hosting providers acting on incomplete data, we’ve used this as an opportunity to strengthen our security and communication practices.

This has been a learning experience, and we’ve emerged with stronger safeguards for our users. We’re grateful for the ongoing trust and feedback from our community, and we remain dedicated to providing tools that meet the highest security standards while supporting the needs of WordPress professionals for years to come.

Key Changes We’re Implementing

One-Time Password for Initial Connection: A password option will now be available and will be set by default for the first connection between the Dashboard and Child site. An experienced user who knows the risks can turn this off by simply unchecking the password box.

Time-Limited Connection Window: The MainWP Child plugin will be open for connection only briefly after activation, automatically disabling if not connected.

Explicit Disconnect Option: Users can fully clear connection data, giving them control over reconnections.

These updates ensure that MainWP remains user-friendly while aligning with evolving security standards. The new features are projected to be released in version 5.3.

Read Me First

Before getting into the details, we want to highlight that MainWP fully supports the work of security researchers and actively collaborates with white-hat researchers to identify any potential vulnerabilities. Our MainWP White Hat Reward program is dedicated to such collaborations, and we’re also active participants in the PatchStack Vulnerability Disclosure Program (VDP) and HackerOne’s bounty program.

MainWP is committed to proactive security management, but sometimes the process isn’t straightforward, and unexpected issues can arise. Even if we don’t agree with a CVE or security report, its presence can impact our reputation, so we strive to handle all security concerns with care and transparency.

To maintain a constructive tone, we’ve redacted the names of the security company, the security researcher, company representatives, and the CVE number. This post isn’t meant to start a debate between security researchers and companies but simply to illustrate how plugin developers can face complex challenges with potential CVEs and security concerns, and how these can impact a plugin’s reputation.

Why a Security Company Flagged Our Connection Process

Since its inception 11 years ago, MainWP’s initial connection process was intentionally designed to provide a secure, efficient setup for agencies managing multiple sites. With built-in protections like public-private key pairing and dashboard warnings, this approach balances security with ease of use.

Recently, a security company flagged this connection method as a potential vulnerability, categorizing it as a potential “unauthenticated privilege escalation” with a severity score of 9.8!

This triggered an internal review on our end. While confident that the feature was designed intentionally with security controls in place, we acknowledged that security standards evolve, and it’s important to adapt where needed.

Security Measures Built Into the Initial Connection Process

MainWP has always prioritized security in communication between the Dashboard and Child sites. Here are the safeguards we have in place for this feature:

• Public-Private Key Pairing: A secure RSA key pair is generated when a MainWP Dashboard connects to a Child site. The private key is stored on the Dashboard, while the public key resides on the Child site, ensuring that all communication remains secure and restricted to the original connection.

• Dashboard Warning: To prevent unintentional exposure, MainWP displays a clear warning in the wp-admin area of any Child site where the plugin is active but not yet connected. Users are advised to connect immediately or deactivate the plugin until ready.

• Optional Unique Security ID: Users seeking an added layer of security can opt to add a unique security ID during the initial setup, providing further control over the connection process.

Our Interaction with the Security Company

After the security company flagged our connection process, we clarified that this setup was an intentional, documented feature. We outlined the security measures already in place and explained how the feature is designed to support easy setup for agencies and developers without compromising security.

In response, the security company suggested additional improvements and ultimately agreed that the feature did not constitute a security vulnerability. Nonetheless, they recommended some adjustments to enhance user awareness and safeguard instances where the setup may not be completed promptly. These suggestions aligned well with the feedback we’d received from our user community.

Following this exchange, we began developing new security features based on this collaborative input to further strengthen the initial connection setup. 

The security company involved in the initial report who, while acknowledging that it fell outside bounty scope, sought to publish a CVE for the sake of public record. Our stance was clear: recognizing research contributions is important, but keeping the CVE open in this context could mislead users by implying a security flaw where there isn’t one.

Listening to Our Users: Community Feedback and Enhancements

To understand how our users felt about the initial connection setup, we ran a poll in our Facebook group. Here’s what users had to say:

Out of curiosity, when you first installed MainWP and connected your first Child site, how did you feel about your Dashboard not requiring a password or other verification for that initial connection?

Very concerned	3%
Somewhat concerned	38%
Not concerned	28%
Didn’t notice / Didn’t think about it	5%
Would prefer more security options in setup	2%
Not Concerned – I used the verification key from the start (user-added)	24%

We interpreted the response ‘Not Concerned – I used the verification key from the start (user-added)’ as indicating at least some concern, given that these users took additional steps to enhance connection security.

Taking that into account, that means around 65% of respondents were concerned when they first started using MainWP on how the initial connection works so we decided to implement several enhancements that align with both user preferences and the security company’s recommendations.

The Solution: Adding a Password Requirement and Enhanced Control Features

To address CVE concerns and add user-requested security options, we’re implementing several key changes:

• One-Time Password for Initial Connection: A password option will now be available and will be set by default for the first connection between the Dashboard and Child site. An experienced user who knows the risks can turn this off by simply unchecking the password box. This password will be used only once and won’t be stored. After the initial connection, MainWP’s public-private key encryption will continue to protect all communication.

• Time-Limited Connection Window: We’re introducing a time-limited connection window for new installations. Once activated, the MainWP Child plugin will be available for connection for a brief period. If no connection is made within this timeframe, the plugin will automatically disable itself, reducing potential exposure.

• Explicit Disconnect Option: We’re adding a “Disconnect Site from Dashboard” option. This feature will allow users to fully clear connection data, giving them control over reconnections.

Together, these updates align with the security company’s standards, address user feedback, and enhance MainWP’s setup while preserving the simplicity our users appreciate.

Moving Forward: A Commitment to User-Driven Security

At MainWP, we’re committed to balancing usability with robust security. Although we believe the security report may not fully align with our original intent, we’re dedicated to meeting evolving security standards and providing a secure, reliable experience for our users. We will continue to participate in both the PatchStack Vulnerability Disclosure Program (VDP) and HackerOne’s bounty program to protect the users of MainWP, and we welcome constructive input from researchers who help us achieve this goal.

Timeline of Events

(all dates and times listed are EST) 

1. Initial Setup Design (Since Launch about 11 years ago): The MainWP initial connection process was designed as an intentional feature to make it easy for agencies and developers managing multiple sites to setup. It includes documented safeguards, such as public-private key pairing and in-dashboard warnings, to protect users while maintaining usability.

1.b Previously Dismissed by the Same Security Company (Sometime in 2019): According to a quote on the security researcher’s blog, the same security company previously dismissed this issue in 2019, stating, “The team discussed it at that time and came to the same conclusion—if it’s documented and the user gets a warning, it can’t be considered a vulnerability.” However, based on our records, emails, and recollections, we were never informed of this issue or the conclusion by the security company. If they have notes or records of these discussions, we’d welcome the opportunity to review them.

2. Security Concern Raised (Mon, Nov 4, 2024, at 9:49 AM): A security company flagged the initial connection process as a potential “unauthenticated privilege escalation” and proposed issuing a CVE, initiating a review of our process.

3. MainWP’s Initial Response (Mon, Nov 4, 2024, at 12:11 PM): We responded to clarify that this connection method was an intentional feature, designed with multiple safeguards in place, including public-private key encryption, in-dashboard warnings, and an optional Unique Security ID.

4. User Feedback Poll (Mon, Nov 4, 2024, at 1:23 PM): We conducted a poll in our Facebook group to understand user concerns. The results showed that while many users were comfortable with the setup, around 63% expressed interest in additional security options for the initial connection.

5. Constructive Suggestions from the Security Company (Tues, Nov 5, 2024, at 5:55 PM): The security company provided suggestions that aligned with the feedback we’d received from users. They also confirmed that this was a documented feature, not a security vulnerability.

6. Planning Security Enhancements Based on Feedback (Wed, Nov 6, 2024, at 11:18 AM): Based on feedback from both the security company and our community, we committed to implementing additional security features:

•   One-Time Password for Initial Connection
•   Time-Limited Connection Window
•   Explicit Disconnect Option

 We followed up with an email detailing these planned updates.

7. Direct Researcher Outreach via HackerOne (Wed, Nov 6, 2024, at 6:41 PM): A user reached out via HackerOne to inform us that the CVE had been marked as out of scope, prompting direct contact from the security researcher.

8. Verification Request to the Security Company (Thur, Nov 6, 2024, at 7:43 AM): We reached out to the security company to confirm who we should be coordinating with and to verify that the CVE had indeed been dismissed.

9. Company’s Reaffirmation to Dismiss the CVE (Thur, Nov 7, 2024, at 10:10 AM): The security company confirmed our planned changes and acknowledged the documented safeguards we had in place since the feature’s initial design.

10. MainWP’s Follow-Up Response (Thur, Nov 7, 2024, at 11:05 AM): We expressed appreciation for the constructive collaboration, reaffirming our commitment to enhancing security and supporting our users’ experience, even without a CVE.

11. CVE Reconsideration by Security Company (Thur, Nov 7, 2024 at 3:43 PM): Later that day, the security company suggested keeping the CVE open to recognize the researcher’s contribution, despite acknowledging it wasn’t a true vulnerability.

12. MainWP’s Final Request to Keep the CVE Closed (Thur, Nov 7, 2024, at 4:14 PM): We reiterated our request that the CVE remain closed to prevent user confusion. While we offered alternative recognition for the researcher, we emphasized that an open CVE wouldn’t align with CVE standards.

13. Closed Security Researchers HackerOne Post (Mon, Nov 11, 2024, at 3:42 PM): We Closed the security researchers HackerOne post as informative and explained to them how the connection process works

13. Notification Security Researcher Released a blog post (Tues, Nov 12, 2024, at 8:42 AM):
We received an automated notice that our name was mentioned on Reddit and found that the security researcher had published a blog post about his perceived security issue. We had assumed the security company had been communicating our conversation to the researcher. The security researcher published their blog post with no additional communication with us, we won’t publish a link to the post but it can be found in the Reddit r/wordpress community.

14. Reached out to the Security Company about the researcher’s blog post (Tues, Nov 12, 2024, at 9:25 AM): Reached out to the Security Company on if this is something they condone for their security researchers so we know how to proceed going forward in communications with them.

15. The release of this blog post (Tues, Nov 12, 2024 at 9:50 AM):
We had pre-written this blog post to explain to our users why 5.3 was delayed, but with the security researcher publishing their blog post, I felt we needed to get ours out to show the whole story.

16. Received a response from the Security Company CTO (Tues, Nov 12, 2024, 5:37 PM): In regards to my reach out in update 14 the CTO of the Security Company addressed the situation, acknowledging that it has become complicated due to differing views on the flagged issue. While the Security Company considers it a vulnerability, MainWP’s documentation presents it as a known and intentional feature, leading to miscommunication.

“It sounds like you think this is merely a bug and if that’s the case, you should have no problem with anyone disclosing this publicly”

17. Replied to Security Company CTO (Tues, Nov 12, 2024, 5:58 PM): I clarified that MainWP’s primary concern isn’t about the disclosure but rather the assignment of a 9.8 CVE rating to a well-documented feature intentionally designed with safeguards like public-private key encryption and dashboard warnings. I invited further understanding by sharing this blog post response to the issue.

18. Received follow-up email from Security Company CTO (Wed, Nov 13, 2024, at 8:44 PM): The CTO stated that the researcher has been banned from their program for six months due to their public disclosure of what they considered an unpatched vulnerability and the tone of their blog post. The CTO emphasized the company’s focus on fostering trust between vendors and researchers and noted that the researcher’s actions were counterproductive to that goal. Additional updates from another team member were mentioned but were never received.

19. Received message in MainWP Managers Community (Wed, Nov 20, 2024, at 2:03 AM): A member reported WP Engine is sending misleading emails about a supposed vulnerability in the MainWP Child plugin, based solely on an unverified blog post and a reserved (not published or validated) CVE. WPScan has also listed the CVE, further spreading misinformation. This premature and irresponsible action creates unnecessary confusion, despite MainWP’s proactive steps to address user feedback and enhance security. (https://managers.mainwp.com/t/wp-engine-2024-nov-18-security-plugin-vulnerability-notices/9643)

20. Sent a reply to Security Company CTO (Wed, Nov 20, 2024, at 10:48 AM): Pointing out that WP Engine is sending emails to their customers, flagging MainWP Child as having an active vulnerability, based solely on their reserved CVE and the security researchers blog post. WPScan has also listed this reserved CVE, which appears to further validate WP Engine’s claims despite the CVE not being published or confirmed. Asked for a response from their side.

21. Released MainWP Child 5.2.1 (Wed, Nov 20, 2024, at 12:03 PM): We’ve released an update to the MainWP Child plugin that 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’s recent disclosure.

22. Requested a review from WPScan of the CVE-2024-10783 listing (Wed, Nov 20, 2024 at 1:10 PM): As it appears to be based on an unverified blog post, without confirmation from MainWP or the Security Company. Given the circumstances, I believe a re-evaluation is warranted, and if removal isn’t possible, note that MainWP Child has been updated in version 5.2.1 to address the concerns raised.

23. Released MainWP 5.3-RC1 (Thur, Nov 21, 2024, at 10:00 AM): We’ve released the MainWP 5.3 release candidate for public testing.

24. Response from Security Company Lead (Thur, Nov 21, 2024, at 1:00 PM): The Security Company confirmed the CVE ID remains valid as a reserved identifier, despite withholding publication of details to allow time for a patch. They suggested reaching out to WPScan to request temporary removal or marking version 5.2.1 as addressing the issue until the full fixes are released and asked for an ETA on the proposed enhancements.

25. Our Response to Security Company (Thur, Nov 21, 2024, at 1:10 PM): Replied to the Security Company Lead for clarification on whether the issue is officially considered a CVE, citing confusion and frustration over inconsistent communication. Explained that version 5.2.1 addresses the core concern by requiring the Unique Security ID by default, aligning with the Security Company’s recommendations. Confirmed that WPScan had been contacted to request updates to their listing. Shared that the full enhancements in version 5.3 are planned for release in the first week of December, with early release testing already in progress.

26. Received Ticket Regarding FlyWheel Notification (Sun, Nov 24, 2024, at 12:36): We received a support ticket from a user who shared a FlyWheel-hosted notification regarding the MainWP Child plugin. The message cited a security issue and advised the user to contact the plugin author for more information. As of this writing:

• WPScan has not responded to our initial request to update their database with the release of MainWP Child version 5.2.1, which addresses the flagged concern by requiring the Unique Security ID by default.
• We have also not received clear confirmation from the Security Company that they are officially classifying this as a security issue or issuing a CVE.

This situation continues to create unnecessary confusion among hosting providers and users due to premature notifications based on incomplete or unverified information.

27. Released MainWP 5.3-RC2 (Mon, Nov 25, 2024, at 11:15 AM): We’ve released the MainWP 5.3-RC2 release candidate for public testing.

28. Reached out a second time to WPScan (Mon, Nov 25, 2024, at 5:43 PM): Reached out a second time to WPScan after receiving no response to the initial contact attempt on Wed, Nov 20, 2024 at 1:10 PM.

29. Additional followup to the Security Company to ensure they had received the previous email and remind them of 3 business day policy for reply (Tue, Nov 26, 2024, at 8:57 AM): Sent a polite reminder to the Security Company regarding the lack of response to our previous email. We noted that this is now the third business day without acknowledgment, as required by CVE Record Dispute Policy, which states:

• “Step 2: The CNA will acknowledge receipt of the dispute, in writing, within three business days.”

We also reminded them of their prior statements supporting our position that this issue should not be classified as a CVE.

To recap those statements:

• Prior Security Company Statements: Internal discussions from the CNA in 2019 aligned with our position, stating: “If it’s documented and the user gets a warning, it’s not a vulnerability.”

• Prior Security Company Statements: As quoted from [Name Redacted] [Security Company Name Redacted] Vulnerability Researcher November 5th, 2024, in email documentation: “Those options are just for your consideration; we understand that if something is documented, it becomes a feature 🙂 Additionally, we might not have a complete picture of how agencies or/and your plugin work.“ [‘emphasis added’]

• Prior Security Company Statements: As quoted from [Name Redacted] [Security Company Name Redacted] Vulnerability Researcher November 7, 2024, in email documentation: “Regarding [Security Researcher Name Redacted] message to you. I’ve just shared with him the same information we discussed here – related to the fact that it’s not a vulnerability when something is documented. We’ve reserved the CVE number when we’ve got an incoming vulnerability report, but it’s not published and doesn’t contain any data – https://www.cve.org/CVERecord?id=CVE-2024-10783 And we are going to dismiss it.” [‘emphasis added’]

• Prior Security Company Statements on leaving it open just to reward the researcher: During correspondence with [Name Redacted] [Security Company Name Redacted] Vulnerability Researcher, it was stated: “If you are okay with us leaving the CVE open, [Security Researcher Name Redacted] will be happy to have it (probably for you, it would be an argument for reasoning those changes, too). This wouldn’t have happened without his involvement, so it would have been fair to reward him somehow.” [‘emphasis added’].

  This quote suggests that factors beyond technical merit may have influenced the decision to leave the CVE open. We believe this underscores the need for a reassessment based solely on technical criteria.

30. Release of Updated Features – MainWP 5.3 (Tue, Nov 26, 2024, at 11:20 AM): The updated initial connection features are set to be available in version MainWP 5.3.

• MainWP Dashboard 5.3 Changelog
• MainWP Child 5.3 Changelog

31. Received Response from Security Company Lead (Tue, Nov 26, 2024, at 3:50 PM): This email provided much-needed clarification and addressed some of the concerns we’ve been raising for nearly a month.

Key Points from the Security Company Lead:

• CVE Classification and Confirmation:
  “On November 12th, 2024, [CTO Name Redacted] stated:
  ‘This has now been escalated to the executive team at [security company name redacted], and we’ve made a final determination that we do think this is a vulnerability. The application design leads to an exploitable race condition. There are safe ways to design a system like this, given that you have the option of public/private keypairs on both sides that can provide authentication and authorization from the first install. It also represents a real risk if anyone is able to obtain a list of fresh installs; they can script an exploit that will move faster than a user can and will succeed in compromising a site.’
  ‘We’re keeping the CVE assigned, adding it to our vulnerability database, and notifying users to update to your new version that contains a fix.’”

The Security Company Lead noted that their position on retaining the CVE ID was firm and cited previous communications as evidence that this stance had been clear.

• Responses to Our Questions:
  • Admin Username Dependency:
    They asserted that the need for an admin username does not reduce the classification or severity, citing the ease of username enumeration in WordPress (e.g., default usernames like “admin”).
  • Criteria for CVE Qualification:
    The CVE was assigned due to risks posed by insecure default configurations and the importance of notifying users of updated, non-vulnerable plugin versions.
  • Safeguards Consideration:
    Optional safeguards like public-private key encryption and the Unique Security ID were not factored into the classification since they were not enabled by default. They highlighted CNA Rule 4.1.4, which states, “Insecure default configuration settings SHOULD be determined to be Vulnerabilities.”
  • Authentication Bypass Classification:
    They maintained the issue qualifies as an authentication bypass, stating that knowledge of an admin username does not negate the vulnerability classification.

• CVSS Score Adjustment:
  The lead acknowledged the increased attack complexity and offered to adjust the CVSS score to 8.1 (High). They noted that this adjustment reflects the need for the plugin to remain in a default state and for the attacker to have access to an admin username. They also committed to clarifying in the vulnerability description that the issue only affects unconfigured installations of the MainWP Child plugin.

Reflection on Communication Challenges:

This response provided clarity but also highlighted the miscommunication and delays that compounded this issue:

• November 13, 2024 (Timeline #18): The CTO announced the suspension of the security researcher and mentioned that additional updates would follow from the Security Company Lead. However, no further communication came until we reached out again on November 20, 2024 (#20).
• November 21, 2024 (Timeline #24): The Security Company Lead’s response confirmed the CVE would remain reserved but lacked explicit clarification on its status, leaving room for further confusion.

While we take responsibility for any assumptions made during this process, the lack of consistent updates and clarity from the security company added unnecessary complexity to resolving this issue.

32. Sent Response to Security Company Lead (Tue, Nov 27, 2024, at 8:48 AM): After careful consideration, we decided to acknowledge the updated CVSS score while reiterating our disagreement with the CVE classification. Our response emphasized the following:

• The proactive measures implemented in MainWP Child versions 5.2.1 and 5.3 to address concerns, including enabling the Unique Security ID by default and adding additional safeguards like one-time passwords and automatic deactivation.
• Appreciation for the CVSS score adjustment and clear vulnerability description to help minimize unnecessary user concern.
• A request for notification when the CVSS score adjustment and updated CVE description were finalized to align messaging across platforms.

Excerpt from Our Response:

“Thank you for your detailed response and for addressing the points we raised. While we still respectfully disagree with the classification of this issue as a CVE, we appreciate the clarification on [security company name redacted] position and your willingness to adjust the CVSS score.”

33. Received Response from Security Company Lead (Thur, Dec 12, 2024, at 3:52 PM): The security lead confirmed that the Security Company reviewed MainWP 5.3, found it satisfactory, and has now published the vulnerability record, which marks the issue as patched. The CVE details will be updated within 12–24 hours to align with the published record. They expressed hope for smoother collaboration in the future and thanked us for the updates to ensure user security.

Epilogue: Reflections on CVE-2024-10783 and Lessons Learned

For anyone unfamiliar with how security companies and CVEs typically operate, let us start by saying this: this is not the norm. CVEs are generally handled with professionalism, clarity, and minimal back-and-forth. Miscommunication and ambiguity, like what we experienced here, are rare and shouldn’t happen. This case has been an outlier, and we sincerely hope it remains that way.

A statement from the Security Company’s Lead during this process stands out:

“I’d like to kindly request that you please refrain from calling internal communication between you and our analysts our “statements” as the lines you are pulling are merely miscommunicated responses from one member of our team, not ‘statements’ from our company.”

This raises an important question: If we can’t trust the responses of the individuals security companies designate to communicate with plugin and theme developers, what do we do? Do we need to escalate every issue to the CTO of the company to ensure the communication is trustworthy? This level of inconsistency undermines the collaborative spirit needed for a secure WordPress ecosystem.

Addressing Common Questions

Why did you fight this so hard if you agreed to make the changes anyway?

We believe in standing up for what we think is right. In this case, we didn’t believe the issue warranted classification as a security vulnerability or CVE. That said, when we polled our users, we found there was concern about the pre-connection process, even though it had worked this way for over a decade. Based on that feedback, we decided to enhance the process, not because we believed it was a vulnerability, but because we recognized an opportunity to better serve our users.

However, we pushed back on the CVE classification because we felt the process lacked clarity, and even the Security Company seemed uncertain at times. It’s important to have honest discussions about what truly constitutes a security vulnerability.

Why didn’t you take this to a dispute with MITRE?

Disputing a CVE with MITRE is no small feat, and there’s no guarantee of success. Since we were already making the changes and wanted to focus on supporting our users, a formal dispute felt like a moot point at this stage. For anyone interested in what a dispute process looks like, we recommend reading the curl project developers’ post: CVE-2020-19909 is everything that is wrong with CVEs. It highlights many of the same frustrations we experienced.

Moving Forward

As the Security Company involved in this case is a CNA in the WordPress space, we’ll inevitably work with them again. Our hope is that future interactions will be more professional, consistent, and collaborative. Everyone involved, ourselves included, dropped the ball at various points in this process, and we believe this case should serve as a lesson for all parties.

For now, our focus remains on serving our users. The updates in MainWP 5.2.1 and 5.3 add additional safeguards, and we will continue working to ensure the MainWP ecosystem remains secure, transparent, and trusted.