CVE-2026-43879: WWBN AVideo SSRF Vulnerability

CVE-2026-43879 Overview

CVE-2026-43879 is a Server-Side Request Forgery (SSRF) vulnerability in WWBN AVideo, an open source video platform. The flaw affects all versions up to and including 29.0. An authenticated user can configure a donation-notification webhook URL pointing to internal hosts, loopback addresses, or cloud metadata endpoints. When any donation is processed through plugin/CustomizeUser/donate.json.php, the AVideo server issues a curl POST to the attacker-controlled URL, producing a blind SSRF. The vulnerability is classified under CWE-918: Server-Side Request Forgery.

Critical Impact

Authenticated attackers can force the AVideo server to send HTTP POST requests to internal services, RFC1918 networks, and cloud instance metadata endpoints such as 169.254.169.254, enabling reconnaissance and potential credential theft.

Affected Products

• WWBN AVideo versions up to and including 29.0
• AVideo CustomizeUser plugin donation handler
• Deployments exposing plugin/CustomizeUser/donate.json.php

Discovery Timeline

• 2026-05-11 - CVE-2026-43879 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43879

Vulnerability Analysis

The vulnerability resides in the donation-notification webhook flow of the AVideo CustomizeUser plugin. Authenticated users can register an arbitrary URL as their donation-notification target. When another user, including a second account controlled by the same attacker, donates any amount through plugin/CustomizeUser/donate.json.php, the server issues a curl POST to the stored URL.

The handler validates the URL using only isValidURL(), which performs a syntactic format check. It does not call the existing isSSRFSafeURL() helper that enforces network-level allow/deny rules. As a result, attackers can target loopback addresses (http://127.0.0.1:8080/...), RFC1918 ranges, and cloud metadata services such as http://169.254.169.254/latest/....

A second issue compounds the flaw: CURLOPT_FOLLOWLOCATION is enabled without per-hop revalidation. Even if the stored URL passed validation, an attacker-controlled host can respond with an HTTP 307 redirect that forwards the POST, along with its body, to an internal target.

Root Cause

The root cause is missing SSRF-aware destination validation [CWE-918]. The codebase ships an isSSRFSafeURL() helper, but the donation webhook handler bypasses it in favor of a format-only check. Combined with unrestricted redirect following in libcurl, the server acts as a confused deputy for outbound HTTP requests.

Attack Vector

An authenticated user sets their donation-notification webhook to an internal URL through the user profile customization interface. The attacker then triggers a minimal donation using a second account or any third party. The AVideo backend dispatches a POST to the stored URL on behalf of the server, reaching internal services that are not exposed externally. Because the response is not returned to the attacker, the SSRF is blind, but state-changing requests and metadata service responses can still be leveraged. The fix is published in commit aaacd48f29f1ff71d1eb5fc81d37605f593cefa9.

Detection Methods for CVE-2026-43879

Indicators of Compromise

• Outbound HTTP POST requests originating from the AVideo PHP worker process destined for 127.0.0.1, 169.254.169.254, or RFC1918 ranges.
• Stored donation-notification webhook values in user records that resolve to private, loopback, or link-local addresses.
• Web access logs showing repeated calls to plugin/CustomizeUser/donate.json.php shortly after profile updates.
• HTTP 307 responses from external hosts referenced by webhook configurations, indicating redirect-based bypass attempts.

Detection Strategies

• Inspect the AVideo database for notification_url or equivalent donation webhook fields and flag entries failing an isSSRFSafeURL()-equivalent allowlist.
• Monitor egress traffic from the AVideo host and alert on connections to internal CIDR ranges or cloud metadata IPs.
• Correlate donation events in application logs with outbound curl activity to identify abusive webhook destinations.

Monitoring Recommendations

• Enable verbose logging for the CustomizeUser plugin and forward events to a centralized log platform for analysis.
• Apply egress firewall rules that block AVideo workers from reaching 169.254.169.254 and private network ranges, and alert on policy hits.
• Review user profile change events for newly added or modified donation webhook URLs.

How to Mitigate CVE-2026-43879

Immediate Actions Required

• Upgrade WWBN AVideo to a release that includes commit aaacd48f29f1ff71d1eb5fc81d37605f593cefa9.
• Audit existing user records and remove any donation-notification webhook URLs pointing to internal, loopback, or metadata addresses.
• Restrict egress traffic from the AVideo host so it cannot reach cloud metadata services or internal management networks.

Patch Information

The maintainers published a fix in commit aaacd48f29f1ff71d1eb5fc81d37605f593cefa9. The update routes donation webhook URLs through isSSRFSafeURL() and addresses redirect handling. Full advisory details are available in GitHub Security Advisory GHSA-wp38-whx3-xffh.

Workarounds

• Disable the CustomizeUser plugin until the patched version is deployed.
• Apply a reverse proxy or host-level egress policy that blocks outbound connections from the AVideo server to 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16.
• Set CURLOPT_FOLLOWLOCATION to false in the donation webhook handler or enforce per-hop URL revalidation.
• Require administrator approval before any user-supplied webhook URL becomes active.

# Configuration example: block AVideo host egress to internal ranges via iptables
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT