Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The Authorize.Net webhook handler at plugin/AuthorizeNet/webhook.php contains a signature verification bypass that allows an attacker to forge webhook requests with arbitrary payment amounts and target user IDs. By supplying a valid transaction ID from a small legitimate purchase, the attacker bypasses signature validation and credits arbitrary wallet balances to any user account via attacker-controlled payload fields. Details Three flaws combine into an exploit chain: 1. Signature Bypass via OR Logic (webhook.php:33) The webhook is rejected only when both conditions are true: the signature is invalid AND the transaction lookup fails. If the attacker supplies a real transaction ID (e.g., from their own $1 purchase), getTransactionDetails() succeeds and returns valid data, so the second condition is false. The invalid signature is silently ignored. 2. Payload Values Override API-Fetched Values (AuthorizeNet.php:169-171, webhook.php:44-48) In analyzeTransactionFromWebhook(),…
Recommended action: Upgrade to 29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Details CWE: CWE-538 - Insertion of Sensitive Information into Externally-Accessible File or Directory The official docker-compose.yml (line 61) mounts the entire project root directory as the Apache document root: This causes the .env file — which contains database credentials, admin passwords, and infrastructure configuration — to be served as a static file at /.env. No .htaccess rule or Apache configuration blocks access to dotfiles. Exposed Information An unauthenticated request to GET /.env returns: Steps to Reproduce Prerequisites - AVideo deployed using the official docker-compose.yml - No modifications to the default configuration Steps 1. Deploy AVideo using docker compose up -d 2. Send: curl http://target/.env 3. The full .env file contents are returned, including database credentials and admin password Impact - Attacker: Unauthenticated (any remote user) - Victim: AVideo server and database - Specific damage: Attacker obtains database credentials…
Recommended action: Upgrade to 29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The setapisignUp method in the API plugin accepts emailVerified, canUpload, canStream, and canCreateMeet parameters from user-supplied input and applies them to newly created accounts without verifying that the request was authenticated with a valid APISecret. Any anonymous user who can solve a CAPTCHA can self-grant elevated permissions during account registration. Details The authentication check in setapisignUp (plugin/API/API.php:4222) allows either a valid APISecret (admin-level credential) or a solved CAPTCHA (anonymous access): After this check, both code paths (APISecret and CAPTCHA) reach the privilege parameter handling unconditionally: These $global values are then consumed by User::save() (objects/user.php:829-840), which overrides the user object's permission fields: Note that even though userCreate.json.php:90 sets canUpload from the site's default configuration, User::save() subsequently overrides it with the attacker-controlled $global value. The codebase…
Recommended action: Upgrade to 29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In objects/like.php, the getLike() method constructs a SQL query using a prepared statement placeholder (?) for usersid but directly concatenates $this-videosid into the query string without parameterization. An attacker who can control the videosid value (via a crafted request) can inject arbitrary SQL, bypassing the partial prepared-statement protection. Details File: objects/like.php Vulnerable code: The query mixes a parameterized placeholder for usersid with raw string concatenation for videosid. The $this-videosid value originates from user-supplied request input (typically a POST/GET parameter identifying the video being liked/disliked) and is not cast to integer or validated before being embedded in the SQL string. All other queries in the same file correctly use ? placeholders for both columns: The inconsistency means any attacker who can submit a like/dislike action with a crafted videosid can inject SQL. Since like/dislike actions are typically available to any…
Recommended action: Upgrade to 26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The listFiles.json.php endpoint accepts a path POST parameter and passes it directly to glob() without restricting the path to an allowed base directory. An authenticated uploader can traverse the entire server filesystem by supplying arbitrary absolute paths, enumerating .mp4 filenames and their full absolute filesystem paths wherever they exist on the server — including locations outside the web root, such as private or premium media directories. Details The vulnerable code is at objects/listFiles.json.php:8-45: The $POST['path'] value is used directly in glob() with no call to realpath() for normalization and no prefix check against a permitted base directory (e.g., $global['systemRootPath'] . 'videos/'). The response includes obj-path containing the full absolute filesystem path of each matched file. The extension filter ({.mp4,.mp4,.MP4}) limits results to .mp4 files, which prevents reading credentials or source code but does not prevent enumeration of video files stored…
Recommended action: Upgrade to 26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Scheduler plugin's run() function in plugin/Scheduler/Scheduler.php calls urlgetcontents() with an admin-configurable callbackURL that is validated only by isValidURL() (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler's callback URL is never passed through isSSRFSafeURL(), which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network callbackURL to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet. Details The vulnerable code is at plugin/Scheduler/Scheduler.php:157-166: isValidURL() in objects/functions.php uses filtervar($url, FILTERVALIDATEURL) — it validates URL syntax only and does not block internal/private network targets. isSSRFSafeURL() in objects/functions.php:4021 explicitly blocks: - 127.x.x.x / ::1…
Recommended action: Upgrade to 26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Product: AVideo (https://github.com/WWBN/AVideo) Version: Latest (tested March 2026) Type: Insecure Direct Object Reference (IDOR) Auth Required: No User Interaction: None Summary The /objects/playlistsFromUser.json.php endpoint returns all playlists for any user without requiring authentication or authorization. An unauthenticated attacker can enumerate user IDs and retrieve playlist information including playlist names, video IDs, and playlist status for any user on the platform. Root Cause The endpoint accepts a usersid parameter and directly queries the database without any authentication or authorization check. File: objects/playlistsFromUser.json.php There is no call to User::isLogged() or any comparison between the requesting user and the target usersid. Affected Code | File | Line | Issue | |------|------|-------| | objects/playlistsFromUser.json.php | 10-21 | No authentication or authorization check before returning playlist data | Proof of Concept Retrieve admin's playlists…
Recommended action: Upgrade to 25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An unauthenticated attacker can execute arbitrary OS commands on the server by injecting shell command substitution into the base64Url GET parameter. This can lead to full server compromise, data exfiltration (e.g., configuration secrets, internal keys, credentials), and service disruption. Root Cause The base64Url parameter is Base64-decoded and then interpolated directly into a double-quoted ffmpeg shell command without proper shell escaping. The upstream validation uses FILTERVALIDATEURL, which validates URL syntax but does not prevent shell metacharacters / command substitution sequences from being interpreted by the shell. Affected Components objects/getImage.php objects/security.php Execution path via async command execution helper (shellexec/nohup) Patches Apply strict shell argument escaping (e.g., escapeshellarg()) to all user-supplied values before building any shell command, and avoid double-quoted interpolation of untrusted input. Prefer safer process execution…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Type Authenticated Server-Side Request Forgery (SSRF) Affected Product/Versions AVideo versions prior to 22 (tested on AVideo 21.x). Root Cause Summary The aVideoEncoder.json.php API endpoint accepts a downloadURL parameter and fetches the referenced resource server-side without proper validation or an allow-list. This allows authenticated users to trigger server-side requests to arbitrary URLs (including internal network endpoints). Impact Summary An authenticated attacker can leverage SSRF to interact with internal services and retrieve sensitive data (e.g., internal APIs, metadata services), potentially leading to further compromise depending on the deployment environment. Resolution/Fix This issue has been fixed in AVideo version 22. Users should upgrade to version 22.0 as soon as possible. Credits/Acknowledgement Thanks to Arkadiusz Marta for responsibly reporting this issue. - GitHub Profile: https://github.com/arkmarta/
Recommended action: Upgrade to 22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Type Stored Cross-Site Scripting (XSS) — CWE-79. Affected Product/Versions AVideo 18.0. Root Cause Summary AVideo allows Markdown in video comments and uses Parsedown (v1.7.4) without Safe Mode enabled. Markdown links are not sufficiently sanitized, allowing javascript: URIs to be rendered as clickable links. Impact Summary An authenticated low-privilege attacker can post a malicious comment that injects persistent JavaScript. When another user clicks the link, the attacker can perform actions such as session hijacking, privilege escalation (including admin takeover), and data exfiltration. Resolution/Fix The issue was confirmed and fixed in the master branch. An official release will be published soon. Workarounds Until the release is available, validate and block unsafe URI schemes (e.g., javascript:) before rendering Markdown, and enable Parsedown Safe Mode. Credits/Acknowledgement Reported by Arkadiusz Marta (https://github.com/arkmarta/).
Recommended action: Upgrade to 21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PHP file view/about.php is vulnerable to an XSS issue due to no sanitization of the user agent. At line [53], the website gets the user-agent from the headers through $SERVER['HTTPUSERAGENT'] and echo it without any sanitization. In PHP, echo a user generated statement, here the User-Agent Header, without any sanitization allows an attacker to inject malicious scripts into the output of a web page, which are then executed in the browser of anyone viewing that page.
Recommended action: Upgrade to 14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in WWBN AVideo v.12.4 through v.14.2 allows a remote attacker to execute arbitrary code via the systemRootPath parameter of the submitIndex.php component.
Recommended action: Upgrade to 14.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In AVideo, a normal user can make a Meeting Schedule where the user can invite another user in that Meeting, but I found out that it did not properly sanitize the malicious characters when creating a Meeting Room. This leads the attacker to put malicious scripts. Impact: Since any USER including the ADMIN can see the meeting room that was created by the attacker this can lead to cookie hijacking and takeover of any accounts without user interaction. Step to Reproduce: 1. As normal USER go to Meet - Schedule https://demo.avideo.com/plugin/Meet/ 2. In "Meet topic" field put XSS payload Example: "<img src=x onerror=alert('Pawned+by+Gonz') 3. Then click Save 4. Now as ADMIN go to Meet - Schedule - Upcoming https://demo.avideo.com/plugin/Meet/ 5. Then the XSS payload that normal USER created will be executed Video POC: https://youtu.be/Nke0Bmv5F-o
Recommended action: Upgrade to 12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
WWBN Avideo Authenticated RCE - OS Command Injection Description An OS Command Injection vulnerability in an Authenticated endpoint /plugin/CloneSite/cloneClient.json.php allows attackers to achieve Remote Code Execution. Vulnerable code: We can control $objClone-cloneSiteURL through the admin panel clone site feature. /plugin/CloneSite/cloneClient.json.php sends a GET Request to {$objClone-cloneSiteURL}/plugin/CloneSite/cloneServer.json.php. I hosted a specially crafted cloneServer.json.php that prints the following JSON data Send a GET Request to /plugin/CloneSite/cloneClient.json.php then remote code execution is achieved.
Recommended action: Upgrade to 12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While making an account in demo.avideo.com I found a parameter "?success=" which did not sanitize any symbol character properly which leads to XSS attack. Impact: Since there's an Admin account on demo.avideo.com attacker can use this attack to Takeover the admin's account Step to Reproduce: 1. Click the link below https://demo.avideo.com/user?success="<img src=x onerror=alert(document.cookie) 2. Then XSS will be executed
Recommended action: Upgrade to 12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: An attacker could execute remote code on a system running wwbn/avideo Step to Reproduce: 1. Go to the My Videos tab https://demo.avideo.com/mvideos 2. Click "Embed a video link" Append a command to the url as a query string. eg. ?whoami then click Save This issue has been resolved in commit 236228f15
Recommended action: Upgrade to 12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The import.json.php file before 8.9 for AVideo is vulnerable to a File Deletion vulnerability. This allows the deletion of configuration.php, causing certain privilege checks to not be in place, leading to privilege escalation to admin. Local File Inclusion may also leak credentials and important files. Patches Upgrade to version 8.9
Recommended action: Upgrade to 8.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.