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.
174 vulnerabilities reference this CWE, most recent first.
GHSA-487Q-2WVG-5JPV
Vulnerability from github – Published: 2023-05-10 18:30 – Updated: 2024-04-04 04:01An authentication bypass vulnerability exists in the Authentication functionality of Weston Embedded uC-FTPs v 1.98.00. A specially crafted set of network packets can lead to authentication bypass and denial of service. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-41985"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-10T16:15:09Z",
"severity": "HIGH"
},
"details": "An authentication bypass vulnerability exists in the Authentication functionality of Weston Embedded uC-FTPs v 1.98.00. A specially crafted set of network packets can lead to authentication bypass and denial of service. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.",
"id": "GHSA-487q-2wvg-5jpv",
"modified": "2024-04-04T04:01:05Z",
"published": "2023-05-10T18:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41985"
},
{
"type": "WEB",
"url": "https://github.com/weston-embedded/uC-FTPs/pull/1"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1680"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4J6X-2764-M8GH
Vulnerability from github – Published: 2026-07-01 20:51 – Updated: 2026-07-01 20:51Impact
A vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs.
Specifically, when a user authenticates via the GitHub App provider, Rancher's team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user's specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted group principals for every team within that entire organization during authentication and authorization checks.
This issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.
Exploitation of this vulnerability requires the following conditions to be met:
- The GitHub App authentication provider must be enabled and configured for the target GitHub organization.
- The attacker must possess a valid GitHub account with membership in at least one team within that target organization.
- A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher's login allowlist (allowedPrincipalIds).
Please consult the associated MITRE ATT&CK - Technique - Valid Accounts for further information about this category of attack.
Patches
This fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild group principals using the now-corrected logic.
Patched versions of Rancher include releases v2.14.2 and v2.13.6.
Workarounds
If upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations:
- Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth).
- Remove or restrict team-based group principals from allowed principalIds.
- Audit and temporarily remove RBAC bindings (GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings) that reference GitHub App team principals until the patch is applied.
- Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).
These workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.
References
If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.14.0"
},
{
"fixed": "2.14.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.13.0"
},
{
"fixed": "2.13.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260519172014-d0c047bbc6d2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41053"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:51:54Z",
"nvd_published_at": "2026-06-30T12:16:23Z",
"severity": "HIGH"
},
"details": "### Impact\nA vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs. \n\nSpecifically, when a user authenticates via the GitHub App provider, Rancher\u0027s team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user\u0027s specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted `group principals` for every team within that entire organization during authentication and authorization checks.\n\nThis issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.\n\n**Exploitation of this vulnerability requires the following conditions to be met:**\n- The GitHub App authentication provider must be enabled and configured for the target GitHub organization.\n- The attacker must possess a valid GitHub account with membership in at least one team within that target organization. \n- A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher\u0027s login allowlist (`allowedPrincipalIds`). \n\nPlease consult the associated [MITRE ATT\u0026CK - Technique - Valid Accounts](https://attack.mitre.org/techniques/T1078/) for further information about this category of attack.\n\n### Patches\nThis fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild `group principals` using the now-corrected logic.\n\nPatched versions of Rancher include releases `v2.14.2` and `v2.13.6`.\n\n### Workarounds\nIf upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations:\n- Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth).\n- Remove or restrict team-based `group principals` from allowed principalIds.\n- Audit and temporarily remove RBAC bindings (`GlobalRoleBindings`, `ClusterRoleTemplateBindings`, `ProjectRoleTemplateBindings`) that reference GitHub App team `principals` until the patch is applied.\n- Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).\n\nThese workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.\n\n### References\nIf you have any questions or comments about this advisory:\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
"id": "GHSA-4j6x-2764-m8gh",
"modified": "2026-07-01T20:51:54Z",
"published": "2026-07-01T20:51:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-4j6x-2764-m8gh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41053"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/pull/55093"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/pull/55147"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/commit/361d4d57cd09b87f3c53f88af42046ffaa7b57e4"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/commit/d0c047bbc6d202e953d7557b82cbb354367db6ae"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"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"
}
],
"summary": "Rancher has over-inclusive team membership expansion in GitHub App authentication provider"
}
GHSA-4JCJ-7X88-M979
Vulnerability from github – Published: 2026-06-21 06:32 – Updated: 2026-09-10 22:32A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "litellm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.84.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-12773"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:32:02Z",
"nvd_published_at": "2026-06-21T04:16:28Z",
"severity": "MODERATE"
},
"details": "A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.",
"id": "GHSA-4jcj-7x88-m979",
"modified": "2026-09-10T22:32:02Z",
"published": "2026-06-21T06:32:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12773"
},
{
"type": "WEB",
"url": "https://github.com/BerriAI/litellm/commit/73869f0faf7d11ee21adcb5f91b8c33a340b6c2c"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-12773"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491112"
},
{
"type": "WEB",
"url": "https://gist.github.com/YLChen-007/3cfaad10a69d7a15e4d4d458cb53309e"
},
{
"type": "PACKAGE",
"url": "https://github.com/BerriAI/litellm"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-12773.json"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-12773"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/811282"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/372515"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/372515/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "LiteLLM: MCP Proxy Has Improper Authentication"
}
GHSA-4P4X-7XPG-55GW
Vulnerability from github – Published: 2026-07-21 00:30 – Updated: 2026-07-21 00:30Grav CMS scheduler-webhook plugin contains an authentication bypass vulnerability that allows unauthenticated remote attackers to trigger configured scheduled jobs by exploiting a short-circuit logic flaw in the webhook token validation. Attackers can send a single unauthenticated POST request to the scheduler webhook endpoint to execute all configured scheduled jobs or target a specific job, causing unintended execution of operator-defined commands under the web server process user.
{
"affected": [],
"aliases": [
"CVE-2026-57852"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T22:17:17Z",
"severity": "MODERATE"
},
"details": "Grav CMS scheduler-webhook plugin contains an authentication bypass vulnerability that allows unauthenticated remote attackers to trigger configured scheduled jobs by exploiting a short-circuit logic flaw in the webhook token validation. Attackers can send a single unauthenticated POST request to the scheduler webhook endpoint to execute all configured scheduled jobs or target a specific job, causing unintended execution of operator-defined commands under the web server process user.",
"id": "GHSA-4p4x-7xpg-55gw",
"modified": "2026-07-21T00:30:30Z",
"published": "2026-07-21T00:30:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-xwv3-2mv2-w33x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57852"
},
{
"type": "WEB",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/authentication-bypass-via-null-short-circuit-in-grav-cms-scheduler-webhook-token-check"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/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-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"
}
]
}
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.