A post-mortem on the Modular Connector security incident (Jan 2026)

Following the security incident affecting the Modular Connector plugin a few weeks ago, and now that the situation is under control and we have more information, we want to share more details about what happened, how we handled it, and what we’re doing to prevent similar issues in the future.

On January 14, 2026, we received a report from Patchstack, thanks to security researcher Teemu Saarentaus, about a critical security vulnerability in the Modular DS plugin (Modular Connector).

This vulnerability could allow unauthorized users to gain administrator access to WordPress sites. We released a fix within 82 minutes and immediately began pushing an update to all sites connected to Modular DS.

On January 16, as part of the investigation after the first incident, we detected a related bypass stemming from the same routing logic flaw. Given the context, the issue was treated as a high priority and addressed even faster. We identified the root cause, implemented a more robust fix, and released version 2.6.0, with 97% of connected sites updated before the CVE was published.

We take this issue very seriously and are fully committed to protecting our users. The vulnerability was caused by a flaw in the plugin’s routing logic that, when combined with other factors, created a way for attackers to bypass authentication.

The good news is that our investigation confirmed that no Modular DS platform data was compromised, and the vast majority of sites were protected within hours of each fix being released.

Technical summary

The Modular Connector plugin implements a custom routing system based on Laravel. This was necessary because many WordPress installations block the default JSON API (typically through security plugins like Wordfence or iThemes Security), and we needed a reliable way for our platform to communicate with the plugin.

For executing actions on connected sites, the plugin uses a secure system: Modular DS generates a unique request ID—valid only for a few minutes—that the plugin exchanges for instructions only after validating its OAuth2 access token. This system remains secure and was not compromised.

The vulnerability existed in our routing layer, which had a dual routing architecture:

• Dual routing with unsafe fallback: Our custom router was layered on top of Laravel’s default router. When our custom router couldn’t match a request, it fell back to returning Laravel’s original matched route, including sensitive endpoints like /login/ that should have been protected.
• Exposed routing flow: The isDirectRequest() method identifies when to use the custom routing system, based on URL parameters (origin=mo and type=…). Attackers could use these parameters to enter the custom routing flow and trigger the unsafe fallback.
• Auto-login behavior: The login endpoint, when accessed without specifying a user, would automatically authenticate as the first available administrator account.

When these factors were combined, an attacker could craft a URL that triggered our custom routing, failed to match, fell back to Laravel’s /login/ route, and gained administrator access.

The fix in version 2.5.2 removed the dual routing architecture, implemented strict route matching with a default 404 response, and added verification to request identification.

On January 16, during the subsequent investigation and monitoring, we identified a related bypass (CVE-2026-23800) stemming from the same routing logic flaw. Rather than a separate or different vulnerability, this was a continuation of the original issue: a separate code path within the same routing system that could grant administrator-level access to WordPress REST API routes.

Given that we detected this bypass early and assessed that it was not being widely exploited at the time, we decided to implement a deeper, more definitive fix rather than a quick interim patch.

Version 2.6.0 introduces JWT (JSON Web Token) authentication, a secure industry-standard method where every request between our platform and the plugin is signed with a cryptographic token that is extremely difficult to forge.

Think of it as a digital signature that only Modular DS and your site can verify, making it significantly harder for anyone to impersonate our platform. Additionally, we redesigned the routing system to eliminate the root cause that made both bypasses possible.

For a more detailed technical analysis, see Patchstack’s security article.

The impact

What you need to know

*Note that CVE-2026-23800 was not a new, separate vulnerability. It was a continuation of the same routing logic flaw that caused CVE-2026-23550, exploiting a different code path within the same system.

Were your sites affected?

If your site was running any version of Modular Connector prior to 2.6.0, it was potentially vulnerable to one or both issues.

During the investigation into the first incident, we identified 1,384 sites that showed indicators of potential exposure. The second bypass was detected early and was observed on 154 sites before the fix was deployed.

In addition to urging all users to update to the patched version as quickly as possible, we reached out to the owners of those sites, providing site-specific information and guidance.

What went right

Despite the severity of the vulnerability, several things worked well:

• Rapid remediation. We released the first patch (version 2.5.2 of the plugin) within 82 minutes of being notified.
• Quick update rollout. After version 2.5.2 was released, our system triggered plugin update requests across all connected sites to Modular DS, protecting 97.64% within 35 hours.
• Proactive communication. We worked on a security advisory and notified users as quickly as possible through an in-app alert, email, and direct follow-ups to accounts with potentially affected sites.
• Thorough investigation. We spent 14 hours reviewing all platform data to ensure no data breach occurred.
• Immediate improvements. Within 36 hours, we released a new feature to help users identify common attack patterns: unauthorized admin users being added or legitimate users being removed in an attempt to hijack a site.
• Responsible disclosure. Group.one’s team discovered and quickly reported the issue, and Patchstack coordinated the CVE publication and verified our fix.
• Improved response to the related bypass. When it was detected on Jan 16, the monitoring processes established after the first incident allowed us to catch the issue early and identify the root cause within 30 minutes. Rather than rushing a quick patch, we invested the time to deliver a stronger fix with JWT authentication. Following the release of version 2.6.0, nearly all connected sites were updated within approximately one hour, a significant improvement over the time it took after the first fix.

