Two independent security researchers have found bugs in Royal MCP, filed responsible disclosure reports, and worked with us to verify the fixes before the details went public. Both cases are on the public record. Both researchers are credited by name. Both are the reason Royal MCP is safer today than it was six months ago.
The first disclosure came in through Patchstack a few months after Royal MCP shipped. Subject line: “Security disclosure: Royal MCP plugin.” A researcher I had never met had found something.
For a lot of plugin authors, that email is a bad day. For me it was a good one.
Since Royal MCP shipped to the WordPress.org plugin directory in January 2026, two independent security researchers have found vulnerabilities in the plugin, filed responsible disclosure reports, and worked with us to verify the fixes before the details went public. This post is about what actually happens when a security researcher emails a WordPress plugin author, why the “not so scary” reframe is the right one, and why those closed disclosure tickets are the strongest marketing asset a small plugin shop can build.
The Two Disclosures, on the Record
v1.4.3: reported by Alexis Lafontaine via Patchstack
The first disclosure landed early in Royal MCP’s life. Alexis identified a broken access control condition on the MCP REST API endpoints. Under a specific request path, tool calls could be reached without going through the plugin’s authentication check. The fix landed in v1.4.3. All tool calls now require authenticated credentials (API key or OAuth Bearer), and the Origin header was dropped as a security control.
Origin was never intended to be one. The original code had used it defensively, but it does not carry the guarantees that a proper authentication check does. Alexis was correct to flag it, and the fix was tightened accordingly.
v1.4.26: reported by Alessandro Greco (Aleff)
The second disclosure came from Alessandro, also known as Aleff, an independent security researcher who audits WordPress plugins as part of his ongoing work. Alessandro identified a per-tool WordPress capability enforcement gap. Prior to v1.4.26, an OAuth Bearer token issued to a low-privileged WordPress role (Subscriber or Contributor) could invoke administrator-only operations through certain tool paths. The API-key path was unaffected because API keys always resolve to the site administrator, but the OAuth path, which resolves to whatever WordPress user completed the consent flow, had gaps.
The fix inserted a per-tool capability assertion that runs against the authenticated user’s actual role, using the WordPress-native current_user_can() check with map_meta_cap resolution. Status filters on read tools were also converted from a denylist to a positive allowlist so unknown values fail closed. Alessandro’s report is what pushed us to audit every tool path against its correct capability, not just the umbrella capability.
Then we went further. Alessandro’s report surfaced a class of bug, not just a specific bug. “Authenticated but under-privileged callers can invoke operations they should not be able to” is the kind of gap that a code review pass focused on happy-path functionality routinely misses. We used the disclosure as the trigger to build a role-based capability scanner and bake it into Royal MCP’s pre-ship process. Before any Royal MCP release ships to WordPress.org today, the scanner spins up test accounts at every WordPress role tier (Administrator, Editor, Contributor, Subscriber), enumerates every tool endpoint the plugin exposes, and asserts that low-privileged roles receive permission errors on operations they should not be able to invoke. What started as one researcher’s report became a permanent defense against the same class of issue for Royal MCP — and the pattern is now available to any future Royal Plugins product that exposes an authenticated tool surface with per-user role scoping.
That is the compounding return on taking a single disclosure seriously.
Both disclosures are on the public record via the WordPress vulnerability databases maintained by Wordfence, Patchstack, and WPScan. The Wordfence Threat Intel index for Royal MCP is at wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/royal-mcp — individual records may live on Patchstack or WPScan depending on the disclosure channel, and cross-syndication between the three databases is standard practice.
The Infrastructure That Makes This Work
WordPress has a mature responsible disclosure ecosystem that most plugin authors never think about until it’s their turn to be on the receiving end of it. Three organizations do most of the coordination work.
Patchstack operates a bug bounty and disclosure platform where security researchers file reports against WordPress plugins and themes. Patchstack triages the report, contacts the plugin author, and coordinates the fix and public disclosure timeline. Researchers get paid; plugin authors get a professional intermediary; users get patched software before the details go public.
Wordfence runs its own vulnerability disclosure program and a public Threat Intel database. Their team reproduces reports, works with plugin authors on fixes, and publishes CVE-tagged records once patches ship. The database is one of the reference sources site owners use to check whether the plugins they run have known unpatched vulnerabilities.
WPScan, owned by Automattic, runs the community’s oldest WordPress-specific vulnerability database. Researchers file disclosures, WPScan verifies them, and the records get published in a standardized format that many WordPress security plugins consume for their scanning tools.
All three cross-syndicate. A vulnerability disclosed via Patchstack usually shows up in the Wordfence and WPScan databases within days of the fix shipping. That’s a feature, not a duplication problem. Users of any of the three services get the same coverage.
What Plugin Authors Get Wrong
A lot of plugin authors treat their first vulnerability disclosure as a crisis. It isn’t. What happens if you handle it badly, though, can be.
The bad response is well documented. Some authors deny the report. Some ship a silent fix without acknowledging it. Some go quiet for weeks, hoping the researcher will lose interest. Some argue with the researcher about severity. Some threaten legal action if the disclosure goes public.
The end state of the bad response is usually the same: the vulnerability gets disclosed anyway (because the researcher owns the report, not the vendor), the plugin’s reputation takes a hit, the researcher publicly documents the poor response, and users lose trust. The vulnerability was going to be fixed either way. The only variable was whether the author looked professional or defensive.
The good response is boring. Acknowledge the report within a business day. Ask clarifying questions if the reproduction steps are unclear. Fix it fast. Ship the patched version to WordPress.org. Confirm the fix with the researcher. Publish the changelog entry crediting the researcher by name. Move on.
The good response takes less energy than the bad one. It also builds trust with the entire security research community, which increases the odds that the next researcher who finds a bug in your plugin will contact you privately instead of publishing directly.
The Royal MCP Security Response Process
For anyone considering reporting a vulnerability in a Royal Plugins product, here is what the internal process looks like on our end.
Triage. Every disclosure email is read within one business day. We reproduce the reported condition against the latest shipping build. If it reproduces, it’s a disclosure. If it doesn’t, we ask the researcher for a repro that works and treat it as a research question, not a report to close.
Fix. The fix goes into the next patch release. Emergency fixes ship out of band if the severity warrants it. We write the fix to close the reported vector plus any adjacent vectors we can see from the same class of issue. In the case of Alessandro’s report, that meant not just adding capability checks to the specific tool path he identified but auditing every OAuth-callable tool against its correct capability, which turned up additional gaps that shipped in later releases.
Verify. We ask the researcher to verify the fix against a build we send them. Both v1.4.3 and v1.4.26 shipped only after the reporting researcher confirmed the vector was closed.
Credit. Every changelog entry names the researcher (or their handle if they prefer) and includes a description of the class of issue that was fixed. No coy language. No downplaying.
Publish. The public vulnerability databases pick up the disclosure automatically once the fix is on wp.org. We do not fight this. We amplify it, because a public record of “found, fixed, verified, credited” is how the security research community measures whether a vendor is worth their time.
Why We Treat This as a Feature
External security review is the closest thing a small plugin shop has to a peer review process. Two independent researchers looking at the same code from different angles will find things the original authors missed. Both disclosures we have received made the plugin measurably safer. The v1.4.3 fix closed an authentication bypass that we would have shipped indefinitely otherwise. The v1.4.26 fix turned into a full audit that surfaced additional capability-ordering issues in six integration tool wrappers that we then fixed in v1.4.30 and v1.4.31, and it produced the role-based pre-ship scanner that now runs against every Royal MCP release before any WordPress.org update.
We would not have found any of those without Alexis and Alessandro and we would not have built the scanner without Alessandro’s report as the catalyst.
Closed Tickets Are Marketing, Not Damage
Here is what most plugin authors miss about public vulnerability records. They are not damage to a plugin’s reputation. They are the opposite.
A record that reads “found, fixed, verified, credited” is one of the strongest possible signals to a prospective user that a plugin is being actively maintained and taken seriously. It says the author has an intake process for disclosure, ships fixes fast, coordinates with the researcher through to verification, and is willing to put the entire chain of custody on the public record.
A plugin with no public vulnerability records could mean it has never had one. In practice, on a plugin of any real complexity, it usually means either the author has been hiding them or no researcher has bothered to look. Neither is a virtue.
When a prospective user checks Wordfence’s Threat Intel database or WPScan and sees a clean patch record on Royal MCP, that is not a warning label. That is credibility. Every entry represents a class of issue that was found, closed, and documented instead of shipped indefinitely into thousands of production sites. The two open records on Royal MCP say more about the plugin’s engineering process than any marketing page ever could.
Which is why we treat those closed tickets like bragging rights, not scars.
If you find a security issue in Royal MCP or any Royal Plugins product, contact us at security@royalplugins.com. If you would rather go through a coordinated disclosure program, Patchstack and Wordfence both know how to reach us. We respond fast. We credit fairly. We do not fight your report.
The email is not a bad day. It is a good one.