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-38X9-25WX-7FG2

Vulnerability from github – Published: 2026-06-18 14:24 – Updated: 2026-06-18 14:24
VLAI
Summary
Heimdall: IP Spoofing via Unvalidated Forwarding Headers
Details

Summary

When the trusted_proxies option is configured, heimdall extracts client IP addresses from the Forwarded (for= parameter) and X-Forwarded-For headers and exposes them as Request.ClientIPAddresses to the rule pipeline. However, extracted values are not validated to be syntactically valid IP addresses. Arbitrary strings, malformed IP literals, and RFC 7239 unknown values and obfuscated identifiers are accepted without further checks. In addition, the Forwarded header parser splits on , and ; without accounting for RFC 7239 quoted strings, which can cause a single quoted value to be parsed as multiple entries, with fragments — including trailing quote characters — treated as independent addresses.

Impact

Request.ClientIPAddresses is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property — for example, in a CEL authorizer that checks whether a request originates from a trusted IP range using the networks() function, or in a Remote authorizer that forwards the client IP as part of its payload to an external authorization system. Whether and how Request.ClientIPAddresses is used is entirely determined by the rule configuration.

Additionally, in proxy mode, Request.ClientIPAddresses is used directly to construct the X-Forwarded-For and Forwarded headers forwarded to upstream services. Injected or malformed values are therefore propagated to upstream services unchanged.

Attack Scenarios

All scenarios require that trusted_proxies is configured. If this option is not set, heimdall ignores forwarding headers entirely, and this vulnerability is not exploitable. Scenarios A and C (see below) additionally require that rules reference Request.ClientIPAddresses in their pipeline.

Scenario A – Manipulation of rule evaluation

An attacker who can influence forwarding headers — either by connecting directly to heimdall or through a proxy that does not sanitize these headers — can inject arbitrary values into Request.ClientIPAddresses. In deployments where a rule references this property (e.g. to restrict access to specific IP ranges), this may allow an attacker to bypass the intended access control logic.

Scenario B – IP spoofing against upstream services (proxy mode)

In proxy mode, injected or malformed values in Request.ClientIPAddresses are written unchanged into the X-Forwarded-For header sent to upstream services. Upstream services that trust this header may therefore receive and act on attacker-controlled IP values.

Scenario C – Malformed entries via quoted-string misparse

A Forwarded header containing a quoted value with embedded delimiters (, or ;) is misparsed, producing unintended additional entries in Request.ClientIPAddresses, including malformed fragments with trailing quote characters.

Workarounds

  • Ensure at the network level that only trusted proxies can communicate directly with heimdall.
  • Ensure that the proxy forwarding the requests to heimdall sanitizes or overrides (not merely appends to) Forwarded or X-Forwarded-For headers before forwarding them.
  • Avoid relying on Request.ClientIPAddresses for security-sensitive decisions until patched
