CVE-2026-41056: WWBN AVideo CSRF Vulnerability

CVE-2026-41056 Overview

CVE-2026-41056 is a critical CORS (Cross-Origin Resource Sharing) misconfiguration vulnerability affecting WWBN AVideo, an open source video platform. The vulnerability exists in the allowOrigin($allowAll=true) function within objects/functions.php, which improperly reflects any arbitrary Origin header back in the Access-Control-Allow-Origin response header along with Access-Control-Allow-Credentials: true. This dangerous combination enables cross-origin credential theft attacks.

The vulnerable function is invoked by both plugin/API/get.json.php and plugin/API/set.json.php — the primary API endpoints responsible for handling user data retrieval, authentication, livestream credentials, and state-changing operations. When combined with the application's SameSite=None session cookie policy, any malicious website can make credentialed cross-origin requests and read authenticated API responses, enabling theft of user PII, livestream keys, and performing unauthorized state changes on behalf of victims.

Critical Impact

Any attacker-controlled website can steal user PII, livestream keys, and perform unauthorized actions on authenticated user accounts through cross-origin requests.

Affected Products

• WWBN AVideo versions 29.0 and below
• All installations using the vulnerable allowOrigin() function in objects/functions.php
• Deployments utilizing plugin/API/get.json.php and plugin/API/set.json.php endpoints

Discovery Timeline

• April 21, 2026 - CVE-2026-41056 published to NVD
• April 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-41056

Vulnerability Analysis

This vulnerability represents a classic permissive CORS policy misconfiguration (CWE-942). The root issue lies in how the application handles cross-origin requests by blindly reflecting the requesting origin without validation. When a browser makes a credentialed request (using credentials: 'include'), the CORS specification prohibits wildcard (*) responses for Access-Control-Allow-Origin. To work around this restriction, the vulnerable code reflects whatever origin is present in the request header.

The critical flaw is that this reflection occurs alongside Access-Control-Allow-Credentials: true, creating a scenario where any third-party website can make authenticated requests to the AVideo API and read the responses. This defeats the browser's same-origin policy protections entirely for the affected endpoints.

Root Cause

The vulnerability stems from an incorrect understanding of CORS security implications. The original implementation assumed that reflecting arbitrary origins was safe because the endpoints serve "public ad XML" content. However, the same function is called by API endpoints that handle sensitive session-authenticated data, including user personal information, authentication tokens, and livestream credentials.

The SameSite=None cookie policy further exacerbates the issue by allowing session cookies to be sent with cross-origin requests, enabling full session hijacking through malicious websites.

Attack Vector

An attacker can exploit this vulnerability by creating a malicious webpage that makes JavaScript fetch requests to the vulnerable AVideo API endpoints. When an authenticated victim visits the attacker's page, their browser automatically includes session cookies with the cross-origin requests. The permissive CORS policy then allows the attacker's JavaScript to read the API responses containing sensitive user data.

Attack scenarios include:

1. Theft of user PII through get.json.php API calls
2. Exfiltration of livestream keys and credentials
3. Performing state-changing operations via set.json.php on behalf of victims
4. Account takeover through session token theft

// Security patch in objects/functions.php - fix: Enhance CORS security by validating origins for credentialed requests
 
     // Public resources (e.g. VAST/VMAP ad XML) should be readable by any
     // origin.  Pass $allowAll = true for permissive CORS.
