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-995C-QWW8-64FJ

Vulnerability from github – Published: 2024-12-20 18:31 – Updated: 2024-12-20 19:40
VLAI
Summary
Oqtane Framework Incorrect Access Control vulnerability
Details

Oqtane Framework 6.0.0 is vulnerable to Incorrect Access Control. By manipulating the entityid parameter, attackers can bypass passcode validation and successfully log into the application or access restricted data without proper authorization. The lack of server-side validation exacerbates the issue, as the application relies on client-side information for authentication.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Oqtane.Framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "6.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Oqtane.Server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "6.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-55470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-20T19:40:51Z",
    "nvd_published_at": "2024-12-20T16:15:23Z",
    "severity": "HIGH"
  },
  "details": "Oqtane Framework 6.0.0 is vulnerable to Incorrect Access Control. By manipulating the entityid parameter, attackers can bypass passcode validation and successfully log into the application or access restricted data without proper authorization. The lack of server-side validation exacerbates the issue, as the application relies on client-side information for authentication.",
  "id": "GHSA-995c-qww8-64fj",
  "modified": "2024-12-20T19:40:51Z",
  "published": "2024-12-20T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55470"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oqtane/oqtane.framework/pull/4878/files"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Kaushikjoshi/2d8ad350ba5e72030fcee2536498cfe4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oqtane/oqtane.framework"
    }
  ],
  "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:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Oqtane Framework Incorrect Access Control vulnerability"
}

GHSA-995J-3CJ2-3P49

Vulnerability from github – Published: 2025-02-20 18:31 – Updated: 2025-11-04 21:31
VLAI
Details

A lack of rate limiting in the 'Forgot Password' feature of PHPJabbers Cleaning Business Software v1.0 allows attackers to send an excessive amount of email for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-51327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-20T16:15:35Z",
    "severity": "MODERATE"
  },
  "details": "A lack of rate limiting in the \u0027Forgot Password\u0027 feature of PHPJabbers Cleaning Business Software v1.0 allows attackers to send an excessive amount of email for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages.",
  "id": "GHSA-995j-3cj2-3p49",
  "modified": "2025-11-04T21:31:30Z",
  "published": "2025-02-20T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51327"
    },
    {
      "type": "WEB",
      "url": "https://packetstorm.news/files/id/176506"
    },
    {
      "type": "WEB",
      "url": "https://www.phpjabbers.com/cleaning-business-software/#sectionDemo"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176506/PHPJabbers-Cleaning-Business-Software-1.0-Missing-Rate-Limiting.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-99M3-849W-RG54

Vulnerability from github – Published: 2024-09-10 21:31 – Updated: 2024-09-10 21:31
VLAI
Details

An incorrectly implemented authentication scheme that is subjected to a spoofing attack in the management console of Ivanti Workspace Control version 10.18.0.0 and below allows a local authenticated attacker to escalate their privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-44104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T21:15:13Z",
    "severity": "HIGH"
  },
  "details": "An incorrectly implemented authentication scheme that is subjected to a spoofing attack in the management console of Ivanti Workspace Control version 10.18.0.0 and below allows a local authenticated attacker to escalate their privileges.",
  "id": "GHSA-99m3-849w-rg54",
  "modified": "2024-09-10T21:31:40Z",
  "published": "2024-09-10T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44104"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Workspace-Control-IWC"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9F4W-C8MJ-53R3

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

If exploited, this vulnerability allows an attacker to access resources which are not otherwise accessible without proper authentication. Roon Labs has already fixed this vulnerability in the following versions: Roon Server 2021-05-18 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-28810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-08T03:15:00Z",
    "severity": "HIGH"
  },
  "details": "If exploited, this vulnerability allows an attacker to access resources which are not otherwise accessible without proper authentication. Roon Labs has already fixed this vulnerability in the following versions: Roon Server 2021-05-18 and later",
  "id": "GHSA-9f4w-c8mj-53r3",
  "modified": "2022-05-24T19:04:23Z",
  "published": "2022-05-24T19:04:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28810"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/zh-tw/security-advisory/qsa-21-17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9F74-XW28-QC4R

