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.

1199 vulnerabilities reference this CWE, most recent first.

GHSA-CG43-3Q5J-MWP7

Vulnerability from github – Published: 2025-02-07 18:31 – Updated: 2025-02-07 18:31
VLAI
Details

A vulnerability has been found in D-Link DHP-W310AV 1.04 and classified as critical. This vulnerability affects unknown code. The manipulation leads to authentication bypass by spoofing. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-1104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-07T17:15:31Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in D-Link DHP-W310AV 1.04 and classified as critical. This vulnerability affects unknown code. The manipulation leads to authentication bypass by spoofing. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-cg43-3q5j-mwp7",
  "modified": "2025-02-07T18:31:23Z",
  "published": "2025-02-07T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kn1g78/cve/blob/main/dlink.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.294934"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.294934"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.489958"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-CGXF-X59W-2X25

Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31
VLAI
Details

FUXA versions 1.3.1 and prior contain an authentication bypass vulnerability via dot-segment path normalization in the REST API. The API router fails to normalize dot-segment sequences before applying authentication middleware, allowing unauthenticated requests to access protected endpoints by prefixing paths with dot-segments such as /api/./users, /api/./roles, and /api/project/../users. These requests bypass authentication checks and return sensitive user and role data without credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-13207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T21:16:30Z",
    "severity": "HIGH"
  },
  "details": "FUXA versions 1.3.1 and prior contain an authentication bypass vulnerability via dot-segment path normalization in the REST API. The API router fails to normalize dot-segment sequences before applying authentication middleware, allowing unauthenticated requests to access protected endpoints by prefixing paths with dot-segments such as /api/./users, /api/./roles, and /api/project/../users. These requests bypass authentication checks and return sensitive user and role data without credentials.",
  "id": "GHSA-cgxf-x59w-2x25",
  "modified": "2026-06-30T21:31:45Z",
  "published": "2026-06-30T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-181-02.json"
    },
    {
      "type": "WEB",
      "url": "https://github.com/frangoteam/FUXA/releases"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-181-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "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-CH6H-XWWM-655W

Vulnerability from github – Published: 2026-09-24 15:31 – Updated: 2026-09-24 15:31
VLAI
Details

An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. The gateway API allows an authenticated administrator to create a new service key for the Controller service cluster. Because service-key creation is not restricted to the installer-provisioned provisioning path, an administrator-issued key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token that impersonates the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker's authorization boundary.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-94416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T13:17:17Z",
    "severity": "MODERATE"
  },
  "details": "An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. The gateway API allows an authenticated administrator to create a new service key for the Controller service cluster. Because service-key creation is not restricted to the installer-provisioned provisioning path, an administrator-issued key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token that impersonates the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker\u0027s authorization boundary.",
  "id": "GHSA-ch6h-xwwm-655w",
  "modified": "2026-09-24T15:31:29Z",
  "published": "2026-09-24T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94416"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible.platform/pull/254"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/jewel/pull/235"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-94416"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2537465"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CHG8-G9J3-VRQ2

Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32
VLAI
Details

IBM Resilient SOAR V38.0 could allow an attacker on the internal net work to provide the server with a spoofed source IP address. IBM X-Force ID: 190567.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-29T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Resilient SOAR V38.0 could allow an attacker on the internal net work to provide the server with a spoofed source IP address. IBM X-Force ID: 190567.",
  "id": "GHSA-chg8-g9j3-vrq2",
  "modified": "2022-05-24T17:32:42Z",
  "published": "2022-05-24T17:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4864"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/190567"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6356441"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CHM2-M3W2-WCXM

Vulnerability from github – Published: 2026-02-17 22:56 – Updated: 2026-02-17 22:56
VLAI
Summary
OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch
Details

Summary

Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (users/<id>). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

Affected Packages / Versions

(As of 2026-02-14; based on latest published npm versions) - openclaw (npm): <= 2026.2.13 - clawdbot (npm): <= 2026.1.24-3

Details

Affected component: - extensions/googlechat/src/monitor.ts

The allowFrom checks accept: - Immutable sender id (users/<id>) - Raw email (alice@example.com) for usability

Historically, users/<email> was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

Security Triage (2026-02-14)

Severity: Low

Rationale: - Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector. - A realistic exploit generally requires Google Workspace / IdP administrative control over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different users/<id>. - With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

Remediation / Behavior Changes

Goal: preserve usability while reducing footguns. - Raw email allowlists remain supported. - users/<email> is deprecated and treated as a user id, not as an email allowlist. - Documentation recommends users/<id> when strict immutable binding is required.

