CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1254 vulnerabilities reference this CWE, most recent first.
GHSA-XV7Q-FVMC-JX96
Vulnerability from github – Published: 2026-10-09 20:49 – Updated: 2026-10-09 20:49Summary
With the per-provider OIDC emailfallback option enabled, Vikunja links an SSO login to a pre-existing local (username+password) account using only the email claim — no email_verified (or Microsoft xms_edov) check and no password check, on the unauthenticated callback. An attacker who can make the configured issuer emit a token bearing a victim's email logs in as that victim with a full session and no victim interaction (the nOAuth / Grafana CVE-2023-3128 class). The 2.3.0 fix for GHSA-8jvc-mcx6-r4cg added a TOTP gate, not an email_verified gate, so users without TOTP remain exposed.
Details
References are pkg/modules/auth/openid/openid.go at HEAD. Identity is first resolved on the immutable (issuer, subject) pair (openid.go:428). On a subject miss with emailfallback on, fallbackSearchUsers adds an email-only lookup against local accounts:
// openid.go:413
searches = append(searches, &user.User{Issuer: user.IssuerLocal, Email: cl.Email})
getUser resolves this via s.Get(), which ANDs non-zero fields -> WHERE issuer='local' AND email=?. Local users always have Issuer="local" (user_create.go:38), so the lookup matches any local account by email alone; getOrCreateUser returns it and the caller mints a session — the password is never read. The claims struct has no email_verified field (openid.go:80) and getClaims never consults one; a repo-wide grep for email_verified/xms_edov returns nothing. The code already warns about this at openid.go:388 ("Discouraged for untrusted providers where someone can set email without verification") — but enforces nothing.
Impact
Unauthenticated takeover of any existing local account (read/write/delete its projects, tasks, attachments, shares), bypassing the password. Scope notes: only issuer='local' accounts are matched (not pure-SSO users); the attacker's sub is not bound to the victim record, but the attack is repeatable; TOTP users are protected by the 2.3.0 enforceTOTPIfRequired gate (openid.go:250), non-TOTP users are not.
Preconditions
- Admin enabled
emailfallback: true(defaults false — a default install is unaffected). - The configured issuer lets the attacker assert the victim's unverified email: a self-service IdP (Keycloak/Authentik/Auth0/Dex with editable email), a mixed federation, or a multi-tenant Entra
/commonapp.iss/audare pinned, but the attacker controlsemail, not the issuer. - The victim has a local account.
Not reachable against a single-tenant IdP that verifies email and disallows self-set addresses.
Recommended Fix
Add email_verified to the claims struct and require it true on the email-fallback branch before linking to a local account; reject when absent/false. For Entra also require xms_edov and pin multi-tenant configs to an allowed-tenant list. Fail closed on an email collision not backed by a verified email from a trusted single-tenant issuer rather than silently logging the caller in.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.3.0"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62367"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:49:06Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nWith the per-provider OIDC `emailfallback` option enabled, Vikunja links an SSO login to a pre-existing **local** (username+password) account using only the `email` claim \u2014 no `email_verified` (or Microsoft `xms_edov`) check and no password check, on the unauthenticated callback. An attacker who can make the configured issuer emit a token bearing a victim\u0027s email logs in as that victim with a full session and no victim interaction (the nOAuth / Grafana CVE-2023-3128 class). The 2.3.0 fix for GHSA-8jvc-mcx6-r4cg added a TOTP gate, not an `email_verified` gate, so users without TOTP remain exposed.\n\n## Details\n\nReferences are `pkg/modules/auth/openid/openid.go` at HEAD. Identity is first resolved on the immutable `(issuer, subject)` pair (`openid.go:428`). On a subject miss with `emailfallback` on, `fallbackSearchUsers` adds an email-only lookup against local accounts:\n\n```go\n// openid.go:413\nsearches = append(searches, \u0026user.User{Issuer: user.IssuerLocal, Email: cl.Email})\n```\n\n`getUser` resolves this via `s.Get()`, which ANDs non-zero fields -\u003e `WHERE issuer=\u0027local\u0027 AND email=?`. Local users always have `Issuer=\"local\"` (`user_create.go:38`), so the lookup matches any local account by email alone; `getOrCreateUser` returns it and the caller mints a session \u2014 the password is never read. The `claims` struct has no `email_verified` field (`openid.go:80`) and `getClaims` never consults one; a repo-wide grep for `email_verified`/`xms_edov` returns nothing. The code already warns about this at `openid.go:388` (\"Discouraged for untrusted providers where someone can set email without verification\") \u2014 but enforces nothing.\n\n## Impact\n\nUnauthenticated takeover of any existing **local** account (read/write/delete its projects, tasks, attachments, shares), bypassing the password. Scope notes: only `issuer=\u0027local\u0027` accounts are matched (not pure-SSO users); the attacker\u0027s `sub` is not bound to the victim record, but the attack is repeatable; TOTP users are protected by the 2.3.0 `enforceTOTPIfRequired` gate (`openid.go:250`), non-TOTP users are not.\n\n## Preconditions\n\n1. Admin enabled `emailfallback: true` (defaults false \u2014 a default install is unaffected).\n2. The configured issuer lets the attacker assert the victim\u0027s unverified email: a self-service IdP (Keycloak/Authentik/Auth0/Dex with editable email), a mixed federation, or a multi-tenant Entra `/common` app. `iss`/`aud` are pinned, but the attacker controls `email`, not the issuer.\n3. The victim has a local account.\n\nNot reachable against a single-tenant IdP that verifies email and disallows self-set addresses.\n\n## Recommended Fix\n\nAdd `email_verified` to the `claims` struct and require it `true` on the email-fallback branch before linking to a local account; reject when absent/false. For Entra also require `xms_edov` and pin multi-tenant configs to an allowed-tenant list. Fail closed on an email collision not backed by a verified email from a trusted single-tenant issuer rather than silently logging the caller in.",
"id": "GHSA-xv7q-fvmc-jx96",
"modified": "2026-10-09T20:49:06Z",
"published": "2026-10-09T20:49:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-xv7q-fvmc-jx96"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/7854f2729ab72000210b61c25929678fd6901630"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Vikunja: OIDC email-fallback account linking ignores email_verified, enabling local-account takeover"
}
GHSA-XVXM-X86G-723R
Vulnerability from github – Published: 2025-11-07 00:30 – Updated: 2025-11-12 21:31Inappropriate implementation in Omnibox in Google Chrome on Android prior to 141.0.7390.54 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2025-11209"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-06T22:15:38Z",
"severity": "HIGH"
},
"details": "Inappropriate implementation in Omnibox in Google Chrome on Android prior to 141.0.7390.54 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-xvxm-x86g-723r",
"modified": "2025-11-12T21:31:04Z",
"published": "2025-11-07T00:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11209"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2025/09/stable-channel-update-for-desktop_30.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/438226517"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XW94-4RMP-7QW5
Vulnerability from github – Published: 2022-03-07 00:00 – Updated: 2022-03-17 00:03A DNS rebinding issue in ReadyMedia (formerly MiniDLNA) before 1.3.1 allows a remote web server to exfiltrate media files.
{
"affected": [],
"aliases": [
"CVE-2022-26505"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-06T07:15:00Z",
"severity": "HIGH"
},
"details": "A DNS rebinding issue in ReadyMedia (formerly MiniDLNA) before 1.3.1 allows a remote web server to exfiltrate media files.",
"id": "GHSA-xw94-4rmp-7qw5",
"modified": "2022-03-17T00:03:11Z",
"published": "2022-03-07T00:00:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26505"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/04/msg00005.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202311-12"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/minidlna/git/ci/c21208508dbc131712281ec5340687e5ae89e940"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2022/03/03/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/06/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWHP-9M57-54VW
Vulnerability from github – Published: 2024-06-04 12:31 – Updated: 2024-06-04 12:31Authentication Bypass by Spoofing vulnerability in WP Maintenance allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects WP Maintenance: from n/a through 6.1.3.
{
"affected": [],
"aliases": [
"CVE-2023-47769"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-04T10:15:11Z",
"severity": "LOW"
},
"details": "Authentication Bypass by Spoofing vulnerability in WP Maintenance allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects WP Maintenance: from n/a through 6.1.3.",
"id": "GHSA-xwhp-9m57-54vw",
"modified": "2024-06-04T12:31:03Z",
"published": "2024-06-04T12:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47769"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/wp-maintenance/wordpress-wp-maintenance-plugin-6-1-3-ip-filtering-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
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-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
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.