Vulnerability from github – Published: 2024-05-17 12:30 – Updated: 2024-05-17 12:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability in RafflePress Giveaways and Contests allows Functionality Bypass.This issue affects Giveaways and Contests: from n/a through 1.12.7.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-32827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T10:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in RafflePress Giveaways and Contests allows Functionality Bypass.This issue affects Giveaways and Contests: from n/a through 1.12.7.",
  "id": "GHSA-9f74-xw28-qc4r",
  "modified": "2024-05-17T12:30:59Z",
  "published": "2024-05-17T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32827"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/rafflepress/wordpress-giveaways-and-contests-by-rafflepress-plugin-1-12-7-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:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GFQ-FQG4-F89Q

Vulnerability from github – Published: 2025-04-17 12:30 – Updated: 2025-04-17 12:30
VLAI
Details

There is a whitelist mechanism bypass in GameCenter ,successful exploitation of this vulnerability may affect service confidentiality and integrity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-2188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T10:15:15Z",
    "severity": "HIGH"
  },
  "details": "There is a whitelist mechanism bypass in GameCenter ,successful exploitation of this vulnerability may affect service confidentiality and integrity.",
  "id": "GHSA-9gfq-fqg4-f89q",
  "modified": "2025-04-17T12:30:32Z",
  "published": "2025-04-17T12:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2188"
    },
    {
      "type": "WEB",
      "url": "https://www.honor.com/global/security/cve-2025-2188"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9HV9-FHRR-M92V

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.0 before 4.4.1, improper validation of API request parameters enables remote code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-59706"
  ],
  "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.0 before 4.4.1, improper validation of API request parameters enables remote code execution.",
  "id": "GHSA-9hv9-fhrr-m92v",
  "modified": "2026-03-26T21:31:23Z",
  "published": "2026-03-25T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59706"
    },
    {
      "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-9HV9-J7P5-6W36

Vulnerability from github – Published: 2023-11-01 18:30 – Updated: 2023-11-01 18:30
VLAI
Details

Multiple Cisco products are affected by a vulnerability in Snort access control policies that could allow an unauthenticated, remote attacker to bypass the configured policies on an affected system. This vulnerability is due to a logic error that occurs when the access control policies are being populated. An attacker could exploit this vulnerability by establishing a connection to an affected device. A successful exploit could allow the attacker to bypass configured access control rules on the affected system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-01T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Multiple Cisco products are affected by a vulnerability in Snort access control policies that could allow an unauthenticated, remote attacker to bypass the configured policies on an affected system. This vulnerability is due to a logic error that occurs when the access control policies are being populated. An attacker could exploit this vulnerability by establishing a connection to an affected device. A successful exploit could allow the attacker to bypass configured access control rules on the affected system.",
  "id": "GHSA-9hv9-j7p5-6w36",
  "modified": "2023-11-01T18:30:33Z",
  "published": "2023-11-01T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20246"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftd-snort3acp-bypass-3bdR2BEh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9M63-33Q3-XQ5X

Vulnerability from github – Published: 2025-03-10 22:24 – Updated: 2025-03-14 20:02
VLAI
Summary
Vela Server Has Insufficient Webhook Payload Data Verification
Details

Impact

Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit.

Any user with access to the CI instance and the linked source control manager can perform the exploit.

Method

By spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository.

These secrets could be exfiltrated by follow up builds to the repository.

Patches

v0.26.3 — Image: target/vela-server:v0.26.3 v0.25.3 — Image: target/vela-server:v0.25.3

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There are no workarounds to the issue.

References

Are there any links users can visit to find out more?

Please see linked CWEs (common weakness enumerators) for more information.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-vela/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.25.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.26.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-vela/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.26.0"
            },
            {
              "fixed": "0.26.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-10T22:24:35Z",
    "nvd_published_at": "2025-03-10T19:15:41Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUsers with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit. \n\nAny user with access to the CI instance and the linked source control manager can perform the exploit.\n\n### Method\nBy spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. \n\nThese secrets could be exfiltrated by follow up builds to the repository.\n\n### Patches\n`v0.26.3` \u2014 Image: `target/vela-server:v0.26.3`\n`v0.25.3` \u2014 Image: `target/vela-server:v0.25.3`\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere are no workarounds to the issue.\n\n### References\n_Are there any links users can visit to find out more?_\n\nPlease see linked CWEs (common weakness enumerators) for more information.",
  "id": "GHSA-9m63-33q3-xq5x",
  "modified": "2025-03-14T20:02:47Z",
  "published": "2025-03-10T22:24:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/security/advisories/GHSA-9m63-33q3-xq5x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27616"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/commit/257886e5a3eea518548387885894e239668584f5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/commit/67c1892e2464dc54b8d2588815dfb7819222500b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vela/server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/releases/tag/v0.25.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/releases/tag/v0.26.3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3509"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vela Server Has Insufficient Webhook Payload Data Verification"
}

