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.
6877 vulnerabilities reference this CWE, most recent first.
GHSA-45G5-QMV3-9F22
Vulnerability from github – Published: 2026-06-04 09:30 – Updated: 2026-06-04 21:31The debugging routine SCREEN_CLICK(5053) enables a connection to skip the standard device login prompt entirely and directly enter an interactive shell interface.
{
"affected": [],
"aliases": [
"CVE-2026-49194"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T07:16:27Z",
"severity": "CRITICAL"
},
"details": "The debugging routine\u00a0SCREEN_CLICK(5053)\u00a0enables a connection to skip the standard device login prompt entirely and directly enter an interactive shell interface.",
"id": "GHSA-45g5-qmv3-9f22",
"modified": "2026-06-04T21:31:20Z",
"published": "2026-06-04T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49194"
},
{
"type": "WEB",
"url": "https://community.acer.com/en/kb/articles/19707"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-45GV-9WJV-XH7P
Vulnerability from github – Published: 2026-10-09 17:08 – Updated: 2026-10-09 17:08Summary
nginx-ui supports two second-factor methods — TOTP (OTP) and WebAuthn passkeys —
and reports an account as 2FA-enabled when either is configured. However, the
password login endpoint (POST /api/login) only enforces a second factor when a
TOTP secret is present. An account that has registered a passkey but no
TOTP is logged in after password verification alone — the passkey is never
requested. This silently downgrades a passkey-protected account to single-factor
(password-only) authentication.
Details
The account's 2FA policy treats passkeys as a valid factor (model/user.go):
func (u *User) EnabledOTP() bool { return len(u.OTPSecret) != 0 }
func (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }
func (u *User) Enabled2FA() bool { return u.EnabledOTP() || u.EnabledPasskey() }
func (u *User) AfterFind(_ *gorm.DB) error {
u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`
return nil
}
But the login handler only checks EnabledOTP() (api/user/auth.go, Login):
u, err := user.Login(json.Name, json.Password)
...
if u.EnabledOTP() { // <-- only TOTP is enforced
if json.OTP == "" && json.RecoveryCode == "" {
c.JSON(http.StatusOK, LoginResponse{Message: "The user has enabled 2FA", Code: Enabled2FA}) // 199
user.BanIP(clientIP)
return
}
if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }
secureSessionID = user.SetSecureSessionID(u.ID)
}
// Passkey-only accounts fall through to here and receive a full session token:
accessToken, err := user.GenerateJWT(u)
No branch requires a WebAuthn assertion during password login when
EnabledPasskey() is true. The root cause is the mismatch between the
policy definition (Enabled2FA() = OTP or passkey) and the
enforcement check (EnabledOTP() only).
The same EnabledOTP()-only gating in RequireSecureSession()
(internal/middleware/secure_session.go) means passkey-only users are also
exempted from step-up on sensitive actions.
Proof of Concept
Tested against nginx-ui built from source (go build -tags unembed) on
127.0.0.1:9000, with WebAuthn configured and a victim account that has a
registered passkey and no TOTP. The vulnerable code is identical on the
production main branch (api/user/auth.go Login gates on u.EnabledOTP()
only; verified at commit 6c86e5a, 2026-05-17).
Account state advertised by GET /api/2fa_status:
{"enabled":true,"otp_status":false,"passkey_status":true, ...}
Attacker logs in with password only (POST /api/login, encrypted params as
the client normally sends):
HTTP 200
{"message":"ok","code":200,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}
code: 200 + a valid JWT = an authenticated session, with the passkey never
used. For comparison, the identical account with a TOTP secret instead correctly
returns the second-factor challenge:
HTTP 200
{"message":"The user has enabled 2FA","code":199}
| Account state | POST /api/login (password only) |
|---|---|
| Passkey registered, no TOTP | code 200 + JWT — 2FA NOT enforced |
| TOTP registered | code 199 — 2FA challenge enforced |
This isolates the defect: the login path enforces OTP but ignores passkeys.
Impact
- Any account protected only by a passkey is reduced to password-only authentication. An attacker who obtains the password (phishing, reuse, leak) gains full access despite the registered security key.
- In nginx-ui all authenticated users are effectively administrators and the terminal feature grants a host shell, so account takeover leads to full control of the managed nginx instance / host.
- Users are given a false sense of security: the UI shows the account as 2FA-enabled while the second factor is not enforced at login.
Remediation
- Gate the second-factor decision on
u.Enabled2FA()(notu.EnabledOTP()) inLogin, in both SSO callbacks, and inRequireSecureSession(). - For a passkey-only user logging in with a password, return a
"passkey assertion required" challenge and complete login only after a
successful WebAuthn assertion (the
begin_passkey_login/finish_passkey_loginflow already exists and should be required as the second step). - Centralize session-token issuance so no login entry point can skip the 2FA decision.
Affected components
api/user/auth.go—Loginmodel/user.go—EnabledOTP,EnabledPasskey,Enabled2FA,AfterFindapi/user/2fa.go—get2FAStatusinternal/middleware/secure_session.go—RequireSecureSession
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/0xJacky/Nginx-UI"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.10-0.20250517140552-daee3ac7ade1"
},
{
"fixed": "1.9.10-0.20260728074558-95cd21b70814"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107808"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-305",
"CWE-308"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T17:08:15Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nnginx-ui supports two second-factor methods \u2014 TOTP (OTP) and WebAuthn passkeys \u2014\nand reports an account as 2FA-enabled when **either** is configured. However, the\npassword login endpoint (`POST /api/login`) only enforces a second factor when a\n**TOTP secret** is present. An account that has registered a **passkey but no\nTOTP** is logged in after password verification alone \u2014 the passkey is never\nrequested. This silently downgrades a passkey-protected account to single-factor\n(password-only) authentication.\n\n## Details\n\nThe account\u0027s 2FA policy treats passkeys as a valid factor (`model/user.go`):\n\n```go\nfunc (u *User) EnabledOTP() bool { return len(u.OTPSecret) != 0 }\nfunc (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }\nfunc (u *User) Enabled2FA() bool { return u.EnabledOTP() || u.EnabledPasskey() }\n\nfunc (u *User) AfterFind(_ *gorm.DB) error {\n u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`\n return nil\n}\n```\n\nBut the login handler only checks `EnabledOTP()` (`api/user/auth.go`, `Login`):\n\n```go\nu, err := user.Login(json.Name, json.Password)\n...\nif u.EnabledOTP() { // \u003c-- only TOTP is enforced\n if json.OTP == \"\" \u0026\u0026 json.RecoveryCode == \"\" {\n c.JSON(http.StatusOK, LoginResponse{Message: \"The user has enabled 2FA\", Code: Enabled2FA}) // 199\n user.BanIP(clientIP)\n return\n }\n if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }\n secureSessionID = user.SetSecureSessionID(u.ID)\n}\n\n// Passkey-only accounts fall through to here and receive a full session token:\naccessToken, err := user.GenerateJWT(u)\n```\n\nNo branch requires a WebAuthn assertion during password login when\n`EnabledPasskey()` is true. The root cause is the mismatch between the\n**policy definition** (`Enabled2FA()` = OTP **or** passkey) and the\n**enforcement check** (`EnabledOTP()` only).\n\nThe same `EnabledOTP()`-only gating in `RequireSecureSession()`\n(`internal/middleware/secure_session.go`) means passkey-only users are also\nexempted from step-up on sensitive actions.\n\n## Proof of Concept\n\nTested against nginx-ui built from source (`go build -tags unembed`) on\n`127.0.0.1:9000`, with WebAuthn configured and a victim account that has a\nregistered passkey and **no** TOTP. The vulnerable code is identical on the\nproduction `main` branch (`api/user/auth.go` `Login` gates on `u.EnabledOTP()`\nonly; verified at commit `6c86e5a`, 2026-05-17).\n\nAccount state advertised by `GET /api/2fa_status`:\n\n```json\n{\"enabled\":true,\"otp_status\":false,\"passkey_status\":true, ...}\n```\n\nAttacker logs in with **password only** (`POST /api/login`, encrypted params as\nthe client normally sends):\n\n```\nHTTP 200\n{\"message\":\"ok\",\"code\":200,\"token\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....\"}\n```\n\n`code: 200` + a valid JWT = an authenticated session, with the passkey never\nused. For comparison, the identical account with a TOTP secret instead correctly\nreturns the second-factor challenge:\n\n```\nHTTP 200\n{\"message\":\"The user has enabled 2FA\",\"code\":199}\n```\n\n| Account state | `POST /api/login` (password only) |\n|---|---|\n| Passkey registered, no TOTP | `code 200` + JWT \u2014 **2FA NOT enforced** |\n| TOTP registered | `code 199` \u2014 2FA challenge enforced |\n\nThis isolates the defect: the login path enforces OTP but ignores passkeys.\n\n## Impact\n\n- Any account protected **only** by a passkey is reduced to password-only\n authentication. An attacker who obtains the password (phishing, reuse, leak)\n gains full access despite the registered security key.\n- In nginx-ui all authenticated users are effectively administrators and the\n terminal feature grants a host shell, so account takeover leads to full\n control of the managed nginx instance / host.\n- Users are given a false sense of security: the UI shows the account as\n 2FA-enabled while the second factor is not enforced at login.\n\n## Remediation\n\n- Gate the second-factor decision on `u.Enabled2FA()` (not `u.EnabledOTP()`) in\n `Login`, in both SSO callbacks, and in `RequireSecureSession()`.\n- For a passkey-only user logging in with a password, return a\n \"passkey assertion required\" challenge and complete login only after a\n successful WebAuthn assertion (the `begin_passkey_login` / `finish_passkey_login`\n flow already exists and should be required as the second step).\n- Centralize session-token issuance so no login entry point can skip the 2FA\n decision.\n\n## Affected components\n\n- `api/user/auth.go` \u2014 `Login`\n- `model/user.go` \u2014 `EnabledOTP`, `EnabledPasskey`, `Enabled2FA`, `AfterFind`\n- `api/user/2fa.go` \u2014 `get2FAStatus`\n- `internal/middleware/secure_session.go` \u2014 `RequireSecureSession`",
"id": "GHSA-45gv-9wjv-xh7p",
"modified": "2026-10-09T17:08:15Z",
"published": "2026-10-09T17:08:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-45gv-9wjv-xh7p"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/commit/95cd21b70814e5d9a48a359aa238aeea1ac97429"
},
{
"type": "PACKAGE",
"url": "https://github.com/0xJacky/nginx-ui"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.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:H",
"type": "CVSS_V3"
}
],
"summary": "Nginx UI: Authentication bypass: password login does not enforce a passkey-only second factor (2FA bypass)"
}
GHSA-45JJ-6GXC-RH25
Vulnerability from github – Published: 2021-12-07 00:00 – Updated: 2021-12-08 00:01It was possible to bypass 2FA for LDAP users and access some specific pages with Basic Authentication in GitLab 14.1.1 and above.
{
"affected": [],
"aliases": [
"CVE-2021-39890"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-06T18:15:00Z",
"severity": "CRITICAL"
},
"details": "It was possible to bypass 2FA for LDAP users and access some specific pages with Basic Authentication in GitLab 14.1.1 and above.",
"id": "GHSA-45jj-6gxc-rh25",
"modified": "2021-12-08T00:01:53Z",
"published": "2021-12-07T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39890"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39890.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/341522"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-45JV-WV9V-QQFR
Vulnerability from github – Published: 2025-06-09 12:31 – Updated: 2025-06-09 12:31A vulnerability classified as problematic was found in Lucky LM-520-SC, LM-520-FSC and LM-520-FSC-SAM up to 20250321. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-5876"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-09T12:15:22Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as problematic was found in Lucky LM-520-SC, LM-520-FSC and LM-520-FSC-SAM up to 20250321. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-45jv-wv9v-qqfr",
"modified": "2025-06-09T12:31:13Z",
"published": "2025-06-09T12:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5876"
},
{
"type": "WEB",
"url": "https://github.com/zeke2997/cve_request_LuckyTechnologyLtd"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.311635"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.311635"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.585821"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/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"
}
]
}
GHSA-45QR-3X63-9J8C
Vulnerability from github – Published: 2022-06-18 00:00 – Updated: 2022-06-30 00:00A vulnerability classified as critical was found in uTorrent. This vulnerability affects unknown code of the component PRNG. The manipulation leads to weak authentication. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to upgrade the affected component.
{
"affected": [],
"aliases": [
"CVE-2018-25043"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-17T13:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability classified as critical was found in uTorrent. This vulnerability affects unknown code of the component PRNG. The manipulation leads to weak authentication. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. It is recommended to upgrade the affected component.",
"id": "GHSA-45qr-3x63-9j8c",
"modified": "2022-06-30T00:00:39Z",
"published": "2022-06-18T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25043"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1524"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.113806"
},
{
"type": "WEB",
"url": "http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/efaq.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-45RH-4228-3JMV
Vulnerability from github – Published: 2022-05-01 18:32 – Updated: 2022-05-01 18:32cp_memberedit.php in LightBlog 8.4.1.1 does not check for administrative credentials when processing an admin action, which allows remote authenticated users to increase the privileges of any account.
{
"affected": [],
"aliases": [
"CVE-2007-5374"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-10-11T10:17:00Z",
"severity": "MODERATE"
},
"details": "cp_memberedit.php in LightBlog 8.4.1.1 does not check for administrative credentials when processing an admin action, which allows remote authenticated users to increase the privileges of any account.",
"id": "GHSA-45rh-4228-3jmv",
"modified": "2022-05-01T18:32:42Z",
"published": "2022-05-01T18:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5374"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/37050"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/4505"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27164"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/25990"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-45X7-38M2-H2JC
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15Zoho ManageEngine ADManager Plus version 7110 and prior allows account takeover via SSO.
{
"affected": [],
"aliases": [
"CVE-2021-37927"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-22T14:15:00Z",
"severity": "CRITICAL"
},
"details": "Zoho ManageEngine ADManager Plus version 7110 and prior allows account takeover via SSO.",
"id": "GHSA-45x7-38m2-h2jc",
"modified": "2022-05-24T19:15:25Z",
"published": "2022-05-24T19:15:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37927"
},
{
"type": "WEB",
"url": "https://www.manageengine.com"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/ad-manager/release-notes.html#7111"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/self-service-password/release-notes.html#6110"
}
],
"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-45X9-Q6VJ-CQGQ
Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2022-10-13 20:11Apache Shiro before 1.10.0, Authentication Bypass Vulnerability in Shiro when forwarding or including via RequestDispatcher.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.shiro:shiro-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-40664"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-12T19:43:15Z",
"nvd_published_at": "2022-10-12T07:15:00Z",
"severity": "CRITICAL"
},
"details": "Apache Shiro before 1.10.0, Authentication Bypass Vulnerability in Shiro when forwarding or including via RequestDispatcher.",
"id": "GHSA-45x9-q6vj-cqgq",
"modified": "2022-10-13T20:11:12Z",
"published": "2022-10-12T12:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40664"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/shiro"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/loc2ktxng32xpy7lfwxto13k4lvnhjwg"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20221118-0005"
},
{
"type": "WEB",
"url": "https://shiro.apache.org/blog/2022/10/10/2022/apache-shiro-1101-released.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/10/12/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/10/12/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/10/13/1"
}
],
"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"
}
],
"summary": "Apache Shiro Authentication Bypass vulnerability"
}
GHSA-4643-H6PQ-84F9
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-06-03 00:00SFCB (Small Footprint CIM Broker) as used in ESXi has an authentication bypass vulnerability. A malicious actor with network access to port 5989 on ESXi may exploit this issue to bypass SFCB authentication by sending a specially crafted request.
{
"affected": [],
"aliases": [
"CVE-2021-21994"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-13T19:15:00Z",
"severity": "CRITICAL"
},
"details": "SFCB (Small Footprint CIM Broker) as used in ESXi has an authentication bypass vulnerability. A malicious actor with network access to port 5989 on ESXi may exploit this issue to bypass SFCB authentication by sending a specially crafted request.",
"id": "GHSA-4643-h6pq-84f9",
"modified": "2022-06-03T00:00:38Z",
"published": "2022-05-24T19:07:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21994"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2021-0014.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4643-VGH5-4R2C
Vulnerability from github – Published: 2022-04-21 01:57 – Updated: 2022-04-21 01:57stonith-ng in pacemaker and cluster-glue passed passwords as commandline parameters, making it possible for local attackers to gain access to passwords of the HA stack and potentially influence its operations. This is fixed in cluster-glue 1.0.6 and newer, and pacemaker 1.1.3 and newer.
{
"affected": [],
"aliases": [
"CVE-2010-2496"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-18T13:15:00Z",
"severity": "MODERATE"
},
"details": "stonith-ng in pacemaker and cluster-glue passed passwords as commandline parameters, making it possible for local attackers to gain access to passwords of the HA stack and potentially influence its operations. This is fixed in cluster-glue 1.0.6 and newer, and pacemaker 1.1.3 and newer.",
"id": "GHSA-4643-vgh5-4r2c",
"modified": "2022-04-21T01:57:57Z",
"published": "2022-04-21T01:57:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2496"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2010-2496"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.