CWE-305
AllowedAuthentication Bypass by Primary Weakness
Abstraction: Base · Status: Draft
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
281 vulnerabilities reference this CWE, most recent first.
GHSA-MQQJ-FX8H-437J
Vulnerability from github – Published: 2024-07-10 14:25 – Updated: 2024-07-12 13:22In v1.5 we introduced the YOURLS server-side proxy. The idea was to allow using the YOURLs URL shortener without running the YOURLs instance without authentication and/or exposing the authentication token to the public, allowing anyone to shorten any URL. With the proxy mechanism, anyone can shorten any URL pointing to the configured PrivateBin instance. The vulnerability allowed other URLs to be shortened, as long as they contain the PrivateBin instance, defeating the limit imposed by the proxy.
Neither the confidentially of existing pastes on the server nor the configuration options including the YOURLs token are affected.
Impact
This issue only affects non-standard configurations of PrivateBin. Instances are affected if all of the following conditions are met: 1. The PrivateBin instance enables URL shortening. 2. A YOURLs URL shortener is used and it is configured not to be public and require authentication to shorten URLs. 3. A basepath, the YOURLs proxy mechanism and an authentication token is configured in PrivateBin to use the non-public YOURLs instance. 4. A crafted URL is sent to PrivateBins' YOURLs proxy endpoint with a URL that contains the PrivateBin instance URL as a GET-parameter or as part of the URL-fragment, but doesn't start with the instance URL (a third-party URL)
The root cause is, that the guard clause checking whether the URL to be shortened belongs to your own PrivateBin domain only checks if the PrivateBin instance is contained in the URL but not if it starts with it.
This is a kind of authentication bypass due to incomplete filtering. This has a similar impact like an open redirect except it does not directly redirect, but allows a further hiding of the target URL as is common and known for URL shorteners. If the URL shortener domain used is trusted by it's users, this allows hiding a malicious URL.
The highest impact may be that this can be used for phishing campaigns, by routing users to some kind of fake site mimicking the trusted shortener or PrivateBin domain, which could then extract sensitive data from entered data or similar. That said, this is a general concern with URL shorteners and users are advised to follow general phishing prevention attempts like verifying the domain of the site they are using and using a trusted PrivateBin instance.
Indicators of exploitation
Check your YOURLs proxy for shortened domains that do not start with your own PrivateBin instance. Also note, that for this to be a result of an exploitation of this vulnerability, somewhere in the URL the base path + ? e.g. https://privatebin.example/? has to appear in the destination URL, as this is what the guard checked for.
Patches
The problem has been patched in version 1.7.4 of PrivateBin. In addition to upgrading, users of the YOURLs proxy feature should check for the indicators of exploitation, as outlined above.
Workarounds
- Disable URL shortening, if you have been using it.
- Only the YOURLs proxy is affected. Other URL shortening options either require a public, un-authenticated shortener, or expose the token to the client, which by design allows shortening any URL.
Proof of concept
See the unit test that got introduced to prevent similar regressions for an example of a URL that would circumvent the configured basepath.
Here is an example of how a manual exploitation would work:
In a PrivateBin instance hosted on https://privatebin.example/, with a valid URL YOURLs shortening proxy configuration using a token to prevent un-authenticated short-URL creation, send a URL shortening request for the domain https://attacker.example.com/?q=https://privatebin.example/?foo#bar. attacker.example.com is any attacker controlled, arbitrary domain.
You can do this by sending a GET request to https://privatebin.example/shortenviayourls?link=https%3A%2F%2Fattacker.example.com%2F%3Fq%3Dhttps%3A%2F%2Fprivatebin.example%2F%3Ffoo%23bar, without URL encoding this looks as follows: https://privatebin.example/shortenviayourls?link=https://attacker.example.com/?q=https://privatebin.example/?foo#bar.
On an affected setup, you will get a valid short URL, which when accessed, leads to https://attacker.example.com/?foo#bar, the attackers domain. On a patched system your request will get rejected and only URLs starting with https://privatebin.example/?[...] are allowed for shortening.
Post-mortem
From our limited analysis, the issue has been introduced in commit 0dc9ab7 while refactoring. The use of substr got replaced by strpos. The initial contribution contained no tests, but an implementation without this flaw. All these changes got introduced in a single pull request. This follows many best practices, as tests were added and the refactoring was done in close collaboration with the original author.
In the future, we plan to switch to the more obvious, readable and understandable str_starts_with, which is available since PHP v8. Such a better function naming and insisting on using modern functions would not only result in a better code quality, but would possibly have prevented the issue, but for backwards-compatibility with PHP 7.3, we stay on the old function for now.
Final Thoughts
The project maintainers have always discouraged the use of URL shorteners and users are always safer sharing the complete, long URL to a paste, see our FAQ.
If you need or want to provide a URL shortener option as a PrivateBin instance administrator, YOURLs is the best option available to use with PrivateBin, because it is the only shortener supported, through the proxy mechanism, preventing arbitrarily shortening any URLs. Running a public URL shortener instance and allowing anonymous users shortening arbitrary domains invites the shortener getting abused.
References
- PR to fix the vulnerability: https://github.com/PrivateBin/PrivateBin/pull/1370
Timeline
- 2024-06-28 Issue report by @nbxiglk via email
- 2024-06-29 Vulnerability reproduced by @elrido, mitigation created and shared with maintainers and issue reporter for review
- 2024-07-06 Pull request with mitigation raised
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "privatebin/privatebin"
},
"ranges": [
{
"events": [
{
"introduced": "1.5.0"
},
{
"fixed": "1.7.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39899"
],
"database_specific": {
"cwe_ids": [
"CWE-305",
"CWE-791"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-10T14:25:23Z",
"nvd_published_at": "2024-07-09T19:15:13Z",
"severity": "MODERATE"
},
"details": "In [v1.5](https://github.com/PrivateBin/PrivateBin/blob/master/CHANGELOG.md#15-2022-12-11) we introduced the YOURLS server-side proxy. The idea was to allow using the YOURLs URL shortener without running the YOURLs instance without authentication and/or exposing the authentication token to the public, allowing anyone to shorten any URL. With the proxy mechanism, anyone can shorten any URL pointing to the configured PrivateBin instance. The vulnerability allowed other URLs to be shortened, as long as they contain the PrivateBin instance, defeating the limit imposed by the proxy.\n\nNeither the confidentially of existing pastes on the server nor the configuration options including the YOURLs token are affected.\n\n### Impact\n\nThis issue only affects non-standard configurations of PrivateBin. Instances are affected if all of the following conditions are met:\n1. The PrivateBin instance enables URL shortening.\n2. A YOURLs URL shortener is used and it is configured not to be public and require authentication to shorten URLs.\n3. A basepath, the YOURLs proxy mechanism and an authentication token is configured in PrivateBin to use the non-public YOURLs instance.\n4. A crafted URL is sent to PrivateBins\u0027 YOURLs proxy endpoint with a URL that contains the PrivateBin instance URL as a GET-parameter or as part of the URL-fragment, but doesn\u0027t start with the instance URL (a third-party URL)\n\nThe root cause is, [that the guard clause checking whether the URL to be shortened belongs to your own PrivateBin domain only checks if the PrivateBin instance is contained in the URL](https://github.com/PrivateBin/PrivateBin/blob/3cba170f3255de21bbebb77f6c565519ef33e8c1/lib/YourlsProxy.php#L50-L53) but not if it starts with it.\n\nThis is a kind of authentication bypass due to incomplete filtering. This [has a similar impact like an open redirect](https://cwe.mitre.org/data/definitions/601.html) except it does not directly redirect, but allows a further hiding of the target URL as is common and known for URL shorteners. If the URL shortener domain used is trusted by it\u0027s users, this allows hiding a malicious URL. \n\nThe highest impact may be that this can be used for phishing campaigns, by routing users to some kind of fake site mimicking the trusted shortener or PrivateBin domain, which could then extract sensitive data from entered data or similar. That said, this is a general concern with URL shorteners and users are advised to follow general phishing prevention attempts like verifying the domain of the site they are using and [using a trusted PrivateBin instance](https://github.com/PrivateBin/PrivateBin?tab=readme-ov-file#what-it-doesnt-provide).\n\n### Indicators of exploitation\n\nCheck your YOURLs proxy for shortened domains that do not start with your own PrivateBin instance. Also note, that for this to be a result of an exploitation of this vulnerability, somewhere in the URL the `base path + ?` e.g. `https://privatebin.example/?` has to appear in the destination URL, as this is what the guard checked for.\n\n### Patches\n\nThe problem has been patched in version 1.7.4 of PrivateBin. In addition to upgrading, users of the YOURLs proxy feature should check for the indicators of exploitation, as outlined above.\n\n### Workarounds\n\n* Disable URL shortening, if you have been using it.\n* Only the YOURLs proxy is affected. Other URL shortening options either require a public, un-authenticated shortener, or expose the token to the client, which by design allows shortening any URL.\n\n### Proof of concept\n\nSee [the unit test that got introduced](https://github.com/PrivateBin/PrivateBin/blob/2c711e9d3ca21230fc68f5b4dba2a7a0592b963b/tst/YourlsProxyTest.php#L57-L62) to prevent similar regressions for an example of a URL that would circumvent the configured basepath.\n\nHere is an example of how a manual exploitation would work:\n\nIn a PrivateBin instance hosted on `https://privatebin.example/`, with a valid URL YOURLs shortening proxy configuration using a token to prevent un-authenticated short-URL creation, send a URL shortening request for the domain `https://attacker.example.com/?q=https://privatebin.example/?foo#bar`. `attacker.example.com` is any attacker controlled, arbitrary domain.\n\nYou can do this by sending a GET request to `https://privatebin.example/shortenviayourls?link=https%3A%2F%2Fattacker.example.com%2F%3Fq%3Dhttps%3A%2F%2Fprivatebin.example%2F%3Ffoo%23bar`, without URL encoding this looks as follows: `https://privatebin.example/shortenviayourls?link=https://attacker.example.com/?q=https://privatebin.example/?foo#bar`.\n\nOn an affected setup, you will get a valid short URL, which when accessed, leads to `https://attacker.example.com/?foo#bar`, the attackers domain. On a patched system your request will get rejected and only URLs starting with `https://privatebin.example/?[...]` are allowed for shortening.\n\n### Post-mortem\n\nFrom our limited analysis, the issue [has been introduced in commit `0dc9ab7` while refactoring](https://github.com/PrivateBin/PrivateBin/commit/0dc9ab7576d5a1296debeb788afb2ae9c72d137c). The use of [`substr`](http://php.net/manual/function.substr.php) got replaced by [`strpos`](https://www.php.net/manual/function.strpos). The [initial contribution](https://github.com/PrivateBin/PrivateBin/commit/b0f17f0a91cdebbfd6732781943f1e04ce3311f7) contained no tests, but an implementation without this flaw. All these changes got introduced [in a single pull request](https://github.com/PrivateBin/PrivateBin/pull/997). This follows many best practices, as tests were added and the refactoring was done in close collaboration with the original author.\n\nIn the future, [we plan to switch to the more obvious, readable and understandable](https://github.com/PrivateBin/PrivateBin/issues/1373) [`str_starts_with`](https://www.php.net/manual/function.str-starts-with.php), which is available since PHP v8. Such a better function naming and insisting on using modern functions would not only result in a better code quality, but would possibly have prevented the issue, but for backwards-compatibility with PHP 7.3, we stay on the old function for now.\n\n### Final Thoughts\n\nThe project maintainers have always discouraged the use of URL shorteners and **users are always safer sharing the complete, long URL to a paste**, see [our FAQ](https://github.com/PrivateBin/PrivateBin/wiki/FAQ#the-url-is-so-long-cant-i-just-use-an-url-shortener).\n\nIf you need or want to provide a URL shortener option as a PrivateBin instance administrator, YOURLs is the _best option_ available to use with PrivateBin, because it is the only shortener supported, through the proxy mechanism, preventing arbitrarily shortening any URLs. Running a public URL shortener instance and allowing anonymous users shortening arbitrary domains invites the shortener getting abused.\n\n### References\n\n* PR to fix the vulnerability: https://github.com/PrivateBin/PrivateBin/pull/1370\n\n### Timeline\n\n- 2024-06-28 Issue report by @nbxiglk via email\n- 2024-06-29 Vulnerability reproduced by @elrido, mitigation created and shared with maintainers and issue reporter for review\n- 2024-07-06 Pull request with mitigation raised",
"id": "GHSA-mqqj-fx8h-437j",
"modified": "2024-07-12T13:22:14Z",
"published": "2024-07-10T14:25:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-mqqj-fx8h-437j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39899"
},
{
"type": "WEB",
"url": "https://github.com/PrivateBin/PrivateBin/pull/1370"
},
{
"type": "WEB",
"url": "https://github.com/PrivateBin/PrivateBin/commit/0c4e810e6728f67d678458838d8430dfba4fcca4"
},
{
"type": "PACKAGE",
"url": "https://github.com/PrivateBin/PrivateBin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "PrivateBin allows shortening of URLs for other domains"
}
GHSA-MV7W-J26M-H74P
Vulnerability from github – Published: 2025-05-02 15:31 – Updated: 2025-05-02 15:31KUNBUS Revolution Pi OS Bookworm 01/2025 is vulnerable because authentication is not configured by default for the Node-RED server. This can give an unauthenticated remote attacker full access to the Node-RED server where they can run arbitrary commands on the underlying operating system.
{
"affected": [],
"aliases": [
"CVE-2025-24522"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T19:15:57Z",
"severity": "CRITICAL"
},
"details": "KUNBUS Revolution Pi OS Bookworm 01/2025 is vulnerable because authentication is not configured by default for the Node-RED server. This can give an unauthenticated remote attacker full access to the Node-RED server where they can run arbitrary commands on the underlying operating system.",
"id": "GHSA-mv7w-j26m-h74p",
"modified": "2025-05-02T15:31:45Z",
"published": "2025-05-02T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24522"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-121-01"
},
{
"type": "WEB",
"url": "http://packages.revolutionpi.de/pool/main/p/pictory"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/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: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-P2R3-58QH-PHF8
Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 18:30An Authentication Bypass by Primary Weakness vulnerability [CWE-305] vulnerability in Fortinet FortiOS 7.6.0 through 7.6.4 may allow an unauthenticated attacker to bypass LDAP authentication of Agentless VPN or FSSO policy, when the remote LDAP server is configured in a specific way.
{
"affected": [],
"aliases": [
"CVE-2026-22153"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-10T16:16:11Z",
"severity": "HIGH"
},
"details": "An Authentication Bypass by Primary Weakness vulnerability [CWE-305] vulnerability in Fortinet FortiOS 7.6.0 through 7.6.4 may allow an unauthenticated attacker to bypass LDAP authentication of Agentless VPN or FSSO policy, when the remote LDAP server is configured in a specific way.",
"id": "GHSA-p2r3-58qh-phf8",
"modified": "2026-02-10T18:30:39Z",
"published": "2026-02-10T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22153"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-1052"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PCJ4-9FCJ-56C8
Vulnerability from github – Published: 2025-03-03 18:31 – Updated: 2025-04-25 15:31OpenID Connect Core through 1.0 errata set 2 allows audience injection in certain situations. When the private_key_jwt authentication mechanism is used, a malicious Authorization Server could trick a Client into writing attacker-controlled values into the audience, including token endpoints or issuer identifiers of other Authorization Servers. The malicious Authorization Server could then use these private key JWTs to impersonate the Client.
{
"affected": [],
"aliases": [
"CVE-2025-27370"
],
"database_specific": {
"cwe_ids": [
"CWE-305",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-03T18:15:40Z",
"severity": "MODERATE"
},
"details": "OpenID Connect Core through 1.0 errata set 2 allows audience injection in certain situations. When the private_key_jwt authentication mechanism is used, a malicious Authorization Server could trick a Client into writing attacker-controlled values into the audience, including token endpoints or issuer identifiers of other Authorization Servers. The malicious Authorization Server could then use these private key JWTs to impersonate the Client.",
"id": "GHSA-pcj4-9fcj-56c8",
"modified": "2025-04-25T15:31:20Z",
"published": "2025-03-03T18:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27370"
},
{
"type": "WEB",
"url": "https://github.com/OWASP/ASVS/issues/2678"
},
{
"type": "WEB",
"url": "https://eprint.iacr.org/2025/629"
},
{
"type": "WEB",
"url": "https://openid.net/notice-of-a-security-vulnerability"
},
{
"type": "WEB",
"url": "https://openid.net/wp-content/uploads/2025/01/OIDF-Responsible-Disclosure-Notice-on-Security-Vulnerability-for-private_key_jwt.pdf"
},
{
"type": "WEB",
"url": "https://talks.secworkshop.events/osw2025/talk/R8D9BS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PHRQ-PC6R-F6GH
Vulnerability from github – Published: 2026-03-23 20:28 – Updated: 2026-03-25 20:44Mantis Bug Tracker instances running on MySQL and compatible databases are affected by an authentication bypass vulnerability in the SOAP API, as a result of improper type checking on the password parameter.
Other database backends are not affected, as they do not perform implicit type conversion from string to integer.
Impact
Using a crafted SOAP envelope, an attacker knowing the victim's username is able to login to the SOAP API with their account without knowledge of the actual password, and execute any API function they have access to.
Patches
- b349e5c890eeda9bd82e7c7e14479853f8a30d9f
Workarounds
- Disabling the SOAP API significantly reduces the risk, but still allows the attacker to retrieve user account information including email address and real name.
Resources
- https://mantisbt.org/bugs/view.php?id=36902
Credits
MantisBT thanks Alexander Philiotis of SynerComm for discovering and responsibly reporting the issue.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "mantisbt/mantisbt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.28.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30849"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-23T20:28:52Z",
"nvd_published_at": "2026-03-23T20:16:25Z",
"severity": "CRITICAL"
},
"details": "Mantis Bug Tracker instances running on MySQL and compatible databases are affected by an authentication bypass vulnerability in the SOAP API, as a result of improper type checking on the password parameter.\n\nOther database backends are not affected, as they do not perform implicit type conversion from string to integer.\n\n### Impact\nUsing a crafted SOAP envelope, an attacker knowing the victim\u0027s username is able to login to the SOAP API with their account without knowledge of the actual password, and execute any API function they have access to.\n\n### Patches\n* b349e5c890eeda9bd82e7c7e14479853f8a30d9f\n\n### Workarounds\n- [Disabling the SOAP API](https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.config.api.disable) significantly reduces the risk, but still allows the attacker to retrieve user account information including email address and real name.\n\n### Resources\n- https://mantisbt.org/bugs/view.php?id=36902\n\n### Credits\nMantisBT thanks Alexander Philiotis of SynerComm for discovering and responsibly reporting the issue.",
"id": "GHSA-phrq-pc6r-f6gh",
"modified": "2026-03-25T20:44:16Z",
"published": "2026-03-23T20:28:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mantisbt/mantisbt/security/advisories/GHSA-phrq-pc6r-f6gh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30849"
},
{
"type": "WEB",
"url": "https://github.com/mantisbt/mantisbt/commit/b349e5c890eeda9bd82e7c7e14479853f8a30d9f"
},
{
"type": "PACKAGE",
"url": "https://github.com/mantisbt/mantisbt"
}
],
"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:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MantisBT is vulnerable to authentication bypass through the SOAP API on MySQL"
}
GHSA-Q6H7-XXP7-7429
Vulnerability from github – Published: 2026-05-28 06:31 – Updated: 2026-07-01 21:26A flaw was found in Keycloak, an open-source identity and access management solution. When a user account is temporarily locked due to repeated failed login attempts, an attacker with valid client credentials can exploit the Client-Initiated Backchannel Authentication (CIBA) flow to bypass this brute-force protection. This allows continued authentication attempts and token issuance even when the account should be locked, potentially enabling further unauthorized access attempts.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.5.0"
},
{
"last_affected": "26.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9798"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T21:26:22Z",
"nvd_published_at": "2026-05-28T06:16:29Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak, an open-source identity and access management solution. When a user account is temporarily locked due to repeated failed login attempts, an attacker with valid client credentials can exploit the Client-Initiated Backchannel Authentication (CIBA) flow to bypass this brute-force protection. This allows continued authentication attempts and token issuance even when the account should be locked, potentially enabling further unauthorized access attempts.",
"id": "GHSA-q6h7-xxp7-7429",
"modified": "2026-07-01T21:26:22Z",
"published": "2026-05-28T06:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9798"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/issues/49432"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/49791"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/49903"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/49905"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/11c2695064cd93da1d333df3f69d4a4141e86c29"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/2edc6b112e2dedce63062b89ab3c7ae542e0d9ac"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/a11e3254efc16ae72ce5092b93b9f557a4ba43ae"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-9798"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2482470"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak has an Authentication Bypass by Primary Weakness"
}
GHSA-Q87C-GJJF-XQFW
Vulnerability from github – Published: 2024-05-01 18:30 – Updated: 2024-05-01 18:30A vulnerability in the web-based management interface of Cisco IP Phone firmware could allow an unauthenticated, remote attacker to retrieve sensitive information from an affected device.
This vulnerability is due to a lack of authentication for specific endpoints of the web-based management interface on an affected device. An attacker could exploit this vulnerability by connecting to the affected device. A successful exploit could allow the attacker to gain unauthorized access to the device, enabling the recording of user credentials and traffic to and from the affected device, including VoIP calls that could be replayed.
{
"affected": [],
"aliases": [
"CVE-2024-20378"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T17:15:28Z",
"severity": "HIGH"
},
"details": "A vulnerability in the web-based management interface of Cisco IP Phone firmware could allow an unauthenticated, remote attacker to retrieve sensitive information from an affected device. \n\n This vulnerability is due to a lack of authentication for specific endpoints of the web-based management interface on an affected device. An attacker could exploit this vulnerability by connecting to the affected device. A successful exploit could allow the attacker to gain unauthorized access to the device, enabling the recording of user credentials and traffic to and from the affected device, including VoIP calls that could be replayed.",
"id": "GHSA-q87c-gjjf-xqfw",
"modified": "2024-05-01T18:30:41Z",
"published": "2024-05-01T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20378"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ipphone-multi-vulns-cXAhCvS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q9FM-68JC-87X3
Vulnerability from github – Published: 2023-03-30 21:30 – Updated: 2024-03-27 15:30An authentication bypass vulnerability exists in libcurl <8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However, certain FTP settings such as CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC, and CURLOPT_USE_SSL were not included in the configuration match checks, causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer, potentially allowing unauthorized access to sensitive information.
{
"affected": [],
"aliases": [
"CVE-2023-27535"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-30T20:15:00Z",
"severity": "HIGH"
},
"details": "An authentication bypass vulnerability exists in libcurl \u003c8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However, certain FTP settings such as CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC, and CURLOPT_USE_SSL were not included in the configuration match checks, causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer, potentially allowing unauthorized access to sensitive information.",
"id": "GHSA-q9fm-68jc-87x3",
"modified": "2024-03-27T15:30:36Z",
"published": "2023-03-30T21:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27535"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1892780"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/04/msg00025.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/36NBD5YLJXXEDZLDGNFCERWRYJQ6LAQW"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/36NBD5YLJXXEDZLDGNFCERWRYJQ6LAQW"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202310-12"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230420-0010"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q9QG-G2C3-3HR2
Vulnerability from github – Published: 2026-03-11 12:31 – Updated: 2026-03-11 15:31libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request.
libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.
When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates connections and not requests, contrary to how HTTP is designed to work.
An application that allows Negotiate authentication to a server (that responds
wanting Negotiate) with user1:password1 and then does another operation to
the same server also using Negotiate but with user2:password2 (while the
previous connection is still alive) - the second request wrongly reused the
same connection and since it then sees that the Negotiate negotiation is
already made, it just sends the request over that connection thinking it uses
the user2 credentials when it is in fact still using the connection
authenticated for user1...
The set of authentication methods to use is set with CURLOPT_HTTPAUTH.
Applications can disable libcurl's reuse of connections and thus mitigate this
problem, by using one of the following libcurl options to alter how
connections are or are not reused: CURLOPT_FRESH_CONNECT,
CURLOPT_MAXCONNECTS and CURLMOPT_MAX_HOST_CONNECTIONS (if using the
curl_multi API).
{
"affected": [],
"aliases": [
"CVE-2026-1965"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T11:15:59Z",
"severity": "MODERATE"
},
"details": "libcurl can in some circumstances reuse the wrong connection when asked to do\nan Negotiate-authenticated HTTP or HTTPS request.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criterion must first be met. Due to a\nlogical error in the code, a request that was issued by an application could\nwrongfully reuse an existing connection to the same server that was\nauthenticated using different credentials. One underlying reason being that\nNegotiate sometimes authenticates *connections* and not *requests*, contrary\nto how HTTP is designed to work.\n\nAn application that allows Negotiate authentication to a server (that responds\nwanting Negotiate) with `user1:password1` and then does another operation to\nthe same server also using Negotiate but with `user2:password2` (while the\nprevious connection is still alive) - the second request wrongly reused the\nsame connection and since it then sees that the Negotiate negotiation is\nalready made, it just sends the request over that connection thinking it uses\nthe user2 credentials when it is in fact still using the connection\nauthenticated for user1...\n\nThe set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.\n\nApplications can disable libcurl\u0027s reuse of connections and thus mitigate this\nproblem, by using one of the following libcurl options to alter how\nconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,\n`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the\ncurl_multi API).",
"id": "GHSA-q9qg-g2c3-3hr2",
"modified": "2026-03-11T15:31:52Z",
"published": "2026-03-11T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1965"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-1965.html"
},
{
"type": "WEB",
"url": "https://curl.se/docs/CVE-2026-1965.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QHFM-M6PM-JRQ6
Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30A Control-M/Server communication command does not sufficiently filter or sanitize user-supplied input. Under certain conditions, this issue may allow an unauthenticated attacker to execute unauthorized commands on the affected server, potentially leading to compromise of the server.
This vulnerability affects Control-M/Server versions 9.0.20.x to 9.0.21.200 (included) and potentially earlier unsupported versions.
{
"affected": [],
"aliases": [
"CVE-2026-10539"
],
"database_specific": {
"cwe_ids": [
"CWE-305"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T08:16:20Z",
"severity": "CRITICAL"
},
"details": "A Control-M/Server communication command does not sufficiently filter or sanitize user-supplied input. Under certain conditions, this issue may allow an unauthenticated attacker to execute unauthorized commands on the affected server, potentially leading to compromise of the server.\u00a0\n\n\n\nThis vulnerability affects Control-M/Server versions 9.0.20.x to 9.0.21.200 (included) and potentially earlier unsupported versions.",
"id": "GHSA-qhfm-m6pm-jrq6",
"modified": "2026-07-01T09:30:25Z",
"published": "2026-07-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10539"
},
{
"type": "WEB",
"url": "https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=kA3cx000000GFZNCA4\u0026type=Solution"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/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:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.