GHSA-9Q47-3CM2-2RP8

Vulnerability from github – Published: 2026-10-09 17:09 – Updated: 2026-10-09 17:09
VLAI
Summary
pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header
Details

Summary

pyLoad determines the "client IP" used for its rate-limiting decorator and for its security/audit logging by reading the client-supplied X-Forwarded-For (XFF) HTTP header and taking the leftmost value. No trusted-proxy configuration exists (the Cheroot WSGI server faces clients directly, and there is no ProxyFix middleware). Because any client can freely set this header, an attacker can (1) completely bypass rate limiting by rotating the header on each request, and (2) forge the source IP recorded in security logs for login and API-key authentication failures, defeating IP-based blocking (e.g. fail2ban) and poisoning attribution.

Severity

Medium — CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L (~5.3)

  • CWE-807: Reliance on Untrusted Inputs in a Security Decision
  • CWE-290: Authentication Bypass by Spoofing
  • CWE-348: Use of Less Trusted Source

Affected Version

pyLoad 0.5.0b3 (built from the develop branch). Confirmed still present and exploitable in the later pyload-develop-2 snapshot (the affected files are byte-identical between the two; the develop-2 changes only touched the unrelated API-key cache).

Affected Component

Web UI request handling — client-IP derivation used by rate limiting and security logging.

  • src/pyload/webui/app/helpers.py:446 — inside the rate_limit() decorator; derives the per-IP bucket key.
  • src/pyload/webui/app/helpers.py:357 — API-key authentication success/failure logging.
  • src/pyload/webui/app/blueprints/app_blueprint.py:81 — web login success/failure logging.
  • src/pyload/webui/webserver_thread.py — Cheroot serves the Flask app directly; no reverse-proxy trust boundary or ProxyFix.
  • Consumer: src/pyload/webui/app/blueprints/api_blueprint.py:25 applies @rate_limit(count=100, period=60) to the /api/<func> RPC endpoint.

Description:

All three locations derive the client IP with the identical expression:

client_ip = flask.request.headers.get("X-Forwarded-For", "").split(",")[0].strip() or flask.request.remote_addr

X-Forwarded-For is an HTTP request header fully controlled by the client. The code takes split(",")[0] — the leftmost token — which is always the value supplied by the original client (a proxy appends its own value to the right). Only when the header is entirely absent does the code fall back to request.remote_addr (the real TCP peer). There is no configured trusted-proxy count, and pyLoad's server (Cheroot) terminates client connections directly, so remote_addr is the true peer and the XFF value is untrusted attacker input.

Two security decisions are made on this untrusted value:

  1. Rate limiting (rate_limit()): the decorator keeps request_history[client_ip] and enforces count requests per period per client_ip. Since client_ip is attacker-controlled, sending a distinct value each request creates a distinct bucket, so the counter never accumulates and the limit never triggers.
  2. Audit logging: login-failure and API-auth-failure log lines embed [CLIENT: {client_ip}] using the same spoofable value, so the recorded source address is chosen by the attacker.

Notably, the codebase is internally inconsistent: is_loopback_request() (helpers.py:288) treats the presence of X-Forwarded-For / X-Real-IP / Forwarded as a reason to distrust an apparent loopback source, while the rate-limit and logging paths naively trust the same header — indicating the trust here is unintended.

Proof of Concept

