GHSA-3MV2-VMWH-RWFX
Vulnerability from github – Published: 2026-05-15 18:34 – Updated: 2026-05-15 18:34Summary
Type: Cross-site request forgery on the 2FA toggle. plugin/LoginControl/set.json.php accepts POST type=set2FA value=false, calls LoginControl::setUser2FA(User::getId(), false) on the session-authenticated user, and returns. There is no forbidIfIsUntrustedRequest() call, no isTokenValid() check, no X-CSRF-Token/SameSite enforcement, and no re-authentication step. A cross-origin page that the victim visits while logged into the AVideo dashboard issues the POST via a hidden form (or fetch without credentials:"omit") and disables the victim's 2FA in one request. The next phishing/credential-stuffing attempt against that account no longer needs the second factor.
File: plugin/LoginControl/set.json.php, lines 1-37.
Root cause: the developer relied on the User::isLogged() check at line 9 as the only auth, then dispatched directly into LoginControl::setUser2FA(User::getId(), $value=='true'). Other AVideo state-changing endpoints in the same codebase (videoUpdateUsage.json.php, videoStatus.json.php, videoRotate.json.php, etc.) call forbidIfIsUntrustedRequest('<name>') to compare Origin/Referer against the AVideo domain; this endpoint simply omits the call. The session cookie carries the user's identity on every cross-origin POST, so any attacker page can speak for the logged-in user on this endpoint.
Affected Code
File: plugin/LoginControl/set.json.php, lines 1-37.
<?php
require_once '../../videos/configuration.php';
_session_write_close();
header('Content-Type: application/json');
$obj = new stdClass();
$obj->error = true;
$obj->msg = "";
if (!User::isLogged()) {
$obj->msg = "Not logged";
die(json_encode($obj));
}
if (empty($_POST['type'])) {
$obj->msg = "Type is empty";
die(json_encode($obj));
}
if (!isset($_POST['value'])) {
$obj->msg = "value is empty";
die(json_encode($obj));
}
$cu = AVideoPlugin::loadPluginIfEnabled('LoginControl');
if (empty($cu)) {
$obj->msg = "Plugin not enabled";
die(json_encode($obj));
}
$obj->error = false;
switch ($_POST['type']) {
case 'set2FA':
LoginControl::setUser2FA(User::getId(), $_POST['value']=="true" ? true : false); // <-- BUG: no CSRF gate, no re-auth
break;
}
die(json_encode($obj));
Why it's wrong: disabling a victim's second factor is exactly the kind of state change the AVideo CSRF helper forbidIfIsUntrustedRequest() exists to protect. Compare with objects/comments_like.json.php:18 (forbidIfIsUntrustedRequest('comments_like')) — comments-likes get CSRF protection, but the 2FA toggle does not. Beyond CSRF, security-sensitive toggles like 2FA-disable conventionally also require either the current 2FA code or a password re-prompt: a malicious browser extension, an XSS that lands in any AVideo subdomain, or a compromised tab can otherwise flip the bit silently. None of those mitigations exist here.
Exploit Chain
- Attacker hosts
https://attacker.example/avideo-2fa-off.htmlcontaining: ```html
``
State: page is live and indexable.
2. Attacker delivers the page to a victim who is logged in toavideo.example(open redirect on a trusted partner, ad campaign, IM phishing link, encyclopedic-looking forum post). The victim's browser opens the page; the form auto-submits to AVideo. State: cross-origin POST hitsset.json.phpwith the victim's session cookie attached (the cookie'sSameSiteattribute is set toLax/Noneby AVideo's defaults so the cross-origin POST succeeds for top-level navigations).
3.set.json.php:9confirmsUser::isLogged()(true, victim's session is valid). Lines 13-19 seetype=set2FA,value=false. Line 30-32 callsLoginControl::setUser2FA(victim_user_id, false)and persists the change. State: victim's 2FA is now disabled inusers.externalOptions.LoginControl.is2FAEnabled.
4. Victim sees a generic "operation completed" JSON response in a redirected browser tab (or no visible feedback at all if the form lands in aniframe). State: victim notices nothing unusual.
5. Attacker (in a separate session) attempts credential stuffing or password-spray againstavideo.example/objects/login.json.php`. Without the second factor, any one of: a previously leaked password, a successful credential-stuffing match, or a spear-phishing-collected password completes the login. State: attacker holds full session for victim's account.
6. Final state: the second factor that the victim explicitly enabled was silently disabled across the wire by visiting an attacker-hosted page. The whole chain takes one HTTP POST and zero clicks beyond the initial visit.
Security Impact
Severity: sec-moderate. CVSS 6.5: network attack, low complexity, low privileges (the attacker themselves are unauthenticated; the victim must be a logged-in AVideo user; this is captured by PR:L because the action's effect requires the victim's session), user interaction required (visit attacker page), scope unchanged, no confidentiality directly, high integrity (the victim's 2FA configuration is silently corrupted), no availability claim.
Attacker capability: with one cross-origin POST, the attacker turns a victim's 2FA-protected account into a plain password-only account. Combined with any password leak, credential-stuffing match, or successful phishing of the password, the account is fully compromised. The change is permanent until the victim notices and re-enables 2FA, and AVideo does not raise an audit-log event when 2FA is disabled (see LoginControl::setUser2FA — it simply writes the boolean), so detection is unlikely.
Preconditions: AVideo deployment with the LoginControl plugin enabled (the plugin shipping the 2FA feature); the victim is logged in to AVideo at the moment they visit the attacker page; the AVideo session cookie does not have SameSite=Strict (the deployment default is SameSite=Lax per objects/phpsessionid.json.php:53, which still allows cross-origin top-level POSTs from a form auto-submit).
Differential: source-inspection-verified. set.json.php does not contain forbidIfIsUntrustedRequest, isTokenValid, verifyToken, or any equivalent string; the entire body of the file is reproduced above. With the suggested fix below, the same cross-origin POST returns a 403 with Invalid Request and the setUser2FA call never fires.
Suggested Fix
Add the same CSRF gate every other state-changing endpoint in this codebase uses, and require the current 2FA code (or a password re-prompt) when the user is disabling the second factor.
--- a/plugin/LoginControl/set.json.php
+++ b/plugin/LoginControl/set.json.php
@@ -9,6 +9,8 @@
if (!User::isLogged()) {
$obj->msg = "Not logged";
die(json_encode($obj));
}
+forbidIfIsUntrustedRequest('LoginControl-set');
+
if (empty($_POST['type'])) {
$obj->msg = "Type is empty";
die(json_encode($obj));
@@ -28,7 +30,15 @@
$obj->error = false;
switch ($_POST['type']) {
case 'set2FA':
- LoginControl::setUser2FA(User::getId(), $_POST['value']=="true" ? true : false);
+ $newValue = ($_POST['value'] == 'true');
+ // Require the current 2FA code (or a password re-prompt) when DISABLING 2FA;
+ // turning it on is fine, turning it off needs a step-up.
+ if (!$newValue && !LoginControl::confirmStepUpForCurrentUser($_POST['confirm'] ?? '')) {
+ $obj->error = true;
+ $obj->msg = __('Re-authentication required to disable 2FA');
+ die(json_encode($obj));
+ }
+ LoginControl::setUser2FA(User::getId(), $newValue);
break;
}
Defence-in-depth: the AVideo session cookie should be issued with SameSite=Strict for the management dashboard's first-party POSTs; the public read-only player can keep a separate SameSite=Lax cookie. Audit-log every 2FA-disable event with the source IP and user agent so an unexpected disable is visible to the operator.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "WWBN/AVideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "29.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45610"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-15T18:34:57Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n**Type:** Cross-site request forgery on the 2FA toggle. `plugin/LoginControl/set.json.php` accepts `POST type=set2FA value=false`, calls `LoginControl::setUser2FA(User::getId(), false)` on the session-authenticated user, and returns. There is no `forbidIfIsUntrustedRequest()` call, no `isTokenValid()` check, no `X-CSRF-Token`/`SameSite` enforcement, and no re-authentication step. A cross-origin page that the victim visits while logged into the AVideo dashboard issues the POST via a hidden form (or `fetch` without `credentials:\"omit\"`) and disables the victim\u0027s 2FA in one request. The next phishing/credential-stuffing attempt against that account no longer needs the second factor.\n**File:** `plugin/LoginControl/set.json.php`, lines 1-37.\n**Root cause:** the developer relied on the `User::isLogged()` check at line 9 as the only auth, then dispatched directly into `LoginControl::setUser2FA(User::getId(), $value==\u0027true\u0027)`. Other AVideo state-changing endpoints in the same codebase (`videoUpdateUsage.json.php`, `videoStatus.json.php`, `videoRotate.json.php`, etc.) call `forbidIfIsUntrustedRequest(\u0027\u003cname\u003e\u0027)` to compare `Origin`/`Referer` against the AVideo domain; this endpoint simply omits the call. The session cookie carries the user\u0027s identity on every cross-origin POST, so any attacker page can speak for the logged-in user on this endpoint.\n\n## Affected Code\n\n**File:** `plugin/LoginControl/set.json.php`, lines 1-37.\n\n```php\n\u003c?php\nrequire_once \u0027../../videos/configuration.php\u0027;\n_session_write_close();\nheader(\u0027Content-Type: application/json\u0027);\n\n$obj = new stdClass();\n$obj-\u003eerror = true;\n$obj-\u003emsg = \"\";\nif (!User::isLogged()) {\n $obj-\u003emsg = \"Not logged\";\n die(json_encode($obj));\n}\nif (empty($_POST[\u0027type\u0027])) {\n $obj-\u003emsg = \"Type is empty\";\n die(json_encode($obj));\n}\nif (!isset($_POST[\u0027value\u0027])) {\n $obj-\u003emsg = \"value is empty\";\n die(json_encode($obj));\n}\n\n$cu = AVideoPlugin::loadPluginIfEnabled(\u0027LoginControl\u0027);\n\nif (empty($cu)) {\n $obj-\u003emsg = \"Plugin not enabled\";\n die(json_encode($obj));\n}\n\n$obj-\u003eerror = false;\nswitch ($_POST[\u0027type\u0027]) {\n case \u0027set2FA\u0027:\n LoginControl::setUser2FA(User::getId(), $_POST[\u0027value\u0027]==\"true\" ? true : false); // \u003c-- BUG: no CSRF gate, no re-auth\n break;\n}\n\ndie(json_encode($obj));\n```\n\n**Why it\u0027s wrong:** disabling a victim\u0027s second factor is exactly the kind of state change the AVideo CSRF helper `forbidIfIsUntrustedRequest()` exists to protect. Compare with `objects/comments_like.json.php:18` (`forbidIfIsUntrustedRequest(\u0027comments_like\u0027)`) \u2014 comments-likes get CSRF protection, but the 2FA toggle does not. Beyond CSRF, security-sensitive toggles like 2FA-disable conventionally also require either the current 2FA code or a password re-prompt: a malicious browser extension, an XSS that lands in any AVideo subdomain, or a compromised tab can otherwise flip the bit silently. None of those mitigations exist here.\n\n## Exploit Chain\n\n1. Attacker hosts `https://attacker.example/avideo-2fa-off.html` containing:\n ```html\n \u003cform id=\"f\" action=\"https://avideo.example/plugin/LoginControl/set.json.php\" method=\"POST\"\u003e\n \u003cinput type=\"hidden\" name=\"type\" value=\"set2FA\"\u003e\n \u003cinput type=\"hidden\" name=\"value\" value=\"false\"\u003e\n \u003c/form\u003e\n \u003cscript\u003edocument.getElementById(\u0027f\u0027).submit();\u003c/script\u003e\n ```\n State: page is live and indexable.\n2. Attacker delivers the page to a victim who is logged in to `avideo.example` (open redirect on a trusted partner, ad campaign, IM phishing link, encyclopedic-looking forum post). The victim\u0027s browser opens the page; the form auto-submits to AVideo. State: cross-origin POST hits `set.json.php` with the victim\u0027s session cookie attached (the cookie\u0027s `SameSite` attribute is set to `Lax`/`None` by AVideo\u0027s defaults so the cross-origin POST succeeds for top-level navigations).\n3. `set.json.php:9` confirms `User::isLogged()` (true, victim\u0027s session is valid). Lines 13-19 see `type=set2FA`, `value=false`. Line 30-32 calls `LoginControl::setUser2FA(victim_user_id, false)` and persists the change. State: victim\u0027s 2FA is now disabled in `users.externalOptions.LoginControl.is2FAEnabled`.\n4. Victim sees a generic \"operation completed\" JSON response in a redirected browser tab (or no visible feedback at all if the form lands in an `iframe`). State: victim notices nothing unusual.\n5. Attacker (in a separate session) attempts credential stuffing or password-spray against `avideo.example/objects/login.json.php`. Without the second factor, any one of: a previously leaked password, a successful credential-stuffing match, or a spear-phishing-collected password completes the login. State: attacker holds full session for victim\u0027s account.\n6. Final state: the second factor that the victim explicitly enabled was silently disabled across the wire by visiting an attacker-hosted page. The whole chain takes one HTTP POST and zero clicks beyond the initial visit.\n\n## Security Impact\n\n**Severity:** sec-moderate. CVSS 6.5: network attack, low complexity, low privileges (the attacker themselves are unauthenticated; the victim must be a logged-in AVideo user; this is captured by `PR:L` because the action\u0027s effect requires the victim\u0027s session), user interaction required (visit attacker page), scope unchanged, no confidentiality directly, high integrity (the victim\u0027s 2FA configuration is silently corrupted), no availability claim.\n**Attacker capability:** with one cross-origin POST, the attacker turns a victim\u0027s 2FA-protected account into a plain password-only account. Combined with any password leak, credential-stuffing match, or successful phishing of the password, the account is fully compromised. The change is permanent until the victim notices and re-enables 2FA, and AVideo does not raise an audit-log event when 2FA is disabled (see `LoginControl::setUser2FA` \u2014 it simply writes the boolean), so detection is unlikely.\n**Preconditions:** AVideo deployment with the `LoginControl` plugin enabled (the plugin shipping the 2FA feature); the victim is logged in to AVideo at the moment they visit the attacker page; the AVideo session cookie does not have `SameSite=Strict` (the deployment default is `SameSite=Lax` per `objects/phpsessionid.json.php:53`, which still allows cross-origin top-level POSTs from a form auto-submit).\n**Differential:** source-inspection-verified. `set.json.php` does not contain `forbidIfIsUntrustedRequest`, `isTokenValid`, `verifyToken`, or any equivalent string; the entire body of the file is reproduced above. With the suggested fix below, the same cross-origin POST returns a 403 with `Invalid Request` and the `setUser2FA` call never fires.\n\n## Suggested Fix\n\nAdd the same CSRF gate every other state-changing endpoint in this codebase uses, and require the current 2FA code (or a password re-prompt) when the user is *disabling* the second factor.\n\n```diff\n--- a/plugin/LoginControl/set.json.php\n+++ b/plugin/LoginControl/set.json.php\n@@ -9,6 +9,8 @@\n if (!User::isLogged()) {\n $obj-\u003emsg = \"Not logged\";\n die(json_encode($obj));\n }\n+forbidIfIsUntrustedRequest(\u0027LoginControl-set\u0027);\n+\n if (empty($_POST[\u0027type\u0027])) {\n $obj-\u003emsg = \"Type is empty\";\n die(json_encode($obj));\n@@ -28,7 +30,15 @@\n $obj-\u003eerror = false;\n switch ($_POST[\u0027type\u0027]) {\n case \u0027set2FA\u0027:\n- LoginControl::setUser2FA(User::getId(), $_POST[\u0027value\u0027]==\"true\" ? true : false);\n+ $newValue = ($_POST[\u0027value\u0027] == \u0027true\u0027);\n+ // Require the current 2FA code (or a password re-prompt) when DISABLING 2FA;\n+ // turning it on is fine, turning it off needs a step-up.\n+ if (!$newValue \u0026\u0026 !LoginControl::confirmStepUpForCurrentUser($_POST[\u0027confirm\u0027] ?? \u0027\u0027)) {\n+ $obj-\u003eerror = true;\n+ $obj-\u003emsg = __(\u0027Re-authentication required to disable 2FA\u0027);\n+ die(json_encode($obj));\n+ }\n+ LoginControl::setUser2FA(User::getId(), $newValue);\n break;\n }\n```\n\nDefence-in-depth: the AVideo session cookie should be issued with `SameSite=Strict` for the management dashboard\u0027s first-party POSTs; the public read-only player can keep a separate `SameSite=Lax` cookie. Audit-log every 2FA-disable event with the source IP and user agent so an unexpected disable is visible to the operator.",
"id": "GHSA-3mv2-vmwh-rwfx",
"modified": "2026-05-15T18:34:57Z",
"published": "2026-05-15T18:34:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-3mv2-vmwh-rwfx"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo: 2FA toggle endpoint has no CSRF protection, letting an attacker page silently disable a logged-in victim\u0027s 2FA"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.