Fix Commit(s)

  • c8424bf29a921e25663b29f308640b3d91a49432 (PR #16243)

Thanks @vincentkoc for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "clawdbot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.1.24-3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T22:56:39Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nGoogle Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/\u003cid\u003e`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.\n\n### Affected Packages / Versions\n(As of 2026-02-14; based on latest published npm versions)\n- `openclaw` (npm): `\u003c= 2026.2.13`\n- `clawdbot` (npm): `\u003c= 2026.1.24-3`\n\n### Details\nAffected component:\n- `extensions/googlechat/src/monitor.ts`\n\nThe `allowFrom` checks accept:\n- Immutable sender id (`users/\u003cid\u003e`)\n- Raw email (`alice@example.com`) for usability\n\nHistorically, `users/\u003cemail\u003e` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.\n\n### Security Triage (2026-02-14)\nSeverity: **Low**\n\nRationale:\n- Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector.\n- A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/\u003cid\u003e`.\n- With that level of access, the attacker typically has broader compromise paths.\n\nWe still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.\n\n### Remediation / Behavior Changes\nGoal: preserve usability while reducing footguns.\n- Raw email allowlists remain supported.\n- `users/\u003cemail\u003e` is deprecated and treated as a **user id**, not as an email allowlist.\n- Documentation recommends `users/\u003cid\u003e` when strict immutable binding is required.\n\n### Fix Commit(s)\n- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)\n\nThanks @vincentkoc for reporting.",
  "id": "GHSA-chm2-m3w2-wcxm",
  "modified": "2026-02-17T22:56:39Z",
  "published": "2026-02-17T22:56:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-chm2-m3w2-wcxm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/16243"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c8424bf29a921e25663b29f308640b3d91a49432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch"
}

GHSA-CHR9-M4Q2-76HW

Vulnerability from github – Published: 2026-07-02 16:04 – Updated: 2026-07-02 16:04
VLAI
Summary
OpenClaw: Control UI locality spoofing could mint a durable admin device token
Details

Summary

In affected LAN/shared-token Control UI deployments, a caller could spoof locality information used during Control UI pairing and obtain a durable admin-capable device token.

This issue is limited to deployments where the caller already has the network/authentication foothold needed to reach the Control UI pairing path. It is not an unauthenticated internet exposure issue.

Affected configurations

This affects configurations such as LAN-bound gateways or shared-token Control UI access where locality signals were accepted as sufficient for pairing decisions.

Impact

A temporary or shared Control UI access path could be turned into a persistent admin device token. That token could remain useful after the shared gateway token was rotated, unless the paired device was removed.

The issue is a pairing/locality validation problem: locality-derived trust was stronger than it should have been.

Patched Versions

The first stable patched version is 2026.5.22.

Mitigations

Upgrade to openclaw@2026.5.22 or later. For older deployments, remove unexpected paired devices and avoid exposing Control UI pairing paths on networks with untrusted clients.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53817"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-287",
      "CWE-290",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T16:04:35Z",
    "nvd_published_at": "2026-06-11T21:16:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nIn affected LAN/shared-token Control UI deployments, a caller could spoof locality information used during Control UI pairing and obtain a durable admin-capable device token.\n\nThis issue is limited to deployments where the caller already has the network/authentication foothold needed to reach the Control UI pairing path. It is not an unauthenticated internet exposure issue.\n\n### Affected configurations\n\nThis affects configurations such as LAN-bound gateways or shared-token Control UI access where locality signals were accepted as sufficient for pairing decisions.\n\n### Impact\n\nA temporary or shared Control UI access path could be turned into a persistent admin device token. That token could remain useful after the shared gateway token was rotated, unless the paired device was removed.\n\nThe issue is a pairing/locality validation problem: locality-derived trust was stronger than it should have been.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.22`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.22` or later. For older deployments, remove unexpected paired devices and avoid exposing Control UI pairing paths on networks with untrusted clients.",
  "id": "GHSA-chr9-m4q2-76hw",
  "modified": "2026-07-02T16:04:35Z",
  "published": "2026-07-02T16:04:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-chr9-m4q2-76hw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53817"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-control-ui-locality-spoofing-in-device-pairing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Control UI locality spoofing could mint a durable admin device token"
}

GHSA-CJ5H-7HQ4-3Q37

Vulnerability from github – Published: 2025-02-28 15:31 – Updated: 2025-02-28 15:31
VLAI
Details

The application or its infrastructure allows for IP address spoofing by providing its own value in the "X-Forwarded-For" header. Thus, the action logging mechanism in the application loses accountability