The rate_limit() decorator's actual source (bytes read from pyload-develop-2/src/pyload/webui/app/helpers.py, lines 416–514) was executed under a real Flask test client. Rate limit set to 5/60s for brevity (identical logic to the production 100/min):

import ast, math, time
from functools import wraps
import flask

HELPERS = ".../pyload-develop-2/src/pyload/webui/app/helpers.py"
src = open(HELPERS).read()
node = next(n for n in ast.parse(src).body
            if isinstance(n, ast.FunctionDef) and n.name == "rate_limit")
ns = {"flask": flask, "time": time, "math": math, "wraps": wraps}
exec(compile(ast.get_source_segment(src, node), HELPERS, "exec"), ns)
rate_limit = ns["rate_limit"]

def build_app():
    app = flask.Flask(__name__)
    @app.route("/api/ping")
    @rate_limit(count=5, period=60)
    def ping():
        return flask.json.jsonify({"ok": True})
    return app

def run(hdr):
    app = build_app()
    with app.test_client() as c:
        return [c.get("/api/ping", headers=hdr(i)).status_code for i in range(8)]

print("FIXED   XFF:", run(lambda i: {"X-Forwarded-For": "203.0.113.9"}))
print("ROTATE  XFF:", run(lambda i: {"X-Forwarded-For": f"10.0.0.{i}"}))

Output:

FIXED   XFF: [200, 200, 200, 200, 200, 429, 429, 429]     # limit enforced
ROTATE  XFF: [200, 200, 200, 200, 200, 200, 200, 200]     # 0x 429 -> limit bypassed
# server log during FIXED run:
#   WARNING in helpers: Rate limit exceeded for IP 203.0.113.9: 5 requests in 60 (limit: 5/60)

Derivation check (XFF present, real peer is loopback):

# request with header X-Forwarded-For: 8.8.8.8 and REMOTE_ADDR 127.0.0.1
client_ip = request.headers.get("X-Forwarded-For","").split(",")[0].strip() or request.remote_addr
# -> client_ip == "8.8.8.8"   (the spoofed value wins over the real remote_addr)

Equivalent against a live instance:

# Rate limit never trips regardless of volume:
for i in $(seq 1 500); do
  curl -s -o /dev/null -H "X-API-Key: pl_1<valid-key>" \
       -H "X-Forwarded-For: 10.0.0.$((RANDOM%255))" \
       http://127.0.0.1:8000/api/get_server_version
done   # no HTTP 429 is ever returned

# Forged source IP in the audit log:
curl -s -o /dev/null -H "X-Forwarded-For: 8.8.8.8" \
     --data 'username=admin&password=wrong' http://127.0.0.1:8000/login
# server log: Login failed for user 'admin' using Web Client [CLIENT: 8.8.8.8]

Steps To Reproduce

  1. Start a pyLoad instance directly exposed (no reverse proxy), as in a default deployment.
  2. Obtain any valid API key (or use the login endpoint) so requests reach the rate-limited / logged code paths.
  3. Send more than the configured limit of requests to a @rate_limit-protected endpoint (e.g. /api/get_server_version) while setting a different X-Forwarded-For value on each request. Observe that no 429 Too Many Requests is ever returned.
  4. Control: repeat step 3 with a fixed X-Forwarded-For value; observe 429 after the limit, proving the bucket is keyed on the header value.
  5. Send a failed login (or failed API-key request) with X-Forwarded-For: 8.8.8.8 and inspect the server log; the failure is attributed to 8.8.8.8 rather than the real client address.

Impact

  • Rate limiting on the authenticated API (/api/<func>, 100/min) and any other @rate_limit-protected endpoint provides no protection against a single attacker, who can issue unlimited requests — enabling resource abuse and unthrottled brute-forcing of anything reachable through those endpoints.
  • Security/audit logs cannot be trusted for source attribution. An attacker can stamp every malicious request with an arbitrary or innocent third-party IP, evading IP-based blocklists / fail2ban and misdirecting incident response.
  • Amplifies other authentication weaknesses (e.g. the absence of throttling on /login), since even the throttling that does exist elsewhere is defeated and the attacker's IP is unlogged.

