CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
4625 vulnerabilities reference this CWE, most recent first.
GHSA-R7V3-X45F-G7HP
Vulnerability from github – Published: 2026-08-25 14:56 – Updated: 2026-08-25 14:56Summary
praisonai serve agents exposes HTTP routes that invoke registered agents. The CLI advertises --api-key with help text "API key for authentication", parses it, and forwards it into ServeHandler. But _create_agents_app() never reads config["api_key"] again and installs no auth dependency or middleware on its direct routes. The configured key is a no-op flag.
As a result, an unauthenticated network caller can invoke exposed agents (POST /agents and POST /agents/{agent_name}) even when the operator passed --api-key. Requests with no credentials, a wrong Authorization: Bearer, a wrong X-API-Key, or an empty bearer all reach agent.start().
The failure is made sharper by the fact that a working auth dependency already exists in the same module — praisonai.api.agent_invoke.verify_token guards every /api/v1/... route with Depends(verify_token) and is mounted into the very same app. The direct n8n-compat routes simply do not use it.
Technical Detail
Source-to-sink trace
1. CLI advertises and forwards --api-key:
# cli/commands/serve.py
@app.command("agents")
def serve_agents(..., api_key: Optional[str] = typer.Option(None, "--api-key", help="API key for authentication")):
...
if api_key:
args.extend(["--api-key", api_key])
exit_code = handle_serve_command(args)
2. cmd_agents() parses api_key into the spec — and that is the last time it is touched:
# cli/features/serve.py — cmd_agents()
spec = { ..., "api_key": {"default": None} }
parsed = self._parse_args(args, spec)
app = self._create_agents_app(parsed)
A grep of the entire cli/features/serve.py for api_key returns only the two spec entries (cmd_agents line ~199 and cmd_unified line ~847). config["api_key"] is never read inside _create_agents_app() / _create_unified_app(); it is never compared, and no dependency is attached.
3. _create_agents_app() imports FastAPI, HTTPException, Request — no Depends, no Header, no auth middleware. Every HTTPException raised in the agents routes is 400/404/500 (validation / not-found / execution error); none is 401.
4. Sink — unauthenticated request reaches agent.start():
# cli/features/serve.py
@app.post("/agents/{agent_name}") # n8n compatibility route
async def invoke_single_agent(agent_name: str, request: Request):
body = await request.json()
query = body.get("query", "") or body.get("message", "")
...
agent = agent_invoke.get_agent(agent_name)
result = await loop.run_in_executor(None, agent.start, query) # no auth anywhere above
return {"response": str(result)}
@app.post(path) # default path "/agents"
async def invoke_agents(request: Request, query_data: AgentQuery = None):
... agent.start(query) ...
The auth dependency exists — it just isn't applied here
_create_agents_app() mounts the agent_invoke router into the same app:
# cli/features/serve.py
if getattr(agent_invoke, 'FASTAPI_AVAILABLE', False) and hasattr(agent_invoke, 'router'):
app.include_router(agent_invoke.router)
That router properly authenticates every sensitive route:
# api/agent_invoke.py
CALL_SERVER_TOKEN = os.getenv('CALL_SERVER_TOKEN')
async def verify_token(request, authorization=Header(None)) -> None:
...
if token != CALL_SERVER_TOKEN:
raise HTTPException(status_code=401, detail="Unauthorized")
@router.get("/api/v1/agents")
async def list_agents(_: None = Depends(verify_token)): ... # and register/unregister/info all use it
So in the same process GET /api/v1/agents returns 401 without a token, while POST /agents/{agent_name} returns 200. Note also that verify_token reads the CALL_SERVER_TOKEN env var — not the CLI --api-key — so the CLI option feeds no auth path at all.
Trigger conditions
praisonai serve agents --file agents.yaml --host 0.0.0.0 --port 8765 --api-key expected-secret
POST /agents/{agent_name} body {"query":"..."} with no / wrong / empty credentials
Proof of Concept
Built the real _create_agents_app() and exercised it over HTTP via FastAPI TestClient. Only praisonaiagents.Agent is stubbed (.start() returns EXEC:<query>), so no real LLM/credentials. CALL_SERVER_TOKEN=expected-secret was set so the sibling /api/v1 router is genuinely armed — making the contrast explicit.
Operator started with: --api-key expected-secret (CALL_SERVER_TOKEN also set)
== Sibling /api/v1 route WITH Depends(verify_token) ==
GET /api/v1/agents [no creds ] -> HTTP 401
GET /api/v1/agents [wrong bearer] -> HTTP 401
== Direct agent-invocation route (the bug) ==
POST /agents/owned [no creds ] -> HTTP 200 {'response': 'EXEC:hello'}
POST /agents/owned [wrong bearer ] -> HTTP 200 {'response': 'EXEC:hello'}
POST /agents/owned [wrong x-api-key] -> HTTP 200 {'response': 'EXEC:hello'}
POST /agents/owned [empty bearer ] -> HTTP 200 {'response': 'EXEC:hello'}
POST /agents [no creds ] -> HTTP 200 {'response': 'EXEC:hi'}
The auth mechanism works for /api/v1 (401) and is entirely absent on the direct /agents routes (200), despite --api-key being configured.
Equivalent HTTP trigger in a fully installed environment
praisonai serve agents --file agents.yaml --host 0.0.0.0 --port 8765 --api-key expected-secret
curl -sS -X POST http://TARGET:8765/agents/owned \
-H 'Content-Type: application/json' --data-binary '{"query":"hello"}'
# -> 200 {"response":"..."} (expected: 401 Unauthorized)
Impact
- Direct primitive: unauthenticated agent invocation despite a configured API key.
- Misleading control (aggravating): because the CLI advertises
--api-keyas authentication, operators may deliberately expose the service (e.g.--host 0.0.0.0, reverse proxy, n8n integration) believing it is protected, increasing the real-world likelihood of exposure. - Downstream: exposed agents commonly hold LLM provider credentials, RAG/memory, browser/search, MCP, or shell/file tools; the bypass lets an attacker drive those capabilities. Baseline impact is unauthorized LLM cost + access to agent responses.
Suggested Mitigation
- When
config["api_key"]is set, build a shared auth dependency and attach it to every agent-invocation / state-changing route in_create_agents_app()and_create_unified_app()(dependencies=[Depends(verify)]). - Reuse / unify with the existing
verify_tokenso the direct/agentsroutes and the/api/v1routes share one mechanism, and wire the CLI--api-keyinto that mechanism (today it feeds nothing;verify_tokenreadsCALL_SERVER_TOKEN). - Use constant-time comparison (
hmac.compare_digest);verify_tokencurrently uses!=. - Update discovery metadata from
auth_modes=["none"]to["api-key","bearer"]for protected endpoints. - Regression tests next to
tests/unit/test_serve_unified.py:_create_agents_app({"api_key":"secret",...})→POST /agents/{name}with no creds / wrongAuthorization/ wrongX-API-Keyreturns401; correct key succeeds.
import hmac
from fastapi import Header, HTTPException, Depends
def _auth_dependency(expected_key: str):
async def verify(authorization: str | None = Header(None),
x_api_key: str | None = Header(None, alias="X-API-Key")):
token = x_api_key
if authorization and authorization.startswith("Bearer "):
token = authorization[7:]
if not token or not hmac.compare_digest(token, expected_key):
raise HTTPException(status_code=401, detail="Unauthorized")
return Depends(verify)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "PraisonAI"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.58"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55538"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T14:56:59Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`praisonai serve agents` exposes HTTP routes that invoke registered agents. The CLI advertises `--api-key` with help text \"API key for authentication\", parses it, and forwards it into `ServeHandler`. But `_create_agents_app()` **never reads `config[\"api_key\"]` again** and installs no auth dependency or middleware on its direct routes. The configured key is a no-op flag.\n \nAs a result, an unauthenticated network caller can invoke exposed agents (`POST /agents` and `POST /agents/{agent_name}`) even when the operator passed `--api-key`. Requests with no credentials, a wrong `Authorization: Bearer`, a wrong `X-API-Key`, or an empty bearer all reach `agent.start()`.\n \nThe failure is made sharper by the fact that a **working auth dependency already exists in the same module** \u2014 `praisonai.api.agent_invoke.verify_token` guards every `/api/v1/...` route with `Depends(verify_token)` and is mounted into the very same app. The direct n8n-compat routes simply do not use it.\n\n## Technical Detail\n \n### Source-to-sink trace\n \n**1. CLI advertises and forwards `--api-key`:**\n \n```python\n# cli/commands/serve.py\n@app.command(\"agents\")\ndef serve_agents(..., api_key: Optional[str] = typer.Option(None, \"--api-key\", help=\"API key for authentication\")):\n ...\n if api_key:\n args.extend([\"--api-key\", api_key])\n exit_code = handle_serve_command(args)\n```\n \n**2. `cmd_agents()` parses `api_key` into the spec \u2014 and that is the last time it is touched:**\n \n```python\n# cli/features/serve.py \u2014 cmd_agents()\nspec = { ..., \"api_key\": {\"default\": None} }\nparsed = self._parse_args(args, spec)\napp = self._create_agents_app(parsed)\n```\n \nA grep of the entire `cli/features/serve.py` for `api_key` returns **only** the two `spec` entries (`cmd_agents` line ~199 and `cmd_unified` line ~847). `config[\"api_key\"]` is never read inside `_create_agents_app()` / `_create_unified_app()`; it is never compared, and no dependency is attached.\n \n**3. `_create_agents_app()` imports `FastAPI, HTTPException, Request` \u2014 no `Depends`, no `Header`, no auth middleware.** Every `HTTPException` raised in the agents routes is `400`/`404`/`500` (validation / not-found / execution error); none is `401`.\n \n**4. Sink \u2014 unauthenticated request reaches `agent.start()`:**\n \n```python\n# cli/features/serve.py\n@app.post(\"/agents/{agent_name}\") # n8n compatibility route\nasync def invoke_single_agent(agent_name: str, request: Request):\n body = await request.json()\n query = body.get(\"query\", \"\") or body.get(\"message\", \"\")\n ...\n agent = agent_invoke.get_agent(agent_name)\n result = await loop.run_in_executor(None, agent.start, query) # no auth anywhere above\n return {\"response\": str(result)}\n \n@app.post(path) # default path \"/agents\"\nasync def invoke_agents(request: Request, query_data: AgentQuery = None):\n ... agent.start(query) ...\n```\n\n### The auth dependency exists \u2014 it just isn\u0027t applied here\n \n`_create_agents_app()` mounts the `agent_invoke` router into the same app:\n \n```python\n# cli/features/serve.py\nif getattr(agent_invoke, \u0027FASTAPI_AVAILABLE\u0027, False) and hasattr(agent_invoke, \u0027router\u0027):\n app.include_router(agent_invoke.router)\n```\n \nThat router properly authenticates every sensitive route:\n \n```python\n# api/agent_invoke.py\nCALL_SERVER_TOKEN = os.getenv(\u0027CALL_SERVER_TOKEN\u0027)\nasync def verify_token(request, authorization=Header(None)) -\u003e None:\n ...\n if token != CALL_SERVER_TOKEN:\n raise HTTPException(status_code=401, detail=\"Unauthorized\")\n \n@router.get(\"/api/v1/agents\")\nasync def list_agents(_: None = Depends(verify_token)): ... # and register/unregister/info all use it\n```\n \nSo in the same process `GET /api/v1/agents` returns `401` without a token, while `POST /agents/{agent_name}` returns `200`. Note also that `verify_token` reads the `CALL_SERVER_TOKEN` env var \u2014 **not** the CLI `--api-key` \u2014 so the CLI option feeds no auth path at all.\n \n### Trigger conditions\n \n```\npraisonai serve agents --file agents.yaml --host 0.0.0.0 --port 8765 --api-key expected-secret\nPOST /agents/{agent_name} body {\"query\":\"...\"} with no / wrong / empty credentials\n```\n \n## Proof of Concept\n \nBuilt the **real** `_create_agents_app()` and exercised it over HTTP via FastAPI `TestClient`. Only `praisonaiagents.Agent` is stubbed (`.start()` returns `EXEC:\u003cquery\u003e`), so no real LLM/credentials. `CALL_SERVER_TOKEN=expected-secret` was set so the sibling `/api/v1` router is genuinely armed \u2014 making the contrast explicit.\n \n```\nOperator started with: --api-key expected-secret (CALL_SERVER_TOKEN also set)\n \n== Sibling /api/v1 route WITH Depends(verify_token) ==\n GET /api/v1/agents [no creds ] -\u003e HTTP 401\n GET /api/v1/agents [wrong bearer] -\u003e HTTP 401\n \n== Direct agent-invocation route (the bug) ==\n POST /agents/owned [no creds ] -\u003e HTTP 200 {\u0027response\u0027: \u0027EXEC:hello\u0027}\n POST /agents/owned [wrong bearer ] -\u003e HTTP 200 {\u0027response\u0027: \u0027EXEC:hello\u0027}\n POST /agents/owned [wrong x-api-key] -\u003e HTTP 200 {\u0027response\u0027: \u0027EXEC:hello\u0027}\n POST /agents/owned [empty bearer ] -\u003e HTTP 200 {\u0027response\u0027: \u0027EXEC:hello\u0027}\n POST /agents [no creds ] -\u003e HTTP 200 {\u0027response\u0027: \u0027EXEC:hi\u0027}\n```\n \nThe auth mechanism works for `/api/v1` (401) and is entirely absent on the direct `/agents` routes (200), despite `--api-key` being configured.\n \n### Equivalent HTTP trigger in a fully installed environment\n \n```bash\npraisonai serve agents --file agents.yaml --host 0.0.0.0 --port 8765 --api-key expected-secret\ncurl -sS -X POST http://TARGET:8765/agents/owned \\\n -H \u0027Content-Type: application/json\u0027 --data-binary \u0027{\"query\":\"hello\"}\u0027\n# -\u003e 200 {\"response\":\"...\"} (expected: 401 Unauthorized)\n```\n\n## Impact\n \n- **Direct primitive**: unauthenticated agent invocation despite a configured API key.\n- **Misleading control (aggravating)**: because the CLI advertises `--api-key` as authentication, operators may deliberately expose the service (e.g. `--host 0.0.0.0`, reverse proxy, n8n integration) believing it is protected, increasing the real-world likelihood of exposure.\n- **Downstream**: exposed agents commonly hold LLM provider credentials, RAG/memory, browser/search, MCP, or shell/file tools; the bypass lets an attacker drive those capabilities. Baseline impact is unauthorized LLM cost + access to agent responses.\n\n## Suggested Mitigation\n \n- When `config[\"api_key\"]` is set, build a shared auth dependency and attach it to every agent-invocation / state-changing route in `_create_agents_app()` and `_create_unified_app()` (`dependencies=[Depends(verify)]`).\n- Reuse / unify with the existing `verify_token` so the direct `/agents` routes and the `/api/v1` routes share one mechanism, and wire the CLI `--api-key` into that mechanism (today it feeds nothing; `verify_token` reads `CALL_SERVER_TOKEN`).\n- Use constant-time comparison (`hmac.compare_digest`); `verify_token` currently uses `!=`.\n- Update discovery metadata from `auth_modes=[\"none\"]` to `[\"api-key\",\"bearer\"]` for protected endpoints.\n- Regression tests next to `tests/unit/test_serve_unified.py`: `_create_agents_app({\"api_key\":\"secret\",...})` \u2192 `POST /agents/{name}` with no creds / wrong `Authorization` / wrong `X-API-Key` returns `401`; correct key succeeds.\n```python\nimport hmac\nfrom fastapi import Header, HTTPException, Depends\n \ndef _auth_dependency(expected_key: str):\n async def verify(authorization: str | None = Header(None),\n x_api_key: str | None = Header(None, alias=\"X-API-Key\")):\n token = x_api_key\n if authorization and authorization.startswith(\"Bearer \"):\n token = authorization[7:]\n if not token or not hmac.compare_digest(token, expected_key):\n raise HTTPException(status_code=401, detail=\"Unauthorized\")\n return Depends(verify)\n```",
"id": "GHSA-r7v3-x45f-g7hp",
"modified": "2026-08-25T14:56:59Z",
"published": "2026-08-25T14:56:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-r7v3-x45f-g7hp"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/commit/2f9677abb2ea68eab864ee8b6a828fd0141612e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.6.58"
}
],
"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: [Auth Bypass] `praisonai serve agents --api-key` is silently ignored \u2014 agent-invocation routes (`POST /agents`, `POST /agents/{agent_name}`) run unauthenticated"
}
GHSA-R838-P3XG-9MFP
Vulnerability from github – Published: 2026-09-16 15:31 – Updated: 2026-09-16 15:31Nozomi Networks Labs identified a CWE-306: Missing Authentication for Critical Function vulnerability in the edgserver management protocol of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote unauthenticated attacker to invoke critical device-management functions, including network reconfiguration, reboot, reset, and firmware upgrade, by sending crafted requests to TCP port 5058.
{
"affected": [],
"aliases": [
"CVE-2026-73173"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T13:18:05Z",
"severity": "HIGH"
},
"details": "Nozomi Networks Labs identified a CWE-306: Missing Authentication for Critical Function vulnerability in the edgserver management protocol of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote unauthenticated attacker to invoke critical device-management functions, including network reconfiguration, reboot, reset, and firmware upgrade, by sending crafted requests to TCP port 5058.",
"id": "GHSA-r838-p3xg-9mfp",
"modified": "2026-09-16T15:31:09Z",
"published": "2026-09-16T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73173"
},
{
"type": "WEB",
"url": "https://advcloudfiles.advantech.com/cms/5dafee28-ad53-4d07-a328-7896fcc24b6e/Security%20Advisory%20PDF%20File/SECURITY-ADVISORY----EKI-1242IEIMS-updated-20260904.pdf"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2026-73173"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/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-R849-HJQV-324F
Vulnerability from github – Published: 2022-05-13 01:52 – Updated: 2022-05-13 01:52A vulnerability has been identified in EN100 Ethernet module IEC 61850 variant (All versions < V4.30), EN100 Ethernet module DNP3 variant (All versions < V1.04), EN100 Ethernet module PROFINET IO variant (All versions), EN100 Ethernet module Modbus TCP variant (All versions), EN100 Ethernet module IEC 104 variant (All versions < V1.22). The web interface (TCP/80) of affected devices allows an unauthenticated user to upgrade or downgrade the firmware of the device, including to older versions with known vulnerabilities.
{
"affected": [],
"aliases": [
"CVE-2018-4838"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-08T17:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in EN100 Ethernet module IEC 61850 variant (All versions \u003c V4.30), EN100 Ethernet module DNP3 variant (All versions \u003c V1.04), EN100 Ethernet module PROFINET IO variant (All versions), EN100 Ethernet module Modbus TCP variant (All versions), EN100 Ethernet module IEC 104 variant (All versions \u003c V1.22). The web interface (TCP/80) of affected devices allows an unauthenticated user to upgrade or downgrade the firmware of the device, including to older versions with known vulnerabilities.",
"id": "GHSA-r849-hjqv-324f",
"modified": "2022-05-13T01:52:41Z",
"published": "2022-05-13T01:52:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4838"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-845879.pdf"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-067-01"
},
{
"type": "WEB",
"url": "https://www.securityfocus.com/bid/103379"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R872-92CG-5V5H
Vulnerability from github – Published: 2025-03-24 18:31 – Updated: 2025-03-24 18:31HCL DevOps Deploy / HCL Launch could allow an authenticated user to obtain sensitive information about other users on the system due to missing authorization for a function.
{
"affected": [],
"aliases": [
"CVE-2025-0256"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-24T16:15:33Z",
"severity": "MODERATE"
},
"details": "HCL DevOps Deploy / HCL Launch could allow an authenticated user to obtain sensitive information about other users on the system due to missing authorization for a function.",
"id": "GHSA-r872-92cg-5v5h",
"modified": "2025-03-24T18:31:02Z",
"published": "2025-03-24T18:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0256"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0119059"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R88H-WHF8-G952
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-05-24 17:28It is possible to enumerate access card credentials via an unauthenticated network connection to the server in versions of Command Centre v8.20 prior to v8.20.1166(MR3), versions of 8.10 prior to v8.10.1211(MR5), versions of 8.00 prior to v8.00.1228(MR6), all versions of 7.90 and earlier. These credentials can then be used to encode low security cards to be used by the system where insecure card technologies are supported.
{
"affected": [],
"aliases": [
"CVE-2020-16098"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-15T14:15:00Z",
"severity": "CRITICAL"
},
"details": "It is possible to enumerate access card credentials via an unauthenticated network connection to the server in versions of Command Centre v8.20 prior to v8.20.1166(MR3), versions of 8.10 prior to v8.10.1211(MR5), versions of 8.00 prior to v8.00.1228(MR6), all versions of 7.90 and earlier. These credentials can then be used to encode low security cards to be used by the system where insecure card technologies are supported.",
"id": "GHSA-r88h-whf8-g952",
"modified": "2022-05-24T17:28:20Z",
"published": "2022-05-24T17:28:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16098"
},
{
"type": "WEB",
"url": "https://security.gallagher.com/Security-Advisories/CVE-2020-16098"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R8H6-CWXJ-RV5J
Vulnerability from github – Published: 2024-07-30 00:34 – Updated: 2025-05-03 00:30There is a MEDIUM severity vulnerability affecting CPython.
The “socket” module provides a pure-Python fallback to the socket.socketpair() function for platforms that don’t support AF_UNIX, such as Windows. This pure-Python implementation uses AF_INET or AF_INET6 to create a local connected pair of sockets. The connection between the two sockets was not verified before passing the two sockets back to the user, which leaves the server socket vulnerable to a connection race from a malicious local peer.
Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included.
{
"affected": [],
"aliases": [
"CVE-2024-3219"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T22:15:04Z",
"severity": "LOW"
},
"details": "There is a MEDIUM severity vulnerability affecting CPython.\n\nThe\n \u201csocket\u201d module provides a pure-Python fallback to the \nsocket.socketpair() function for platforms that don\u2019t support AF_UNIX, \nsuch as Windows. This pure-Python implementation uses AF_INET or \nAF_INET6 to create a local connected pair of sockets. The connection \nbetween the two sockets was not verified before passing the two sockets \nback to the user, which leaves the server socket vulnerable to a \nconnection race from a malicious local peer.\n\nPlatforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included.",
"id": "GHSA-r8h6-cwxj-rv5j",
"modified": "2025-05-03T00:30:32Z",
"published": "2024-07-30T00:34:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3219"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/122133"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/122134"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/f071f01b7b7e19d7d6b3a4b0ec62f820ecb14660"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/e319f774f9e766a2b92949444a2d46081df3363a"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/c5655aa6ad120d2ed7f255bebd6e8b71a9c07dde"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/c21a36112a0028d7ac3cf8f480e0dc88dba5922c"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/b252317956b7fc035bb3774ef6a177e227f9fc54"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/78df1043dbdce5c989600616f9f87b4ee72944e5"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/5f90abaa786f994db3907fc31e2ee00ea2cf0929"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/5df322e91a40909e6904bbdbc0c3a6b6a9eead39"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/3f5d9d12c74787fbf3f5891835c85cc15526c86d"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/31302f5fc24eecd693f0c8aaba7c2840b09b594d"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/2621a8a40ba4b2c68ca564671b7daa5da80a4508"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/220e31adeaaa8436c9ff234cba1398bc49e2bb6c"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/0b65c8bf5367625673eafb92f85046a1b31259f2"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/06fa244666ec6335a3b9bf2367e31b42b9a89b20"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/WYKDQWIERRE2ICIYMSVRZJO33GSCWU2B"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250502-0004"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/07/29/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/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-R8J6-4HRP-V4W7
Vulnerability from github – Published: 2024-11-20 12:30 – Updated: 2026-04-01 18:32Missing Authentication for Critical Function vulnerability in deco.Agency de:branding allows Privilege Escalation.This issue affects de:branding: from n/a through 1.0.2.
{
"affected": [],
"aliases": [
"CVE-2024-52438"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-20T12:15:19Z",
"severity": "HIGH"
},
"details": "Missing Authentication for Critical Function vulnerability in deco.Agency de:branding allows Privilege Escalation.This issue affects de:branding: from n/a through 1.0.2.",
"id": "GHSA-r8j6-4hrp-v4w7",
"modified": "2026-04-01T18:32:34Z",
"published": "2024-11-20T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52438"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/debranding/vulnerability/wordpress-de-branding-plugin-1-0-2-privilege-escalation-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/debranding/wordpress-de-branding-plugin-1-0-2-privilege-escalation-vulnerability?_s_id=cve"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-R8VP-XWH5-G2HF
Vulnerability from github – Published: 2023-10-11 15:30 – Updated: 2024-04-04 08:33Vulnerability of access permissions not being strictly verified in the APPWidget module.Successful exploitation of this vulnerability may cause some apps to run without being authorized.
{
"affected": [],
"aliases": [
"CVE-2023-44116"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-11T13:15:10Z",
"severity": "CRITICAL"
},
"details": "Vulnerability of access permissions not being strictly verified in the APPWidget module.Successful exploitation of this vulnerability may cause some apps to run without being authorized.",
"id": "GHSA-r8vp-xwh5-g2hf",
"modified": "2024-04-04T08:33:58Z",
"published": "2023-10-11T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44116"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/10"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202310-0000001663676540"
}
],
"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-R8XP-M5J7-VP76
Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31Vulnerability in the PeopleSoft Enterprise HCM Human Resources product of Oracle PeopleSoft (component: Job Profile Manager). The supported version that is affected is 9.2. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Human Resources. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Human Resources accessible data as well as unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Human Resources accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N).
{
"affected": [],
"aliases": [
"CVE-2026-34280"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T21:16:32Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the PeopleSoft Enterprise HCM Human Resources product of Oracle PeopleSoft (component: Job Profile Manager). The supported version that is affected is 9.2. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Human Resources. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Human Resources accessible data as well as unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Human Resources accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N).",
"id": "GHSA-r8xp-m5j7-vp76",
"modified": "2026-04-21T21:31:25Z",
"published": "2026-04-21T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34280"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R944-M35H-4Q37
Vulnerability from github – Published: 2025-08-20 18:30 – Updated: 2025-08-20 18:30AOMEI Cyber Backup Missing Authentication for Critical Function Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of AOMEI Cyber Backup. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the DaoService service, which listens on TCP port 9074 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-26158.
{
"affected": [],
"aliases": [
"CVE-2025-8611"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-20T17:15:38Z",
"severity": "CRITICAL"
},
"details": "AOMEI Cyber Backup Missing Authentication for Critical Function Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of AOMEI Cyber Backup. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the DaoService service, which listens on TCP port 9074 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-26158.",
"id": "GHSA-r944-m35h-4q37",
"modified": "2025-08-20T18:30:22Z",
"published": "2025-08-20T18:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8611"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-807"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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
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
- 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
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
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.