CWE-287
DiscouragedImproper 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-HP6V-6JW7-GV2F
Vulnerability from github – Published: 2026-07-24 21:17 – Updated: 2026-07-24 21:17Summary
Budibase's OIDC SSO login links an incoming SSO identity to an existing Budibase account by email address alone, without ever checking the email_verified claim of the OIDC ID token. Budibase first tries to match the IdP sub; when that misses (any fresh attacker IdP account) it silently falls back to matching by the email claim and merges into the existing account by email, preserving that account's _id and roles. Because the email_verified flag is never read, an attacker who can make a configured/trusted IdP emit a token carrying email = <victim> with email_verified = false is logged into Budibase as the victim, inheriting the victim's roles (including global admin/builder). Per OIDC Core §5.7 the email claim MUST NOT be used as an identity key unless email_verified is true; Budibase effectively delegates all account-linking trust to every configured IdP's email-verification policy while checking nothing itself. Full account takeover of any existing Budibase user, including the instance owner.
Details
The OIDC verify callback extracts the email and never consults email_verified:
- packages/backend-core/src/middleware/passport/sso/oidc.ts:59 — email: getEmail(profile, jwtClaims).
- getEmail (oidc.ts:113-135) returns profile._json.email ->jwtClaims.email -> preferred_username. No email_verified check.
- buildJwtClaims (oidc.ts:99-107) assembles claims from _json.email/emails[0].value — no verification flag is read. grep -r email_verified packages/ -> 0 hits.
The email is then used as the account-linking key:
- sso.authenticate(...) -> packages/backend-core/src/middleware/passport/sso/sso.ts:
- :38,44 users.getById(generateGlobalUserID(details.userId)) keyed on the IdP sub; for a fresh attacker IdP account this 404s and is swallowed (:45-54).
- :57-59 fallback: dbUser = await users.getGlobalUserByEmail(details.email) -> loads the victim's account (victim _id + roles) purely by email (packages/backend-core/src/users/users.ts:100-124, USER_BY_EMAIL view, no binding to the IdP sub).
- syncUser(...) (sso.ts:80,102-138) spreads ...user, preserving the victim _id/tenantId/roles; only overwrites provider fields.
- UserDB.save (packages/backend-core/src/users/db.ts:235): because ssoUser._id is the victim's, the _id branch runs (:253), getById(_id) matches the victim (:256), the "Email address cannot be changed" guard (:257-259) does not fire (dbUser.email === email), and the EmailUnavailableError guard (:269-275) is skipped (it only runs in the !dbUser branch). The merge proceeds silently; a session JWT is issued for the victim.
Per OIDC Core §5.7, the email claim MUST NOT be used as an identity key unless email_verified is true. Budibase never reads the flag.
Preconditions (attack requirement — AT:P): the attacker must be able to authenticate through an IdP that the Budibase instance trusts AND get that IdP to assert the victim's email with email_verified = false. This is reachable, not exotic:
- Self-registration with an unverified email — Keycloak and Authentik ship with "Verify Email" OFF by default; if the trusted IdP allows public sign-up, the attacker registers a new account and simply enters email = <victim> at sign-up. No confirmation email is needed — the IdP stores and asserts it unverified.
- Self-service profile editing — many IdPs let a logged-in user change their own email without forced re-verification.
- Attacker-operated / federated IdP or permissive social login — where the attacker controls or influences a trusted provider, or the provider asserts a user-typed (unverified) email.
It is not exploitable through a strict corporate IdP that enforces email verification (there email_verified = true and the attacker cannot claim the victim's address) — which is exactly why Budibase must check the flag rather than assume every configured IdP enforces it. The defect is unconditional on the Budibase side; the attack requirement is purely the (default, common) IdP email policy.
PoC
Reproduced live on Budibase 3.39.14 (self-hosted, community license) against a stock Keycloak 26 realm budi with default "Verify Email" = off; OIDC client registered and activated in Budibase.
Setup: a pre-existing victim global-admin Budibase account victim@stand.local (_id = us_1ab2dfcf…, local account, no IdP link). The attacker owns their own IdP account (attacker, distinct sub) and can set its email attribute unverified.
Step 1 — the IdP asserts the claim (proves email_verified=false):
POST /realms/budi/protocol/openid-connect/token (Keycloak)
grant_type=password&client_id=budibase&client_secret=…&username=attacker&password=Attacker123!&scope=openid email profile
-> id_token payload: { "sub":"3cf58c45-…", "preferred_username":"attacker",
"email":"victim@stand.local", "email_verified":false }
The authenticated principal is provably attacker (its own sub/preferred_username/password), merely claiming the victim's email, unverified.
Step 2 — drive the standard OIDC flow as attacker:
GET /api/global/auth/default/oidc/configs/kc-oidc-1 -> IdP login as attacker/Attacker123! -> GET /api/global/auth/oidc/callback?code=…&state=….
Step 3 — result (takeover): Budibase sets budibase:auth to a session JWT
{ "userId":"us_1ab2dfcf…", "email":"victim@stand.local", "tenantId":"default" }, and
GET /api/global/self returns the victim: _id = us_1ab2dfcf…, admin.global = true, builder.global = true, providerType = oidc. The attacker authenticated as a different IdP principal with an unverified email yet now holds a full global-admin session for the victim.
Negative control (proves the email claim is the cause, not a normal self-login):
A second attacker attacker2 with a benign unverified email attacker2@evil.local (matching no Budibase user) runs the identical flow:
id_token: { "sub":"55794bf2-…", "preferred_username":"attacker2", "email":"attacker2@evil.local", "email_verified":false }
-> budibase:auth: { "userId":"us_55794bf2-…" } (a NEW account, _id derived from the IdP sub)
-> /api/global/self: { "_id":"us_55794bf2-…", "email":"attacker2@evil.local", admin.global: null, builder.global: null }
With a benign email the attacker gets their own new low-privilege account; only when the email claim equals the victim's does the same flow yield the victim's admin account. Same self-authentication, single variable changed = the unverified-email merge is the vulnerability.
Impact
Takeover of any existing Budibase account by email, including the instance owner / global admin -> full control of the tenant (apps, datasources, automations, user management, stored datasource credentials). The attacker authenticates as their own (different) IdP principal and ends up holding the victim's session and roles. The only requirement beyond a trusted IdP login is that the IdP assert the victim's email unverified — the default for a freshly-created Keycloak/Authentik realm and common in social logins (see Preconditions). Any deployment that trusts an OIDC IdP without enforced email verification is exposed; the Budibase-side flaw (ignoring email_verified) is unconditional.
Remediation
Primary fix: in the OIDC verify path, require email_verified === true before using email to look up / link an existing account; otherwise reject the login (or fall back to sub-only matching and never merge into a pre-existing local/SSO account). Concretely, thread the email_verified claim through buildJwtClaims/getEmail (oidc.ts) and gate the getGlobalUserByEmail fallback in sso.ts:57-59 on it.
Audit the whole class: apply the same email_verified (and, for SAML, EmailVerified/assertion-signature) gate to every SSO strategy that links by email — OIDC, SAML, and any social provider — not only the Google strategy (which already passes requireLocalAccount=true). Email-based account linking anywhere must require a verified email.
Defense-in-depth for operators who cannot patch immediately:
- On the IdP, enable "Verify Email" / require verified email before issuing tokens (Keycloak: realm -> Login -> Verify Email = on), and restrict which email domains the IdP will assert.
- Prefer sub-based account mapping over email in the IdP/Budibase mapping config where available.
- Audit existing accounts for unexpected OIDC links to privileged users; rotate sessions.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.38.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:17:39Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nBudibase\u0027s OIDC SSO login links an incoming SSO identity to an existing Budibase account **by email address alone**, without ever checking the `email_verified` claim of the OIDC ID token. Budibase first tries to match the IdP `sub`; when that misses (any fresh attacker IdP account) it silently falls back to matching by the `email` claim and **merges into the existing account by email**, preserving that account\u0027s `_id` and roles. Because the `email_verified` flag is never read, an attacker who can make a **configured/trusted** IdP emit a token carrying `email = \u003cvictim\u003e` with `email_verified = false` is logged into Budibase **as the victim**, inheriting the victim\u0027s roles (including global admin/builder). Per OIDC Core \u00a75.7 the `email` claim MUST NOT be used as an identity key unless `email_verified` is `true`; Budibase effectively delegates all account-linking trust to every configured IdP\u0027s email-verification policy while checking nothing itself. Full account takeover of any existing Budibase user, including the instance owner.\n\n### Details\nThe OIDC verify callback extracts the email and never consults `email_verified`:\n- `packages/backend-core/src/middleware/passport/sso/oidc.ts:59` \u2014 `email: getEmail(profile, jwtClaims)`.\n- `getEmail` (`oidc.ts:113-135`) returns `profile._json.email` -\u003e`jwtClaims.email` -\u003e `preferred_username`. **No `email_verified` check.**\n- `buildJwtClaims` (`oidc.ts:99-107`) assembles claims from `_json.email`/`emails[0].value` \u2014 no verification flag is read. `grep -r email_verified packages/` -\u003e 0 hits.\n\nThe email is then used as the **account-linking key**:\n- `sso.authenticate(...)` -\u003e `packages/backend-core/src/middleware/passport/sso/sso.ts`:\n - `:38,44` `users.getById(generateGlobalUserID(details.userId))` keyed on the IdP `sub`; for a fresh attacker IdP account this 404s and is swallowed (`:45-54`).\n - `:57-59` **fallback:** `dbUser = await users.getGlobalUserByEmail(details.email)` -\u003e loads the **victim\u0027s** account (victim `_id` + roles) purely by email (`packages/backend-core/src/users/users.ts:100-124`, `USER_BY_EMAIL` view, no binding to the IdP `sub`).\n - `syncUser(...)` (`sso.ts:80,102-138`) spreads `...user`, preserving the victim `_id`/`tenantId`/`roles`; only overwrites provider fields.\n- `UserDB.save` (`packages/backend-core/src/users/db.ts:235`): because `ssoUser._id` is the victim\u0027s, the `_id` branch runs (`:253`), `getById(_id)` matches the victim (`:256`), the \"Email address cannot be changed\" guard (`:257-259`) does not fire (`dbUser.email === email`), and the `EmailUnavailableError` guard (`:269-275`) is skipped (it only runs in the `!dbUser` branch). The merge proceeds silently; a session JWT is issued for the victim.\n\nPer OIDC Core \u00a75.7, the `email` claim MUST NOT be used as an identity key unless `email_verified` is `true`. Budibase never reads the flag.\n\n**Preconditions (attack requirement \u2014 `AT:P`):** the attacker must be able to authenticate through an IdP that the Budibase instance **trusts** AND get that IdP to assert the victim\u0027s email with `email_verified = false`. This is reachable, not exotic:\n- **Self-registration with an unverified email \u2014 Keycloak and Authentik ship with *\"Verify Email\" OFF by default*; if the trusted IdP allows public sign-up, the attacker registers a new account and simply enters `email = \u003cvictim\u003e` at sign-up. No confirmation email is needed \u2014 the IdP stores and asserts it unverified.**\n- **Self-service profile editing** \u2014 many IdPs let a logged-in user change their own email without forced re-verification.\n- **Attacker-operated / federated IdP or permissive social login** \u2014 where the attacker controls or influences a trusted provider, or the provider asserts a user-typed (unverified) email.\nIt is **not** exploitable through a strict corporate IdP that enforces email verification (there `email_verified = true` and the attacker cannot claim the victim\u0027s address) \u2014 which is exactly why Budibase must check the flag rather than assume every configured IdP enforces it. The defect is unconditional on the Budibase side; the attack requirement is purely the (default, common) IdP email policy.\n\n### PoC\nReproduced live on Budibase `3.39.14` (self-hosted, community license) against a stock **Keycloak 26** realm `budi` with default \"Verify Email\" = off; OIDC client registered and activated in Budibase.\n\n**Setup:** a pre-existing **victim** global-admin Budibase account `victim@stand.local` (`_id = us_1ab2dfcf\u2026`, local account, *no IdP link*). The attacker owns their **own** IdP account (`attacker`, distinct `sub`) and can set its email attribute unverified.\n\n**Step 1 \u2014 the IdP asserts the claim (proves `email_verified=false`):**\n```\nPOST /realms/budi/protocol/openid-connect/token (Keycloak)\ngrant_type=password\u0026client_id=budibase\u0026client_secret=\u2026\u0026username=attacker\u0026password=Attacker123!\u0026scope=openid email profile\n-\u003e id_token payload: { \"sub\":\"3cf58c45-\u2026\", \"preferred_username\":\"attacker\",\n \"email\":\"victim@stand.local\", \"email_verified\":false }\n```\nThe authenticated principal is provably **`attacker`** (its own `sub`/`preferred_username`/password), merely *claiming* the victim\u0027s email, unverified.\n\n\u003cimg width=\"1484\" height=\"685\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cdddac3c-b7c0-4c59-aaec-9092706a7ad8\" /\u003e\n\n\n**Step 2 \u2014 drive the standard OIDC flow** as `attacker`:\n`GET /api/global/auth/default/oidc/configs/kc-oidc-1` -\u003e IdP login as `attacker`/`Attacker123!` -\u003e `GET /api/global/auth/oidc/callback?code=\u2026\u0026state=\u2026`.\n\n\u003cimg width=\"1145\" height=\"454\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ac0a73d0-c5fc-4d0f-b9b0-95f6273b99f7\" /\u003e\n\n\u003cimg width=\"1172\" height=\"445\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a4b27a7e-4293-4caf-957f-d27c54ea461a\" /\u003e\n\n\u003cimg width=\"1157\" height=\"648\" alt=\"image\" src=\"https://github.com/user-attachments/assets/06699774-92b0-4163-a171-9a30bc877ecc\" /\u003e\n\n\u003cimg width=\"1201\" height=\"525\" alt=\"image\" src=\"https://github.com/user-attachments/assets/92a92fcf-9d29-42ca-921d-de6fbd78198f\" /\u003e\n\n\n\n**Step 3 \u2014 result (takeover):** Budibase sets `budibase:auth` to a session JWT\n`{ \"userId\":\"us_1ab2dfcf\u2026\", \"email\":\"victim@stand.local\", \"tenantId\":\"default\" }`, and\n`GET /api/global/self` returns the **victim**: `_id = us_1ab2dfcf\u2026`, `admin.global = true`, `builder.global = true`, `providerType = oidc`. The attacker authenticated as a *different* IdP principal with an *unverified* email yet now holds a full global-admin session for the victim.\n\n\u003cimg width=\"1001\" height=\"456\" alt=\"image\" src=\"https://github.com/user-attachments/assets/c8dfc25f-aed7-4cd7-9323-f029e4d1a725\" /\u003e\n\n\n**Negative control (proves the email claim is the cause, not a normal self-login):**\nA second attacker `attacker2` with a **benign** unverified email `attacker2@evil.local` (matching no Budibase user) runs the *identical* flow:\n```\nid_token: { \"sub\":\"55794bf2-\u2026\", \"preferred_username\":\"attacker2\", \"email\":\"attacker2@evil.local\", \"email_verified\":false }\n-\u003e budibase:auth: { \"userId\":\"us_55794bf2-\u2026\" } (a NEW account, _id derived from the IdP sub)\n-\u003e /api/global/self: { \"_id\":\"us_55794bf2-\u2026\", \"email\":\"attacker2@evil.local\", admin.global: null, builder.global: null }\n```\n\u003cimg width=\"1153\" height=\"489\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8f6cb849-e6f3-49f1-b576-8aeba026a3be\" /\u003e\n\n\u003cimg width=\"1089\" height=\"466\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a892ec3e-3753-4bc0-9eee-9f0613b2d92e\" /\u003e\n\n\u003cimg width=\"826\" height=\"532\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cc30bd9c-1bdb-4bea-934f-a8b3e228940e\" /\u003e\n\n\nWith a benign email the attacker gets **their own new low-privilege account**; only when the email claim equals the victim\u0027s does the same flow yield the **victim\u0027s admin account**. Same self-authentication, single variable changed = the unverified-email merge is the vulnerability.\n\n### Impact\nTakeover of any existing Budibase account by email, including the instance owner / global admin -\u003e full control of the tenant (apps, datasources, automations, user management, stored datasource credentials). The attacker authenticates as their *own* (different) IdP principal and ends up holding the victim\u0027s session and roles. The only requirement beyond a trusted IdP login is that the IdP assert the victim\u0027s email unverified \u2014 the default for a freshly-created Keycloak/Authentik realm and common in social logins (see Preconditions). Any deployment that trusts an OIDC IdP without enforced email verification is exposed; the Budibase-side flaw (ignoring `email_verified`) is unconditional.\n\n### Remediation\n**Primary fix:** in the OIDC verify path, require `email_verified === true` before using `email` to look up / link an existing account; otherwise reject the login (or fall back to `sub`-only matching and never merge into a pre-existing local/SSO account). Concretely, thread the `email_verified` claim through `buildJwtClaims`/`getEmail` (`oidc.ts`) and gate the `getGlobalUserByEmail` fallback in `sso.ts:57-59` on it.\n\n**Audit the whole class:** apply the same `email_verified` (and, for SAML, `EmailVerified`/assertion-signature) gate to every SSO strategy that links by email \u2014 OIDC, SAML, and any social provider \u2014 not only the Google strategy (which already passes `requireLocalAccount=true`). Email-based account linking anywhere must require a verified email.\n\n**Defense-in-depth for operators who cannot patch immediately:**\n- On the IdP, enable \"Verify Email\" / require verified email before issuing tokens (Keycloak: realm -\u003e Login -\u003e Verify Email = on), and restrict which email domains the IdP will assert.\n- Prefer `sub`-based account mapping over email in the IdP/Budibase mapping config where available.\n- Audit existing accounts for unexpected OIDC links to privileged users; rotate sessions.",
"id": "GHSA-hp6v-6jw7-gv2f",
"modified": "2026-07-24T21:17:39Z",
"published": "2026-07-24T21:17:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-hp6v-6jw7-gv2f"
},
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/commit/9ecd0048d9c3ae0ee9bd0e6204c621794dd1a4d3"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
},
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/releases/tag/3.39.30"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": " Budibase: OIDC SSO account takeover: incoming identity linked by email without checking email_verified"
}
GHSA-HP9H-GMR9-R5H4
Vulnerability from github – Published: 2022-04-23 00:03 – Updated: 2022-05-10 00:00An authentication bypass vulnerability was discovered in an internal service of the Lenovo Fan Power Controller2 (FPC2) and Lenovo System Management Module (SMM) firmware during an that could allow an unauthenticated attacker to execute commands on the SMM and FPC2. SMM2 is not affected.
{
"affected": [],
"aliases": [
"CVE-2021-3897"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-22T21:15:00Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass vulnerability was discovered in an internal service of the Lenovo Fan Power Controller2 (FPC2) and Lenovo System Management Module (SMM) firmware during an that could allow an unauthenticated attacker to execute commands on the SMM and FPC2. SMM2 is not affected.",
"id": "GHSA-hp9h-gmr9-r5h4",
"modified": "2022-05-10T00:00:45Z",
"published": "2022-04-23T00:03:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3897"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-72615"
}
],
"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-HPC9-P79M-Q8WM
Vulnerability from github – Published: 2025-04-08 21:31 – Updated: 2025-04-08 21:31ColdFusion versions 2023.12, 2021.18, 2025.0 and earlier are affected by an Improper Authentication vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could leverage this vulnerability to bypass authentication mechanisms and execute code with the privileges of the authenticated user. Exploitation of this issue requires user interaction in that a victim must be coerced into performing actions within the application.
{
"affected": [],
"aliases": [
"CVE-2025-30287"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T20:15:26Z",
"severity": "HIGH"
},
"details": "ColdFusion versions 2023.12, 2021.18, 2025.0 and earlier are affected by an Improper Authentication vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could leverage this vulnerability to bypass authentication mechanisms and execute code with the privileges of the authenticated user. Exploitation of this issue requires user interaction in that a victim must be coerced into performing actions within the application.",
"id": "GHSA-hpc9-p79m-q8wm",
"modified": "2025-04-08T21:31:41Z",
"published": "2025-04-08T21:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30287"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/coldfusion/apsb25-15.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPF6-JP82-WRPJ
Vulnerability from github – Published: 2025-04-25 12:30 – Updated: 2025-04-25 12:30The JobSearch WP Job Board plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.8.8. This is due to improper configurations in the 'jobsearch_xing_response_data_callback', 'set_access_tokes', and 'google_callback' functions. This makes it possible for unauthenticated attackers to log in as the first connected Xing user, or any connected Xing user if the Xing id is known. It is also possible for unauthenticated attackers to log in as the first connected Google user if the user has logged in, without subsequently logging out, in thirty days. The vulnerability was partially patched in version 2.8.4.
{
"affected": [],
"aliases": [
"CVE-2024-11917"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-25T12:15:16Z",
"severity": "HIGH"
},
"details": "The JobSearch WP Job Board plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.8.8. This is due to improper configurations in the \u0027jobsearch_xing_response_data_callback\u0027, \u0027set_access_tokes\u0027, and \u0027google_callback\u0027 functions. This makes it possible for unauthenticated attackers to log in as the first connected Xing user, or any connected Xing user if the Xing id is known. It is also possible for unauthenticated attackers to log in as the first connected Google user if the user has logged in, without subsequently logging out, in thirty days. The vulnerability was partially patched in version 2.8.4.",
"id": "GHSA-hpf6-jp82-wrpj",
"modified": "2025-04-25T12:30:27Z",
"published": "2025-04-25T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11917"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/jobsearch-wp-job-board-wordpress-plugin/21066856"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6de8a608-8715-4f9c-9f2f-df60dd1cc579?source=cve"
}
],
"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"
}
]
}
GHSA-HPH8-QR89-F778
Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32Vulnerability in the Oracle Commerce Platform product of Oracle Commerce (component: Dynamo Application Framework). The supported version that is affected is 11.4.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Commerce Platform. Successful attacks of this vulnerability can result in takeover of Oracle Commerce Platform. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-61137"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:18:45Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Commerce Platform product of Oracle Commerce (component: Dynamo Application Framework). The supported version that is affected is 11.4.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Commerce Platform. Successful attacks of this vulnerability can result in takeover of Oracle Commerce Platform. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-hph8-qr89-f778",
"modified": "2026-07-22T00:32:18Z",
"published": "2026-07-22T00:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61137"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.html"
}
],
"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"
}
]
}
GHSA-HPMX-Q5W5-CJ4C
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-04-04 01:26cPanel before 74.0.0 allows file modification in the context of the root account because of incorrect HTTP authentication (SEC-424).
{
"affected": [],
"aliases": [
"CVE-2018-20888"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-01T14:15:00Z",
"severity": "MODERATE"
},
"details": "cPanel before 74.0.0 allows file modification in the context of the root account because of incorrect HTTP authentication (SEC-424).",
"id": "GHSA-hpmx-q5w5-cj4c",
"modified": "2024-04-04T01:26:26Z",
"published": "2022-05-24T16:51:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20888"
},
{
"type": "WEB",
"url": "https://documentation.cpanel.net/display/CL/74+Change+Log"
},
{
"type": "WEB",
"url": "https://news.cpanel.com/cpanel-tsr-2018-0004-full-disclosure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPQG-7FJP-436P
Vulnerability from github – Published: 2023-07-14 12:30 – Updated: 2024-10-14 15:30Issue summary: The AES-SIV cipher implementation contains a bug that causes it to ignore empty associated data entries which are unauthenticated as a consequence.
Impact summary: Applications that use the AES-SIV algorithm and want to authenticate empty data entries as associated data can be mislead by removing adding or reordering such empty entries as these are ignored by the OpenSSL implementation. We are currently unaware of any such applications.
The AES-SIV algorithm allows for authentication of multiple associated data entries along with the encryption. To authenticate empty data the application has to call EVP_EncryptUpdate() (or EVP_CipherUpdate()) with NULL pointer as the output buffer and 0 as the input buffer length. The AES-SIV implementation in OpenSSL just returns success for such a call instead of performing the associated data authentication operation. The empty data thus will not be authenticated.
As this issue does not affect non-empty associated data authentication and we expect it to be rare for an application to use empty associated data entries this is qualified as Low severity issue.
{
"affected": [],
"aliases": [
"CVE-2023-2975"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-14T12:15:09Z",
"severity": "MODERATE"
},
"details": "Issue summary: The AES-SIV cipher implementation contains a bug that causes\nit to ignore empty associated data entries which are unauthenticated as\na consequence.\n\nImpact summary: Applications that use the AES-SIV algorithm and want to\nauthenticate empty data entries as associated data can be mislead by removing\nadding or reordering such empty entries as these are ignored by the OpenSSL\nimplementation. We are currently unaware of any such applications.\n\nThe AES-SIV algorithm allows for authentication of multiple associated\ndata entries along with the encryption. To authenticate empty data the\napplication has to call EVP_EncryptUpdate() (or EVP_CipherUpdate()) with\nNULL pointer as the output buffer and 0 as the input buffer length.\nThe AES-SIV implementation in OpenSSL just returns success for such a call\ninstead of performing the associated data authentication operation.\nThe empty data thus will not be authenticated.\n\nAs this issue does not affect non-empty associated data authentication and\nwe expect it to be rare for an application to use empty associated data\nentries this is qualified as Low severity issue.",
"id": "GHSA-hpqg-7fjp-436p",
"modified": "2024-10-14T15:30:44Z",
"published": "2023-07-14T12:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2975"
},
{
"type": "WEB",
"url": "https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=00e2f5eea29994d19293ec4e8c8775ba73678598"
},
{
"type": "WEB",
"url": "https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=6a83f0c958811f07e0d11dfc6b5a6a98edfd5bdc"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202402-08"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230725-0004"
},
{
"type": "WEB",
"url": "https://www.openssl.org/news/secadv/20230714.txt"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/15/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/07/19/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPRW-M99V-PPGF
Vulnerability from github – Published: 2022-05-24 17:08 – Updated: 2022-05-24 17:08Improper Authentication in subsystem in Intel(R) CSME versions 12.0 through 12.0.48 (IOT only: 12.0.56), versions 13.0 through 13.0.20, versions 14.0 through 14.0.10 may allow a privileged user to potentially enable escalation of privilege, denial of service or information disclosure via local access.
{
"affected": [],
"aliases": [
"CVE-2019-14598"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-13T19:15:00Z",
"severity": "MODERATE"
},
"details": "Improper Authentication in subsystem in Intel(R) CSME versions 12.0 through 12.0.48 (IOT only: 12.0.56), versions 13.0 through 13.0.20, versions 14.0 through 14.0.10 may allow a privileged user to potentially enable escalation of privilege, denial of service or information disclosure via local access.",
"id": "GHSA-hprw-m99v-ppgf",
"modified": "2022-05-24T17:08:52Z",
"published": "2022-05-24T17:08:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14598"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200221-0005"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00307.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HPV4-5H6F-WQR3
Vulnerability from github – Published: 2026-05-29 19:39 – Updated: 2026-06-11 14:06Summary
The russh server authentication path keeps internal userauth state across SSH_MSG_USERAUTH_REQUEST messages without separating that state when the request principal changes.
RFC 4252 allows the user name and service name fields to change between authentication requests. The issue is not that such changes are invalid. The issue is that russh-owned authentication state, such as remaining methods, partial-success state, and in-progress method state, can remain associated with the connection and then influence a later request for a different (user, service).
This is an internal library state mismatch. Applications are responsible for any authentication state they keep in their own handlers, but russh must reset or separate state that russh itself owns.
Details
The relevant server-side auth logic is in:
russh/src/server/encrypted.rsrussh/src/auth.rs
RFC 4252 section 5 says the user name and service name fields are repeated in every SSH_MSG_USERAUTH_REQUEST and may change. It also says the server implementation must check those fields in every message and flush accumulated authentication state if they change; if it cannot flush that state, it must disconnect.
In vulnerable russh code, the username and service are decoded from each SSH_MSG_USERAUTH_REQUEST, while the AuthRequest state remains connection-scoped. That state includes:
methods, which is later encoded as theSSH_MSG_USERAUTH_FAILUREremaining-methods list.partial_success, which is later encoded inSSH_MSG_USERAUTH_FAILURE.current, which tracks in-progress method state such as public-key offer or keyboard-interactive challenge state.rejection_count.
If one request narrows russh's internal methods set, a later request for a different user can observe that narrowed set unless the internal state is reset at the principal boundary.
PoC
The PoC demonstrates only russh-owned state. The handler does not store any cross-request state. Alice's request narrows russh's remaining methods to password; Bob's later plain reject should not reuse that internal state.
struct RemainingMethodsUserSwitchServer;
impl server::Handler for RemainingMethodsUserSwitchServer {
type Error = russh::Error;
async fn auth_none(&mut self, user: &str) -> Result<server::Auth, Self::Error> {
if user == "alice" {
Ok(server::Auth::Reject {
proceed_with_methods: Some(MethodSet::from(&[MethodKind::Password][..])),
partial_success: true,
})
} else {
Ok(server::Auth::reject())
}
}
}
#[tokio::test]
async fn auth_does_not_carry_remaining_methods_across_username_change() {
let alice = session.authenticate_none("alice").await.unwrap();
assert!(matches!(
alice,
client::AuthResult::Failure {
ref remaining_methods,
..
} if *remaining_methods == MethodSet::from(&[MethodKind::Password][..])
));
let bob = session.authenticate_none("bob").await.unwrap();
if let client::AuthResult::Failure {
remaining_methods, ..
} = bob {
assert!(
remaining_methods.contains(&MethodKind::PublicKey),
"server reused Alice's narrowed remaining methods for Bob: {remaining_methods:?}"
);
}
}
On upstream/main, this fails with:
server reused Alice's narrowed remaining methods for Bob: MethodSet([Password])
That failure is produced by russh's retained AuthRequest.methods; it does not depend on handler-owned MFA/session state.
Impact
Suggested provisional CVSS v3.1:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N- Score:
5.3
Reasoning:
AV:N: reachable by a remote SSH client during authentication.AC:L: the attack is a normal sequence of SSH user-auth packets.PR:N: the attacker does not need an already-authenticated SSH session.UI:N: no user interaction is required on the server side.S:U: the impact is within the vulnerable SSH server implementation.C:N: the narrow PoC does not disclose confidential data.I:L: russh-owned authentication state for one principal can affect the authentication flow for a different principal.A:N: the narrow PoC does not demonstrate an availability impact.
This report does not claim that username changes are inherently invalid, nor does it rely on application-owned authentication state being mishandled by the embedding server.
Fix / Patch Direction
The fix should update russh's internal userauth state handling so that accumulated russh-owned state is flushed or separated when (user, service) changes between SSH_MSG_USERAUTH_REQUEST messages.
The fix stores the last seen (user, service) on AuthRequest. When a new auth request arrives for a different principal, russh resets its internal auth state before dispatching the new request. This keeps username changes protocol-valid while preventing prior russh-owned auth state from carrying into the new principal.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0.34.0-beta.1"
},
{
"fixed": "0.61.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46705"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T19:39:41Z",
"nvd_published_at": "2026-06-10T22:17:00Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe `russh` server authentication path keeps internal userauth state across `SSH_MSG_USERAUTH_REQUEST` messages without separating that state when the request principal changes.\n\nRFC 4252 allows the `user name` and `service name` fields to change between authentication requests. The issue is not that such changes are invalid. The issue is that russh-owned authentication state, such as remaining methods, partial-success state, and in-progress method state, can remain associated with the connection and then influence a later request for a different `(user, service)`.\n\nThis is an internal library state mismatch. Applications are responsible for any authentication state they keep in their own handlers, but russh must reset or separate state that russh itself owns.\n\n### Details\nThe relevant server-side auth logic is in:\n\n- `russh/src/server/encrypted.rs`\n- `russh/src/auth.rs`\n\nRFC 4252 section 5 says the `user name` and `service name` fields are repeated in every `SSH_MSG_USERAUTH_REQUEST` and may change. It also says the server implementation must check those fields in every message and flush accumulated authentication state if they change; if it cannot flush that state, it must disconnect.\n\nIn vulnerable `russh` code, the username and service are decoded from each `SSH_MSG_USERAUTH_REQUEST`, while the `AuthRequest` state remains connection-scoped. That state includes:\n\n- `methods`, which is later encoded as the `SSH_MSG_USERAUTH_FAILURE` remaining-methods list.\n- `partial_success`, which is later encoded in `SSH_MSG_USERAUTH_FAILURE`.\n- `current`, which tracks in-progress method state such as public-key offer or keyboard-interactive challenge state.\n- `rejection_count`.\n\nIf one request narrows russh\u0027s internal `methods` set, a later request for a different user can observe that narrowed set unless the internal state is reset at the principal boundary.\n\n### PoC\nThe PoC demonstrates only russh-owned state. The handler does not store any cross-request state. Alice\u0027s request narrows russh\u0027s remaining methods to `password`; Bob\u0027s later plain reject should not reuse that internal state.\n\n```rust\nstruct RemainingMethodsUserSwitchServer;\n\nimpl server::Handler for RemainingMethodsUserSwitchServer {\n type Error = russh::Error;\n\n async fn auth_none(\u0026mut self, user: \u0026str) -\u003e Result\u003cserver::Auth, Self::Error\u003e {\n if user == \"alice\" {\n Ok(server::Auth::Reject {\n proceed_with_methods: Some(MethodSet::from(\u0026[MethodKind::Password][..])),\n partial_success: true,\n })\n } else {\n Ok(server::Auth::reject())\n }\n }\n}\n\n#[tokio::test]\nasync fn auth_does_not_carry_remaining_methods_across_username_change() {\n let alice = session.authenticate_none(\"alice\").await.unwrap();\n\n assert!(matches!(\n alice,\n client::AuthResult::Failure {\n ref remaining_methods,\n ..\n } if *remaining_methods == MethodSet::from(\u0026[MethodKind::Password][..])\n ));\n\n let bob = session.authenticate_none(\"bob\").await.unwrap();\n\n if let client::AuthResult::Failure {\n remaining_methods, ..\n } = bob {\n assert!(\n remaining_methods.contains(\u0026MethodKind::PublicKey),\n \"server reused Alice\u0027s narrowed remaining methods for Bob: {remaining_methods:?}\"\n );\n }\n}\n```\n\nOn `upstream/main`, this fails with:\n\n```text\nserver reused Alice\u0027s narrowed remaining methods for Bob: MethodSet([Password])\n```\n\nThat failure is produced by russh\u0027s retained `AuthRequest.methods`; it does not depend on handler-owned MFA/session state.\n\n### Impact\nSuggested provisional CVSS v3.1:\n\n- `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N`\n- Score: `5.3`\n\nReasoning:\n\n- `AV:N`: reachable by a remote SSH client during authentication.\n- `AC:L`: the attack is a normal sequence of SSH user-auth packets.\n- `PR:N`: the attacker does not need an already-authenticated SSH session.\n- `UI:N`: no user interaction is required on the server side.\n- `S:U`: the impact is within the vulnerable SSH server implementation.\n- `C:N`: the narrow PoC does not disclose confidential data.\n- `I:L`: russh-owned authentication state for one principal can affect the authentication flow for a different principal.\n- `A:N`: the narrow PoC does not demonstrate an availability impact.\n\nThis report does not claim that username changes are inherently invalid, nor does it rely on application-owned authentication state being mishandled by the embedding server.\n\n### Fix / Patch Direction\nThe fix should update russh\u0027s internal userauth state handling so that accumulated russh-owned state is flushed or separated when `(user, service)` changes between `SSH_MSG_USERAUTH_REQUEST` messages.\n\nThe fix stores the last seen `(user, service)` on `AuthRequest`. When a new auth request arrives for a different principal, russh resets its internal auth state before dispatching the new request. This keeps username changes protocol-valid while preventing prior russh-owned auth state from carrying into the new principal.",
"id": "GHSA-hpv4-5h6f-wqr3",
"modified": "2026-06-11T14:06:30Z",
"published": "2026-05-29T19:39:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-hpv4-5h6f-wqr3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46705"
},
{
"type": "PACKAGE",
"url": "https://github.com/Eugeny/russh"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "russh server userauth state is not reset when authentication principal changes"
}
GHSA-HQ5P-QH3J-36WG
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-09-18 15:30A vulnerability was found in whuan132 AIBattery up to 1.0.9. The affected element is an unknown function of the file AIBatteryHelper/XPC/BatteryXPCService.swift of the component com.collweb.AIBatteryHelper. The manipulation results in missing authentication. The attack requires a local approach. The exploit has been made public and could be used.
{
"affected": [],
"aliases": [
"CVE-2025-10672"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T15:15:37Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in whuan132 AIBattery up to 1.0.9. The affected element is an unknown function of the file AIBatteryHelper/XPC/BatteryXPCService.swift of the component com.collweb.AIBatteryHelper. The manipulation results in missing authentication. The attack requires a local approach. The exploit has been made public and could be used.",
"id": "GHSA-hq5p-qh3j-36wg",
"modified": "2025-09-18T15:30:35Z",
"published": "2025-09-18T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10672"
},
{
"type": "WEB",
"url": "https://github.com/SwayZGl1tZyyy/n-days/blob/main/AIBattery-Charge-Limiter/README.md"
},
{
"type": "WEB",
"url": "https://github.com/SwayZGl1tZyyy/n-days/blob/main/AIBattery-Charge-Limiter/README.md#proof-of-concept"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.324793"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.324793"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.653159"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P/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
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.