Root Causes

  1. A client-controlled HTTP header (X-Forwarded-For) is used directly in security decisions (rate-limit bucketing and audit attribution) without any trusted-proxy validation (CWE-807).
  2. The leftmost XFF token is selected, which is always the value supplied by the original client; this is spoofable both in direct-exposure and behind-a-proxy deployments (CWE-348).
  3. No ProxyFix / trusted-proxy-hop configuration exists, and the server terminates client connections directly, so there is no basis for trusting forwarded headers at all.
  4. Inconsistent handling across the codebase (loopback checks distrust these headers while rate-limit/logging trust them) indicates the trust is accidental rather than designed.

Suggested Fix

  1. By default, use request.remote_addr (the real TCP peer) for rate limiting and logging; do not trust X-Forwarded-For unless a proxy is explicitly configured.
  2. Add an explicit, operator-configured trusted-proxy count (default 0 = trust none). When set, apply Werkzeug's ProxyFix(app.wsgi_app, x_for=N) and read the correct hop (the value inserted by the trusted proxy — typically the Nth-from-right token — not the leftmost client-supplied token).
  3. Derive the trusted client IP once in a single helper and use it consistently for rate limiting, logging, and the loopback checks, removing the duplicated inline expressions.
  4. Consider defense-in-depth: cap the number of distinct rate-limit buckets and/or additionally rate-limit on remote_addr so a spoofed header cannot create unbounded buckets.