This issue affects CyberArk Endpoint Privilege Manager in SaaS version 24.7.1. The status of other versions is unknown. After multiple attempts to contact the vendor we did not receive any answer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-22271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-28T13:15:27Z",
    "severity": "MODERATE"
  },
  "details": "The application or its infrastructure allows for IP address spoofing by providing its own value in the \"X-Forwarded-For\" header. Thus, the action logging mechanism in the application loses\u00a0accountability\n\n\nThis issue affects\u00a0CyberArk Endpoint Privilege Manager in SaaS version 24.7.1. The status of other versions is unknown.\u00a0After multiple attempts to contact the vendor we did not receive any answer.",
  "id": "GHSA-cj5h-7hq4-3q37",
  "modified": "2025-02-28T15:31:02Z",
  "published": "2025-02-28T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22271"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2025/02/CVE-2025-22270"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2025/02/CVE-2025-22270"
    },
    {
      "type": "WEB",
      "url": "https://docs.cyberark.com/epm/24.7.1/en/content/resources/_topnav/cc_home.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/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-CJQR-JJ24-MFR6

Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-16 15:33
VLAI
Details

ThingsBoard v4.3.0.1 is vulnerable to an authentication bypass during the OAuth authorization code exchange. The application improperly trusts user-supplied identity data within the user parameter of the /login/oauth2/code/ endpoint. By manipulating the email address in this JSON object, a remote attacker can bypass authentication and gain full access to any existing user account on the platform without possessing the target user's credentials. This results in a complete account takeover.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-36537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T20:16:25Z",
    "severity": "CRITICAL"
  },
  "details": "ThingsBoard v4.3.0.1 is vulnerable to an authentication bypass during the OAuth authorization code exchange. The application improperly trusts user-supplied identity data within the user parameter of the /login/oauth2/code/ endpoint. By manipulating the email address in this JSON object, a remote attacker can bypass authentication and gain full access to any existing user account on the platform without possessing the target user\u0027s credentials. This results in a complete account takeover.",
  "id": "GHSA-cjqr-jj24-mfr6",
  "modified": "2026-06-16T15:33:45Z",
  "published": "2026-06-15T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-36537"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/KKC73/b9d4efda05693882f1e613c0e0fac78d"
    }
  ],
  "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-CM3P-J4F2-PC4M

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12
VLAI
Details

Inappropriate implementation in Autofill in Google Chrome prior to 93.0.4577.63 allowed a remote attacker to spoof security UI via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30621"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-03T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Autofill in Google Chrome prior to 93.0.4577.63 allowed a remote attacker to spoof security UI via a crafted HTML page.",
  "id": "GHSA-cm3p-j4f2-pc4m",
  "modified": "2022-05-24T19:12:57Z",
  "published": "2022-05-24T19:12:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30621"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2021/08/stable-channel-update-for-desktop_31.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1204722"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5LVY4WIWTVVYKQMROJJS365TZBKEARCF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJPUSAWIJMQFBQQQYXAICLI4EKFQOH6"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QW4R2K5HVJ4R6XDZYOJCCFPIN2XHNS3L"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-30621"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CP2C-X2PC-FPH7

Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2024-07-30 16:30
VLAI
Summary
Apache SeaTunnel Web Authentication vulnerability
Details

Web Authentication vulnerability in Apache SeaTunnel. Since the jwt key is hardcoded in the application, an attacker can forge any token to log in any user.

Attacker can get secret key in /seatunnel-server/seatunnel-app/src/main/resources/application.yml and then create a token. This issue affects Apache SeaTunnel: 1.0.0.

Users are recommended to upgrade to version 1.0.1, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.seatunnel:seatunnel-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-48396"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-30T16:30:35Z",
    "nvd_published_at": "2024-07-30T09:15:02Z",
    "severity": "HIGH"
  },
  "details": "Web Authentication vulnerability in Apache SeaTunnel.\u00a0Since the jwt key is hardcoded in the application, an attacker can forge any token to log in any user.\n\nAttacker can get\u00a0secret key in\u00a0/seatunnel-server/seatunnel-app/src/main/resources/application.yml and then create a token. This issue affects Apache SeaTunnel: 1.0.0.\n\nUsers are recommended to upgrade to version 1.0.1, which fixes the issue.",
  "id": "GHSA-cp2c-x2pc-fph7",
  "modified": "2024-07-30T16:30:35Z",
  "published": "2024-07-30T09:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48396"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/seatunnel-web/commit/4a37ebfa4b57e177bf7857cf39a6dbdc00f75f78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/seatunnel"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/1tdxfjksx0vb9gtyt77wlr6rdcy1qwmw"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/07/30/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache SeaTunnel Web Authentication vulnerability"
}

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.