Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

3465 vulnerabilities reference this CWE, most recent first.

GHSA-3JGF-VX5M-8PJM

Vulnerability from github – Published: 2023-06-02 12:30 – Updated: 2024-04-04 04:28
VLAI
Details

It is identified a vulnerability of insufficient authentication in the system configuration interface of Hitron Technologies CODA-5310. An unauthorized remote attacker can exploit this vulnerability to access system configuration interface, resulting in performing arbitrary system operation or disrupt service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-30604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T11:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "It is identified a vulnerability of insufficient authentication in the system configuration interface of Hitron Technologies CODA-5310. An unauthorized remote attacker can exploit this vulnerability to access system configuration interface, resulting in performing arbitrary system operation or disrupt service.",
  "id": "GHSA-3jgf-vx5m-8pjm",
  "modified": "2024-04-04T04:28:50Z",
  "published": "2023-06-02T12:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30604"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7086-35622-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3JQW-2342-VGXW

Vulnerability from github – Published: 2026-04-10 12:31 – Updated: 2026-04-10 12:31
VLAI
Details

This vulnerability exists in the Atom 3x Projector due to improper exposure of the Android Debug Bridge (ADB) service over the local network without authentication or access controls. An unauthenticated attacker on the same network can exploit this vulnerability to obtain root-level access, leading to complete compromise of the targeted device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5777"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-10T12:16:04Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in the Atom 3x Projector due to improper exposure of the Android Debug Bridge (ADB) service over the local network without authentication or access controls. An unauthenticated attacker on the same network can exploit this vulnerability to obtain root-level access, leading to complete compromise of the targeted device.",
  "id": "GHSA-3jqw-2342-vgxw",
  "modified": "2026-04-10T12:31:44Z",
  "published": "2026-04-10T12:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5777"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2026-0179"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3JRC-J5P2-V7XJ

Vulnerability from github – Published: 2025-03-27 15:31 – Updated: 2025-03-27 15:31
VLAI
Details

IBM UrbanCode Deploy (UCD) 7.1 through 7.1.2.22, 7.2 through 7.2.3.15, and 7.3 through 7.3.2.10 / IBM DevOps Deploy 8.0 through 8.0.1.5 and 8.1 through 8.1.0.1 could allow unauthorized access to other services or potential exposure of sensitive data due to missing authentication in its Agent Relay service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-56469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-27T15:15:53Z",
    "severity": "MODERATE"
  },
  "details": "IBM UrbanCode Deploy (UCD) 7.1 through 7.1.2.22, 7.2 through 7.2.3.15, and 7.3 through 7.3.2.10 / IBM DevOps Deploy 8.0 through 8.0.1.5 and 8.1 through 8.1.0.1 could allow unauthorized access to other services or potential exposure of sensitive data due to missing authentication in its Agent Relay service.",
  "id": "GHSA-3jrc-j5p2-v7xj",
  "modified": "2025-03-27T15:31:10Z",
  "published": "2025-03-27T15:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56469"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7229031"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3JVJ-F4F8-9HP2

Vulnerability from github – Published: 2025-08-08 18:32 – Updated: 2025-08-08 18:32
VLAI
Details

By default, the Packet Power Monitoring and Control Web Interface do not enforce authentication mechanisms. This vulnerability could allow unauthorized users to access and manipulate monitoring and control functions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-8284"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-08T17:15:30Z",
    "severity": "CRITICAL"
  },
  "details": "By default, the Packet Power Monitoring and Control Web Interface do not\n enforce authentication mechanisms. This vulnerability could allow \nunauthorized users to access and manipulate monitoring and control \nfunctions.",
  "id": "GHSA-3jvj-f4f8-9hp2",
  "modified": "2025-08-08T18:32:22Z",
  "published": "2025-08-08T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8284"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-219-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3M2R-MJF7-5QHP

Vulnerability from github – Published: 2023-02-01 06:30 – Updated: 2023-02-08 21:30
VLAI
Details

A CWE-306: Missing Authentication for Critical Function The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. Affected Products: APC Easy UPS Online Monitoring Software (Windows 7, 10, 11 & Windows Server 2016, 2019, 2022 - Versions prior to V2.5-GA), APC Easy UPS Online Monitoring Software (Windows 11, Windows Server 2019, 2022 - Versions prior to V2.5-GA-01-22261), Schneider Electric Easy UPS Online Monitoring Software (Windows 7, 10, 11 & Windows Server 2016, 2019, 2022 - Versions prior to V2.5-GS), Schneider Electric Easy UPS Online Monitoring Software (Windows 11, Windows Server 2019, 2022 - Versions prior to V2.5-GS-01-22261)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-42970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-01T04:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A CWE-306: Missing Authentication for Critical Function The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. Affected Products: APC Easy UPS Online Monitoring Software (Windows 7, 10, 11 \u0026 Windows Server 2016, 2019, 2022 - Versions prior to V2.5-GA), APC Easy UPS Online Monitoring Software (Windows 11, Windows Server 2019, 2022 - Versions prior to V2.5-GA-01-22261), Schneider Electric Easy UPS Online Monitoring Software (Windows 7, 10, 11 \u0026 Windows Server 2016, 2019, 2022 - Versions prior to V2.5-GS), Schneider Electric Easy UPS Online Monitoring Software (Windows 11, Windows Server 2019, 2022 - Versions prior to V2.5-GS-01-22261)",
  "id": "GHSA-3m2r-mjf7-5qhp",
  "modified": "2023-02-08T21:30:20Z",
  "published": "2023-02-01T06:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42970"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_SEVD-2022-347-01\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2022-347-01_Easy_UPS_Online_Monitoring_Software_Security_Notification.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3M56-P87C-39JP

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:36
VLAI
Details

RouterOS versions 6.45.6 Stable, 6.44.5 Long-term, and below allow remote unauthenticated attackers to trigger DNS queries via port 8291. The queries are sent from the router to a server of the attacker's choice. The DNS responses are cached by the router, potentially resulting in cache poisoning

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-29T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "RouterOS versions 6.45.6 Stable, 6.44.5 Long-term, and below allow remote unauthenticated attackers to trigger DNS queries via port 8291. The queries are sent from the router to a server of the attacker\u0027s choice. The DNS responses are cached by the router, potentially resulting in cache poisoning",
  "id": "GHSA-3m56-p87c-39jp",
  "modified": "2024-04-04T02:36:05Z",
  "published": "2022-05-24T17:00:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3978"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2019-46"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/155036/MikroTik-RouterOS-6.45.6-DNS-Cache-Poisoning.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3MV2-VMWH-RWFX

Vulnerability from github – Published: 2026-05-15 18:34 – Updated: 2026-06-09 10:27
VLAI
Summary
AVideo: 2FA toggle endpoint has no CSRF protection, letting an attacker page silently disable a logged-in victim's 2FA
Details

Summary

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

  1. Attacker hosts https://attacker.example/avideo-2fa-off.html containing: ```html
document.getElementById('f').submit();

`` 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.

Show details on source website

{
  "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": "2026-05-29T14:16:30Z",
    "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-06-09T10:27:26Z",
  "published": "2026-05-15T18:34:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-3mv2-vmwh-rwfx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45610"
    },
    {
      "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"
}

GHSA-3P4G-VG78-JQRV

Vulnerability from github – Published: 2026-03-12 21:34 – Updated: 2026-03-12 21:34
VLAI
Details

The Honeywell IQ4x building management controller, exposes its full web-based HMI without authentication in its factory-default configuration. With no user module configured, security is disabled by design and the system operates under a System Guest (level 100) context, granting read/write privileges to any party able to reach the HTTP interface. Authentication controls are only enforced after a web user is created via U.htm, which dynamically enables the user module. Because this function is accessible prior to authentication, a remote user can create a new account with administrative read/write permissions enabling the user module and imposing authentication under attacker-controlled credentials. This action can effectively lock legitimate operators out of local and web-based configuration and administration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-12T21:16:27Z",
    "severity": "CRITICAL"
  },
  "details": "The Honeywell IQ4x building management controller, exposes its full web-based HMI without authentication in its factory-default configuration. With no user module configured, security is disabled by design and the system operates under a System Guest (level 100) context, granting read/write privileges to any party able to reach the HTTP interface. Authentication controls are only enforced after a web user is created via U.htm, which dynamically enables the user module. Because this function is accessible prior to authentication, a remote user can create a new account with administrative read/write permissions enabling the user module and imposing authentication under attacker-controlled credentials. This action can effectively lock legitimate operators out of local and web-based configuration and administration.",
  "id": "GHSA-3p4g-vg78-jqrv",
  "modified": "2026-03-12T21:34:51Z",
  "published": "2026-03-12T21:34:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-069-03.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-069-03"
    },
    {
      "type": "WEB",
      "url": "https://www.honeywell.com/us/en/contact"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3P9X-XXX6-2W4P

Vulnerability from github – Published: 2023-02-02 03:30 – Updated: 2023-02-08 00:23
VLAI
Summary
Broken Access Control in 3rd party TYPO3 extension "femanager"
Details

A missing access check in the InvitationController allows an unauthenticated user to delete all frontend users.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "in2code/femanager"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T00:23:30Z",
    "nvd_published_at": "2023-02-02T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "A missing access check in the `InvitationController` allows an unauthenticated user to delete all frontend users.",
  "id": "GHSA-3p9x-xxx6-2w4p",
  "modified": "2023-02-08T00:23:30Z",
  "published": "2023-02-02T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25014"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/in2code-de/femanager"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-ext-sa-2023-001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Broken Access Control in 3rd party TYPO3 extension \"femanager\""
}

GHSA-3PGW-QMV2-HV8M

Vulnerability from github – Published: 2026-03-21 00:31 – Updated: 2026-03-21 00:31
VLAI
Details

WebSocket endpoints lack proper authentication mechanisms, enabling attackers to perform unauthorized station impersonation and manipulate data sent to the backend. An unauthenticated attacker can connect to the OCPP WebSocket endpoint using a known or discovered charging station identifier, then issue or receive OCPP commands as a legitimate charger. Given that no authentication is required, this can lead to privilege escalation, unauthorized control of charging infrastructure, and corruption of charging network data reported to the backend.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-29796"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-20T23:16:43Z",
    "severity": "CRITICAL"
  },
  "details": "WebSocket endpoints lack proper authentication mechanisms, enabling attackers to perform unauthorized station impersonation and manipulate data sent to the backend. An unauthenticated attacker can connect to the OCPP WebSocket endpoint using a known or discovered charging station identifier, then issue or receive OCPP commands as a legitimate charger. Given that no authentication is required, this can lead to privilege escalation, unauthorized control of charging infrastructure, and corruption of charging network data reported to the backend.",
  "id": "GHSA-3pgw-qmv2-hv8m",
  "modified": "2026-03-21T00:31:43Z",
  "published": "2026-03-21T00:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29796"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-078-08.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-078-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.