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.
6778 vulnerabilities reference this CWE, most recent first.
GHSA-FHPW-7642-FF4W
Vulnerability from github – Published: 2022-05-24 17:04 – Updated: 2022-10-14 12:00An authentication issue was addressed with improved state management. This issue is fixed in macOS Mojave 10.14.5. A user may be unexpectedly logged in to another user?s account.
{
"affected": [],
"aliases": [
"CVE-2019-8634"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "An authentication issue was addressed with improved state management. This issue is fixed in macOS Mojave 10.14.5. A user may be unexpectedly logged in to another user?s account.",
"id": "GHSA-fhpw-7642-ff4w",
"modified": "2022-10-14T12:00:21Z",
"published": "2022-05-24T17:04:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8634"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT210119"
}
],
"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"
}
]
}
GHSA-FHQX-HM87-5JCM
Vulnerability from github – Published: 2022-05-17 00:51 – Updated: 2022-05-17 00:51Apple OS X before 10.10.5 does not properly implement authentication, which allows local users to obtain admin privileges via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2015-3775"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-08-16T23:59:00Z",
"severity": "HIGH"
},
"details": "Apple OS X before 10.10.5 does not properly implement authentication, which allows local users to obtain admin privileges via unspecified vectors.",
"id": "GHSA-fhqx-hm87-5jcm",
"modified": "2022-05-17T00:51:46Z",
"published": "2022-05-17T00:51:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-3775"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT205031"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2015/Aug/msg00001.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/76340"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1033276"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FHVP-9HCJ-6M33
Vulnerability from github – Published: 2026-04-14 23:14 – Updated: 2026-04-24 20:39Summary
The OIDC authentication provider unconditionally sets SkipClientIDCheck: true in the go-oidc verifier configuration, disabling the standard audience (aud) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia.
Impact
In deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different client_id/aud) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC.
All versions using OIDC authentication are affected.
Details
In oxiad/common/rpc/auth/oidc.go, both createStaticKeyVerifier() and createRemoteVerifier() set SkipClientIDCheck: true. While a custom audience check exists in Authenticate(), the library-level check — which validates the aud claim against the expected client_id — is completely bypassed.
Patches
Fixed by removing SkipClientIDCheck: true and setting the ClientID field from the configured AllowedAudiences.
Workarounds
Ensure network-level isolation so that only trusted services can reach the Oxia gRPC endpoints.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.16.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/oxia-db/oxia"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40946"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T23:14:49Z",
"nvd_published_at": "2026-04-21T22:16:20Z",
"severity": "CRITICAL"
},
"details": "### Summary\nThe OIDC authentication provider unconditionally sets `SkipClientIDCheck: true` in the `go-oidc` verifier configuration, disabling the standard audience (`aud`) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia.\n\n### Impact\nIn deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different `client_id`/`aud`) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC.\n\nAll versions using OIDC authentication are affected.\n\n### Details\nIn `oxiad/common/rpc/auth/oidc.go`, both `createStaticKeyVerifier()` and `createRemoteVerifier()` set `SkipClientIDCheck: true`. While a custom audience check exists in `Authenticate()`, the library-level check \u2014 which validates the `aud` claim against the expected `client_id` \u2014 is completely bypassed.\n\n### Patches\nFixed by removing `SkipClientIDCheck: true` and setting the `ClientID` field from the configured `AllowedAudiences`.\n\n### Workarounds\nEnsure network-level isolation so that only trusted services can reach the Oxia gRPC endpoints.",
"id": "GHSA-fhvp-9hcj-6m33",
"modified": "2026-04-24T20:39:53Z",
"published": "2026-04-14T23:14:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oxia-db/oxia/security/advisories/GHSA-fhvp-9hcj-6m33"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40946"
},
{
"type": "PACKAGE",
"url": "https://github.com/oxia-db/oxia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Oxia has an OIDC token audience validation bypass via SkipClientIDCheck"
}
GHSA-FHVV-P968-6VVJ
Vulnerability from github – Published: 2022-09-18 00:00 – Updated: 2022-09-22 17:28Snipe-IT prior to 6.0.10 is vulnerable to Improper Authentication. A user without the View and Modify License Files permission may access files uploaded to licenses as long as they have the View permission for licenses.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "snipe/snipe-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3173"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-20T18:19:21Z",
"nvd_published_at": "2022-09-17T07:15:00Z",
"severity": "MODERATE"
},
"details": "Snipe-IT prior to 6.0.10 is vulnerable to Improper Authentication. A user without the `View and Modify License Files` permission may access files uploaded to licenses as long as they have the `View` permission for licenses.",
"id": "GHSA-fhvv-p968-6vvj",
"modified": "2022-09-22T17:28:56Z",
"published": "2022-09-18T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3173"
},
{
"type": "WEB",
"url": "https://github.com/snipe/snipe-it/commit/dcab1381e7ee0b7fd1df3a34750dbff4b79185b2"
},
{
"type": "PACKAGE",
"url": "https://github.com/snipe/snipe-it"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/6d8ffcc6-c6e3-4385-8ead-bdbbbacf79e9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Snipe-IT vulnerable to Improper Authentication"
}
GHSA-FJ7H-V25Q-FVPR
Vulnerability from github – Published: 2022-06-17 00:01 – Updated: 2022-06-29 00:00An issue was discovered on D-Link DIR-850L 1.21WW devices. A partially completed WPA handshake is sufficient for obtaining full access to the wireless network. A client can access the network by sending packets on Data Frames to the AP without encryption.
{
"affected": [],
"aliases": [
"CVE-2018-18907"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-16T22:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on D-Link DIR-850L 1.21WW devices. A partially completed WPA handshake is sufficient for obtaining full access to the wireless network. A client can access the network by sending packets on Data Frames to the AP without encryption.",
"id": "GHSA-fj7h-v25q-fvpr",
"modified": "2022-06-29T00:00:25Z",
"published": "2022-06-17T00:01:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18907"
},
{
"type": "WEB",
"url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10097"
},
{
"type": "WEB",
"url": "https://www.synopsys.com/blogs/software-security/wpa2-encryption-bypass-defensics-fuzzing"
},
{
"type": "WEB",
"url": "http://us.dlink.com/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FJ83-J657-QPV5
Vulnerability from github – Published: 2022-05-17 05:52 – Updated: 2022-05-17 05:52AJ Square Free Polling Script (AJPoll) allows remote attackers to bypass authentication and create new polls via a direct request to admin/include/newpoll.php, a different vector than CVE-2008-7045. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.
{
"affected": [],
"aliases": [
"CVE-2008-7046"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-08-24T10:30:00Z",
"severity": "MODERATE"
},
"details": "AJ Square Free Polling Script (AJPoll) allows remote attackers to bypass authentication and create new polls via a direct request to admin/include/newpoll.php, a different vector than CVE-2008-7045. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.",
"id": "GHSA-fj83-j657-qpv5",
"modified": "2022-05-17T05:52:20Z",
"published": "2022-05-17T05:52:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-7046"
},
{
"type": "WEB",
"url": "http://osvdb.org/49779"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/32600"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FJ8V-W5XG-JHC7
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10AIMANAGER before B115 on MONITORAPP Application Insight Web Application Firewall (AIWAF) devices with Manager 2.1.0 has Improper Authentication. An attacker can gain administrative access by modifying the response to an authentication check request.
{
"affected": [],
"aliases": [
"CVE-2021-36921"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-12T18:15:00Z",
"severity": "HIGH"
},
"details": "AIMANAGER before B115 on MONITORAPP Application Insight Web Application Firewall (AIWAF) devices with Manager 2.1.0 has Improper Authentication. An attacker can gain administrative access by modifying the response to an authentication check request.",
"id": "GHSA-fj8v-w5xg-jhc7",
"modified": "2022-05-24T19:10:51Z",
"published": "2022-05-24T19:10:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36921"
},
{
"type": "WEB",
"url": "https://github.com/fireeye/Vulnerability-Disclosures/blob/master/FEYE-2021-0021/FEYE-2021-0021.md"
},
{
"type": "WEB",
"url": "https://github.com/monitorapp-aicc/report/wiki/CVE-2021-36921"
},
{
"type": "WEB",
"url": "https://www.monitorapp.com/waf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FJ9W-C36G-H5X8
Vulnerability from github – Published: 2026-09-17 17:18 – Updated: 2026-09-17 17:18Impact
For SCRAM, and for Digest with mutual authentication, the client computes the server's verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client's only signal that the peer does not know the secret.
Affected versions
- 3.x: 3.0.8 through 3.0.11
Earlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.
Patches
Fixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.
Known limitations
Verification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.
Verification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.
Details
In the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Known limitation
This fix does not cover Digest exchanges negotiated with qop="auth-int". Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.
A peer that controls the challenge can select this deliberately by offering qop="auth-int" alone, which switches mutual authentication off for the whole exchange. Offering auth,auth-int does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.11"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.8"
},
{
"fixed": "3.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-85716"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:18:39Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nFor SCRAM, and for Digest with mutual authentication, the client computes the server\u0027s verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value and the issue is inert; it matters over a non TLS transport, or when the transport is already compromised, where it removes the client\u0027s only signal that the peer does not know the secret.\n\n### Affected versions\n* 3.x: 3.0.8 through 3.0.11\n\nEarlier 3.0.x releases are not affected: neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8. The 2.x line is not affected either: it has no SCRAM support, and its interceptor chain does not implement Digest mutual authentication, so there is no verification result to act on.\n\n### Patches\nFixed in 3.0.12. A present ServerSignature (SCRAM) or rspauth (Digest) that does not verify now fails the request instead of being logged and ignored, on both the origin and proxy paths.\n\n### Known limitations\nVerification is only enforced when the value is present and the parameters the client sent can be recovered. A response that omits the Authentication-Info header entirely, or that carries the header without a recognisable verification parameter, is still accepted: a well behaved server may send the value in chunked trailers, which the client does not read. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth (an unterminated quote, an empty unquoted value, or a bare rspauth token) as absent and accepts the response. Enforcing presence is tracked as a follow up.\n\nVerification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed.\n\n### Details\nIn the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered. Both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent.\n\nNote that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.\n\n### Known limitation\n\nThis fix does not cover Digest exchanges negotiated with `qop=\"auth-int\"`. Under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point. The client logs a warning and delivers the response without enforcing mutual authentication.\n\nA peer that controls the challenge can select this deliberately by offering `qop=\"auth-int\"` alone, which switches mutual authentication off for the whole exchange. Offering `auth,auth-int` does not work, because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4.",
"id": "GHSA-fj9w-c36g-h5x8",
"modified": "2026-09-17T17:18:39Z",
"published": "2026-09-17T17:18:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-fj9w-c36g-h5x8"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/pull/2235"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/10b3db9910f0bbad2ea3dc7c7553bae12bc4a5e4"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/685173afea07892462071d966ef6ce5c88cbc66f"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/7fe8700fd5b46c668cee7774624f36b87b9dd32a"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncHttpClient doesn\u0027t verify SCRAM and Digest mutual-authentication responses"
}
GHSA-FJCX-6Q79-F4VV
Vulnerability from github – Published: 2026-08-18 21:33 – Updated: 2026-08-18 21:33Vulnerability in the Oracle Financial Services Enterprise Case Management product of Oracle Financial Services Applications (component: Web UI). Supported versions that are affected are 8.0.8.2 and 8.1.2.11. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Enterprise Case Management. Successful attacks of this vulnerability can result in takeover of Oracle Financial Services Enterprise Case Management. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-70922"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T21:17:50Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Financial Services Enterprise Case Management product of Oracle Financial Services Applications (component: Web UI). Supported versions that are affected are 8.0.8.2 and 8.1.2.11. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Enterprise Case Management. Successful attacks of this vulnerability can result in takeover of Oracle Financial Services Enterprise Case Management. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-fjcx-6q79-f4vv",
"modified": "2026-08-18T21:33:12Z",
"published": "2026-08-18T21:33:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70922"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspuaug2026.html"
}
],
"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"
}
]
}
GHSA-FJF4-CC29-RVFV
Vulnerability from github – Published: 2022-05-17 02:56 – Updated: 2022-05-17 02:56IBM QRadar 7.2 does not perform an authentication check for a critical resource or functionality allowing anonymous users access to protected areas. IBM Reference #: 1999545.
{
"affected": [],
"aliases": [
"CVE-2016-9729"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-07T17:59:00Z",
"severity": "MODERATE"
},
"details": "IBM QRadar 7.2 does not perform an authentication check for a critical resource or functionality allowing anonymous users access to protected areas. IBM Reference #: 1999545.",
"id": "GHSA-fjf4-cc29-rvfv",
"modified": "2022-05-17T02:56:07Z",
"published": "2022-05-17T02:56:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9729"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg21999545"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96538"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.