How Scalelite Playback Broke Tenant Isolation in BigBlueButton Multitenancy

While researching the BigBlueButton bug bounty program on YesWeHack, I found an access control issue in Scalelite’s recording playback flow.

The problem appeared when multitenancy was enabled.

Scalelite already derived tenant context from the request hostname for BigBlueButton API requests and scoped recording queries to that tenant. The playback controller did not follow the same model. It resolved recordings using only record_id and playback format.

As a result, a recording assigned to Tenant A could also be requested through Tenant B’s hostname if the same record_id was known.

I submitted the finding as High, with CVSS 3.1 score 7.5. Triage later classified it as Medium, with CVSS score 5.3. The report received a €250 bounty.

The intended tenant boundary

When Scalelite multitenancy is enabled through MULTITENANCY_ENABLED=true, tenant identity is derived from the request hostname.

The helper responsible for that behavior was:

def fetch_tenant_name_from_url
  request.host.split(".").first
end

def fetch_tenant(name: nil)
  return nil unless Rails.configuration.x.multitenancy_enabled

  tenant_name = name.presence || fetch_tenant_name_from_url
  tenant = Tenant.find_by_name(tenant_name)
  raise ChecksumError if tenant.blank?

  tenant
end

For example, these hostnames represent different tenant contexts:

tenantA.sl.example.com
tenantB.sl.example.com

The project documentation also states that each tenant should have access only to its own meetings and recordings.

The BigBlueButton API controller followed this model. When multitenancy was enabled, it resolved the current tenant and used that context when querying recordings.

The recording query included a metadata filter matching tenant-id to the current tenant:

query = Recording
        .includes(playback_formats: [:thumbnails], metadata: [])
        .left_joins(:metadata)
        .distinct

query = query.where(
  metadata: {
    key: "tenant-id",
    value: @tenant.id
  }
) if @tenant.present?

So the tenant boundary already existed for recording discovery through the API.

Playback used a global lookup

The vulnerable behavior was inside PlaybackController.

Both playback actions resolved a recording using its identifier and playback format:

@playback_format = PlaybackFormat
                   .joins(:recording)
                   .find_by!(
                     format: params[:playback_format],
                     recordings: {
                       record_id: params[:record_id]
                     }
                   )

@recording = @playback_format.recording

There was no tenant lookup from the hostname.

There was no before_action :set_tenant.

There was no condition requiring the recording metadata to contain a tenant-id matching the current request.

The query therefore answered only whether a recording with the requested identifier and format existed.

It did not verify whether that recording belonged to the tenant represented by the hostname.

Reproducing the issue

I reproduced the problem with an RSpec request test while multitenancy was enabled.

The test created a published recording and explicitly associated it with Tenant A:

create(
  :metadatum,
  recording: recording,
  key: "tenant-id",
  value: "tenantA-id"
)

A presentation playback resource was then created for the same recording:

create(
  :playback_format,
  recording: recording,
  format: "presentation",
  url: "/presentation/#{recording.record_id}/index.html"
)

The first request used Tenant A’s hostname and returned HTTP 200 as expected.

The second request used Tenant B’s hostname while keeping the same path and record_id.

That request also returned HTTP 200.

Both responses exposed the same X-Accel-Redirect target for the recording resource.

The recording ownership never changed. Only the request hostname changed.

The test completed successfully:

Finished in 0.19804 seconds
2 examples, 0 failures

This demonstrated that playback authorization depended on possession of the record_id, not on tenant ownership.

Why this matters

The affected playback routes can serve recording pages and their associated resources.

Depending on the generated recording format and meeting content, those resources may include presentation material, media, captions, notes, chat content, participant related information, and other recording assets.

The attacker still needs to know or obtain the victim recording’s record_id.

The vulnerability is not that every identifier is automatically discoverable. The issue is that once an identifier is known, the playback path does not enforce the tenant boundary that multitenancy is supposed to provide.

Protected recordings also have their own token and cookie mechanism. That mechanism is separate from tenant ownership and does not replace tenant isolation.

Why this is an access control flaw

The key difference is between object existence and object ownership.

The vulnerable lookup effectively used:

record_id + format

Under multitenancy, the authorization decision needed to include the current tenant:

tenant + record_id + format

The API side already enforced that distinction through tenant-id metadata.

Playback did not.

That is why the issue fits CWE 284, Improper Access Control. It also matches the authorization bypass pattern described by CWE 639, where a user controlled object identifier can reach data outside the caller’s authorization boundary.

Severity

I originally submitted the issue with this CVSS 3.1 vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

That produced a base score of 7.5.

During triage, the confidentiality impact was reduced from High to Low, resulting in:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

The final score was 5.3, and the finding was classified as Medium.

The public writeup preserves both values because the first reflects the submitted assessment and the second reflects the final program classification.

Remediation

The playback path should enforce the same tenant ownership rule already used by the recording API.

When multitenancy is enabled, PlaybackController should resolve the tenant from the request hostname and scope the recording lookup to metadata where tenant-id matches that tenant.

The expected behavior should be:

Tenant A requesting Tenant A recording = HTTP 200
Tenant B requesting Tenant A recording = HTTP 404

The cross tenant response should not receive an X-Accel-Redirect for the recording resource.

Legacy recordings without tenant metadata also need an explicit policy. The safer behavior under multitenancy is to deny access until ownership has been established or migrated.

A regression test should keep this boundary covered by creating a recording for one tenant and confirming that the same identifier cannot be served through another tenant hostname.