Severity
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.17.16"
      },
      "package": {
        "ecosystem": "Go",
        "name": "https://github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-20",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:24:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen the `trusted_proxies` option is configured, heimdall extracts client IP addresses from the `Forwarded` (`for=` parameter) and `X-Forwarded-For` headers and exposes them as `Request.ClientIPAddresses` to the rule pipeline. However, extracted values are not validated to be syntactically valid IP addresses. Arbitrary strings, malformed IP literals, and RFC 7239 `unknown` values and obfuscated identifiers are accepted without further checks.\nIn addition, the `Forwarded` header parser splits on `,` and `;` without accounting for RFC 7239 quoted strings, which can cause a single quoted value to be parsed as multiple entries, with fragments \u2014 including trailing quote characters \u2014 treated as independent addresses.\n\n### Impact\n\n`Request.ClientIPAddresses` is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property \u2014 for example, in a `CEL` authorizer that checks whether a request originates from a trusted IP range using the `networks()` function, or in a `Remote` authorizer that forwards the client IP as part of its payload to an external authorization system. Whether and how `Request.ClientIPAddresses` is used is entirely determined by the rule configuration.\n\nAdditionally, in proxy mode, `Request.ClientIPAddresses` is used directly to construct the `X-Forwarded-For` and `Forwarded` headers forwarded to upstream services. Injected or malformed values are therefore propagated to upstream services unchanged.\n\n### Attack Scenarios\n\nAll scenarios require that `trusted_proxies` is configured. If this option is not set, heimdall ignores forwarding headers entirely, and this vulnerability is not exploitable. Scenarios A and C  (see below) additionally require that rules reference `Request.ClientIPAddresses` in their pipeline.\n\n#### Scenario A \u2013 Manipulation of rule evaluation\n\nAn attacker who can influence forwarding headers \u2014 either by connecting directly to heimdall or through a proxy that does not sanitize these headers \u2014 can inject arbitrary values into `Request.ClientIPAddresses`. In deployments where a rule references this property (e.g. to restrict access to specific IP ranges), this may allow an attacker to bypass the intended access control logic.\n\n#### Scenario B \u2013 IP spoofing against upstream services (proxy mode)\n\nIn proxy mode, injected or malformed values in `Request.ClientIPAddresses` are written unchanged into the `X-Forwarded-For` header sent to upstream services. Upstream services that trust this header may therefore receive and act on attacker-controlled IP values.\n\n#### Scenario C \u2013 Malformed entries via quoted-string misparse\n\nA `Forwarded` header containing a quoted value with embedded delimiters (`,` or `;`) is misparsed, producing unintended additional entries in `Request.ClientIPAddresses`, including malformed fragments with trailing quote characters.\n\n### Workarounds\n\n* Ensure at the network level that only trusted proxies can communicate directly with heimdall.\n* Ensure that the proxy forwarding the requests to heimdall sanitizes or overrides (not merely appends to) `Forwarded` or `X-Forwarded-For` headers before forwarding them.\n* Avoid relying on `Request.ClientIPAddresses` for security-sensitive decisions until patched",
  "id": "GHSA-38x9-25wx-7fg2",
  "modified": "2026-06-18T14:24:37Z",
  "published": "2026-06-18T14:24:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-38x9-25wx-7fg2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: IP Spoofing via Unvalidated Forwarding Headers"
}

GHSA-3CH4-XRP6-59FQ

Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31
VLAI
Details

Authentication Bypass by Spoofing vulnerability in LionScripts IP Blocker Lite allows Functionality Bypass.This issue affects IP Blocker Lite: from n/a through 11.1.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-30479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T09:15:28Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in LionScripts IP Blocker Lite allows Functionality Bypass.This issue affects IP Blocker Lite: from n/a through 11.1.1.",
  "id": "GHSA-3ch4-xrp6-59fq",
  "modified": "2024-05-17T09:31:02Z",
  "published": "2024-05-17T09:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30479"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/ip-address-blocker/wordpress-lionscripts-ip-blocker-lite-plugin-11-1-1-bypass-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3CM7-PVJF-2X7Q

Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-23 15:32
VLAI
Details

Authentication Bypass by Spoofing vulnerability in opa plugin.

An attacker could relay spoofed identity headers to upstream capitalising on non-default configuration in opa plugin.

This could allow the attacker to assume higher privileges on the upstream service. This issue affects Apache APISIX: from 3.5.0 through 3.16.0.

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

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-49231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-19T14:16:23Z",
    "severity": "LOW"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in opa plugin.\n\nAn attacker could relay spoofed identity headers to upstream capitalising on non-default configuration in opa plugin.\n\nThis could allow the attacker to assume higher privileges on the upstream service.\nThis issue affects Apache APISIX: from 3.5.0 through 3.16.0.\n\nUsers are recommended to upgrade to version 3.17.0, which fixes the issue.",
  "id": "GHSA-3cm7-pvjf-2x7q",
  "modified": "2026-06-23T15:32:30Z",
  "published": "2026-06-19T15:33:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49231"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/s1jd1vxm59p6ghx47xhmpjdk1cobo4hn"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/19/13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/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-3FXJ-6JH8-HVHX

Vulnerability from github – Published: 2026-06-25 18:21 – Updated: 2026-06-25 18:21
VLAI
Summary
chi Has an IP Spoofing Vulnerability in `middleware.RealIP`
Details

Summary

