permission_callback Returns True
WordPress's REST API includes a security mechanism: every endpoint must define a permission_callback that determines who can access it. Gravity SMTP — an email integration plugin installed on over 100,000 WordPress sites — defined its /wp-json/gravitysmtp/v1/tests/mock-data endpoint with a permission_callback that unconditionally returns true. No authentication check. No role verification. No nonce validation. Anyone on the internet can call it.
Appending ?page=gravitysmtp-settings triggers the register_connector_data() function, which returns approximately 365KB of JSON containing live API keys and OAuth tokens for every email service connected to the site — Amazon SES, Google Workspace, Mailjet, Resend, and Zoho. The vulnerability was patched on March 17, 2026. Mass exploitation began three months later. Wordfence has blocked over 17 million exploit attempts, peaking at 4 million per day on June 7.
The Three-Month Patch Gap
The patch was available on March 17. Mass exploitation peaked on June 7. That is an 82-day gap where every unpatched Gravity SMTP installation was leaking live credentials to anyone who asked. This pattern is not unique to Gravity SMTP. It is the WordPress ecosystem's defining security characteristic: patches exist but are not applied. WordPress's auto-update mechanism covers core but not all plugins. Site owners who disable auto-updates, who run managed hosting that delays updates, or who simply do not log into their admin panel for three months remain vulnerable.
WebPulse tracks 18,335 CVEs across the WordPress ecosystem. The Gravity SMTP case demonstrates that the CVE count is only half the story. The other half is patch velocity — how quickly the ecosystem actually applies fixes. A vulnerability that is patched but not deployed is functionally equivalent to a vulnerability that is unpatched.
One Plugin, Every Credential
The architectural lesson is specific to WordPress's extensibility model. Gravity SMTP is an email plugin. It has no business exposing Amazon SES API keys, Google OAuth tokens, or Zoho credentials to unauthenticated users. But WordPress's plugin architecture gives every plugin access to the site's full configuration surface. A single permission_callback returning true does not just expose the plugin's own data. It exposes every service credential the plugin integrates with.
For CISOs managing WordPress infrastructure: the security perimeter is not WordPress core. It is not even your theme or your custom code. It is the worst permission_callback in any plugin in your stack. With 17 million exploit attempts targeting a single endpoint, attackers are systematically scanning for exactly these implementation errors. The WordPress ecosystem has 60,000+ plugins. How many of them have a permission_callback that returns true?
