CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5966 vulnerabilities reference this CWE, most recent first.
GHSA-RXJG-CX74-H635
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2023-12-31 21:30{
"affected": [],
"aliases": [
"CVE-2020-17020"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-11T07:15:00Z",
"severity": "MODERATE"
},
"details": "Microsoft Word Security Feature Bypass Vulnerability",
"id": "GHSA-rxjg-cx74-h635",
"modified": "2023-12-31T21:30:25Z",
"published": "2022-05-24T17:33:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17020"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-17020"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RXPR-5X8P-2XF5
Vulnerability from github – Published: 2023-05-10 00:30 – Updated: 2024-04-04 03:58An improper authentication vulnerability exists in Avalanche Premise versions 6.3.x and below that could allow an attacker to gain access to the server by registering to receive messages from the server and perform an authentication bypass.
{
"affected": [],
"aliases": [
"CVE-2023-28125"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-09T22:15:09Z",
"severity": "MODERATE"
},
"details": "An improper authentication vulnerability exists in Avalanche Premise versions 6.3.x and below that could allow an attacker to gain access to the server by registering to receive messages from the server and perform an authentication bypass.",
"id": "GHSA-rxpr-5x8p-2xf5",
"modified": "2024-04-04T03:58:07Z",
"published": "2023-05-10T00:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28125"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/ZDI-CAN-17729-CVE-2023-28125-Bug-958437-ZDI-CAN-17729-Ivanti-Avalanche-InfoRail-Authentication-Bypass-Vulnerability?language=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-RXQ3-GM4P-5FJ4
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2024-02-14 21:33The example code for the digest authentication functionality (http_authentication.rb) in Ruby on Rails before 2.3.3 defines an authenticate_or_request_with_http_digest block that returns nil instead of false when the user does not exist, which allows context-dependent attackers to bypass authentication for applications that are derived from this example by sending an invalid username without a password.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rails"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2009-2422"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:56:22Z",
"nvd_published_at": "2009-07-10T15:30:00Z",
"severity": "CRITICAL"
},
"details": "The example code for the digest authentication functionality (http_authentication.rb) in Ruby on Rails before 2.3.3 defines an authenticate_or_request_with_http_digest block that returns nil instead of false when the user does not exist, which allows context-dependent attackers to bypass authentication for applications that are derived from this example by sending an invalid username without a password.",
"id": "GHSA-rxq3-gm4p-5fj4",
"modified": "2024-02-14T21:33:07Z",
"published": "2017-10-24T18:33:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2422"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/51528"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rails/CVE-2009-2422.yml"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20090711160153/http://secunia.com/advisories/35702"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200229192617/http://www.securityfocus.com/bid/35579"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2010//Mar/msg00001.html"
},
{
"type": "WEB",
"url": "http://n8.tumblr.com/post/117477059/security-hole-found-in-rails-2-3s"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4077"
},
{
"type": "WEB",
"url": "http://weblog.rubyonrails.org/2009/6/3/security-problem-with-authenticate_with_http_digest"
}
],
"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"
}
],
"summary": "rails vulnerable to improper authentication"
}
GHSA-RXR8-FC83-WVXF
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08A vulnerability in /Login.html of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to bypass login and obtain a partially authorized token and uid.
{
"affected": [],
"aliases": [
"CVE-2020-21932"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-21T15:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in /Login.html of Motorola CX2 router CX 1.0.2 Build 20190508 Rel.97360n allows attackers to bypass login and obtain a partially authorized token and uid.",
"id": "GHSA-rxr8-fc83-wvxf",
"modified": "2022-05-24T19:08:50Z",
"published": "2022-05-24T19:08:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-21932"
},
{
"type": "WEB",
"url": "https://github.com/cc-crack/router/blob/master/motocx2.md"
},
{
"type": "WEB",
"url": "https://l0n0l.xyz/post/motocx2"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-RXW2-PC8J-VXWM
Vulnerability from github – Published: 2026-07-02 20:38 – Updated: 2026-07-02 20:38Summary
fast-mcp-telegram validates HTTP Bearer tokens by joining the raw token string into a session-file path. The verifier rejects the exact reserved token telegram, but it does not reject path separators or normalize the path before checking whether the session file exists. A remote HTTP client can therefore authenticate as the default legacy session with a token such as ../fast-mcp-telegram/telegram when the documented default session file ~/.config/fast-mcp-telegram/telegram.session exists.
This bypasses the reserved session name control that is intended to prevent HTTP multi-user sessions from colliding with the default stdio or legacy account. With account-prefixed MCP tools enabled, the attacker still sees and calls the prefixed tools for the default account, so the prefix middleware does not stop the session selection bypass.
Impact
An unauthenticated network client can access the Telegram account represented by the default telegram.session file without knowing a generated bearer token, if that legacy or default session file is present on a server running HTTP auth. The attacker can then call Telegram MCP tools as that account, including message reading, message sending, MTProto API calls, and attachment-producing tool surfaces available to the session.
Technical details
SessionFileTokenVerifier.verify_token() strips whitespace and rejects exact reserved names:
if token.lower() in RESERVED_SESSION_NAMES:
return None
It then appends .session to the raw token and checks the resulting path:
session_path = self._session_directory / f"{token}.session"
if not session_path.is_file():
return None
No check rejects /, \\, .., absolute paths, or resolved paths outside the configured session directory. The session client path is built the same way in src/client/connection.py:
session_path = SESSION_DIR / f"{token}.session"
client = await _build_telegram_client_for_token(session_path, token)
With the default session directory, the token ../fast-mcp-telegram/telegram resolves as follows:
~/.config/fast-mcp-telegram/../fast-mcp-telegram/telegram.session
= ~/.config/fast-mcp-telegram/telegram.session
The exact token telegram is denied, but the traversal alias reaches the same file and is accepted. This is especially important because telegram is the documented default session_name, and the security documentation says reserved names are blocked to prevent conflicts with stdio and HTTP no-auth sessions.
The vulnerable code is present on current master commit 167ab705f1cd09b21e85c370570471fe75a4f8c9 and in release tag 0.19.0 commit 77bdf6d7e5c6a84d87acc423db613e6c6ba30094.
Reproduction
The following proof uses stub session files and stub Telegram clients, so it does not need real Telegram credentials. It validates the auth decision and the eventual session path used by the client builder.
Run on current master:
git clone https://github.com/leshchenko1979/fast-mcp-telegram.git
cd fast-mcp-telegram
python validation_token_traversal.py
The local proof script created for validation is attached below for reference:
# High-level proof outline
# 1. Create a temporary session directory containing telegram.session and a random token session.
# 2. Instantiate SessionFileTokenVerifier with that directory.
# 3. Verify denied controls: token `telegram` is rejected, and a traversal token to a missing file is rejected.
# 4. Verify allowed control: a normal random token with a matching session file is accepted.
# 5. Verify bypass: token `../fast-mcp-telegram/telegram` is accepted and the client builder receives the default telegram.session path.
# 6. Verify prefix behavior: account-prefixed tools are listed for the traversal-authenticated default account, a prefixed call reaches send_message, and an unprefixed call is still denied.
Key controls from the current-master run:
{
"reserved_default_token_denied": true,
"normal_random_token_allowed": true,
"missing_traversal_token_denied": true,
"traversal_alias_to_reserved_default_allowed": true,
"traversal_access_token_value": "../fast-mcp-telegram/telegram",
"client_builder_used_default_session_file": true,
"prefixed_tool_listed_for_traversal_token": "defaultalice_send_message",
"prefixed_tool_call_reached_handler_as": "send_message",
"unprefixed_tool_call_denied_when_prefix_resolved": true
}
Interpretation:
- Denied control: the exact reserved token
telegramis rejected. - Allowed control: a normal random session token is accepted when its matching session file exists.
- Denied control: a traversal token pointing to a missing file is rejected.
- Bypass:
../fast-mcp-telegram/telegramauthenticates and the client builder receives the resolved default session path. - Prefix control: once authenticated through the traversal token, account-prefixed tools are listed and a prefixed
tools/callreaches the internalsend_messagehandler. An unprefixed call is rejected when the prefix resolves, so the confirmed bug is the session selection and authentication bypass, not a missing-prefix execution bypass.
Why this crosses the auth boundary
A production HTTP auth deployment is expected to require high-entropy per-session bearer tokens. Reserved names are explicitly blocked because common names such as telegram can collide with the default session. The traversal alias turns the public token namespace back into a filesystem namespace and bypasses that reserved-name policy.
The account-prefix middleware is downstream of authentication. It labels tools based on the resolved Telegram account for the token that was accepted. Because the traversal token is accepted as a valid FastMCP AccessToken, the middleware correctly exposes the default account's prefixed tools to the attacker. It cannot recover the lost authentication boundary.
Remediation
Reject bearer tokens that are not strict opaque token identifiers before using them in file paths. Recommended checks:
- Accept only a safe token alphabet, for example
^[A-Za-z0-9_-]{32,128}$, matching generated URL-safe base64 tokens. - Reject
/,\\,.,.., empty segments, and absolute paths for both header auth and URL auth. - Resolve the final session path and require it to remain directly under the configured session directory:
session_dir = self._session_directory.resolve()
session_path = (session_dir / f"{token}.session").resolve()
if session_path.parent != session_dir:
return None
- Apply the same validation in
SessionFileTokenVerifier, URL auth middleware, setup flows, cleanup code, and any code that opens session files by token. - Add regression tests for exact reserved names, traversal aliases such as
../fast-mcp-telegram/telegram, absolute paths, URL-encoded traversal if any route decodes path components, Windows separators, and normal generated tokens.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.19.0"
},
"package": {
"ecosystem": "PyPI",
"name": "fast-mcp-telegram"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.19.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52830"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T20:38:50Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nfast-mcp-telegram validates HTTP Bearer tokens by joining the raw token string into a session-file path. The verifier rejects the exact reserved token `telegram`, but it does not reject path separators or normalize the path before checking whether the session file exists. A remote HTTP client can therefore authenticate as the default legacy session with a token such as `../fast-mcp-telegram/telegram` when the documented default session file `~/.config/fast-mcp-telegram/telegram.session` exists.\n\nThis bypasses the reserved session name control that is intended to prevent HTTP multi-user sessions from colliding with the default stdio or legacy account. With account-prefixed MCP tools enabled, the attacker still sees and calls the prefixed tools for the default account, so the prefix middleware does not stop the session selection bypass.\n\n## Impact\n\nAn unauthenticated network client can access the Telegram account represented by the default `telegram.session` file without knowing a generated bearer token, if that legacy or default session file is present on a server running HTTP auth. The attacker can then call Telegram MCP tools as that account, including message reading, message sending, MTProto API calls, and attachment-producing tool surfaces available to the session.\n\n## Technical details\n\n`SessionFileTokenVerifier.verify_token()` strips whitespace and rejects exact reserved names:\n\n```python\nif token.lower() in RESERVED_SESSION_NAMES:\n return None\n```\n\nIt then appends `.session` to the raw token and checks the resulting path:\n\n```python\nsession_path = self._session_directory / f\"{token}.session\"\nif not session_path.is_file():\n return None\n```\n\nNo check rejects `/`, `\\\\`, `..`, absolute paths, or resolved paths outside the configured session directory. The session client path is built the same way in `src/client/connection.py`:\n\n```python\nsession_path = SESSION_DIR / f\"{token}.session\"\nclient = await _build_telegram_client_for_token(session_path, token)\n```\n\nWith the default session directory, the token `../fast-mcp-telegram/telegram` resolves as follows:\n\n```text\n~/.config/fast-mcp-telegram/../fast-mcp-telegram/telegram.session\n= ~/.config/fast-mcp-telegram/telegram.session\n```\n\nThe exact token `telegram` is denied, but the traversal alias reaches the same file and is accepted. This is especially important because `telegram` is the documented default `session_name`, and the security documentation says reserved names are blocked to prevent conflicts with stdio and HTTP no-auth sessions.\n\nThe vulnerable code is present on current `master` commit `167ab705f1cd09b21e85c370570471fe75a4f8c9` and in release tag `0.19.0` commit `77bdf6d7e5c6a84d87acc423db613e6c6ba30094`.\n\n## Reproduction\n\nThe following proof uses stub session files and stub Telegram clients, so it does not need real Telegram credentials. It validates the auth decision and the eventual session path used by the client builder.\n\nRun on current master:\n\n```bash\ngit clone https://github.com/leshchenko1979/fast-mcp-telegram.git\ncd fast-mcp-telegram\npython validation_token_traversal.py\n```\n\nThe local proof script created for validation is attached below for reference:\n\n```python\n# High-level proof outline\n# 1. Create a temporary session directory containing telegram.session and a random token session.\n# 2. Instantiate SessionFileTokenVerifier with that directory.\n# 3. Verify denied controls: token `telegram` is rejected, and a traversal token to a missing file is rejected.\n# 4. Verify allowed control: a normal random token with a matching session file is accepted.\n# 5. Verify bypass: token `../fast-mcp-telegram/telegram` is accepted and the client builder receives the default telegram.session path.\n# 6. Verify prefix behavior: account-prefixed tools are listed for the traversal-authenticated default account, a prefixed call reaches send_message, and an unprefixed call is still denied.\n```\n\nKey controls from the current-master run:\n\n```json\n{\n \"reserved_default_token_denied\": true,\n \"normal_random_token_allowed\": true,\n \"missing_traversal_token_denied\": true,\n \"traversal_alias_to_reserved_default_allowed\": true,\n \"traversal_access_token_value\": \"../fast-mcp-telegram/telegram\",\n \"client_builder_used_default_session_file\": true,\n \"prefixed_tool_listed_for_traversal_token\": \"defaultalice_send_message\",\n \"prefixed_tool_call_reached_handler_as\": \"send_message\",\n \"unprefixed_tool_call_denied_when_prefix_resolved\": true\n}\n```\n\nInterpretation:\n\n1. Denied control: the exact reserved token `telegram` is rejected.\n2. Allowed control: a normal random session token is accepted when its matching session file exists.\n3. Denied control: a traversal token pointing to a missing file is rejected.\n4. Bypass: `../fast-mcp-telegram/telegram` authenticates and the client builder receives the resolved default session path.\n5. Prefix control: once authenticated through the traversal token, account-prefixed tools are listed and a prefixed `tools/call` reaches the internal `send_message` handler. An unprefixed call is rejected when the prefix resolves, so the confirmed bug is the session selection and authentication bypass, not a missing-prefix execution bypass.\n\n## Why this crosses the auth boundary\n\nA production HTTP auth deployment is expected to require high-entropy per-session bearer tokens. Reserved names are explicitly blocked because common names such as `telegram` can collide with the default session. The traversal alias turns the public token namespace back into a filesystem namespace and bypasses that reserved-name policy.\n\nThe account-prefix middleware is downstream of authentication. It labels tools based on the resolved Telegram account for the token that was accepted. Because the traversal token is accepted as a valid FastMCP `AccessToken`, the middleware correctly exposes the default account\u0027s prefixed tools to the attacker. It cannot recover the lost authentication boundary.\n\n## Remediation\n\nReject bearer tokens that are not strict opaque token identifiers before using them in file paths. Recommended checks:\n\n1. Accept only a safe token alphabet, for example `^[A-Za-z0-9_-]{32,128}$`, matching generated URL-safe base64 tokens.\n2. Reject `/`, `\\\\`, `.`, `..`, empty segments, and absolute paths for both header auth and URL auth.\n3. Resolve the final session path and require it to remain directly under the configured session directory:\n\n```python\nsession_dir = self._session_directory.resolve()\nsession_path = (session_dir / f\"{token}.session\").resolve()\nif session_path.parent != session_dir:\n return None\n```\n\n4. Apply the same validation in `SessionFileTokenVerifier`, URL auth middleware, setup flows, cleanup code, and any code that opens session files by token.\n5. Add regression tests for exact reserved names, traversal aliases such as `../fast-mcp-telegram/telegram`, absolute paths, URL-encoded traversal if any route decodes path components, Windows separators, and normal generated tokens.",
"id": "GHSA-rxw2-pc8j-vxwm",
"modified": "2026-07-02T20:38:50Z",
"published": "2026-07-02T20:38:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/leshchenko1979/fast-mcp-telegram/security/advisories/GHSA-rxw2-pc8j-vxwm"
},
{
"type": "PACKAGE",
"url": "https://github.com/leshchenko1979/fast-mcp-telegram"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "fast-mcp-telegram: Bearer token path traversal bypasses reserved Telegram session protection"
}
GHSA-RXX4-92M4-W3MH
Vulnerability from github – Published: 2022-05-17 00:42 – Updated: 2022-05-17 00:42admin/auth.php in Gobbl CMS 1.0 allows remote attackers to bypass authentication and gain administrative access by setting the auth cookie to "ok".
{
"affected": [],
"aliases": [
"CVE-2008-5880"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-01-08T19:30:00Z",
"severity": "HIGH"
},
"details": "admin/auth.php in Gobbl CMS 1.0 allows remote attackers to bypass authentication and gain administrative access by setting the auth cookie to \"ok\".",
"id": "GHSA-rxx4-92m4-w3mh",
"modified": "2022-05-17T00:42:30Z",
"published": "2022-05-17T00:42:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-5880"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/7518"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/33190"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4886"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/32918"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V237-W6V2-GM3F
Vulnerability from github – Published: 2022-05-17 00:46 – Updated: 2022-05-17 00:46PHP Jabbers Post Comment 3.0 allows remote attackers to bypass authentication and gain administrative access by setting the PostCommentsAdmin cookie to "logged."
{
"affected": [],
"aliases": [
"CVE-2008-4721"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-10-23T20:00:00Z",
"severity": "HIGH"
},
"details": "PHP Jabbers Post Comment 3.0 allows remote attackers to bypass authentication and gain administrative access by setting the PostCommentsAdmin cookie to \"logged.\"",
"id": "GHSA-v237-w6v2-gm3f",
"modified": "2022-05-17T00:46:41Z",
"published": "2022-05-17T00:46:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4721"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/45503"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/6625"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27991"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4502"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V26H-2HG9-6MQ7
Vulnerability from github – Published: 2022-05-17 01:38 – Updated: 2025-07-08 18:30The management web pages on the Sinapsi eSolar Light Photovoltaic System Monitor (aka Schneider Electric Ezylog photovoltaic SCADA management server), Sinapsi eSolar, and Sinapsi eSolar DUO with firmware before 2.0.2870_2.2.12 do not require authentication, which allows remote attackers to obtain administrative access via a direct request, as demonstrated by a request to ping.php.
{
"affected": [],
"aliases": [
"CVE-2012-5864"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-11-23T12:09:00Z",
"severity": "HIGH"
},
"details": "The management web pages on the Sinapsi eSolar Light Photovoltaic System Monitor (aka Schneider Electric Ezylog photovoltaic SCADA management server), Sinapsi eSolar, and Sinapsi eSolar DUO with firmware before 2.0.2870_2.2.12 do not require authentication, which allows remote attackers to obtain administrative access via a direct request, as demonstrated by a request to ping.php.",
"id": "GHSA-v26h-2hg9-6mq7",
"modified": "2025-07-08T18:30:28Z",
"published": "2022-05-17T01:38:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5864"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/80200"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/80203"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-12-325-01"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/bugtraq/2012-09/0045.html"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/21273"
},
{
"type": "WEB",
"url": "http://www.sinapsitech.it/default.asp?active_page_id=78\u0026news_id=88"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/control_systems/pdf/ICSA-12-325-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V283-23G5-FGC8
Vulnerability from github – Published: 2022-05-24 16:48 – Updated: 2024-04-04 01:03The Quantenna WiFi Controller on Telus Actiontec WEB6000Q v1.1.02.22 allows login with root level access with the user "root" and an empty password by using the enabled onboard UART headers.
{
"affected": [],
"aliases": [
"CVE-2018-15556"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-27T17:15:00Z",
"severity": "CRITICAL"
},
"details": "The Quantenna WiFi Controller on Telus Actiontec WEB6000Q v1.1.02.22 allows login with root level access with the user \"root\" and an empty password by using the enabled onboard UART headers.",
"id": "GHSA-v283-23g5-fgc8",
"modified": "2024-04-04T01:03:26Z",
"published": "2022-05-24T16:48:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15556"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/153262/Telus-Actiontec-WEB6000Q-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Jun/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V2C5-CX8P-42XH
Vulnerability from github – Published: 2022-10-26 19:00 – Updated: 2022-10-28 19:00A vulnerability has been found in SourceCodester Sanitization Management System 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The identifier VDB-212017 was assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-3674"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-26T17:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability has been found in SourceCodester Sanitization Management System 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The identifier VDB-212017 was assigned to this vulnerability.",
"id": "GHSA-v2c5-cx8p-42xh",
"modified": "2022-10-28T19:00:33Z",
"published": "2022-10-26T19:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3674"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.212017"
}
],
"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"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.