AVideo's Meet plugin: uploadRecordedVideo.json.php derives users_id from the uploaded filename and calls passwordless User->login(), allowing any caller with the Meet shared secret to obtain a session as arbitrary users including admin
Summary
Type: Authorization-bypass via user-controlled identifier. The Meet plugin's recorded-video upload endpoint (plugin/Meet/uploadRecordedVideo.json.php) authenticates the caller using a single shared Authorization: Bearer <secret> against $objM->secret. Once that check passes, the endpoint reads the *target user identifier* from the uploaded file's name field, instantiates a User object with that ID, and calls $userObject->login(true, true) — the no-password / encoded-password login path — committing a session for that user and emitting Set-Cookie headers to the caller. There is no check that the caller actually owns the requested users_id.
File: plugin/Meet/uploadRecordedVideo.json.php, lines 56-65; secondary in objects/user.php User::login() (no-password branch at lines 1276-1310).
Root cause: the upload handler's identity model is "service-to-service" (a Meet/Jitsi recorder posts a finished recording back to AVideo with the shared secret) but the users_id to credit the upload to is parsed from the FILENAME the same caller controls — $users_id = explode('-', $_FILES['upl']['name'])[0];. There is no signed claim, no separate proof-of-identity, no allowlist. The subsequent $userObject->login(true, true) call invokes the no-password login path which sets $_SESSION['user'], calls setUserCookie(...), and _session_regenerate_id() — exactly the operations a normal login performs. The response carries the new PHPSESSID back to the caller, who can then reuse it on every subsequent request to act as the targeted user. The Meet shared secret is md5($global['systemRootPath'] . $global['salt'] . "meet") (Meet.php:73), so any attacker who can read videos/configuration.php (e.g., via a path-traversal CVE such as GHSA-83xq-8jxj-4rxm or GHSA-4wmm-6qxj-fpj4 that the project has already addressed in this surface area) can compute the Meet secret deterministically and pivot to full account takeover.
Affected Code
File: plugin/Meet/uploadRecordedVideo.json.php, lines 33-73.
```php
if (empty($token)) {
forbiddenPage('Token not found');
}
$objM = AVideoPlugin::getObjectDataIfEnabled("Meet");
if (empty($objM)) {
forbiddenPage('Plugin disabled');
}
if ($objM->secret != $token) { // <-- shared-secret auth, no per-user proof
forbiddenPage('Token does not match');
}
if (empty($_FILES['upl'])) {
forbiddenPage('videoFile not found');
}
$users_id = explode('-', $_FILES['upl']['name'])[0]; // <-- BUG: target users_id parsed from attacker-controlled filename
$userObject = new User($users_id);
$userObject->login(true, true); // <-- BUG: passwordless login as the chosen user; sets $_SESSION + Set-Cookie
$tmpFile = getTmpDir() . uniqid();
if (move_uploaded_file($_FILES['upl']['tmp_name'], $tmpFile)) {
$_FILES['upl']['tmp_name'] = $tmpFile;
require $global['systemRootPath'] . 'objects/aVideoQueueEncoder.json.php';
}
```
File: objects/user.php, lines 1249-1329 (User::login() no-password branch).
```php
public function login($noPass = false, $encodedPass = false, $ignoreEmailVerification = false)
{
// ...
if ($noPass) {
$user = $this->find($this->user, false, true); // <-- no password check
}
// ...
} elseif ($user) {
$_SESSION['user'] = $user; // <-- session set for the impersonated user
$this->setLastLogin($_SESSION['user']['id']);
// ...
self::setUserCookie($rememberme, $user['id'], $user['user'], $passhash, $expires);
AVideoPlugin::onUserSignIn($_SESSION['user']['id']);
$_SESSION['loginAttempts'] = 0;
_session_regenerate_id(); // <-- new SID committed in Set-Cookie response
_session_write_close();
return self::USER_LOGGED;
}
}
```
Why it's wrong: the endpoint conflates two distinct authentication concerns. The shared-secret check answers "is this request coming from a trusted Meet recorder?" but the filename parse answers "which user does this recording belong to?" — and the second answer is taken from the same untrusted caller. Once User->login(true, true) runs, the server has no way to distinguish a legitimate Meet integration from an attacker who happens to know the same secret. The decision to expose this as a session (cookie + _session_regenerate_id) rather than as a one-shot in-process credit makes the impact larger than it needs to be: even if the Meet integration only needed to *credit* the recording to a user, the implementation gives the caller a fully-authenticated session as that user.
Exploit Chain
1. Attacker obtains the Meet shared sec