The RealIP middleware in go-chi/chi is vulnerable to IP spoofing because it blindly trusts the first (leftmost) element of the X-Forwarded-For HTTP header. This allows a remote attacker to bypass IP-based access control lists (ACLs) and rate-limiting mechanisms by providing a spoofed IP address in the header.

Details

In middleware/realip.go, the realIP function parses the X-Forwarded-For header and extracts the first comma-separated value:

func realIP(r *http.Request) string {
    // ...
    } else if xff := r.Header.Get(xForwardedFor); xff != "" {
        ip, _, _ = strings.Cut(xff, ",")
    }
    // ...
}

Standard practice for X-Forwarded-For is that each proxy appends the client's IP to the end of the list. However, since the client can also provide this header, the leftmost values are untrusted. A client can send a header like X-Forwarded-For: <spoofed_ip>, <actual_proxy_ip>, and go-chi/chi will treat <spoofed_ip> as the source of the request.

Proof of Concept (PoC)

The following code demonstrates how an attacker can bypass an IP-based restriction.

package main

import (
        "fmt"
        "net/http"
        "net/http/httptest"

        "github.com/go-chi/chi/v5"
        "github.com/go-chi/chi/v5/middleware"
)

func main() {
        r := chi.NewRouter()

        // Enable the vulnerable RealIP middleware
        r.Use(middleware.RealIP)

        // An endpoint that should be restricted to a specific administrator IP (1.2.3.4)
        r.Get("/admin/secret", func(w http.ResponseWriter, r *http.Request) {
                clientIP := r.RemoteAddr
                fmt.Printf("[Server] Request received from IP: %s\n", clientIP)

                // Simulate IP-based access control
                if clientIP == "1.2.3.4" {
                        w.WriteHeader(http.StatusOK)
                        w.Write([]byte("CONFIDENTIAL: The secret code is 42\n"))
                } else {
                        w.WriteHeader(http.StatusForbidden)
                        w.Write([]byte("Access Denied: You are not an administrator.\n"))
                }
        })

        // --- Attack Simulation ---
        fmt.Println("--- PoC: IP Spoofing Attack on chi/middleware.RealIP ---")

        // 1. Normal Request (Should be denied)
        req1, _ := http.NewRequest("GET", "/admin/secret", nil)
        rr1 := httptest.NewRecorder()
        r.ServeHTTP(rr1, req1)
        fmt.Printf("[Client] Normal Request -> Status: %d, Body: %s", rr1.Code, rr1.Body.String())

        // 2. Spoofed Request (Using X-Forwarded-For)
        // Attacker claims to be '1.2.3.4'
        req2, _ := http.NewRequest("GET", "/admin/secret", nil)
        req2.Header.Set("X-Forwarded-For", "1.2.3.4, 5.6.7.8") // 5.6.7.8 is a fake proxy IP
        rr2 := httptest.NewRecorder()
        r.ServeHTTP(rr2, req2)
        fmt.Printf("[Client] Spoofed Request -> Status: %d, Body: %s", rr2.Code, rr2.Body.String())
}

Impact

An attacker can masquerade as any IP address. This can lead to: - Bypass of Authentication/Authorization: Accessing administrative panels or private APIs restricted by IP. - Rate Limiting Evasion: Circumbeting rate limiters that use RemoteAddr as a key. - Log Forgery: Causing incorrect IP addresses to be recorded in security logs.

CWE

  • CWE-290: Authentication Bypass by Spoofing
  • CWE-345: Insufficient Verification of Data Authenticity

CVSS 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 (6.9 Moderate)

Affected Versions

  • github.com/go-chi/chi/v5 <= v5.2.1 (and all previous versions)

Recommendation

  1. Stop using middleware.RealIP if you cannot guarantee that the incoming request headers are from a trusted source and have been sanitized by a proxy.
  2. Implement a trust-based IP extraction mechanism that verifies the chain of proxies.
  3. Use the X-Forwarded-For header by traversing it from right to left and stopping at the first IP address that is not in your list of trusted proxies.

Suggested Fix

A secure implementation of RealIP should allow developers to specify a list of trusted proxy IP ranges (CIDRs). Below is a conceptual example of how to fix this by traversing the X-Forwarded-For header from right to left:

