A WordPress Site Leaked 919 Paid Videos Until a Developer Checked the Inverse

A routine support ticket about paying members being blocked revealed a catastrophic paywall failure. The diagnostic principle used to find it is a playbook for any membership site.

A three-sentence support ticket about paying members being blocked from on-demand video led one developer to discover all 919 videos on a WordPress membership site were publicly accessible. The bug users reported was a minor inconvenience. The bug they did not report was a catastrophic failure of the site's paywall.

This case study, detailed in a post by a developer under the handle "highcenburg," is a playbook for debugging access control. It demonstrates how a simple diagnostic counter-move revealed a business-critical vulnerability that had gone completely unnoticed.

The reported bug and a false start

The initial user complaint was reproducible: paying members would log in, navigate to a video, and see a notice demanding they purchase a membership. The developer’s first hypothesis pointed to a common WordPress membership issue. The site had recently renamed a membership tier, and plugins like WishList Member often use level names in their logic, which break upon renaming.

This theory was reasonable. It explained why legitimate members were suddenly failing an access check. The developer assumed the video gate was checking for an old membership level name. This turned out to be incorrect, but it was a logical first step based on the reported symptoms.

Check the inverse

Before attempting a fix, the developer tested the counterfactual: what does a non-member see? They opened the same video URL in an incognito window. The "you must have a membership" notice appeared, but then the Vimeo player loaded and played the video.

This single test reframed the entire problem. The paywall was not malfunctioning; it was non-existent. The notice was merely a block of text displayed above a video that rendered for every visitor, regardless of their login or payment status. The site's entire library of 919 paid videos was open to the public. The only reason the flaw was discovered was because a separate, minor bug incorrectly showed the warning text to paying members.

The root cause: protecting the wrong asset

The technical failure stemmed from a misconfiguration between plugins. The site used a dedicated plugin, All-in-One Video Gallery, which created a custom post type (aiovg_videos) for the video library. The membership plugin, WishList Member, was configured to protect the main parent page where the video gallery was displayed.

It did not, however, protect the individual video posts themselves. Anyone with a direct link to a video post could bypass the parent page's protection entirely. The "paywall" was a sign on a door, but every window in the building was wide open. The fix required rebuilding the access layer to apply protection rules directly to the aiovg_videos post type.

What we'd change

The core diagnostic principle is to always check the inverse of the reported symptom. This is a timeless lesson. The technical stack that enabled the failure, however, is a specific artifact of the WordPress ecosystem, where functionality is often layered through multiple, loosely-coupled plugins. This "plugin spaghetti" creates complex dependencies and failure points.

A proactive audit, rather than a reactive debug, is the primary defense. For any membership site, this audit should be a standard operating procedure. First, map all paid content types, especially custom post types created by third-party plugins. Second, create a test matrix. This should include checks for logged-out users, logged-in non-paying users, users with expired subscriptions, and users in each distinct membership tier.

Finally, automate these checks. A simple script that attempts to curl protected URLs without an authenticated session cookie can provide an early warning system for the most common and dangerous failure mode: public access to paid content. The goal is to discover these issues through systematic testing, not by waiting for a user to report a tangentially related bug.

Landing

The most dangerous vulnerability is often the one that generates no support tickets. While paying members will report when they cannot access content, non-paying users who successfully access that same content for free will not. The developer's story is a reminder that the user-reported problem is only one part of the system's state. Verifying the opposite condition, the one nobody is complaining about, is not just good practice. It is a necessary defense against silent, catastrophic failure.

The investor read

This case study highlights the technical debt inherent in many bootstrapped and micro-SaaS businesses built on complex WordPress stacks. For an investor performing due diligence, this is a signal of operational risk. A business reliant on a fragile chain of third-party plugins for its core revenue protection is vulnerable to silent, catastrophic leaks. An audit of access control logic should be standard practice before any acquisition in this space. Businesses built on more integrated platforms or with headless architectures where security is managed at the API level may represent lower technical risk, potentially justifying a higher valuation.

Pull quote: “The core diagnostic principle is to always check the inverse of the reported symptom.”