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.
6866 vulnerabilities reference this CWE, most recent first.
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-HQ2R-WHW2-GR82
Vulnerability from github – Published: 2026-08-04 03:31 – Updated: 2026-08-04 03:31An improper authentication vulnerability in the "social_login.cgi" CGI program in Zyxel WAX650S firmware versions through 7.10(ABRM.4)C0 could allow an attacker on the WLAN to bypass captive portal authentication.
{
"affected": [],
"aliases": [
"CVE-2026-8508"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-04T03:16:26Z",
"severity": "MODERATE"
},
"details": "An improper authentication vulnerability in the \"social_login.cgi\" CGI program in Zyxel WAX650S firmware versions through 7.10(ABRM.4)C0 could allow an attacker on the WLAN to bypass captive portal authentication.",
"id": "GHSA-hq2r-whw2-gr82",
"modified": "2026-08-04T03:31:10Z",
"published": "2026-08-04T03:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8508"
},
{
"type": "WEB",
"url": "https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-command-injection-and-improper-authentication-vulnerabilities-in-certain-aps-fwa7-and-security-routers-08-04-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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"
}
]
}
GHSA-HQ9P-PM7W-8P54
Vulnerability from github – Published: 2025-06-11 14:44 – Updated: 2025-06-11 16:17Impact
When the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.
Patches
TBD
Workarounds
Configure sslMode=verify-full to prevent MITM attacks.
References
- https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256
- https://datatracker.ietf.org/doc/html/rfc7677
- https://datatracker.ietf.org/doc/html/rfc5802
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.postgresql:postgresql"
},
"ranges": [
{
"events": [
{
"introduced": "42.7.4"
},
{
"fixed": "42.7.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49146"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-11T14:44:04Z",
"nvd_published_at": "2025-06-11T15:15:42Z",
"severity": "HIGH"
},
"details": "### Impact\nWhen the PostgreSQL JDBC driver is configured with channel binding set to `required` (default value is `prefer`), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.\n\n### Patches\nTBD\n\n### Workarounds\n\nConfigure `sslMode=verify-full` to prevent MITM attacks.\n\n### References\n\n* https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256\n* https://datatracker.ietf.org/doc/html/rfc7677\n* https://datatracker.ietf.org/doc/html/rfc5802",
"id": "GHSA-hq9p-pm7w-8p54",
"modified": "2025-06-11T16:17:03Z",
"published": "2025-06-11T14:44:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-hq9p-pm7w-8p54"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49146"
},
{
"type": "WEB",
"url": "https://github.com/pgjdbc/pgjdbc/commit/9217ed16cb2918ab1b6b9258ae97e6ede244d8a0"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc5802"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc7677"
},
{
"type": "PACKAGE",
"url": "https://github.com/pgjdbc/pgjdbc"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256"
}
],
"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"
}
],
"summary": "pgjdbc Client Allows Fallback to Insecure Authentication Despite channelBinding=require Configuration"
}
GHSA-HQFQ-GMW2-W65W
Vulnerability from github – Published: 2022-03-05 00:00 – Updated: 2022-03-17 00:03When the device is in factory state, it can be access the shell without adb authentication process. The LG ID is LVE-SMP-210010.
{
"affected": [],
"aliases": [
"CVE-2022-23729"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-04T16:15:00Z",
"severity": "HIGH"
},
"details": "When the device is in factory state, it can be access the shell without adb authentication process. The LG ID is LVE-SMP-210010.",
"id": "GHSA-hqfq-gmw2-w65w",
"modified": "2022-03-17T00:03:24Z",
"published": "2022-03-05T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23729"
},
{
"type": "WEB",
"url": "https://lgsecurity.lge.com/bulletins/mobile"
}
],
"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"
}
]
}
GHSA-HQP7-G6VH-8MF8
Vulnerability from github – Published: 2026-10-06 09:31 – Updated: 2026-10-06 09:31Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret.
UAA’s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret.
Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client.
{
"affected": [],
"aliases": [
"CVE-2026-59358"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T07:16:59Z",
"severity": "HIGH"
},
"details": "Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client\u2019s configured secret.\n\n\n\nUAA\u2019s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow \u2014 scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none \u2014 satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client\u2019s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client\u2019s actual secret.\n\n\n\nExploitation requires a valid user access token (the attacker\u2019s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id \u2014 a non-default combination. Practical impact scales with the authorities assigned to that client.",
"id": "GHSA-hqp7-g6vh-8mf8",
"modified": "2026-10-06T09:31:23Z",
"published": "2026-10-06T09:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59358"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/blog/cve-2026-59358-uaa-oauth-token-endpoint-vulnerability-allows-user-access-token-reuse-for-client_credentials-grant-type"
}
],
"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:N/SC:N/SI:N/SA:N/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-HQQ8-9486-V237
Vulnerability from github – Published: 2026-09-03 18:31 – Updated: 2026-09-03 18:31ColdFusion is affected by an Improper Authentication vulnerability that could result in privilege escalation. An attacker could leverage this vulnerability to gain limited read and write access. The vulnerable component is restricted to an administrative network zone by default. Exploitation of this issue does not require user interaction. Scope is changed.
{
"affected": [],
"aliases": [
"CVE-2026-83961"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T16:18:23Z",
"severity": "HIGH"
},
"details": "ColdFusion is affected by an Improper Authentication vulnerability that could result in privilege escalation. An attacker could leverage this vulnerability to gain limited read and write access. The vulnerable component is restricted to an administrative network zone by default. Exploitation of this issue does not require user interaction. Scope is changed.",
"id": "GHSA-hqq8-9486-v237",
"modified": "2026-09-03T18:31:46Z",
"published": "2026-09-03T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83961"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/coldfusion/apsb26-90.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HQQV-6F9Q-X66Q
Vulnerability from github – Published: 2025-06-30 18:31 – Updated: 2025-06-30 18:31A vulnerability, which was classified as critical, was found in TOTOLINK T6 4.1.5cu.748_B20211015. This affects the function Form_Login of the file /formLoginAuth.htm. The manipulation of the argument authCode/goURL leads to missing authentication. The attack needs to be initiated within the local network. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-6916"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-30T17:15:34Z",
"severity": "HIGH"
},
"details": "A vulnerability, which was classified as critical, was found in TOTOLINK T6 4.1.5cu.748_B20211015. This affects the function Form_Login of the file /formLoginAuth.htm. The manipulation of the argument authCode/goURL leads to missing authentication. The attack needs to be initiated within the local network. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-hqqv-6f9q-x66q",
"modified": "2025-06-30T18:31:51Z",
"published": "2025-06-30T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6916"
},
{
"type": "WEB",
"url": "https://github.com/c0nyy/IoT_vuln/blob/main/TOTOLINK%20T6%20Vuln.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.314409"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.314409"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.605101"
},
{
"type": "WEB",
"url": "https://www.totolink.net"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/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"
}
]
}
GHSA-HR69-FV9H-FXGR
Vulnerability from github – Published: 2022-05-01 18:29 – Updated: 2022-05-01 18:29NetSupport Manager Client before 10.20.0004 allows remote attackers to bypass the (1) basic and (2) authentication schemes by spoofing the NetSupport Manager.
{
"affected": [],
"aliases": [
"CVE-2007-5057"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-09-24T22:17:00Z",
"severity": "HIGH"
},
"details": "NetSupport Manager Client before 10.20.0004 allows remote attackers to bypass the (1) basic and (2) authentication schemes by spoofing the NetSupport Manager.",
"id": "GHSA-hr69-fv9h-fxgr",
"modified": "2022-05-01T18:29:30Z",
"published": "2022-05-01T18:29:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5057"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/36726"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/26927"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/3163"
},
{
"type": "WEB",
"url": "http://www.netsupportsoftware.com/support/td.asp?td=543\u0026Site=nsltd\u0026Lang="
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/480240/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/25761"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1018732"
}
],
"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.