CWE-303
AllowedIncorrect Implementation of Authentication Algorithm
Abstraction: Base · Status: Draft
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
153 vulnerabilities reference this CWE, most recent first.
GHSA-4R4X-7F2R-2F4C
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2025-04-20 03:34Nextcloud Server before 9.0.54 and 10.0.1 & ownCloud Server before 9.1.2, 9.0.6, and 8.2.9 suffer from SMB User Authentication Bypass. Nextcloud/ownCloud include an optional and not by default enabled SMB authentication component that allows authenticating users against an SMB server. This backend is implemented in a way that tries to connect to a SMB server and if that succeeded consider the user logged-in. The backend did not properly take into account SMB servers that have any kind of anonymous auth configured. This is the default on SMB servers nowadays and allows an unauthenticated attacker to gain access to an account without valid credentials. Note: The SMB backend is disabled by default and requires manual configuration in the Nextcloud/ownCloud config file. If you have not configured the SMB backend then you're not affected by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2016-9463"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-28T02:59:00Z",
"severity": "HIGH"
},
"details": "Nextcloud Server before 9.0.54 and 10.0.1 \u0026 ownCloud Server before 9.1.2, 9.0.6, and 8.2.9 suffer from SMB User Authentication Bypass. Nextcloud/ownCloud include an optional and not by default enabled SMB authentication component that allows authenticating users against an SMB server. This backend is implemented in a way that tries to connect to a SMB server and if that succeeded consider the user logged-in. The backend did not properly take into account SMB servers that have any kind of anonymous auth configured. This is the default on SMB servers nowadays and allows an unauthenticated attacker to gain access to an account without valid credentials. Note: The SMB backend is disabled by default and requires manual configuration in the Nextcloud/ownCloud config file. If you have not configured the SMB backend then you\u0027re not affected by this vulnerability.",
"id": "GHSA-4r4x-7f2r-2f4c",
"modified": "2025-04-20T03:34:57Z",
"published": "2022-05-13T01:38:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9463"
},
{
"type": "WEB",
"url": "https://github.com/nextcloud/apps/commit/b85ace6840b8a6704641086bc3b8eb8e81cb2274"
},
{
"type": "WEB",
"url": "https://github.com/nextcloud/apps/commit/decb91fd31f4ffab191cbf09ce4e5c55c67a4087"
},
{
"type": "WEB",
"url": "https://github.com/owncloud/apps/commit/16cbccfc946c8711721fa684d78135ca1fb64791"
},
{
"type": "WEB",
"url": "https://github.com/owncloud/apps/commit/5d47e7b52646cf79edadd78ce10c754290cbb732"
},
{
"type": "WEB",
"url": "https://github.com/owncloud/apps/commit/a0e07b7ddd5a5fd850a6e07f8457d05b76a300b3"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/148151"
},
{
"type": "WEB",
"url": "https://nextcloud.com/security/advisory/?id=nc-sa-2016-006"
},
{
"type": "WEB",
"url": "https://owncloud.org/security/advisory/?id=oc-sa-2016-017"
},
{
"type": "WEB",
"url": "https://rhinosecuritylabs.com/2016/10/operation-ownedcloud-exploitation-post-exploitation-persistence"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4V46-QWHW-4224
Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30Windows Kerberos Elevation of Privilege Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-26248"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T17:15:46Z",
"severity": "HIGH"
},
"details": "Windows Kerberos Elevation of Privilege Vulnerability",
"id": "GHSA-4v46-qwhw-4224",
"modified": "2024-04-09T18:30:26Z",
"published": "2024-04-09T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26248"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26248"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4V48-4Q5M-8VX4
Vulnerability from github – Published: 2022-12-05 22:01 – Updated: 2026-04-15 20:59Impact
Prometheus can be secured by a web.yml file that specifies usernames and hashed passwords for basic authentication.
Passwords are hashed with bcrypt, which means that even if you have access to the hash, it is very hard to find the original password back.
However, a flaw in the way this mechanism was implemented in the exporter toolkit makes it possible with people who know the hashed password to authenticate against Prometheus.
A request can be forged by an attacker to poison the internal cache used to cache the computation of hashes and make subsequent requests successful. This cache is used in both happy and unhappy scenarios in order to limit side channel attacks that could tell an attacker if a user is present in the file or not.
Patches
Prometheus 2.37.4 (LTS) and 2.40.4 have been released to address this issue.
Workarounds
There is no workaround but attacker must have access to the hashed password, stored in disk, to bypass the authentication.
Credit
We want to thank Lei Wan for reporting this security issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/prometheus/prometheus"
},
"ranges": [
{
"events": [
{
"introduced": "2.24.1"
},
{
"fixed": "2.37.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/prometheus/prometheus"
},
"ranges": [
{
"events": [
{
"introduced": "2.38.0"
},
{
"fixed": "2.40.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/prometheus/prometheus/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.24.1"
},
{
"fixed": "2.37.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/prometheus/prometheus/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.38.0"
},
{
"fixed": "2.40.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-05T22:01:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nPrometheus can be secured by a web.yml file that specifies usernames and hashed passwords for basic authentication.\n\nPasswords are hashed with bcrypt, which means that even if you have access to the hash, it is very hard to find the original password back.\n\nHowever, a flaw in the way this mechanism was implemented in the [exporter toolkit](https://github.com/prometheus/exporter-toolkit) makes it possible with people who know the hashed password to authenticate against Prometheus.\n\nA request can be forged by an attacker to poison the internal cache used to cache the computation of hashes and make subsequent requests successful. This cache is used in both happy and unhappy scenarios in order to limit side channel attacks that could tell an attacker if a user is present in the file or not.\n\n### Patches\n\nPrometheus 2.37.4 ([LTS](https://prometheus.io/docs/introduction/release-cycle/)) and 2.40.4 have been released to address this issue.\n\n### Workarounds\n\nThere is no workaround but attacker must have access to the hashed password, stored in disk, to bypass the authentication.\n\n### Credit\n\nWe want to thank Lei Wan for reporting this security issue.",
"id": "GHSA-4v48-4q5m-8vx4",
"modified": "2026-04-15T20:59:32Z",
"published": "2022-12-05T22:01:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/prometheus/prometheus/security/advisories/GHSA-4v48-4q5m-8vx4"
},
{
"type": "WEB",
"url": "https://github.com/prometheus/prometheus/commit/31a2db3ae9c0f4b486b6895973beabc1d1beac93"
},
{
"type": "WEB",
"url": "https://github.com/prometheus/prometheus/releases/tag/v2.37.4"
},
{
"type": "WEB",
"url": "https://github.com/prometheus/prometheus/releases/tag/v2.40.4"
},
{
"type": "PACKAGE",
"url": "github.com/prometheus/prometheus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Prometheus vulnerable to basic authentication bypass"
}
GHSA-4W7R-3222-8H6V
Vulnerability from github – Published: 2026-03-17 19:42 – Updated: 2026-03-20 21:22Impact
Some specific (1 out of 256) User Supplied Secrets (USS) were not used, making the resulting Compound Device Identifier (CDI) the same as if no USS was provided.
Affected client applications: all client apps using the tkeyclient Go module.
Patches
Upgrade to v1.3.0.
NOTE WELL: For the affected end users upgrading an app containing
tkeyclient to v1.3.0 means their key material will change. An end
user can get their old keys by not entering any USS. Please make sure
to communicate this to end users.
Affected users
The steps required to assess whether your USS is vulnerable may vary
depending on the client application. The example below shows how to
perform the check using tkey-ssh-agent and the known vulnerable USS
adl.
- Insert the TKey into the client
- Run
tkey-ssh-agent -p --uss - When prompted for a User Supplied Secret, enter
adl - Note the public key and call it
pubkey-with-uss - Remove the TKey from the client
- Insert the TKey into the client again
- Run
tkey-ssh-agent -p - Note the public key and call it
pubkey-without-uss
Expected behavior:
pubkey-with-uss and pubkey-without-uss should not be equal.
Observed behavior:
pubkey-with-uss and pubkey-without-uss are equal.
Workaround
We recommend everyone using tkeyclient to update to v1.3.0 and
release new versions of the client apps using it.
However, end users that are unable to upgrade to a new version of a client app, the recommendation is to change to an unaffected USS. Include specific instructions for your client app.
Details
When loading the device app an optional 32 bytes USS digest is also sent. The intention is to ask the end user to enter a USS of arbitrary length, hash it, and then send a 32 bytes digest to TKey.
However, there was a bug when sending the digest from the client. The index in the outgoing buffer is wrong and overwrites the boolean defining if the USS is used or not.
This means that if the USS digest begins with a 0, the rest of the digest is not used at all. If it begins with something else, setting the boolean to true, the USS is used.
The exported LoadApp() function calls an internal helper function
loadApp() which contains this code:
if len(secretPhrase) == 0 {
tx[6] = 0
} else {
tx[6] = 1 // Note the 6 here
// Hash user's phrase as USS
uss := blake2s.Sum256(secretPhrase)
copy(tx[6:], uss[:]) // Note that 6 is used again
}
A side effect of this behavior is that only 31 bytes of the USS are used. This is not considered a security issue, but an option has been added to enforce use of the full USS. See the release notes for details. To avoid forcing all users to roll their keys, this option is disabled by default and must be explicitly enabled.
The fix
The fix focuses on solving the vulnerability only by: 1) use correct index, 2) always use the last 31 bytes of the USS:
if len(secretPhrase) == 0 {
tx[6] = 0
} else {
tx[6] = 1
// Hash user's phrase as USS
uss := blake2s.Sum256(secretPhrase)
copy(tx[7:], uss[1:])
}
This change means the key material of affected end users will change
compared to earlier versions of tkeyclient. They have the choice of:
- Not using a USS and keep their keys.
- Keep using their USS and use new generated keys.
- Use another USS and thus new keys.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tillitis/tkeyclient"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32953"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T19:42:31Z",
"nvd_published_at": "2026-03-20T05:16:14Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nSome specific (1 out of 256) User Supplied Secrets (USS) were not used,\nmaking the resulting Compound Device Identifier (CDI) the same as if no\nUSS was provided.\n\nAffected client applications: all client apps using the\n[tkeyclient](https://github.com/tillitis/tkeyclient) Go module.\n\n## Patches\n\nUpgrade to v1.3.0.\n\n**NOTE WELL**: For the affected end users upgrading an app containing\n`tkeyclient` to v1.3.0 means their key material will change. An end\nuser can get their old keys by not entering any USS. Please make sure\nto communicate this to end users.\n\n## Affected users\n\nThe steps required to assess whether your USS is vulnerable may vary\ndepending on the client application. The example below shows how to\nperform the check using `tkey-ssh-agent` and the known vulnerable USS\n`adl`.\n\n1. Insert the TKey into the client\n2. Run `tkey-ssh-agent -p --uss`\n3. When prompted for a User Supplied Secret, enter `adl`\n4. Note the public key and call it `pubkey-with-uss`\n5. Remove the TKey from the client\n6. Insert the TKey into the client again\n7. Run `tkey-ssh-agent -p`\n8. Note the public key and call it `pubkey-without-uss`\n\nExpected behavior:\n`pubkey-with-uss` and `pubkey-without-uss` should not be equal.\n\nObserved behavior:\n`pubkey-with-uss` and `pubkey-without-uss` are equal.\n\n## Workaround\n\nWe recommend everyone using `tkeyclient` to update to v1.3.0 and\nrelease new versions of the client apps using it.\n\nHowever, end users that are unable to upgrade to a new version of a client\napp, the recommendation is to change to an unaffected USS. Include\nspecific instructions for your client app.\n\n## Details\n\nWhen loading the device app an optional 32 bytes USS digest is also\nsent. The intention is to ask the end user to enter a USS of arbitrary\nlength, hash it, and then send a 32 bytes digest to TKey.\n\nHowever, there was a bug when sending the digest from the client. The\nindex in the outgoing buffer is wrong and overwrites the boolean\ndefining if the USS is used or not.\n\nThis means that if the USS digest begins with a 0, the rest of the\ndigest is not used at all. If it begins with something else, setting\nthe boolean to true, the USS is used.\n\nThe exported `LoadApp()` function calls an internal helper function\n`loadApp()` which contains this code:\n\n```go\n if len(secretPhrase) == 0 {\n tx[6] = 0\n } else {\n tx[6] = 1 // Note the 6 here\n // Hash user\u0027s phrase as USS\n uss := blake2s.Sum256(secretPhrase)\n copy(tx[6:], uss[:]) // Note that 6 is used again\n }\n```\n\nA side effect of this behavior is that only 31 bytes of the USS are\nused. This is not considered a security issue, but an option has been\nadded to enforce use of the full USS. See the release notes for\ndetails. To avoid forcing all users to roll their keys, this option is\ndisabled by default and must be explicitly enabled.\n\n### The fix\n\nThe fix focuses on solving the vulnerability only by: 1) use correct\nindex, 2) always use the last 31 bytes of the USS:\n\n```go\n if len(secretPhrase) == 0 {\n tx[6] = 0\n } else {\n tx[6] = 1\n // Hash user\u0027s phrase as USS\n uss := blake2s.Sum256(secretPhrase)\n copy(tx[7:], uss[1:])\n }\n```\n\nThis change means the key material of affected end users will change\ncompared to earlier versions of `tkeyclient`. They have the choice of:\n\n1. Not using a USS and keep their keys.\n2. Keep using their USS and use new generated keys.\n3. Use another USS and thus new keys.",
"id": "GHSA-4w7r-3222-8h6v",
"modified": "2026-03-20T21:22:09Z",
"published": "2026-03-17T19:42:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tillitis/tkeyclient/security/advisories/GHSA-4w7r-3222-8h6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32953"
},
{
"type": "WEB",
"url": "https://github.com/tillitis/tkeyclient/commit/4954dccf0287657edf8d405057e134cdff9c59e8"
},
{
"type": "PACKAGE",
"url": "https://github.com/tillitis/tkeyclient"
},
{
"type": "WEB",
"url": "https://github.com/tillitis/tkeyclient/releases/tag/v1.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Tillitis TKey Client has an Error in Protocol Implementation"
}
GHSA-4WF4-9RP2-2VHG
Vulnerability from github – Published: 2024-07-09 21:30 – Updated: 2025-01-22 00:33In smp_proc_rand of smp_act.cc, there is a possible authentication bypass during legacy BLE pairing due to incorrect implementation of a protocol. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2024-34722"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T21:15:14Z",
"severity": "HIGH"
},
"details": "In smp_proc_rand of smp_act.cc, there is a possible authentication bypass during legacy BLE pairing due to incorrect implementation of a protocol. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4wf4-9rp2-2vhg",
"modified": "2025-01-22T00:33:34Z",
"published": "2024-07-09T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34722"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/packages/modules/Bluetooth/+/456f705b9acc78d8184536baff3d21b0bc11c957"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2024-07-01"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-01-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5M62-C8GP-6QQV
Vulnerability from github – Published: 2025-06-27 18:30 – Updated: 2025-07-02 15:30A state machine transition flaw in the Bluetooth Low Energy (BLE) stack of Cypress PSoC4 v3.66 allows attackers to bypass the pairing process and authentication via a crafted pairing_failed packet.
{
"affected": [],
"aliases": [
"CVE-2025-44557"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-27T17:15:33Z",
"severity": "HIGH"
},
"details": "A state machine transition flaw in the Bluetooth Low Energy (BLE) stack of Cypress PSoC4 v3.66 allows attackers to bypass the pairing process and authentication via a crafted pairing_failed packet.",
"id": "GHSA-5m62-c8gp-6qqv",
"modified": "2025-07-02T15:30:35Z",
"published": "2025-06-27T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44557"
},
{
"type": "WEB",
"url": "https://github.com/yangting111/BLE_TEST/blob/main/result/PoC/Cypress/Auth_bypass.md"
},
{
"type": "WEB",
"url": "https://www.infineon.com/cms/en/design-support/tools/sdk/psoc-software/psoc-4-components/psoc-creator-component-datasheet-bluetooth-low-energy-ble"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5PW9-F9R4-MV2R
Vulnerability from github – Published: 2024-05-21 00:30 – Updated: 2025-08-27 21:31An authentication bypass vulnerability was present in the GitHub Enterprise Server (GHES) when utilizing SAML single sign-on authentication with the optional encrypted assertions feature. This vulnerability allowed an attacker to forge a SAML response to provision and/or gain access to a user with site administrator privileges. Exploitation of this vulnerability would allow unauthorized access to the instance without requiring prior authentication. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13.0 and was fixed in versions 3.9.15, 3.10.12, 3.11.10 and 3.12.4. This vulnerability was reported via the GitHub Bug Bounty program.
{
"affected": [],
"aliases": [
"CVE-2024-4985"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T22:15:08Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass vulnerability was present in the GitHub Enterprise Server (GHES) when utilizing SAML single sign-on authentication with the optional encrypted assertions feature. This vulnerability allowed an attacker to forge a SAML response to provision and/or gain access to a user with site administrator privileges. Exploitation of this vulnerability would allow unauthorized access to the instance without requiring prior authentication. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13.0 and was fixed in versions 3.9.15, 3.10.12, 3.11.10 and 3.12.4. This vulnerability was reported via the GitHub Bug Bounty program.",
"id": "GHSA-5pw9-f9r4-mv2r",
"modified": "2025-08-27T21:31:37Z",
"published": "2024-05-21T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4985"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.12"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.10"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.4"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.15"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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:U/V:C/RE:M/U:Red",
"type": "CVSS_V4"
}
]
}
GHSA-66XX-C9R9-F474
Vulnerability from github – Published: 2024-06-03 18:30 – Updated: 2025-08-29 21:32An authentication bypass vulnerability has been identified in the REST and SOAP API components of Tripwire Enterprise (TE) 9.1.0 when TE is configured to use LDAP/Active Directory SAML authentication and its optional "Auto-synchronize LDAP Users, Roles, and Groups" feature is enabled. This vulnerability allows unauthenticated attackers to bypass authentication if a valid username is known. Exploitation of this vulnerability could allow remote attackers to gain privileged access to the APIs and lead to unauthorized information disclosure or modification.
{
"affected": [],
"aliases": [
"CVE-2024-4332"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-03T18:15:09Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass vulnerability has been identified in the REST and SOAP API components of Tripwire Enterprise (TE) 9.1.0 when TE is configured to use LDAP/Active Directory SAML authentication and its optional \"Auto-synchronize LDAP Users, Roles, and Groups\" feature is enabled. This vulnerability allows unauthenticated attackers to bypass authentication if a valid username is known. Exploitation of this vulnerability could allow remote attackers to gain privileged access to the APIs and lead to unauthorized information disclosure or modification.",
"id": "GHSA-66xx-c9r9-f474",
"modified": "2025-08-29T21:32:01Z",
"published": "2024-06-03T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4332"
},
{
"type": "WEB",
"url": "https://www.fortra.com/security/advisory/fi-2024-006"
}
],
"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:L/SI:L/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:N/AU:Y/R:U/V:C/RE:L/U:Red",
"type": "CVSS_V4"
}
]
}
GHSA-6736-X63F-C628
Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-11 18:31Bitwarden Server prior to v2026.4.1 does not require master-password re-authentication when retrieving or rotating an organization's SCIM API key, allowing an authenticated user with SCIM management privileges to obtain the key using only a valid session.
{
"affected": [],
"aliases": [
"CVE-2026-43640"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-11T18:16:37Z",
"severity": "HIGH"
},
"details": "Bitwarden Server prior to v2026.4.1 does not require master-password re-authentication when retrieving or rotating an organization\u0027s SCIM API key, allowing an authenticated user with SCIM management privileges to obtain the key using only a valid session.",
"id": "GHSA-6736-x63f-c628",
"modified": "2026-05-11T18:31:46Z",
"published": "2026-05-11T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43640"
},
{
"type": "WEB",
"url": "https://github.com/bitwarden/server/pull/7403"
},
{
"type": "WEB",
"url": "https://github.com/bitwarden/server/commit/eb251d9bf80724c87b187661783b9354d1784083"
},
{
"type": "WEB",
"url": "https://github.com/bitwarden/server/releases/tag/v2026.4.1"
},
{
"type": "WEB",
"url": "https://sanjokkarki.com.np/blog/bitwarden-scim-key-bypass"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/bitwarden-server-authentication-bypass-via-scim-api-key"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/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-6GGV-MMG2-JF4R
Vulnerability from github – Published: 2023-12-27 18:30 – Updated: 2025-11-03 21:30A flaw was found in shadow-utils. When asking for a new password, shadow-utils asks the password twice. If the password fails on the second attempt, shadow-utils fails in cleaning the buffer used to store the first entry. This may allow an attacker with enough access to retrieve the password from the memory.
{
"affected": [],
"aliases": [
"CVE-2023-4641"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-27T16:15:13Z",
"severity": "MODERATE"
},
"details": "A flaw was found in shadow-utils. When asking for a new password, shadow-utils asks the password twice. If the password fails on the second attempt, shadow-utils fails in cleaning the buffer used to store the first entry. This may allow an attacker with enough access to retrieve the password from the memory.",
"id": "GHSA-6ggv-mmg2-jf4r",
"modified": "2025-11-03T21:30:58Z",
"published": "2023-12-27T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4641"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6632"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:7112"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0417"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:2577"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-4641"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2215945"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-90: Reflection Attack in Authentication Protocol
An adversary can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the adversary illegitimate access to the target system, without possessing the requisite credentials. Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An adversary can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication.