GHSA-6w2r-cfpc-23r5: Unauthenticated IDOR in AVideo Playlist Endpoints

AVideo (formerly YouPHPTube) is an open-source video sharing platform widely used for hosting streaming content. A significant access control vulnerability has been identified in the platform's API endpoints responsible for retrieving user playlists. Specifically, the endpoints /objects/playlistsFromUser.json.php and /objects/playlistsFromUserVideos.json.php are exposed to unauthenticated requests and lack necessary authorization checks.

The core issue is a failure to restrict access to sensitive user data based on the session's privileges. When these scripts are accessed, they unconditionally query the backend for all playlists associated with a provided users_id, including those explicitly marked as private. This behavior constitutes an Insecure Direct Object Reference (IDOR), as the system relies on user-supplied input (the User ID) to retrieve objects without verifying that the requester is authorized to view those specific objects.

This vulnerability allows any external actor to map out the private content preferences and curation activities of the platform's user base. While it does not allow for the modification of data (integrity) or denial of service (availability), the breach of confidentiality regarding user activity is absolute for the affected endpoints.

The vulnerability stems from a logical error in how the PlayList::getAllFromUser method is invoked within the public-facing API scripts. In AVideo's architecture, this method accepts a user ID and a boolean flag, commonly referred to as $publicOnly. When this flag is set to true, the method filters the database query to return only public playlists. When set to false, it returns all playlists, including private system lists like 'Watch Later' and 'Favorites'.

In the vulnerable versions (pre-25.0), the code in objects/playlistsFromUser.json.php hardcoded this parameter to false without any preceding authentication logic:

// Vulnerable implementation
$row = PlayList::getAllFromUser($_GET['users_id'], false);

The developers implicitly trusted that the endpoint would handle public/private distinction or intended for this endpoint to be internal-only, yet it was exposed publicly. There was no check to see if User::isLogged() was true, nor was there a comparison between the currently logged-in user's ID and the requested users_id. This effectively effectively bypassed the application's intended privacy model, treating every request as if it came from the playlist owner or an administrator.

The remediation for this issue involved introducing an explicit authorization gate before querying the database. The patch logic ensures that the $publicOnly flag defaults to true (safe) and is only toggled to false (unsafe/full access) if strict conditions are met.

Vulnerable Code (Before Patch):

The original code directly consumed the GET parameter and queried the database with the unsafe flag.

// objects/playlistsFromUser.json.php (Pre-v25.0)
 
if (empty($_GET['users_id'])) {
    die("You need a user");
}
 
// CRITICAL FLAW: The second argument 'false' forces the backend
// to return ALL playlists, including private ones. No auth check exists.
$row = PlayList::getAllFromUser($_GET['users_id'], false);
 
echo json_encode($row);

Patched Code (Version 25.0):

The fix, introduced in commit 12adc66913724736937a61130ae2779c299445ca, implements a standard Access Control List (ACL) check.

// objects/playlistsFromUser.json.php (Patched)
 
$users_id = intval($_GET['users_id']);
 
// 1. Default to SAFE mode (Public playlists only)
$publicOnly = true;
 
// 2. Check Authentication and Authorization
// If the user is logged in AND (is the owner of the ID OR is an Admin)
if (User::isLogged() && (User::isAdmin() || User::getId() == $users_id)) {
    // 3. Allow access to private playlists
    $publicOnly = false;
}
 
// 4. Execute query with the determined flag
$row = PlayList::getAllFromUser($users_id, $publicOnly);
 
echo json_encode($row);

This change ensures that an unauthenticated attacker, or an authenticated user requesting another user's data, will only receive public playlists, preserving the confidentiality of private collections.

Exploiting this vulnerability requires no special tools, authentication, or race conditions. It is a standard GET request manipulatable via a web browser or command-line HTTP client. The attacker only needs to know or guess a valid users_id. Since user IDs are often sequential integers, an attacker can easily iterate through the entire user base.

Proof of Concept:

The following curl command retrieves the private playlists for User ID 1 (typically the administrator):

curl -s "https://target-avideo-site.com/objects/playlistsFromUser.json.php?users_id=1" | jq

Expected Response (Vulnerable):

The server returns a JSON array containing private system playlists. Note the status fields indicating 'private', 'watch_later', or 'favorite'.

[
  {
    "id": 45,
    "name": "Watch Later",
    "status": "watch_later",
    "users_id": 1,
    "videos": [...]
  },
  {
    "id": 46,
    "name": "My Secret Project",
    "status": "private",
    "users_id": 1,
    "videos": [...]
  }
]

In a secured environment, or against the patched version, the response would either be empty or contain only playlists where status is 'public'.

The primary impact of GHSA-6w2r-cfpc-23r5 is Confidentiality Loss. While the vulnerability does not allow for Remote Code Execution (RCE) or data modification, the privacy implications are significant for a social platform.

Specific Consequences:

• Privacy Violation: Users expect their 'Watch Later' and 'Favorite' lists to be private. Exposure of this data can reveal personal interests, political affiliations, or sensitive habits.
• User Enumeration: Attackers can validate the existence of user IDs by observing the difference between an empty response (invalid user) and a response containing empty arrays (valid user with no playlists) or actual data.
• Social Engineering: The metadata retrieved (names of private playlists, specific videos bookmarked) provides highly specific context that can be used to craft convincing phishing emails targeting specific users.

Severity Scoring:

• CVSS v4.0: 6.9 (Medium)
• Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
• Note: The severity is capped at Medium/High because the scope is limited to playlist metadata. However, the ease of exploitation (Network, Unauthenticated, Low Complexity) makes it a high-priority fix for privacy-conscious deployments.