func GetClientIP(r *http.Request, trustedProxies []net.IPNet) string {
        xff := r.Header.Get("X-Forwarded-For")
        if xff == "" {
                return r.RemoteAddr
        }

        ips := strings.Split(xff, ",")
        // Traverse from right to left
        for i := len(ips) - 1; i >= 0; i-- {
                ipStr := strings.TrimSpace(ips[i])
                ip := net.ParseIP(ipStr)
                if ip == nil {
                        continue
                }

                if !isTrustedProxy(ip, trustedProxies) {
                        return ipStr
                }
        }

        return r.RemoteAddr
}

func isTrustedProxy(ip net.IP, trustedProxies []net.IPNet) bool {
        for _, network := range trustedProxies {
                if network.Contains(ip) {
                        return true
                }
        }
        return false
}

By providing a configuration like middleware.RealIPWithConfig(Config{TrustedProxies: []string{"10.0.0.0/8"}}) , the middleware can safely identify the true client IP even in complex proxy environments.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-chi/chi/v5/middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2.1"
            },
            {
              "fixed": "5.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T18:21:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe `RealIP` middleware in `go-chi/chi` is vulnerable to IP spoofing because it blindly trusts the first (leftmost) element of the `X-Forwarded-For` HTTP header. This allows a remote attacker to bypass IP-based access control lists (ACLs) and rate-limiting mechanisms by providing a spoofed IP address in the header.\n\n## Details\nIn `middleware/realip.go`, the `realIP` function parses the `X-Forwarded-For` header and extracts the first comma-separated value:\n\n```go\nfunc realIP(r *http.Request) string {\n    // ...\n    } else if xff := r.Header.Get(xForwardedFor); xff != \"\" {\n        ip, _, _ = strings.Cut(xff, \",\")\n    }\n    // ...\n}\n```\n\nStandard practice for `X-Forwarded-For` is that each proxy appends the client\u0027s IP to the end of the list. However, since the client can also provide this header, the leftmost values are untrusted. A client can send a header like `X-Forwarded-For: \u003cspoofed_ip\u003e, \u003cactual_proxy_ip\u003e`, and `go-chi/chi` will treat `\u003cspoofed_ip\u003e` as the source of the request.\n\n## Proof of Concept (PoC)\nThe following code demonstrates how an attacker can bypass an IP-based restriction.\n\n```go\npackage main\n\nimport (\n        \"fmt\"\n        \"net/http\"\n        \"net/http/httptest\"\n\n        \"github.com/go-chi/chi/v5\"\n        \"github.com/go-chi/chi/v5/middleware\"\n)\n\nfunc main() {\n        r := chi.NewRouter()\n\n        // Enable the vulnerable RealIP middleware\n        r.Use(middleware.RealIP)\n\n        // An endpoint that should be restricted to a specific administrator IP (1.2.3.4)\n        r.Get(\"/admin/secret\", func(w http.ResponseWriter, r *http.Request) {\n                clientIP := r.RemoteAddr\n                fmt.Printf(\"[Server] Request received from IP: %s\\n\", clientIP)\n\n                // Simulate IP-based access control\n                if clientIP == \"1.2.3.4\" {\n                        w.WriteHeader(http.StatusOK)\n                        w.Write([]byte(\"CONFIDENTIAL: The secret code is 42\\n\"))\n                } else {\n                        w.WriteHeader(http.StatusForbidden)\n                        w.Write([]byte(\"Access Denied: You are not an administrator.\\n\"))\n                }\n        })\n\n        // --- Attack Simulation ---\n        fmt.Println(\"--- PoC: IP Spoofing Attack on chi/middleware.RealIP ---\")\n\n        // 1. Normal Request (Should be denied)\n        req1, _ := http.NewRequest(\"GET\", \"/admin/secret\", nil)\n        rr1 := httptest.NewRecorder()\n        r.ServeHTTP(rr1, req1)\n        fmt.Printf(\"[Client] Normal Request -\u003e Status: %d, Body: %s\", rr1.Code, rr1.Body.String())\n\n        // 2. Spoofed Request (Using X-Forwarded-For)\n        // Attacker claims to be \u00271.2.3.4\u0027\n        req2, _ := http.NewRequest(\"GET\", \"/admin/secret\", nil)\n        req2.Header.Set(\"X-Forwarded-For\", \"1.2.3.4, 5.6.7.8\") // 5.6.7.8 is a fake proxy IP\n        rr2 := httptest.NewRecorder()\n        r.ServeHTTP(rr2, req2)\n        fmt.Printf(\"[Client] Spoofed Request -\u003e Status: %d, Body: %s\", rr2.Code, rr2.Body.String())\n}\n```\n\n## Impact\nAn attacker can masquerade as any IP address. This can lead to:\n- **Bypass of Authentication/Authorization:** Accessing administrative panels or private APIs restricted by IP.\n- **Rate Limiting Evasion:** Circumbeting rate limiters that use `RemoteAddr` as a key.\n- **Log Forgery:** Causing incorrect IP addresses to be recorded in security logs.\n\n## CWE\n- **CWE-290:** Authentication Bypass by Spoofing\n- **CWE-345:** Insufficient Verification of Data Authenticity\n\n## CVSS Score\n- **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** (6.9 Moderate)\n\n## Affected Versions\n- `github.com/go-chi/chi/v5` \u003c= `v5.2.1` (and all previous versions)\n\n## Recommendation\n1.  **Stop using `middleware.RealIP`** if you cannot guarantee that the incoming request headers are from a trusted source and have been sanitized by a proxy.\n2.  Implement a trust-based IP extraction mechanism that verifies the chain of proxies.\n3.  Use the `X-Forwarded-For` header by traversing it from **right to left** and stopping at the first IP address that is not in your list of trusted proxies.\n\n## Suggested Fix\nA secure implementation of `RealIP` should allow developers to specify a list of trusted proxy IP ranges (CIDRs). Below is a conceptual example of how to fix this by traversing the `X-Forwarded-For` header from right to left:\n\n```go\nfunc GetClientIP(r *http.Request, trustedProxies []net.IPNet) string {\n        xff := r.Header.Get(\"X-Forwarded-For\")\n        if xff == \"\" {\n                return r.RemoteAddr\n        }\n\n        ips := strings.Split(xff, \",\")\n        // Traverse from right to left\n        for i := len(ips) - 1; i \u003e= 0; i-- {\n                ipStr := strings.TrimSpace(ips[i])\n                ip := net.ParseIP(ipStr)\n                if ip == nil {\n                        continue\n                }\n\n                if !isTrustedProxy(ip, trustedProxies) {\n                        return ipStr\n                }\n        }\n\n        return r.RemoteAddr\n}\n\nfunc isTrustedProxy(ip net.IP, trustedProxies []net.IPNet) bool {\n        for _, network := range trustedProxies {\n                if network.Contains(ip) {\n                        return true\n                }\n        }\n        return false\n}\n```\n\nBy providing a configuration like `middleware.RealIPWithConfig(Config{TrustedProxies: []string{\"10.0.0.0/8\"}})` , the middleware can safely identify the true client IP even in complex proxy environments.",
  "id": "GHSA-3fxj-6jh8-hvhx",
  "modified": "2026-06-25T18:21:38Z",
  "published": "2026-06-25T18:21:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-chi/chi/security/advisories/GHSA-3fxj-6jh8-hvhx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-chi/chi"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "chi Has an IP Spoofing Vulnerability in `middleware.RealIP`"
}

