This vulnerability isn't an obvious coding mistake — it's the visible symptom of a structural failure where the WordPress AJAX architecture trains developers to think of authentication as something you add (nopriv vs priv hooks), not something you build around. The plugin registers AJAX handlers as nopriv by default in frame.php:282, which makes external API calls work without friction. The getPermissions() method returns an empty array, which means every endpoint inherits unauthenticated access unless a developer explicitly overrides it — but empty arrays look intentional during testing because the handlers still function. The frontend receives full task results including plaintext API keys because that satisfied debugging requirements. Sequential task IDs avoid UUID overhead. None of these decisions break a test, and individually each one makes a developer's life easier.
The compounding exposure is straightforward: an unauthenticated attacker can enumerate sequential task IDs and retrieve task results that include live API credentials. The API key alone creates second-order risk — billing abuse, prompt injection if used with LLMs, potential credential reuse across infrastructure.
What makes this worth your attention isn't just this one plugin — it's that the same scaffold appears across the WordPress ecosystem. Base controllers that define getPermissions() returning [], with child methods inheriting that empty array, create a silent failure mode indistinguishable from intentional design. The WordPress plugin review process doesn't catch this pattern because functional testing never reveals information exposure when the returned data is valid-but-sensitive. Static analysis that flags any AJAX handler without a corresponding getPermissions() entry would catch this class of vulnerability, but no such tool runs in the standard review workflow.
Your immediate actions: audit any WordPress plugins you maintain that use similar base controller patterns — check whether getPermissions() returns populated arrays or whether every endpoint relies on the nopriv hook registration alone. If you use this specific plugin, treat any exposed API key as compromised and rotate it immediately. The vulnerability exists in the gap between what the WordPress framework makes easy (nopriv-by-default) and what security requires (authenticated-by-default), and that gap won't close without tooling that makes secure-by-default the path of least resistance.