Invariant to restore: security decisions and audit attribution must be based on a connection-level or trusted-proxy-validated address, never on a raw client-supplied header.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyload-ng"
      },
      "versions": [
        "0.5.0b3.dev101"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T17:09:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\npyLoad determines the \"client IP\" used for its rate-limiting decorator and for its\nsecurity/audit logging by reading the client-supplied `X-Forwarded-For` (XFF) HTTP header and\ntaking the leftmost value. No trusted-proxy configuration exists (the Cheroot WSGI server faces\nclients directly, and there is no `ProxyFix` middleware). Because any client can freely set this\nheader, an attacker can (1) completely bypass rate limiting by rotating the header on each request,\nand (2) forge the source IP recorded in security logs for login and API-key authentication\nfailures, defeating IP-based blocking (e.g. fail2ban) and poisoning attribution.\n\n\n## Severity\n\nMedium \u2014 CVSS 3.1: `AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L` (~5.3)\n\n- CWE-807: Reliance on Untrusted Inputs in a Security Decision\n- CWE-290: Authentication Bypass by Spoofing\n- CWE-348: Use of Less Trusted Source\n\n\n## Affected Version\n\npyLoad 0.5.0b3 (built from the `develop` branch). Confirmed still present and exploitable in the\nlater `pyload-develop-2` snapshot (the affected files are byte-identical between the two; the\n`develop-2` changes only touched the unrelated API-key cache).\n\n\n## Affected Component\n\nWeb UI request handling \u2014 client-IP derivation used by rate limiting and security logging.\n\n- `src/pyload/webui/app/helpers.py:446` \u2014 inside the `rate_limit()` decorator; derives the per-IP\n  bucket key.\n- `src/pyload/webui/app/helpers.py:357` \u2014 API-key authentication success/failure logging.\n- `src/pyload/webui/app/blueprints/app_blueprint.py:81` \u2014 web login success/failure logging.\n- `src/pyload/webui/webserver_thread.py` \u2014 Cheroot serves the Flask app directly; no reverse-proxy\n  trust boundary or `ProxyFix`.\n- Consumer: `src/pyload/webui/app/blueprints/api_blueprint.py:25` applies\n  `@rate_limit(count=100, period=60)` to the `/api/\u003cfunc\u003e` RPC endpoint.\n\n\n## Description:\n\nAll three locations derive the client IP with the identical expression:\n\n```python\nclient_ip = flask.request.headers.get(\"X-Forwarded-For\", \"\").split(\",\")[0].strip() or flask.request.remote_addr\n```\n\n`X-Forwarded-For` is an HTTP request header fully controlled by the client. The code takes\n`split(\",\")[0]` \u2014 the leftmost token \u2014 which is always the value supplied by the *original client*\n(a proxy appends its own value to the right). Only when the header is entirely absent does the code\nfall back to `request.remote_addr` (the real TCP peer). There is no configured trusted-proxy count,\nand pyLoad\u0027s server (Cheroot) terminates client connections directly, so `remote_addr` is the true\npeer and the XFF value is untrusted attacker input.\n\nTwo security decisions are made on this untrusted value:\n\n1. Rate limiting (`rate_limit()`): the decorator keeps `request_history[client_ip]` and enforces\n   `count` requests per `period` per `client_ip`. Since `client_ip` is attacker-controlled, sending\n   a distinct value each request creates a distinct bucket, so the counter never accumulates and\n   the limit never triggers.\n2. Audit logging: login-failure and API-auth-failure log lines embed `[CLIENT: {client_ip}]` using\n   the same spoofable value, so the recorded source address is chosen by the attacker.\n\nNotably, the codebase is internally inconsistent: `is_loopback_request()` (helpers.py:288) treats\nthe *presence* of `X-Forwarded-For` / `X-Real-IP` / `Forwarded` as a reason to *distrust* an\napparent loopback source, while the rate-limit and logging paths naively trust the same header \u2014\nindicating the trust here is unintended.\n\n\n## Proof of Concept\n\nThe `rate_limit()` decorator\u0027s actual source (bytes read from\n`pyload-develop-2/src/pyload/webui/app/helpers.py`, lines 416\u2013514) was executed under a real Flask\ntest client. Rate limit set to 5/60s for brevity (identical logic to the production 100/min):\n\n```python\nimport ast, math, time\nfrom functools import wraps\nimport flask\n\nHELPERS = \".../pyload-develop-2/src/pyload/webui/app/helpers.py\"\nsrc = open(HELPERS).read()\nnode = next(n for n in ast.parse(src).body\n            if isinstance(n, ast.FunctionDef) and n.name == \"rate_limit\")\nns = {\"flask\": flask, \"time\": time, \"math\": math, \"wraps\": wraps}\nexec(compile(ast.get_source_segment(src, node), HELPERS, \"exec\"), ns)\nrate_limit = ns[\"rate_limit\"]\n\ndef build_app():\n    app = flask.Flask(__name__)\n    @app.route(\"/api/ping\")\n    @rate_limit(count=5, period=60)\n    def ping():\n        return flask.json.jsonify({\"ok\": True})\n    return app\n\ndef run(hdr):\n    app = build_app()\n    with app.test_client() as c:\n        return [c.get(\"/api/ping\", headers=hdr(i)).status_code for i in range(8)]\n\nprint(\"FIXED   XFF:\", run(lambda i: {\"X-Forwarded-For\": \"203.0.113.9\"}))\nprint(\"ROTATE  XFF:\", run(lambda i: {\"X-Forwarded-For\": f\"10.0.0.{i}\"}))\n```\n\nOutput:\n\n```\nFIXED   XFF: [200, 200, 200, 200, 200, 429, 429, 429]     # limit enforced\nROTATE  XFF: [200, 200, 200, 200, 200, 200, 200, 200]     # 0x 429 -\u003e limit bypassed\n# server log during FIXED run:\n#   WARNING in helpers: Rate limit exceeded for IP 203.0.113.9: 5 requests in 60 (limit: 5/60)\n```\n\nDerivation check (XFF present, real peer is loopback):\n\n```python\n# request with header X-Forwarded-For: 8.8.8.8 and REMOTE_ADDR 127.0.0.1\nclient_ip = request.headers.get(\"X-Forwarded-For\",\"\").split(\",\")[0].strip() or request.remote_addr\n# -\u003e client_ip == \"8.8.8.8\"   (the spoofed value wins over the real remote_addr)\n```\n\nEquivalent against a live instance:\n\n```bash\n# Rate limit never trips regardless of volume:\nfor i in $(seq 1 500); do\n  curl -s -o /dev/null -H \"X-API-Key: pl_1\u003cvalid-key\u003e\" \\\n       -H \"X-Forwarded-For: 10.0.0.$((RANDOM%255))\" \\\n       http://127.0.0.1:8000/api/get_server_version\ndone   # no HTTP 429 is ever returned\n\n# Forged source IP in the audit log:\ncurl -s -o /dev/null -H \"X-Forwarded-For: 8.8.8.8\" \\\n     --data \u0027username=admin\u0026password=wrong\u0027 http://127.0.0.1:8000/login\n# server log: Login failed for user \u0027admin\u0027 using Web Client [CLIENT: 8.8.8.8]\n```\n\n\n## Steps To Reproduce\n\n1. Start a pyLoad instance directly exposed (no reverse proxy), as in a default deployment.\n2. Obtain any valid API key (or use the login endpoint) so requests reach the rate-limited /\n   logged code paths.\n3. Send more than the configured limit of requests to a `@rate_limit`-protected endpoint (e.g.\n   `/api/get_server_version`) while setting a **different** `X-Forwarded-For` value on each request.\n   Observe that no `429 Too Many Requests` is ever returned.\n4. Control: repeat step 3 with a **fixed** `X-Forwarded-For` value; observe `429` after the limit,\n   proving the bucket is keyed on the header value.\n5. Send a failed login (or failed API-key request) with `X-Forwarded-For: 8.8.8.8` and inspect the\n   server log; the failure is attributed to `8.8.8.8` rather than the real client address.\n\n\n## Impact\n\n- Rate limiting on the authenticated API (`/api/\u003cfunc\u003e`, 100/min) and any other\n  `@rate_limit`-protected endpoint provides no protection against a single attacker, who can issue\n  unlimited requests \u2014 enabling resource abuse and unthrottled brute-forcing of anything reachable\n  through those endpoints.\n- Security/audit logs cannot be trusted for source attribution. An attacker can stamp every\n  malicious request with an arbitrary or innocent third-party IP, evading IP-based blocklists /\n  fail2ban and misdirecting incident response.\n- Amplifies other authentication weaknesses (e.g. the absence of throttling on `/login`), since\n  even the throttling that does exist elsewhere is defeated and the attacker\u0027s IP is unlogged.\n\n\n## Root Causes\n\n1. A client-controlled HTTP header (`X-Forwarded-For`) is used directly in security decisions\n   (rate-limit bucketing and audit attribution) without any trusted-proxy validation (CWE-807).\n2. The leftmost XFF token is selected, which is always the value supplied by the original client;\n   this is spoofable both in direct-exposure and behind-a-proxy deployments (CWE-348).\n3. No `ProxyFix` / trusted-proxy-hop configuration exists, and the server terminates client\n   connections directly, so there is no basis for trusting forwarded headers at all.\n4. Inconsistent handling across the codebase (loopback checks distrust these headers while\n   rate-limit/logging trust them) indicates the trust is accidental rather than designed.\n\n\n## Suggested Fix\n\n1. By default, use `request.remote_addr` (the real TCP peer) for rate limiting and logging; do not\n   trust `X-Forwarded-For` unless a proxy is explicitly configured.\n2. Add an explicit, operator-configured trusted-proxy count (default 0 = trust none). When set,\n   apply Werkzeug\u0027s `ProxyFix(app.wsgi_app, x_for=N)` and read the correct hop (the value inserted\n   by the trusted proxy \u2014 typically the Nth-from-right token \u2014 not the leftmost client-supplied\n   token).\n3. Derive the trusted client IP once in a single helper and use it consistently for rate limiting,\n   logging, and the loopback checks, removing the duplicated inline expressions.\n4. Consider defense-in-depth: cap the number of distinct rate-limit buckets and/or additionally\n   rate-limit on `remote_addr` so a spoofed header cannot create unbounded buckets.\n\nInvariant to restore: security decisions and audit attribution must be based on a connection-level\nor trusted-proxy-validated address, never on a raw client-supplied header.",
  "id": "GHSA-9q47-3cm2-2rp8",
  "modified": "2026-10-09T17:09:12Z",
  "published": "2026-10-09T17:09:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/security/advisories/GHSA-9q47-3cm2-2rp8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/commit/5dc6b628e2d8b9f42dde82f396e5b7a2b513f6d1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyload/pyload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pyLoad: Rate-Limit Bypass and Audit-Log Spoofing via Trusted Client-Controlled `X-Forwarded-For` Header"
}

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.