GHSA-3G7F-9CP4-6M47

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

An Authentication Bypass by Spoofing issue was discovered in LAVA Ether-Serial Link (ESL) running firmware versions 6.01.00/29.03.2007 and prior versions. An improper authentication vulnerability has been identified, which, if exploited, would allow an attacker with the same IP address to bypass authentication by accessing a specific uniform resource locator.

Severity
9.8 (Critical)
CVSS:3.0/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-2017-14003"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-11T19:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "An Authentication Bypass by Spoofing issue was discovered in LAVA Ether-Serial Link (ESL) running firmware versions 6.01.00/29.03.2007 and prior versions. An improper authentication vulnerability has been identified, which, if exploited, would allow an attacker with the same IP address to bypass authentication by accessing a specific uniform resource locator.",
  "id": "GHSA-3g7f-9cp4-6m47",
  "modified": "2022-05-13T01:37:41Z",
  "published": "2022-05-13T01:37:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14003"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-283-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101226"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3J33-HFWP-PGR4

Vulnerability from github – Published: 2024-06-04 15:30 – Updated: 2024-06-04 15:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability in miniorange Malware Scanner allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Malware Scanner: from n/a through 4.7.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-52176"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-04T13:15:50Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in miniorange Malware Scanner allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Malware Scanner: from n/a through 4.7.1.",
  "id": "GHSA-3j33-hfwp-pgr4",
  "modified": "2024-06-04T15:30:58Z",
  "published": "2024-06-04T15:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52176"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/miniorange-malware-protection/wordpress-malware-scanner-plugin-4-7-1-ip-restriction-bypass-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3M3Q-X3GJ-F79X

