CVE-2026-33492: AVideo has Session Fixation via GET PHPSESSID Parameter With Disabled Login Session Regeneration

Published Mar 20, 2026
·
Updated

Summary

AVideo's sessionstart() function accepts arbitrary session IDs via the PHPSESSID GET parameter and sets them as the active PHP session. A session regeneration bypass exists for specific blacklisted endpoints when the request originates from the same domain. Combined with the explicitly disabled session regeneration in User::login(), this allows a classic session fixation attack where an attacker can fix a victim's session ID before authentication and then hijack the authenticated session.

Details

The vulnerability is a chain of three weaknesses that together enable session fixation:

1. Attacker-controlled session ID acceptance (objects/functionsPHP.php:344-367)

php function sessionstart(array $options = []) { // ... if (isset($GET['PHPSESSID']) && !empty($GET['PHPSESSID'])) { $PHPSESSID = $GET['PHPSESSID']; // ... if (!User::isLogged()) { if ($PHPSESSID !== sessionid()) { sessionwriteclose(); sessionid($PHPSESSID); // <-- sets session to attacker's ID } $session = @sessionstart($options); // <-- starts with attacker's ID

The code reads $GET['PHPSESSID'] and programmatically calls sessionid($PHPSESSID), which bypasses both session.useonlycookies and session.usestrictmode PHP settings since the session ID is set via the PHP API, not via cookie/URL handling.

2. Session regeneration bypass for blacklisted endpoints (objects/functionsPHP.php:375-378, objects/functions.php:3100-3116)

php // functionsPHP.php:375-378 if (!blackListRegenerateSession()) { sessionregenerateid(); // <-- SKIPPED when blacklisted + same-domain }

php // functions.php:3100-3116 function blackListRegenerateSession() { if (!requestComesFromSafePlace()) { return false; } $list = [ 'objects/getCaptcha.php', 'objects/userCreate.json.php', 'objects/videoAddViewCount.json.php', ]; foreach ($list as $needle) { if (strendswith($SERVER['SCRIPTNAME'], $needle)) { return true; // <-- regeneration skipped for these endpoints } } return false; }

The requestComesFromSafePlace() check at objects/functionsSecurity.php:182 only verifies that HTTPREFERER matches the AVideo domain. When a victim clicks a link from within the AVideo platform (e.g., in a comment or video description), the browser naturally sets the Referer to the AVideo domain, satisfying this check.

3. Disabled session regeneration on login (objects/user.php:1315-1317)

php // Call custom session regenerate logic // this was regenerating the session all the time, making harder to save info in the session //sessionregenerateid(); // <-- COMMENTED OUT

The session regeneration after authentication is explicitly disabled. This means the session ID persists unchanged through the login transition, which is the fundamental requirement for session fixation to succeed.

Amplifying factors

- objects/phpsessionid.json.php exposes session IDs to any same-origin JavaScript without authentication (line 12: $obj->phpsessid = sessionid()) - view/js/session.js stores the session ID in a global window.PHPSESSID variable and logs it to console (line 15) - No session-to-IP or session-to-user-agent binding exists (verified via codebase search)

PoC

Step 1: Attacker obtains a session ID

bash Attacker visits the site to get a valid session ID curl -v https://target.example.com/ 2>&1 | grep 'set-cookie.PHPSESSID' Response: Set-Cookie: PHPSESSID=attackerknownsessionid; ...

Step 2: Attacker injects a link on the platform

The attacker posts a comment on a video or creates content containing a link:

https://target.example.com/objects/getCaptcha.php?PHPSESSID=attackerknownsessionid

This can be placed in a video comment, video description, user bio, or forum post — anywhere AVideo renders user-provided links.

Step 3: Victim clicks the link while browsing AVideo

When the victim clicks the link from within the AVideo platform: 1. Browser sets Referer: https://target.example.com/... (same-domain) 2. sessionstart() processes $GET['PHPSESSID'], victim is not logged in, so sessionid('attackerknownsessionid') is called 3. blackListRegenerateSession() returns true (script is getCaptcha.php + same-domain Referer) 4. sessionregenerateid() is skipped 5. Victim's session is now fixed to attackerknownsessionid

Step 4: Victim logs in

The victim navigates to the login page and authenticates. User::login() populates $SESSION['user'] but does NOT regenerate the session ID (line 1317 is commented out).

Step 5: Attacker hijacks the authenticated session

bash Attacker uses the known session ID to access victim's account curl -b "PHPSESSID=attackerknownsessionid" https://target.example.com/objects/user.php?userAPI=1 Response: victim's user data, confirming session hijack

Impact

- Full account takeover: An attacker can hijack any user's authenticated session, including administrator accounts - Data access: Full access to the victim's videos, private content, messages, and personal information - Privilege escalation: If the victim is an admin, the attacker gains full administrative control over the AVideo instance - Lateral actions: The attacker can perform any action as the victim — upload/delete content, modify settings, access admin panel

Recommended Fix

Fix 1: Re-enable session regeneration on login (objects/user.php:1317)

php // Replace the commented-out line: //sessionregenerateid();

// With: sessionregenerateid();

This is the most critical fix. Session regeneration on authentication transition is a fundamental defense against session fixation (OWASP recommendation).

Fix 2: Remove GET-based session ID acceptance (objects/functionsPHP.php:344-383)

Remove or restrict the $GET['PHPSESSID'] handling entirely. If it is needed for specific use cases (e.g., CAPTCHA), validate the session ID against a server-side token rather than blindly accepting arbitrary values:

php // Instead of accepting any GET PHPSESSID, remove this block entirely. // If CAPTCHA requires session continuity, pass a CSRF token instead. if (isset($GET['PHPSESSID']) && !empty($GET['PHPSESSID'])) { // REMOVED: Do not accept session IDs from URL parameters }

Fix 3: Remove session ID exposure (objects/phpsessionid.json.php, view/js/session.js)

The phpsessionid.json.php endpoint and the session.js global variable negate the httponly cookie flag. If JavaScript needs to reference the session for AJAX requests, the browser automatically includes session cookies — there is no need to expose the session ID value to JavaScript.

Other sources

WWBN AVideo is an open source video platform. In versions up to and including 26.0, AVideo's sessionstart() function accepts arbitrary session IDs via the PHPSESSID GET parameter and sets them as the active PHP session. A session regeneration bypass exists for specific blacklisted endpoints when the request originates from the same domain. Combined with the explicitly disabled session regeneration in User::login(), this allows a classic session fixation attack where an attacker can fix a victim's session ID before authentication and then hijack the authenticated session. Commit 5647a94d79bf69a972a86653fe02144079948785 contains a patch.

MITRE

Affected Software

2 affected components
composer/wwbn/avideo<=26.0
WWBN AVideo<=26.0

Event History

Mar 20, 2026
Advisory Published
via GitHub·08:49 PM
Data Sourced
via GitHub·08:49 PM
DescriptionSeverityWeaknessAffected Software
Mar 23, 2026
CVE Published
via MITRE·03:25 PM
Data Sourced
via MITRE·03:25 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·04:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Dec 26, 58199
Event
via FIRST·05:20 PM

Frequently Asked Questions

1

What must an attacker do to exploit this issue?

The attacker must cause the victim to use an attacker-chosen PHPSESSID value before the victim authenticates. The attack succeeds when the application retains that fixed session ID through login, allowing the attacker to use the same now-authenticated session.

2

Who is exposed to session takeover?

Users who authenticate after their session ID has been fixed by an attacker are exposed. The resulting impact is unauthorized access to the victim's authenticated session, with high confidentiality and integrity impact indicated by the supplied severity vector.

3

How can I determine whether my deployment contains the vulnerable behavior?

Inspect objects/functionsPHP.php for _session_start() accepting the PHPSESSID GET parameter and passing it to session_id(). Also verify whether User::login() has session regeneration disabled and whether the affected same-domain blacklist bypass is present.

4

What should be done to remediate the issue?

Apply the available vendor patch. The referenced upstream commit is 5647a94d79bf69a972a86653fe02144079948785.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203