-    // When the browser sends a credentialed request (credentials:'include', e.g.
-    // the IMA SDK), it rejects the wildcard '*' – the spec requires echoing the
-    // exact origin in that case.  We reflect whatever origin is in the request
-    // and add Allow-Credentials:true so credentialed fetches also succeed.
-    // These endpoints return public ad XML and carry no session-sensitive data,
-    // so reflecting any origin is safe here.
+    // SECURITY: even in $allowAll mode we must NOT reflect an arbitrary third-party
+    // Origin together with Access-Control-Allow-Credentials:true — that lets any
+    // attacker page make credentialed cross-origin requests and read session-
+    // authenticated API responses (user PII, stream keys, admin flags).
+    // We therefore validate the origin the same way as the $allowAll=false path:
+    // - Same-origin requests get reflected + credentials (logged-in browser calls)
+    // - All other origins get wildcard without credentials (public/ad-tech reads)
+    // Mobile apps use APISecret token auth, not session cookies, so they are
+    // unaffected by removing Allow-Credentials for third-party origins.
     if ($allowAll) {
         $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? '';
-        if (!empty($requestOrigin)) {
+
+        $siteOriginForAllowAll = '';
+        if (!empty($global['webSiteRootURL'])) {
+            $parsedForAllowAll = parse_url($global['webSiteRootURL']);
+            if (!empty($parsedForAllowAll['scheme']) && !empty($parsedForAllowAll['host'])) {
+                $siteOriginForAllowAll = $parsedForAllowAll['scheme'] . '://' . $parsedForAllowAll['host'];
+                if (!empty($parsedForAllowAll['port'])) {
+                    $siteOriginForAllowAll .= ':' . $parsedForAllowAll['port'];
+                }

Source: GitHub Commit caf705f

Detection Methods for CVE-2026-41056

Indicators of Compromise

• Unusual cross-origin requests to plugin/API/get.json.php or plugin/API/set.json.php endpoints from unfamiliar referrers
• Access logs showing API requests with Origin headers from external domains followed by successful authenticated responses
• Multiple API requests originating from the same user session but different Origin headers
• Reports of unauthorized account modifications or livestream key changes without user action

Detection Strategies

• Monitor web server access logs for requests to API endpoints (get.json.php, set.json.php) containing external Origin headers
• Implement alerting for authenticated API responses that include Access-Control-Allow-Credentials: true with non-whitelisted origins
• Review session activity logs for users accessing sensitive endpoints from multiple distinct origins within short timeframes
• Deploy web application firewall (WAF) rules to detect and log suspicious cross-origin request patterns

Monitoring Recommendations

• Enable detailed logging for all CORS-related response headers on API endpoints
• Configure SIEM rules to correlate user authentication events with cross-origin API access patterns
• Monitor for bulk data exfiltration patterns through API endpoints that could indicate active exploitation
• Implement real-time alerting for livestream key access from unusual geographic locations or IP addresses

How to Mitigate CVE-2026-41056

Immediate Actions Required

• Update WWBN AVideo to a version containing commit caf705f38eae0ccfac4c3af1587781355d24495e or later
• Audit existing CORS configurations in objects/functions.php to ensure proper origin validation
• Invalidate existing session tokens and force re-authentication for all users as a precautionary measure
• Review audit logs for potential exploitation indicators and notify affected users if data exposure is suspected

Patch Information

The vulnerability has been addressed in commit caf705f38eae0ccfac4c3af1587781355d24495e. The fix enhances CORS security by validating origins for credentialed requests. Instead of reflecting arbitrary origins with credentials, the patched code now validates that the requesting origin matches the configured site origin before allowing credentialed responses. Third-party origins receive wildcard (*) CORS headers without credentials, which maintains compatibility for public resources while preventing credential theft.

For detailed patch information, see the GitHub Security Advisory and commit details.

Workarounds

• If immediate patching is not possible, modify objects/functions.php to implement a strict origin whitelist that only allows your application's domain
• Configure a reverse proxy or WAF to strip or validate the Access-Control-Allow-Credentials header from API responses
• Consider temporarily disabling the SameSite=None cookie policy if it does not break critical functionality
• Implement additional authentication mechanisms such as API tokens for sensitive operations instead of relying solely on session cookies

# Example: Apache configuration to restrict CORS headers
# Add to .htaccess or virtual host configuration
<Location "/plugin/API/">
    Header always unset Access-Control-Allow-Credentials
    Header always set Access-Control-Allow-Origin "https://your-avideo-domain.com"
</Location>