GHSA-x3pr-vrhq-vq43 CVE-2026-33492
AVideo has Session Fixation via GET PHPSESSID Parameter With Disabled Login Session Regeneration
- Severity
- 7.3 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.30%
- Chance of exploitation in the next 30 days. Higher than 22.91% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-384 Session Fixation
- Fix
- None yet
- No fixed version published
Description
Summary
AVideo's _session_start() 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)
function _session_start(array $options = [])
{
// ...
if (isset($_GET['PHPSESSID']) && !_empty($_GET['PHPSESSID'])) {
$PHPSESSID = $_GET['PHPSESSID'];
// ...
if (!User::isLogged()) {
if ($PHPSESSID !== session_id()) {
_session_write_close();
session_id($PHPSESSID); // <-- sets session to attacker's ID
}
$session = @session_start($options); // <-- starts with attacker's ID
The code reads $_GET['PHPSESSID'] and programmatically calls session_id($PHPSESSID), which bypasses both session.use_only_cookies and session.use_strict_mode 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)
// functionsPHP.php:375-378
if (!blackListRegenerateSession()) {
_session_regenerate_id(); // <-- SKIPPED when blacklisted + same-domain
}
// 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 (str_ends_with($_SERVER['SCRIPT_NAME'], $needle)) {
return true; // <-- regeneration skipped for these endpoints
}
}
return false;
}
The requestComesFromSafePlace() check at objects/functionsSecurity.php:182 only verifies that HTTP_REFERER 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)
// Call custom session regenerate logic
// this was regenerating the session all the time, making harder to save info in the session
//_session_regenerate_id(); // <-- 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.phpexposes session IDs to any same-origin JavaScript without authentication (line 12:$obj->phpsessid = session_id())view/js/session.jsstores the session ID in a globalwindow.PHPSESSIDvariable 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
# 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=attacker_known_session_id; ...
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=attacker_known_session_id
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:
- Browser sets
Referer: https://target.example.com/...(same-domain) _session_start()processes$_GET['PHPSESSID'], victim is not logged in, sosession_id('attacker_known_session_id')is calledblackListRegenerateSession()returnstrue(script isgetCaptcha.php+ same-domain Referer)_session_regenerate_id()is skipped- Victim's session is now fixed to
attacker_known_session_id
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
# Attacker uses the known session ID to access victim's account
curl -b "PHPSESSID=attacker_known_session_id" 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)
// Replace the commented-out line:
//_session_regenerate_id();
// With:
_session_regenerate_id();
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:
// 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.
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| wwbn/avideo | <= 26.0 |
No fix yet |
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 7.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-384: Session Fixation
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
How to prevent it
- Architecture and Design: Invalidate any existing session identifiers prior to authorizing a new user session.
- Architecture and Design: For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7cqp-7cfv-6c3q AVideo Meet plugin: anonymous-to-admin stored XSS via unescaped participant User-Agent in getMeetInfo.json.php Participants panel | Medium | Also affects wwbn/avideo |
| GHSA-wc3f-xc32-435f AVideo has an incomplete fix of CVE-2026-33482: sanitizeFFmpegCommand still allows a single '&' (background operator), giving OS command execution at the same execAsync sh -c sink | High | Also affects wwbn/avideo |
| GHSA-95jh-7r58-xmxw AVideo has an Authorize.Net Webhook Signature Bypass that Enables Wallet Balance Inflation via Forged Payment Data | Medium | Also affects wwbn/avideo |
| GHSA-wf69-r4mx-43rr AVideo Vulnerable to Unauthenticated .env File Exposure via Official Docker Compose Configuration | High | Also affects wwbn/avideo |
| GHSA-8j8m-p79x-g4jm AVideo's Privilege Escalation via Unguarded Permission Parameters in signUp API Allows Self-Granting Upload/Stream/Meet Permissions | Medium | Also affects wwbn/avideo |
| GHSA-8whc-2wmv-ww35 WWBN AVideo: Unauthenticated Stored DOM Cross-Site Scripting via Per-Client Metadata Broadcast in YPTSocket Plugin | Critical | Also affects WWBN/AVideo |
| GHSA-66q5-cj5g-wrfx WWBN AVideo: Stored XSS via Hostile YouTube Video Title in AVideo YouTubeAPI Gallery Section | Medium | Also affects WWBN/AVideo |
| GHSA-hgjh-6wj8-gcgf WWBN AVideo: Unauthenticated Reflected XSS via $_GET['search'] in AVideo YouTubeAPI Gallery Pagination | Medium | Also affects WWBN/AVideo |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor