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.

1196 vulnerabilities reference this CWE, most recent first.

GHSA-QGMM-V3V3-WFF2

Vulnerability from github – Published: 2026-10-02 21:32 – Updated: 2026-10-02 21:32
VLAI
Details

A flaw was found in Dogtag PKI (pki-core). The CMCAuthForEST authentication plugin fails open when an EST fullcmc enrollment request is submitted via BasicAuth without an end-user TLS client certificate. The SSL_CLIENT_CERT session attribute retains the EST subsystem's agent certificate, which causes downstream authorization checks to treat the request as agent-privileged. An authenticated EST user can exploit this to obtain CA-signed certificates with arbitrary subject names.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-104988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-02T20:17:01Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in Dogtag PKI (pki-core). The CMCAuthForEST authentication plugin fails open when an EST fullcmc enrollment request is submitted via BasicAuth without an end-user TLS client certificate. The SSL_CLIENT_CERT session attribute retains the EST subsystem\u0027s agent certificate, which causes downstream authorization checks to treat the request as agent-privileged. An authenticated EST user can exploit this to obtain CA-signed certificates with arbitrary subject names.",
  "id": "GHSA-qgmm-v3v3-wff2",
  "modified": "2026-10-02T21:32:06Z",
  "published": "2026-10-02T21:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104988"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-104988"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2545316"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QGVM-CJ9X-53JJ

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-04-22 21:31
VLAI
Details

wpDiscuz before 7.6.47 contains a vote manipulation vulnerability that allows attackers to manipulate comment votes by obtaining fresh nonces and bypassing rate limiting through client-controlled headers. Attackers can vary User-Agent headers to reset rate limits, request nonces from the unauthenticated wpdGetNonce endpoint, and vote multiple times using IP rotation or reverse proxy header manipulation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-22199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:54:09Z",
    "severity": "MODERATE"
  },
  "details": "wpDiscuz before 7.6.47 contains a vote manipulation vulnerability that allows attackers to manipulate comment votes by obtaining fresh nonces and bypassing rate limiting through client-controlled headers. Attackers can vary User-Agent headers to reset rate limits, request nonces from the unauthenticated wpdGetNonce endpoint, and vote multiple times using IP rotation or reverse proxy header manipulation.",
  "id": "GHSA-qgvm-cj9x-53jj",
  "modified": "2026-04-22T21:31:32Z",
  "published": "2026-03-13T21:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kmkz/Exploits/blob/master/2026/CVE-2026-22192-22199_Voltronic-Power_Preauth_root_RCE.txt"
    },
    {
      "type": "WEB",
      "url": "https://voltronicpower.com"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wpdiscuz"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wpdiscuz/#developers"
    },
    {
      "type": "WEB",
      "url": "https://www.boffsec-services.com/posts/sicuroweb-cve-2026-22191"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/voltronic-power-snmp-web-pro-path-traversal-via-upload-cgi"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wpdiscuz-before-vote-manipulation-via-nonce-oracle-and-ip-rotation"
    }
  ],
  "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"
    },
    {
      "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/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-QGXV-HQXP-4RCX

Vulnerability from github – Published: 2026-08-14 12:31 – Updated: 2026-08-14 12:31
VLAI
Details

go-chi chi versions >= 5.2.1 and before 5.3.0 contain an IP spoofing vulnerability in the RealIP middleware, which blindly trusts the first (leftmost) value of the X-Forwarded-For HTTP header. A remote attacker can bypass IP-based access control lists and rate-limiting mechanisms, and forge log entries, by supplying a spoofed IP address in the X-Forwarded-For header. The issue is fixed in version 5.3.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-72815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-14T12:16:44Z",
    "severity": "MODERATE"
  },
  "details": "go-chi chi versions \u003e= 5.2.1 and before 5.3.0 contain an IP spoofing vulnerability in the RealIP middleware, which blindly trusts the first (leftmost) value of the X-Forwarded-For HTTP header. A remote attacker can bypass IP-based access control lists and rate-limiting mechanisms, and forge log entries, by supplying a spoofed IP address in the X-Forwarded-For header. The issue is fixed in version 5.3.0.",
  "id": "GHSA-qgxv-hqxp-4rcx",
  "modified": "2026-08-14T12:31:25Z",
  "published": "2026-08-14T12:31:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-chi/chi/security/advisories/GHSA-3fxj-6jh8-hvhx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72815"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/go-chi-chi-ip-spoofing-via-x-forwarded-for-header"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-QHVP-7MCR-9PJ9

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:37
VLAI
Details

The Wireless Emergency Alerts (WEA) protocol allows remote attackers to spoof a Presidential Alert because cryptographic authentication is not used, as demonstrated by MessageIdentifier 4370 in LTE System Information Block 12 (aka SIB12). NOTE: testing inside an RF-isolated shield box suggested that all LTE phones are affected by design (e.g., use of Android versus iOS does not matter); testing in an open RF environment is, of course, contraindicated.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-18659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-327"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-02T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Wireless Emergency Alerts (WEA) protocol allows remote attackers to spoof a Presidential Alert because cryptographic authentication is not used, as demonstrated by MessageIdentifier 4370 in LTE System Information Block 12 (aka SIB12). NOTE: testing inside an RF-isolated shield box suggested that all LTE phones are affected by design (e.g., use of Android versus iOS does not matter); testing in an open RF environment is, of course, contraindicated.",
  "id": "GHSA-qhvp-7mcr-9pj9",
  "modified": "2024-04-04T02:37:44Z",
  "published": "2022-05-24T17:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18659"
    },
    {
      "type": "WEB",
      "url": "https://dl.acm.org/citation.cfm?id=3326082"
    }
  ],
  "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-QJ7Q-8P84-WF4Q

Vulnerability from github – Published: 2025-05-15 06:31 – Updated: 2025-05-15 06:31
VLAI
Details

The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-48027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-15T06:15:37Z",
    "severity": "MODERATE"
  },
  "details": "The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver.",
  "id": "GHSA-qj7q-8p84-wf4q",
  "modified": "2025-05-15T06:31:13Z",
  "published": "2025-05-15T06:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48027"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MutonUfoAI/pgina/blob/1922de0fe27492c09d2f188c2c7e54a4b364bbad/Plugins/HttpAuth/HttpAuth/Settings.cs#L44"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kwburns/CVE/blob/main/pGina.Fork/3.9.9.12/README.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QJ9C-59P6-8CGX

Vulnerability from github – Published: 2026-10-07 14:06 – Updated: 2026-10-07 14:06
VLAI
Summary
PraisonAI: AgentMail webhook lacks signature verification, allowing unauthenticated message injection and sender spoofing
Details

Summary

PraisonAI's AgentMail bot, when run in webhook (or hybrid) mode, starts an aiohttp webhook server bound to 0.0.0.0 and processes inbound message.received events without verifying any signature/HMAC and without authentication. The sender address and message body are taken directly from the attacker-controlled request body, so any network peer can inject messages into the agent with a spoofed sender (bypassing sender allow/block lists) and have the agent process the content and reply to an attacker-chosen address. Sibling bots (linear.py, whatsapp.py) fail closed when no secret is configured; AgentMail omits the check entirely. Runtime-confirmed; severity Medium.

Details

Affected component

  • Package: praisonai 4.6.63. File: src/praisonai/praisonai/bots/agentmail.py (AgentMailBot, webhook/hybrid mode).

Vulnerable code / root cause

Path: src/praisonai/praisonai/bots/agentmail.py

Function: _start_webhook_mode / _handle_email_webhook / _handle_message

Snippet:

# _start_webhook_mode: binds all interfaces
self._webhook_site = web.TCPSite(self._webhook_runner, "0.0.0.0", self._webhook_port)

# _handle_email_webhook: no signature/HMAC check, no auth
body = await request.json()
if body.get("type") != "message.received":
    return web.Response(status=200, text="OK")
asyncio.create_task(self._process_webhook_payload(body))   # dispatch attacker body
return web.Response(status=200, text="OK")

# _handle_message: agent processes content, replies to attacker-controlled sender
response = await self._session.chat(self._agent, sender_id, body, ...)
await self.send_message(channel_id=sender_id, ...)

Issue: attacker-controlled input is the raw webhook JSON (from, extracted_text, subject). The guard that should exist is provider signature verification — there is none here (no svix/HMAC, no webhooks_require_verification() call). The sink is self._session.chat(self._agent, ...) (agent invocation) and send_message(channel_id=sender_id, ...) (reply to the spoofed sender). Sibling handlers src/praisonai/praisonai/bots/linear.py and bots/whatsapp.py call webhooks_require_verification() and reject when no secret is set — AgentMail does not, so it fails open.

Attack flow

  1. Operator runs the AgentMail bot in webhook/hybrid mode (documented; binds 0.0.0.0, default path /webhook, default port 8080).
  2. Attacker POSTs a crafted message.received event with a spoofed from and arbitrary extracted_text.
  3. The agent processes the content; any reply is sent to the attacker-chosen sender_id.

Why existing protection is bypassed

There is no protection on this handler: no signature verification, no webhooks_require_verification() gate, no auth. Sender allow/block lists are bypassed because from is attacker-controlled.

Security boundary

Unauthenticated network peer → agent message pipeline + reply destination. Crosses the bot's inbound trust boundary (provider webhooks are expected to be signed/authenticated).

Proof of Concept

Environment

Real AgentMailBot._handle_email_webhook mounted in a local runtime (127.0.0.1:18080); the agent layer is a canary recorder (/webhook-log). No real email is sent. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\.

Steps to reproduce

  1. PRAI-03-01-Webhook-Spoofed-Sender:
POST /webhook HTTP/1.1
Host: 127.0.0.1:18080
Content-Type: application/json

{"type":"message.received","data":{"from":"attacker@evil.example","extracted_text":"PRAISONAI_WEBHOOK_INJECT_CANARY_7f3a91 ...","subject":"hello","headers":{}}}
  1. PRAI-03-02-Agent-Reached-Response: GET /webhook-log.

Expected result

The webhook should reject unsigned/unauthenticated events; spoofed senders should not reach the agent.

Actual result

  • POST /webhook → 200 OK (no auth/signature).
  • GET /webhook-log → {"reached_agent":[{"sender":"attacker@evil.example","content":"...PRAISONAI_WEBHOOK_INJECT_CANARY_7f3a91...","source":"webhook"}],"count":1}.

Impact

Unauthenticated message injection into the agent; sender spoofing (access-control bypass); agent reply/exfiltration to an attacker-chosen address; prompt-injection surface; LLM cost abuse. If the agent has dangerous tools, escalation via prompt injection is possible.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.77"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T14:06:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI\u0027s AgentMail bot, when run in webhook (or hybrid) mode, starts an aiohttp webhook server bound to `0.0.0.0` and processes inbound `message.received` events **without verifying any signature/HMAC and without authentication**. The sender address and message body are taken directly from the attacker-controlled request body, so any network peer can inject messages into the agent with a spoofed sender (bypassing sender allow/block lists) and have the agent process the content and reply to an attacker-chosen address. Sibling bots (`linear.py`, `whatsapp.py`) fail closed when no secret is configured; AgentMail omits the check entirely. Runtime-confirmed; severity Medium.\n\n## Details\n\n### Affected component\n- Package: `praisonai` 4.6.63. File: `src/praisonai/praisonai/bots/agentmail.py` (`AgentMailBot`, webhook/hybrid mode).\n\n### Vulnerable code / root cause\n\nPath:\n`src/praisonai/praisonai/bots/agentmail.py`\n\nFunction:\n`_start_webhook_mode` / `_handle_email_webhook` / `_handle_message`\n\nSnippet:\n```python\n# _start_webhook_mode: binds all interfaces\nself._webhook_site = web.TCPSite(self._webhook_runner, \"0.0.0.0\", self._webhook_port)\n\n# _handle_email_webhook: no signature/HMAC check, no auth\nbody = await request.json()\nif body.get(\"type\") != \"message.received\":\n    return web.Response(status=200, text=\"OK\")\nasyncio.create_task(self._process_webhook_payload(body))   # dispatch attacker body\nreturn web.Response(status=200, text=\"OK\")\n\n# _handle_message: agent processes content, replies to attacker-controlled sender\nresponse = await self._session.chat(self._agent, sender_id, body, ...)\nawait self.send_message(channel_id=sender_id, ...)\n```\nIssue: attacker-controlled input is the raw webhook JSON (`from`, `extracted_text`, `subject`). The guard that *should* exist is provider signature verification \u2014 there is **none** here (no svix/HMAC, no `webhooks_require_verification()` call). The sink is `self._session.chat(self._agent, ...)` (agent invocation) and `send_message(channel_id=sender_id, ...)` (reply to the spoofed sender). Sibling handlers `src/praisonai/praisonai/bots/linear.py` and `bots/whatsapp.py` call `webhooks_require_verification()` and reject when no secret is set \u2014 AgentMail does not, so it fails open.\n\n### Attack flow\n1. Operator runs the AgentMail bot in webhook/hybrid mode (documented; binds `0.0.0.0`, default path `/webhook`, default port 8080).\n2. Attacker POSTs a crafted `message.received` event with a spoofed `from` and arbitrary `extracted_text`.\n3. The agent processes the content; any reply is sent to the attacker-chosen `sender_id`.\n\n### Why existing protection is bypassed\nThere is no protection on this handler: no signature verification, no `webhooks_require_verification()` gate, no auth. Sender allow/block lists are bypassed because `from` is attacker-controlled.\n\n### Security boundary\nUnauthenticated network peer \u2192 agent message pipeline + reply destination. Crosses the bot\u0027s inbound trust boundary (provider webhooks are expected to be signed/authenticated).\n\n## Proof of Concept\n\n### Environment\nReal `AgentMailBot._handle_email_webhook` mounted in a local runtime (`127.0.0.1:18080`); the agent layer is a canary recorder (`/webhook-log`). No real email is sent. Runnable assets: `PraisonAI-Runtime-Repro\\runtime-files\\`.\n\n### Steps to reproduce\n1. `PRAI-03-01-Webhook-Spoofed-Sender`:\n```http\nPOST /webhook HTTP/1.1\nHost: 127.0.0.1:18080\nContent-Type: application/json\n\n{\"type\":\"message.received\",\"data\":{\"from\":\"attacker@evil.example\",\"extracted_text\":\"PRAISONAI_WEBHOOK_INJECT_CANARY_7f3a91 ...\",\"subject\":\"hello\",\"headers\":{}}}\n```\n2. `PRAI-03-02-Agent-Reached-Response`: `GET /webhook-log`.\n\n### Expected result\nThe webhook should reject unsigned/unauthenticated events; spoofed senders should not reach the agent.\n\n### Actual result\n- `POST /webhook` \u2192 `200 OK` (no auth/signature).\n- `GET /webhook-log` \u2192 `{\"reached_agent\":[{\"sender\":\"attacker@evil.example\",\"content\":\"...PRAISONAI_WEBHOOK_INJECT_CANARY_7f3a91...\",\"source\":\"webhook\"}],\"count\":1}`.\n\n## Impact\nUnauthenticated message injection into the agent; sender spoofing (access-control bypass); agent reply/exfiltration to an attacker-chosen address; prompt-injection surface; LLM cost abuse. If the agent has dangerous tools, escalation via prompt injection is possible.",
  "id": "GHSA-qj9c-59p6-8cgx",
  "modified": "2026-10-07T14:06:56Z",
  "published": "2026-10-07T14:06:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qj9c-59p6-8cgx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61428"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-agentmail-before-message-injection-via-webhook"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: AgentMail webhook lacks signature verification, allowing unauthenticated message injection and sender spoofing"
}

GHSA-QMF3-4G6F-3FJV

Vulnerability from github – Published: 2025-04-30 18:31 – Updated: 2025-04-30 21:31
VLAI
Details

An app could impersonate system notifications. Sensitive notifications now require restricted entitlements. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.3. An app may be able to cause a denial-of-service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-24091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-30T18:15:39Z",
    "severity": "MODERATE"
  },
  "details": "An app could impersonate system notifications. Sensitive notifications now require restricted entitlements. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.3. An app may be able to cause a denial-of-service.",
  "id": "GHSA-qmf3-4g6f-3fjv",
  "modified": "2025-04-30T21:31:48Z",
  "published": "2025-04-30T18:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24091"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121838"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122066"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QMG5-V42X-QQHQ

Vulnerability from github – Published: 2025-12-08 17:56 – Updated: 2025-12-09 19:19
VLAI
Summary
1Panel – CAPTCHA Bypass via Client-Controlled Flag
Details

Summary

A CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO).

Details

The /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body:

"ignoreCaptcha": true

The backend implementation uses this value to determine whether CAPTCHA validation should be performed:

if !req.IgnoreCaptcha {
    if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != "" {
        helper.BadAuth(c, errMsg, nil)
        return
    }
}

Because req.IgnoreCaptcha is taken directly from user input—with no server-side validation, no session binding, and no privilege checks—any unauthenticated attacker can force CAPTCHA validation to be skipped.

There are no additional conditions, such as:

no requirement for MFA

no trusted device

no IP reputation checks

no prior valid session

no rate limiting

This results in CAPTCHA being entirely client-controlled, which violates fundamental authentication and anti-automation security assumptions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/1Panel-dev/1Panel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/1Panel-dev/1Panel/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20251128030527-ac43f00273be"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-602",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-08T17:56:27Z",
    "nvd_published_at": "2025-12-09T16:18:19Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO).\n\n### Details\n\nThe /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body:\n\n`\"ignoreCaptcha\": true`\n\n\nThe backend implementation uses this value to determine whether CAPTCHA validation should be performed:\n\n```\nif !req.IgnoreCaptcha {\n    if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != \"\" {\n        helper.BadAuth(c, errMsg, nil)\n        return\n    }\n}\n\n```\n\nBecause req.IgnoreCaptcha is taken directly from user input\u2014with no server-side validation, no session binding, and no privilege checks\u2014any unauthenticated attacker can force CAPTCHA validation to be skipped.\n\nThere are no additional conditions, such as:\n\nno requirement for MFA\n\nno trusted device\n\nno IP reputation checks\n\nno prior valid session\n\nno rate limiting\n\nThis results in CAPTCHA being entirely client-controlled, which violates fundamental authentication and anti-automation security assumptions.",
  "id": "GHSA-qmg5-v42x-qqhq",
  "modified": "2025-12-09T19:19:10Z",
  "published": "2025-12-08T17:56:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/1Panel/security/advisories/GHSA-qmg5-v42x-qqhq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66507"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/1Panel/commit/ac43f00273be745f8d04b90b6e2b9c1a40ef7bca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/1Panel-dev/1Panel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/1Panel/releases/tag/v2.0.14"
    }
  ],
  "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"
    }
  ],
  "summary": "1Panel \u2013 CAPTCHA Bypass via Client-Controlled Flag "
}

GHSA-QP7J-X725-G67F

Vulnerability from github – Published: 2025-08-19 15:34 – Updated: 2025-08-29 20:37
VLAI
Summary
HydrAIDE Authentication Bypass Vulnerability
Details

Summary

There is no authentication of any kind.