Vulnerability from github – Published: 2026-02-17 21:31 – Updated: 2026-03-06 01:01
VLAI
Summary
OpenClaw optional voice-call plugin: webhook verification may be bypassed behind certain proxy configurations
Details

Affected Packages / Versions

This issue affects the optional voice-call plugin only. It is not enabled by default; it only applies to installations where the plugin is installed and enabled.

  • Package: @openclaw/voice-call
  • Vulnerable versions: < 2026.2.3
  • Patched versions: >= 2026.2.3

Legacy package name (if you are still using it):

  • Package: @clawdbot/voice-call
  • Vulnerable versions: <= 2026.1.24
  • Patched versions: none published under this package name; migrate to @openclaw/voice-call

Summary

In certain reverse-proxy / forwarding setups, webhook verification can be bypassed if untrusted forwarded headers are accepted.

Impact

An external party may be able to send voice-call webhook requests that are accepted as valid, which can result in spoofed webhook events being processed.

Root Cause

Some deployments implicitly trusted forwarded headers (for example Forwarded / X-Forwarded-*) when determining request properties used during webhook verification. If those headers are not overwritten by a trusted proxy, a client can supply them directly and influence verification.

Resolution

Ignore forwarded headers by default unless explicitly trusted and allowlisted in configuration. Keep any loopback-only development bypass restricted to local development only. Upgrade to a patched version.

If you cannot upgrade immediately, strip Forwarded and X-Forwarded-* headers at the edge so clients cannot supply them directly.

Fix Commit(s)

  • a749db9820eb6d6224032a5a34223d286d2dcc2f

Credits

Thanks @0x5t for reporting.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@openclaw/voice-call"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clawdbot/voice-call"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.1.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T21:31:58Z",
    "nvd_published_at": "2026-03-05T22:16:19Z",
    "severity": "HIGH"
  },
  "details": "## Affected Packages / Versions\n\nThis issue affects the optional voice-call plugin only. It is not enabled by default; it only applies to installations where the plugin is installed and enabled.\n\n- Package: `@openclaw/voice-call`\n- Vulnerable versions: `\u003c 2026.2.3`\n- Patched versions: `\u003e= 2026.2.3`\n\nLegacy package name (if you are still using it):\n\n- Package: `@clawdbot/voice-call`\n- Vulnerable versions: `\u003c= 2026.1.24`\n- Patched versions: none published under this package name; migrate to `@openclaw/voice-call`\n\n## Summary\n\nIn certain reverse-proxy / forwarding setups, webhook verification can be bypassed if untrusted forwarded headers are accepted.\n\n## Impact\n\nAn external party may be able to send voice-call webhook requests that are accepted as valid, which can result in spoofed webhook events being processed.\n\n## Root Cause\n\nSome deployments implicitly trusted forwarded headers (for example `Forwarded` / `X-Forwarded-*`) when determining request properties used during webhook verification. If those headers are not overwritten by a trusted proxy, a client can supply them directly and influence verification.\n\n## Resolution\n\nIgnore forwarded headers by default unless explicitly trusted and allowlisted in configuration. Keep any loopback-only development bypass restricted to local development only. Upgrade to a patched version.\n\nIf you cannot upgrade immediately, strip `Forwarded` and `X-Forwarded-*` headers at the edge so clients cannot supply them directly.\n\n## Fix Commit(s)\n\n- `a749db9820eb6d6224032a5a34223d286d2dcc2f`\n\n## Credits\n\nThanks `@0x5t` for reporting.",
  "id": "GHSA-3m3q-x3gj-f79x",
  "modified": "2026-03-06T01:01:21Z",
  "published": "2026-02-17T21:31:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3m3q-x3gj-f79x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a749db9820eb6d6224032a5a34223d286d2dcc2f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.3"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-voice-call-webhook-verification-bypass-via-forwarded-headers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw optional voice-call plugin: webhook verification may be bypassed behind certain proxy configurations"
}