What we learned

While our team responded quickly and effectively to fix the vulnerability, the first hours also gave us valuable insight into how we can improve our incident response, especially around coordination, communication, and large-scale system operations.

We’re working on formalizing a structured incident framework so it’s always clearer who leads and approves key decisions, and in what order actions and updates should happen. This includes communication playbooks, as well as clearer guidance on mitigation recommendations under urgency to avoid unnecessary disruption for users.

This was also the first time our system faced updating and re-analyzing all connected sites simultaneously. Although our architecture is resilient, this generated an abnormal traffic spike that revealed some API processes with heavy database queries consuming excessive memory. As a result, the platform was temporarily slow or unresponsive.

During the incident, our technical team decided to prioritize processing plugin updates over platform availability, which was the right call to protect sites given the circumstances. However, this also showed that we need stronger performance strategies to handle urgent security actions without affecting the overall experience.

The technical fix was fast. Now we’re making sure our processes and infrastructure are just as fast and even more reliable.

We’ve outlined the specific improvements we’re already implementing in this section below.

Our response

The first hours

As soon as we received the report (Jan 14 at 08:04 UTC), we immediately began investigating. The following is a broad timeline of how the first and subsequent days unfolded.

January 14, 2026

• 08:30 UTC: Vulnerability confirmed; CVE-2026-23550 assigned. First security advisory published to notify users.
• 09:26 UTC: Version 2.5.2 is released to WordPress.org (82 minutes after notification).
• 10:28 UTC: Patchstack confirms our fix works. We begin pushing updates to all sites connected to Modular DS.
• 10:28 UTC: Our team starts a comprehensive review of all platform data to check for any breach.
• 12:30 UTC: We publish an in-app notification with mitigation steps and guidance for users.
• 14:30 UTC: We send a wider email to all users explaining what happened and what to do.

January 15, 2026

• 00:13 UTC: After nearly 14 hours of analysis, we found no evidence of any platform data breach.
• 06:38 UTC: 95% of all sites on Modular DS are running the patched version.
• 06:38 – 10:13 UTC: Our team conducts a full retrospective to understand what happened.
• 10:13 – 20:11 UTC: The team audits platform security across all integration points and works to identify potentially affected sites. We also continue to support our users and answer their questions.
• 20:11 UTC: We send personalized emails to users with potentially affected sites (1,384 sites showed signs of exposure, 97.64% already patched at this point).
• 20:21 UTC: We release a new security feature to receive alerts when administrator users are added or removed.

January 16, 2026 – Second bypass detected and resolved

• 07:00 – 13:00 UTC: The team continues reviewing plugin code for potential edge cases, refining monitoring rules, and begins discussing the feasibility of implementing JWT authentication for platform-plugin communication.
• 13:00 – 14:05 UTC: As part of the heightened monitoring put in place, we detect unusual behavior on a small number of sites and share our findings with Patchstack. We identify a related bypass (CVE-2026-23800) stemming from the same routing logic flaw.
• 14:05 UTC: Root cause identified. Rather than releasing an interim patch, we decided to implement JWT authentication and redesign the routing system to cut off any further bypasses at the root.
• 18:50 UTC: Version 2.6.0 deployed to our staging environment. Patchstack validates that the bypass is resolved.
• 19:22 UTC: Version 2.6.0 released. Update requests are triggered across all connected sites.
• 20:14 UTC: CVE-2026-23800 is officially disclosed. At this point, 97% of connected sites were already running version 2.6.0.
• 20:25 UTC: We send an email to all our users with more information and ask them to verify that they are running the latest version.
• 23:34 UTC: After verifying update adoption rates, reviewing monitoring dashboards for any remaining anomalies, and confirming no new suspicious activity across connected sites, the team closes the day.

January 17-19, 2026

• The entire team remained on call throughout the weekend, continuously monitoring all connected sites and platform activity to ensure no further issues arose.

In two days, we significantly improved our response across the board. The work we had done in the previous days, reviewing infrastructure weak points, planning the JWT implementation, and strengthening our monitoring, allowed us to detect the issue early, make better decisions under pressure, and deploy a more robust fix faster.

Our investigation

As soon as we were informed about the issue, our technical team started a thorough analysis of platform logs. One of our primary concerns was the possibility of a data breach or a site enumeration vulnerability, as the attack had begun simultaneously across multiple sites, and we had received no similar reports in the days leading up to it.

Our team suspected the attacker had been quietly identifying vulnerable sites over time and waited for the right moment to strike.

We analyzed platform logs looking for suspicious patterns and examined our database for anomalous data. After nearly 14 hours of analysis (completed at 00:13 UTC on January 15), we found no evidence of a data breach or any compromise of our platform’s internal systems.

How did the attacker find the sites?

We currently believe the attacker used internet scanning platforms like Shodan or Censys to identify WordPress sites running our plugin. These platforms continuously scan the internet and index information about web servers, open ports, and the technologies they run, making it possible to search for specific software signatures at scale.