Details

TLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it's free to be read by any adversaries.

On the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221 It should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)

And on the server side, there should be ClientCAs and ClientAuth filled.

PoC

To bypass as is, the simplest way is to take the client and modify the code as such :

Modified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209

            // hostOnly := strings.Split(server.Host, ":")[0]
            // creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)
            // if certErr != nil {
            //  slog.Error("error while loading TLS credentials: ", "error", certErr, "server", server.Host, "fromIsland", server.FromIsland, "toIsland", server.ToIsland)
            //  errorMessages = append(errorMessages, certErr)
            // }
            var opts []grpc.DialOption
            tlsConfig := &tls.Config{
                InsecureSkipVerify: true,
            }
            creds := credentials.NewTLS(tlsConfig)
            opts = append(opts, grpc.WithTransportCredentials(creds))

Impact

It impacts everyone who think there is any kind of authentication.


Resolution

This vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.

All users are strongly advised to upgrade:

  1. Update to hydraidectl v0.2.1
  2. Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.

For migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion. If anything does not work, please report it.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hydraide/hydraide"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.1"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hydraide/hydraide"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20250816184905-1256db38c33c"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-19T15:34:48Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nThere is no authentication of any kind.\n\n\n### Details\nTLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it\u0027s free to be read by any adversaries.\n\nOn the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221\nIt should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)\n\nAnd on the server side, there should be ClientCAs and ClientAuth filled.\n\n### PoC\nTo bypass as is, the simplest way is to take the client and modify the code as such : \n\nModified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209\n```go\n\t\t\t// hostOnly := strings.Split(server.Host, \":\")[0]\n\t\t\t// creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)\n\t\t\t// if certErr != nil {\n\t\t\t// \tslog.Error(\"error while loading TLS credentials: \", \"error\", certErr, \"server\", server.Host, \"fromIsland\", server.FromIsland, \"toIsland\", server.ToIsland)\n\t\t\t// \terrorMessages = append(errorMessages, certErr)\n\t\t\t// }\n\t\t\tvar opts []grpc.DialOption\n\t\t\ttlsConfig := \u0026tls.Config{\n\t\t\t\tInsecureSkipVerify: true,\n\t\t\t}\n\t\t\tcreds := credentials.NewTLS(tlsConfig)\n\t\t\topts = append(opts, grpc.WithTransportCredentials(creds))\n```\n\n### Impact\nIt impacts everyone who think there is any kind of authentication.\n\n---\n\n## Resolution\n\nThis vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.\n\nAll users are strongly advised to upgrade:\n\n1. Update to hydraidectl v0.2.1\n2. Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.\n\nFor migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion.\nIf anything does not work, please report it.",
  "id": "GHSA-qp7j-x725-g67f",
  "modified": "2025-08-29T20:37:10Z",
  "published": "2025-08-19T15:34:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hydraide/hydraide/security/advisories/GHSA-qp7j-x725-g67f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hydraide/hydraide/commit/b252554a811400a81951dc9f959b99077f187975#diff-63efbc8179fff403eb5cc642407b33c0fb21aea2c84baaf5e5223f76f5d75f55"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hydraide/hydraide"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3895"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HydrAIDE Authentication Bypass Vulnerability"
}

GHSA-QP7W-47RC-M64M

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

Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-25055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-18T00:15:21Z",
    "severity": "MODERATE"
  },
  "details": "Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.",
  "id": "GHSA-qp7w-47rc-m64m",
  "modified": "2025-02-18T00:31:42Z",
  "published": "2025-02-18T00:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25055"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN80527854"
    },
    {
      "type": "WEB",
      "url": "https://www.info-brdg.co.jp/support/report/megane/sec20250201.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

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

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

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

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

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

CAPEC-473: Signature Spoof

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

CAPEC-476: Signature Spoofing by Misrepresentation

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

CAPEC-59: Session Credential Falsification through Prediction

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

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

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

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

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

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.