GHSA-3MF6-CPXV-733M

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

EMC Unisphere for VMAX Virtual Appliance (vApp) versions prior to 8.4.0.15, EMC Solutions Enabler Virtual Appliance versions prior to 8.4.0.15, EMC VASA Virtual Appliance versions prior to 8.4.0.512, and EMC VMAX Embedded Management (eManagement) versions prior to and including 1.4 (Enginuity Release 5977.1125.1125 and earlier) contain an authentication bypass vulnerability that may potentially be exploited by malicious users to compromise the affected system.

Severity
9.8 (Critical)
CVSS:3.0/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-2017-14375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-01T01:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "EMC Unisphere for VMAX Virtual Appliance (vApp) versions prior to 8.4.0.15, EMC Solutions Enabler Virtual Appliance versions prior to 8.4.0.15, EMC VASA Virtual Appliance versions prior to 8.4.0.512, and EMC VMAX Embedded Management (eManagement) versions prior to and including 1.4 (Enginuity Release 5977.1125.1125 and earlier) contain an authentication bypass vulnerability that may potentially be exploited by malicious users to compromise the affected system.",
  "id": "GHSA-3mf6-cpxv-733m",
  "modified": "2022-05-13T01:07:27Z",
  "published": "2022-05-13T01:07:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14375"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2017/Oct/70"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101673"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039704"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3MM3-WFPV-Q85G

Vulnerability from github – Published: 2025-11-20 21:30 – Updated: 2025-11-21 00:38
VLAI
Summary
Clerk-js vulnerable to bypass of OAuth authentication flow by manipulating request at OTP verification stage
Details

An issue was discovered in Clerk-js 5.88.0 allowing attackers to bypass the OAuth authentication flow by manipulating the request at the OTP verification stage.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
6.6 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@clerk/clerk-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.88.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-63700"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-21T00:38:59Z",
    "nvd_published_at": "2025-11-20T19:16:21Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Clerk-js 5.88.0 allowing attackers to bypass the OAuth authentication flow by manipulating the request at the OTP verification stage.",
  "id": "GHSA-3mm3-wfpv-q85g",
  "modified": "2025-11-21T00:38:59Z",
  "published": "2025-11-20T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63700"
    },
    {
      "type": "WEB",
      "url": "https://clerk.com"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/clerk/javascript"
    },
    {
      "type": "WEB",
      "url": "https://github.com/itsnishat08/CVE-2025-63700"
    }
  ],
  "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:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Clerk-js vulnerable to bypass of OAuth authentication flow by manipulating request at OTP verification stage"
}

GHSA-3QG8-HQ7J-JJ33

Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-06-13 00:34
VLAI
Details

OpenClaw before 2026.5.18 contains an identity header validation vulnerability allowing local same-host callers to forge trusted-proxy identity headers. Attackers with access to the proxy-facing Gateway port can supply forged identity headers to assume operator identity and potentially escalate privileges.

Severity
7.7 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
7.4 (High)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-53832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T22:16:54Z",
    "severity": "HIGH"
  },
  "details": "OpenClaw before 2026.5.18 contains an identity header validation vulnerability allowing local same-host callers to forge trusted-proxy identity headers. Attackers with access to the proxy-facing Gateway port can supply forged identity headers to assume operator identity and potentially escalate privileges.",
  "id": "GHSA-3qg8-hq7j-jj33",
  "modified": "2026-06-13T00:34:32Z",
  "published": "2026-06-13T00:34:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rggc-m335-3wvj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53832"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-identity-header-forgery-via-trusted-proxy-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/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"
    }
  ]
}

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