WordPress sites are particularly easy to identify because of recognizable patterns in their HTML structure, default paths, and metadata. Additionally, many plugin developers embed identifiable signatures in their code that make detection even easier. This means an attacker with knowledge of a vulnerability can quickly compile a list of potential targets without ever interacting directly with our platform.

And just to clarify, this doesn’t make WordPress insecure. WordPress is a robust, mature CMS that powers over 40% of the web for good reason. The core software is well-maintained and regularly audited. However, like any platform with a rich ecosystem of plugins and themes, vulnerabilities can appear in third-party code, including ours.

The key takeaway? Keep everything updated. When a plugin has a vulnerability, as happened here, attackers can exploit it at scale using automated scripts. But if updates are applied quickly, the window of exposure is minimal.

This is exactly why tools like Modular DS exist: to help you keep all your sites updated and protected without having to check each one manually.

Security is an industry-wide challenge, not unique to Modular DS, but it reinforces why rapid response and fast updates are critical when vulnerabilities are discovered.

What you should do

If you haven’t yet, please ensure your WordPress sites are running Modular Connector version 2.6.0 or later and review these potential indicators of compromise.

If you detect anything unusual, such as suspicious requests, unexpected admin accounts, or unknown changes, complete the additional steps we outline in our support article.

New security feature: Administrator change alerts

As a result of this incident, we’ve worked on a new Modular DS feature that notifies you whenever an administrator user is added to or removed from your connected sites.

This is exactly the type of change attackers made when exploiting this vulnerability. Now, with these alerts enabled, you’ll be notified immediately if any administrator changes are detected.

Good news: If you already had notifications configured with the “New vulnerability discovered” option enabled, this feature is already active by default.

To enable this feature manually:

1. Log in to your Modular DS dashboard
2. Go to Notification settings
3. Create a new notification configuration and/or enable it in the “Security” section:
   • “New administrator user added”
   • “Administrator user removed”

What we’re doing to prevent this in the future

Already completed:

• Released patched versions 2.5.2 and 2.6.0.
• Removed the vulnerable routing logic and redesigned the routing system.
• Implemented JWT authentication for all communication between the Modular DS platform and the plugin.
• Released administrator user change detection notifications.
• Completed platform security audit with no evidence of a data breach.
• Audited all communication processes with external platforms (Stripe, Vonage, and others), improving security across integrations.
• Enabled new security monitoring modules in Datadog to detect unusual behavior and allow immediate response actions.
• Implemented additional API-level security improvements.

Technical improvements (in progress):

• Completing security audit of plugin and platform features to identify and address potential security concerns.
• Improving our static code analysis tools to better detect vulnerability patterns before they reach production.
• Redesigning how we detect premium WordPress plugin updates, which was the origin of the logic flaw in the routing system that allowed both bypasses. We’re building a new approach from the ground up.
• Optimizing internal processes for high-traffic scenarios: Reworking functions like the webhook system to improve database performance during traffic spikes.
• Deploying additional detection systems to identify unusual or suspicious behavior and activity patterns across connected sites.

Process improvements (in progress):

• Improving our security incident response plan with better documented processes, roles, and communication frameworks for notifying users at different stages of an incident.
• Launching a public status page to provide better, real-time visibility into our platform’s health and any ongoing incidents.
• Practicing our response processes so that all our team knows exactly what to do when an issue arises.
• Preparing post-mortem templates so future incidents can be documented more efficiently.

Wall of love

These past few days have been pretty intense for our team.

When we sent out the security notifications, we braced ourselves for frustration and criticism. What we received instead was an overwhelming wave of support and understanding that honestly moved us.

Many of you logged into your dashboards, worried, only to find that the plugin had already been updated. Some of you reached out to ask if there was anything you could do to help. Others wrote to say “thank you for the quick response and transparency” or “we trust you.”

These messages reminded us why we do what we do. Managing WordPress sites is stressful enough without having to worry about security incidents, and knowing that you trust us to handle these situations makes us even more committed to earning that trust every day.

To our users: Thank you for your patience, your understanding, and your support. You are the reason Modular DS exists, and we don’t take that responsibility lightly. We know we didn’t get everything perfect in the first few hours. But we’re here, we’re listening, and we’ll keep supporting you in any way we can.

To Teemu Saarentaus from group.one: Thank you for discovering and responsibly reporting this vulnerability.

To Patchstack: Thank you for coordinating the CVE publication and verifying our fix.

To Carles Javierre: Thank you for your support throughout the incident and for the security improvements applied at the infrastructure level.

And thank you, sincerely, to our entire team for the effort, dedication, and commitment shown during these challenging days.

We’re a small team, but moments like these make us feel like we’re part of something much bigger.

Thank you for being part of this community.

Related resources

• Modular DS security advisory
• Patchstack’s security article
• CVE-2026-23550 details
• CVE-2026-23800 details

We are committed to transparency and continuous improvement. We’ll keep sharing updates as we complete our security improvements.