If you're running the Passster plugin on WordPress with Gutenberg blocks enabled, check whether your version includes a server-side password check before content renders. The vulnerability allows unauthenticated users to bypass the password protection entirely by viewing page source or disabling JavaScript—no network interception required, no special tools, just the browser's developer tools.
The root cause is straightforward: when Passster added Gutenberg block support, the block rendering code renders content into the DOM for client-side decryption, but it skipped WordPress's built-in post_password_required() check that runs in the traditional the_content filter chain. The block rendering hook fires at a different point in the request lifecycle, and the developer likely didn't realize they were bypassing the access control that WordPress provides natively. This wasn't an architectural trade-off—it was a missing reference to an existing function that existed years before this code path was written.
The severity deserves clarification. The CVE describes intercepting the response before password check, which implies sophisticated network-level attacks. The actual exploitation is far simpler: any visitor can right-click, view source, and read the content. The gap between 'sophisticated attacker' and 'anyone with curiosity' is significant, and you should treat this as more severe than the CVSS 7.5 suggests.
WordPress core faced the exact same vulnerability class in version 5.7.x—block editor previews firing before password verification. The fix was documented in core's security advisory three years ago. This suggests the real problem isn't one plugin's mistake; it's a knowledge transfer failure between WordPress's security team and the plugin ecosystem. When you patch this instance, treat it as a signal to audit any custom Gutenberg blocks or rendering-layer code for the same pattern: if you're outputting protected content in a block or AJAX handler, verify server-side password status first.