Loom Subscription Bypass Let Starter Users Download Premium Transcriptions

A simple client-side bypass allowed a Loom Starter user to download video transcriptions that were supposed to be available only to Business users.

I reported the issue through Bugcrowd. The report was ultimately classified as [Informational] because it was considered to have no security impact.

Fair enough. I agreed with the triage decision rather than starting a never-ending "but technically…" discussion. 😄

That said, I still found the behavior interesting from a subscription-enforcement and business-logic perspective.

The Feature

Loom has different subscription tiers, and some functionality is restricted depending on the plan.

One of those features is downloading a video's transcript/captions.

As a Starter/free user, I could watch the video normally, but the transcript download functionality was not available to me.

So far, everything worked as expected.

Looking Under the Hood

I opened a Loom video using a regular Starter account and checked the browser's DevTools.

The UI correctly enforced the subscription restriction.

There was no obvious "Download transcript" functionality available to my account.

But instead of stopping there, I wanted to see whether the restriction was actually enforced server-side or whether the browser was simply hiding functionality based on the user's subscription.

A quick look at the client-side behavior suggested the latter.

The application already had the information necessary to retrieve the transcript. The restriction appeared to be enforced by the frontend rather than by a server-side authorization check.

That made the next test pretty straightforward.

The Bypass

I opened DevTools → Console and executed a small JavaScript snippet.

The original PoC is intentionally redacted here:

(async()=>{
  let h=document.documentElement.innerHTML,

      // [REDACTED] transcription resource extraction
      j=h.match(/REDACTED/)?.[0],

      // [REDACTED] caption resource extraction
      v=h.match(/REDACTED/)?.[0];

  // Remaining PoC logic omitted for disclosure.
  // The script retrieves the transcript/caption resources
  // already exposed to the client and creates local downloads.
})()

(async()=>{
  let h=document.documentElement.innerHTML,

      // [REDACTED] transcription resource extraction
      j=h.match(/REDACTED/)?.[0],

      // [REDACTED] caption resource extraction
      v=h.match(/REDACTED/)?.[0];

  // Remaining PoC logic omitted for disclosure.
  // The script retrieves the transcript/caption resources
  // already exposed to the client and creates local downloads.
})()

And… it worked.😎

The transcript was downloaded even though the account itself was not subscribed to the plan that normally provides the feature.

I've intentionally redacted the resource-extraction logic from the public PoC — partly to keep the writeup within responsible disclosure boundaries and, well, not accidentally hand over a ready-to-use bypass. 😊

If you're interested in the technical details, feel free to reach out and discuss the approach.

The important part here isn't the JavaScript itself.

It's the fact that the browser was able to perform the operation without a meaningful server-side subscription check preventing it.

How the Bypass Works

The bypass itself is actually quite simple.

The Loom page already contained references to the transcription and caption resources in the client-side HTML. The subscription restriction prevented the Starter user from accessing the download functionality through the normal UI, but the underlying resources were still available to the browser.

The PoC simply:

Extracts the transcription/caption resource references from the page.
Fetches those resources from the browser.
Converts the transcription data into a downloadable SRT file.
Provides a small local download interface directly in the page.

So the problem wasn't really "breaking" the transcript system.

It was more like bypassing the UI restriction and using functionality that the browser could already access.

The key distinction is that the UI restriction and the actual resource access were not enforcing the same boundary.

For a paid feature, the stronger model would be to enforce the subscription entitlement when the backend serves or generates the requested resource — not merely when the frontend decides whether to show the download button.

Why This Matters

From a pure security perspective, I can understand why this wasn't considered impactful.

There was no account takeover.

No sensitive data belonging to another user was exposed.

No authentication boundary was crossed.

And there was no obvious confidentiality or integrity impact.

But there was still an interesting business impact.

The affected functionality was a paid feature.

A Starter user could access functionality that was intended to require a higher-tier subscription without actually upgrading.

In other words:

Starter user → premium feature → no upgrade required.

The bypass was also trivial.

It didn't require manipulating complex requests, exploiting a race condition, or chaining several vulnerabilities. Anyone familiar with browser DevTools could reproduce the behavior.

That also means the technique could potentially be shared or automated, making it less effective as a subscription-enforcement mechanism.

From a SaaS perspective, that's arguably more interesting than the technical complexity of the PoC itself.

But Isn't This Just Client-Side Enforcement?

Pretty much.

And that's exactly why I wouldn't describe this as a high-severity security vulnerability.

Client-side checks are generally useful for controlling the UI, but they shouldn't be the final authorization boundary for a paid capability.

If a feature is supposed to be available only to users with a particular subscription, the backend should ideally enforce that entitlement when the actual operation is performed.

Otherwise, hiding the button doesn't necessarily prevent the underlying functionality from being invoked.

In this case, the UI effectively said:

"You can't download this."

While the underlying functionality effectively said:

"Sure, why not?"

That's not exactly the strongest subscription enforcement mechanism.

Bugcrowd Triage

I reported the issue through Bugcrowd and highlighted the potential business impact:

Starter users can access a paid Business feature without upgrading.

I also pointed out that the bypass was trivial, easily shareable, and potentially automatable, which could reduce the effectiveness of Loom's subscription enforcement and the incentive for affected users to upgrade.

The final result?

And honestly, I agree with the classification from a conventional vulnerability perspective.

There was no meaningful security boundary being crossed, and I wasn't accessing someone else's protected data or account.

The interesting part is simply that the behavior demonstrates how a paid feature could be accessed outside its intended subscription tier.

Final Thoughts

Not every interesting bug is a security vulnerability.

Sometimes you find something that is technically real, reproducible, and arguably undesirable from a product or business perspective, but doesn't meet the bar for a security bounty.

That's exactly what happened here.

The PoC was tiny, the impact was mostly commercial, and the triage result was Informational.

Still, it's a good example of why it's worth looking beyond what the UI allows.

A button being hidden doesn't necessarily mean the underlying functionality is protected.

And sometimes, a few minutes in DevTools are enough to find out which one you're dealing with.

TL;DR: The UI said a Starter user couldn't download premium transcriptions. The underlying functionality disagreed.

Contents