CVE-2026-61572 in AVideo-Encoder
Summary
by MITRE • 10/28/2026
AVideo is a video-sharing Platform. Before the initial remediation attempt in 8.1.0, `url_get_contents` in `objects/functions.php` accepts caller-controlled destinations after only `FILTER_VALIDATE_URL` syntax validation, without rejecting private, loopback, or link-local addresses, and disables TLS peer verification. `Login::isLogged` reauthenticates using the attacker-settable `encoder_aVideoURL` cookie together with arbitrary nonempty `encoder_user` and `encoder_pass` cookies, and `Login::run` stores the raw fetched body in `result`. The unauthenticated `objects/login.json.php` endpoint returns that session object, enabling full-response exfiltration through a supplied `siteURL`; its `Streamer::isURLAllowed` gate allows all sites when the operator allowlist is empty, the default. An unauthenticated remote attacker can read internal HTTP and HTTPS responses, including cloud instance-metadata credentials, and reach internal TCP services. A further pre-authentication FTP variant in `view/youtubeDl.json.php` routes an ftp `videoURL` into `FTPDownloader`; `parseFtpUrl` in `objects/FTPDownloader.php` accepts its host and port for `ftp_connect`. This also enables requests to internal FTP services. Untrusted self-signed HTTPS certificates are accepted, and no account or operator interaction is required. Version 8.1.0 contains an initial remediation attempt that removes raw-response reflection and adds destination checks, but private-network exemptions and login TLS-verification defaults leave complete remediation of the described internal-network and TLS variants unresolved.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
AVideo, a widely deployed video-sharing platform, suffers from critical server-side request forgery vulnerabilities stemming from insufficient input validation and insecure default configurations in its core authentication and media processing modules. The primary flaw resides within the `objects/functions.php` file, where the `url_get_contents` function processes caller-controlled URLs with inadequate security checks. While the application employs `FILTER_VALIDATE_URL` to ensure syntactic correctness of the provided destination, it fails to enforce semantic restrictions on the target address space. Specifically, the implementation does not reject private IP ranges, loopback addresses, or link-local networks, nor does it validate that the URL points to an external, public resource. This oversight allows attackers to direct internal HTTP and HTTPS requests toward sensitive infrastructure components that are otherwise inaccessible from the internet. Furthermore, the function disables TLS peer verification by default, meaning that even when targeting secure endpoints, the application will accept self-signed or invalid certificates without raising errors, thereby facilitating man-in-the-middle attacks against internal services that rely on certificate validation for security assurance.
The exploitation of these flaws is significantly amplified by weaknesses in the authentication mechanism located within `Login::isLogged` and `Login::run`. These functions reauthenticate users based on cookies set by the attacker, specifically leveraging the `encoder_aVideoURL`, `encoder_user`, and `encoder_pass` parameters. When an unauthenticated actor supplies arbitrary nonempty values for these cookies, the system proceeds to fetch content from the specified URL using the provided credentials or without them if not required by the target service. The raw response body is then stored in a variable named `result`. Crucially, this data is subsequently exposed through the unauthenticated endpoint `objects/login.json.php`, which returns the session object containing the fetched content. This design flaw creates a direct channel for full-response exfiltration, allowing an attacker to read internal HTTP and HTTPS responses simply by supplying a crafted `siteURL` parameter. The effectiveness of this attack vector is further enhanced because the `Streamer::isURLAllowed` gate function permits all sites when the operator-defined allowlist remains empty, which represents the default configuration for most installations. Consequently, no account privileges or administrative interaction are required to trigger these internal network probes and data extractions.
Beyond HTTP-based exfiltration, AVideo presents additional risks through its media download functionality in `view/youtubeDl.json.php`. This endpoint accepts a `videoURL` parameter that is routed into the `FTPDownloader` class without sufficient sanitization of protocol-specific constraints. The `parseFtpUrl` function within `objects/FTPDownloader.php` directly passes host and port information to `ftp_connect`, enabling unauthenticated remote attackers to initiate connections to internal FTP services. This capability allows for reconnaissance, data theft from unprotected file shares, or potential exploitation of vulnerabilities in legacy FTP servers residing on the local network. The combination of unrestricted protocol support, lack of destination validation, and disabled TLS verification creates a comprehensive attack surface that extends beyond simple HTTP request forgery into broader internal network compromise scenarios. Attackers can leverage these capabilities to map internal service architectures, extract sensitive configuration files, or access cloud instance metadata endpoints such as those found in AWS EC2 or Azure Managed Identity environments, which often expose credentials and secrets when accessed from within the trusted network boundary.
The remediation efforts introduced in version 8.1.0 represent only a partial fix for these systemic issues. While this update removes the direct reflection of raw responses and introduces basic destination checks, it fails to address the root causes comprehensively. Private-network exemptions remain improperly configured or absent, leaving internal services vulnerable to access from external sources via forged requests. Additionally, the default configuration continues to disable TLS verification by default, maintaining a significant security gap for any HTTPS-based interactions with internal resources. These incomplete fixes mean that while some obvious exploitation paths may be blocked, sophisticated attackers can still leverage alternative protocols like FTP or exploit residual HTTP vulnerabilities to achieve unauthorized access and data exfiltration. To fully mitigate these risks, operators must enforce strict allowlists of permitted external domains, disable TLS verification only when absolutely necessary for specific internal legacy systems with compensating controls, implement IP-based filtering at the network perimeter, and ensure that all authentication endpoints require valid session tokens rather than relying on attacker-controlled cookies. Aligning these practices with CWE-918 (Server-Side Request Forgery) and MITRE ATT&CK techniques such as T1504 (Web Shell) or T1071 (Application Layer Protocol) would provide a more robust defense posture against internal network reconnaissance and data theft.