Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5841 vulnerabilities reference this CWE, most recent first.

GHSA-6HX5-97H6-52X3

Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31
VLAI
Details

Incorrect Authorization vulnerability in realmag777 WordPress Meta Data and Taxonomies Filter (MDTF) allows Code Inclusion, Functionality Misuse.This issue affects WordPress Meta Data and Taxonomies Filter (MDTF): from n/a through 1.3.3.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-34434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T09:15:44Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in realmag777 WordPress Meta Data and Taxonomies Filter (MDTF) allows Code Inclusion, Functionality Misuse.This issue affects WordPress Meta Data and Taxonomies Filter (MDTF): from n/a through 1.3.3.2.",
  "id": "GHSA-6hx5-97h6-52x3",
  "modified": "2024-05-17T09:31:03Z",
  "published": "2024-05-17T09:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34434"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wp-meta-data-filter-and-taxonomy-filter/wordpress-mdtf-meta-data-and-taxonomies-filter-plugin-1-3-3-2-arbitrary-shortcode-execution-vulnerability?_s_id=cve"
    }
  ],
  "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-6HXG-X8PV-MVGV

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

CrowdStrike Falcon 6.44.15806 allows an administrative attacker to uninstall Falcon Sensor, bypassing the intended protection mechanism in which uninstallation requires possessing a one-time token. (The sensor is managed at the kernel level.)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-44721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-04T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "CrowdStrike Falcon 6.44.15806 allows an administrative attacker to uninstall Falcon Sensor, bypassing the intended protection mechanism in which uninstallation requires possessing a one-time token. (The sensor is managed at the kernel level.)",
  "id": "GHSA-6hxg-x8pv-mvgv",
  "modified": "2022-12-06T15:30:30Z",
  "published": "2022-12-04T06:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44721"
    },
    {
      "type": "WEB",
      "url": "https://github.com/purplededa/CVE-2022-44721-CsFalconUninstaller"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6HXM-W4HV-VGVW

Vulnerability from github – Published: 2026-06-12 18:31 – Updated: 2026-06-12 18:31
VLAI
Details

Mattermost versions 11.6.x <= 11.6.1, 11.5.x <= 11.5.4, 10.11.x <= 10.11.15, 10.11.x <= 10.11.16 Mattermost fails to require role-management authorization when setting the scheme_admin flag on group syncable link and patch endpoints, which allows a user with group-link permissions to escalate themselves and group members to team or channel admin via crafted API requests.. Mattermost Advisory ID: MMSA-2026-00665

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T17:16:27Z",
    "severity": "HIGH"
  },
  "details": "Mattermost versions 11.6.x \u003c= 11.6.1, 11.5.x \u003c= 11.5.4, 10.11.x \u003c= 10.11.15, 10.11.x \u003c= 10.11.16 Mattermost fails to require role-management authorization when setting the scheme_admin flag on group syncable link and patch endpoints, which allows a user with group-link permissions to escalate themselves and group members to team or channel admin via crafted API requests.. Mattermost Advisory ID: MMSA-2026-00665",
  "id": "GHSA-6hxm-w4hv-vgvw",
  "modified": "2026-06-12T18:31:59Z",
  "published": "2026-06-12T18:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7387"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6J27-PC5C-M8W8

Vulnerability from github – Published: 2026-03-02 22:20 – Updated: 2026-03-19 21:21
VLAI
Summary
OpenClaw's allow-always wrapper persistence could bypass future approvals and enable command execution
Details

Summary

In openclaw npm releases up to and including 2026.2.21-2, approving wrapped system.run commands with allow-always in security=allowlist mode could persist wrapper-level allowlist entries and enable later approval-bypass execution of different inner payloads.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.2.21-2
  • Planned patched version: 2026.2.22

Details

allow-always persistence was based on wrapper-level resolution instead of stable inner executable intent. A benign approved wrapper invocation could therefore broaden future trust boundaries.

Affected paths included gateway and node-host execution approval persistence flows. The fix now persists inner executable paths for known dispatch-wrapper chains (env, nice, nohup, stdbuf, timeout) and fails closed when safe unwrapping cannot be derived.

Impact

Authorization boundary bypass in allowlist mode, potentially leading to approval-free command execution (RCE class) on subsequent wrapped invocations.

Mitigation

Upgrade to 2026.2.22 (planned next release) or run with stricter exec policy (ask=always / security=deny) until upgraded.

Fix Commit(s)

  • 24c954d972400f508814532dea0e4dcb38418bb0

Release Process Note

patched_versions is pre-set to 2026.2.22 so this advisory is publish-ready; publish after the npm release is live.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29607"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T22:20:22Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nIn `openclaw` npm releases up to and including `2026.2.21-2`, approving wrapped `system.run` commands with `allow-always` in `security=allowlist` mode could persist wrapper-level allowlist entries and enable later approval-bypass execution of different inner payloads.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.2.21-2`\n- Planned patched version: `2026.2.22`\n\n### Details\n`allow-always` persistence was based on wrapper-level resolution instead of stable inner executable intent. A benign approved wrapper invocation could therefore broaden future trust boundaries.\n\nAffected paths included gateway and node-host execution approval persistence flows. The fix now persists inner executable paths for known dispatch-wrapper chains (`env`, `nice`, `nohup`, `stdbuf`, `timeout`) and fails closed when safe unwrapping cannot be derived.\n\n### Impact\nAuthorization boundary bypass in allowlist mode, potentially leading to approval-free command execution (RCE class) on subsequent wrapped invocations.\n\n### Mitigation\nUpgrade to `2026.2.22` (planned next release) or run with stricter exec policy (`ask=always` / `security=deny`) until upgraded.\n\n### Fix Commit(s)\n- `24c954d972400f508814532dea0e4dcb38418bb0`\n\n### Release Process Note\n`patched_versions` is pre-set to `2026.2.22` so this advisory is publish-ready; publish after the npm release is live.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-6j27-pc5c-m8w8",
  "modified": "2026-03-19T21:21:56Z",
  "published": "2026-03-02T22:20:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-6j27-pc5c-m8w8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29607"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/24c954d972400f508814532dea0e4dcb38418bb0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-via-allow-always-wrapper-persistence"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw\u0027s allow-always wrapper persistence could bypass future approvals and enable command execution"
}

GHSA-6J44-3GP8-RFHG

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-07 00:00
VLAI
Details

Archer 6.x through 6.9 SP2 P1 (6.9.2.1) contains an improper access control vulnerability on attachments. A remote authenticated malicious user could potentially exploit this vulnerability to gain access to files that should only be allowed by extra privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-26949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Archer 6.x through 6.9 SP2 P1 (6.9.2.1) contains an improper access control vulnerability on attachments. A remote authenticated malicious user could potentially exploit this vulnerability to gain access to files that should only be allowed by extra privileges.",
  "id": "GHSA-6j44-3gp8-rfhg",
  "modified": "2022-04-07T00:00:30Z",
  "published": "2022-03-31T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26949"
    },
    {
      "type": "WEB",
      "url": "https://www.archerirm.community/t5/general-support-information/tkb-p/information-support"
    },
    {
      "type": "WEB",
      "url": "https://www.archerirm.community/t5/security-advisories/archer-an-rsa-business-update-for-multiple-vulnerabilities/ta-p/674497"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6JCC-XGCR-Q3H4

Vulnerability from github – Published: 2025-08-08 14:29 – Updated: 2026-02-04 22:13
VLAI
Summary
@fedify/fedify has Improper Authentication and Incorrect Authorization
Details

Summary

An authentication bypass vulnerability allows any unauthenticated attacker to impersonate any ActivityPub actor by sending forged activities signed with their own keys. Activities are processed before verifying the signing key belongs to the claimed actor, enabling complete actor impersonation across all Fedify instances

Details

The vulnerability exists in handleInboxInternal function in fedify/federation/handler.ts. The critical flaw is in the order of operations:

  1. Line 1712: routeActivity() is called first, which processes the activity (either immediately or by adding to queue)
  2. Line 1730: Authentication check (doesActorOwnKey) happens AFTER processing
  // fedify/federation/handler.ts:1712-1750
  const routeResult = await routeActivity({  // ← Activity processed here
    context: ctx,
    json,
    activity,
    recipient,
    inboxListeners,
    inboxContextFactory,
    inboxErrorHandler,
    kv,
    kvPrefixes,
    queue,
    span,
    tracerProvider,
  });

  if (
    httpSigKey != null && !await doesActorOwnKey(activity, httpSigKey, ctx)  // ← Auth check too late
  ) {
    // Returns 401, but activity already processed
    return new Response("The signer and the actor do not match.", {
      status: 401,
      headers: { "Content-Type": "text/plain; charset=utf-8" },
    });
  }

By the time the 401 response is returned, the malicious activity has already been processed or queued.

PoC

  1. Create an activity claiming to be from any actor:
  const maliciousActivity = {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Create",
    "actor": "https://victim.example.com/users/alice",  // Impersonating victim
    "object": {
      "type": "Note",
      "content": "This is a forged message!"
    }
  }
  1. Sign the HTTP request with attacker's key (not the victim's):
  // Sign with attacker's key: https://attacker.com/users/eve#main-key
  const signedRequest = await signRequest(request, attackerPrivateKey, attackerKeyId);
  1. Send to any Fedify inbox - the activity will be processed despite the key mismatch.

Impact

Type: Authentication Bypass / Actor Impersonation

Who is impacted: All Fedify instances and their users

Consequences: Allows complete impersonation of any ActivityPub actor, enabling: - Sending fake posts/messages as any user - Creating/removing follows as any user - Boosting/sharing content as any user - Complete compromise of federation trust model

The vulnerability affects all Fedify instances but does not propagate to other ActivityPub implementations (Mastodon, etc.) which properly validate before processing.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0-dev.585"
            },
            {
              "fixed": "1.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0-dev.636"
            },
            {
              "fixed": "1.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0-dev.754"
            },
            {
              "fixed": "1.6.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0-pr.251.885"
            },
            {
              "fixed": "1.7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0-dev.909"
            },
            {
              "fixed": "1.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-08T14:29:48Z",
    "nvd_published_at": "2025-08-09T02:15:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n An authentication bypass vulnerability allows any unauthenticated attacker to impersonate any ActivityPub actor by sending forged activities signed with their own keys. Activities are processed before verifying the signing key belongs to the claimed actor, enabling complete actor impersonation across all Fedify instances\n\n### Details\nThe vulnerability exists in handleInboxInternal function in fedify/federation/handler.ts. The critical flaw is in the order of operations:\n\n  1. Line 1712: routeActivity() is called first, which processes the activity (either immediately or by adding to queue)\n  2. Line 1730: Authentication check (doesActorOwnKey) happens AFTER processing\n\n```ts\n  // fedify/federation/handler.ts:1712-1750\n  const routeResult = await routeActivity({  // \u2190 Activity processed here\n    context: ctx,\n    json,\n    activity,\n    recipient,\n    inboxListeners,\n    inboxContextFactory,\n    inboxErrorHandler,\n    kv,\n    kvPrefixes,\n    queue,\n    span,\n    tracerProvider,\n  });\n\n  if (\n    httpSigKey != null \u0026\u0026 !await doesActorOwnKey(activity, httpSigKey, ctx)  // \u2190 Auth check too late\n  ) {\n    // Returns 401, but activity already processed\n    return new Response(\"The signer and the actor do not match.\", {\n      status: 401,\n      headers: { \"Content-Type\": \"text/plain; charset=utf-8\" },\n    });\n  }\n```\n\nBy the time the 401 response is returned, the malicious activity has already been processed or queued.\n\n### PoC\n\n  1. Create an activity claiming to be from any actor:\n```ts\n  const maliciousActivity = {\n    \"@context\": \"https://www.w3.org/ns/activitystreams\",\n    \"type\": \"Create\",\n    \"actor\": \"https://victim.example.com/users/alice\",  // Impersonating victim\n    \"object\": {\n      \"type\": \"Note\",\n      \"content\": \"This is a forged message!\"\n    }\n  }\n```\n  2. Sign the HTTP request with attacker\u0027s key (not the victim\u0027s):\n```ts\n  // Sign with attacker\u0027s key: https://attacker.com/users/eve#main-key\n  const signedRequest = await signRequest(request, attackerPrivateKey, attackerKeyId);\n```\n  3. Send to any Fedify inbox - the activity will be processed despite the key mismatch.\n\n### Impact\n\nType: Authentication Bypass / Actor Impersonation\n\nWho is impacted: All Fedify instances and their users\n\nConsequences: Allows complete impersonation of any ActivityPub actor, enabling:\n  - Sending fake posts/messages as any user\n  - Creating/removing follows as any user\n  - Boosting/sharing content as any user\n  - Complete compromise of federation trust model\n\nThe vulnerability affects all Fedify instances but does not propagate to other ActivityPub implementations (Mastodon, etc.) which properly validate before processing.",
  "id": "GHSA-6jcc-xgcr-q3h4",
  "modified": "2026-02-04T22:13:40Z",
  "published": "2025-08-08T14:29:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-6jcc-xgcr-q3h4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/commit/14a2f8c6d2c3cbc00c3170a86ad3b7b8555c6847"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fedify-dev/fedify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@fedify/fedify has Improper Authentication and Incorrect Authorization"
}

GHSA-6JFG-GMCW-W9P6

Vulnerability from github – Published: 2023-08-13 12:30 – Updated: 2024-04-04 06:53
VLAI
Details

Vulnerability of incomplete permission verification in the input method module. Successful exploitation of this vulnerability may cause features to perform abnormally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-39384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-13T12:15:45Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability of incomplete permission verification in the input method module. Successful exploitation of this vulnerability may cause features to perform abnormally.",
  "id": "GHSA-6jfg-gmcw-w9p6",
  "modified": "2024-04-04T06:53:46Z",
  "published": "2023-08-13T12:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39384"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/8"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202308-0000001667644725"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6JM8-X3G6-R33J

Vulnerability from github – Published: 2026-01-08 21:01 – Updated: 2026-01-08 21:37
VLAI
Summary
Soft Serve is missing an authorization check in LFS lock deletion
Details

LFS Lock Force-Delete Authorization Bypass

Summary

An authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the force flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely.

Severity

  • CWE-863: Incorrect Authorization
  • CVSS 3.1: 5.4 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Affected Code

File: pkg/web/git_lfs.go Function: serviceLfsLocksDelete (lines 831–945) Endpoint: POST /<repo>.git/info/lfs/locks/:lockID/unlock

The control flow processes req.Force at line 905 before retrieving user context at line 919:

// Line 905-916: Force delete executes immediately without authorization
if req.Force {
    if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil {
        // ...
    }
    renderJSON(w, http.StatusOK, l)
    return  // Returns here, never reaching user validation
}

// Line 919: User context retrieved after force path has exited
user := proto.UserFromContext(ctx)

Proof of Concept

Setup: Two users with write access to the same repository—User A (lock owner) and User B (attacker).

  1. User A creates a lock: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks \ -H "Authorization: Basic <user_a_token>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"path": "protected-file.bin"}'

  2. User B deletes User A's lock using force flag: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks/1/unlock \ -H "Authorization: Basic <user_b_token>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"force": true}'

  3. Result: Lock deleted successfully with 200 OK. Expected: 403 Forbidden.

Suggested Fix

Retrieve user context and validate authorization before processing the force flag:

user := proto.UserFromContext(ctx)
if user == nil {
    renderJSON(w, http.StatusUnauthorized, lfs.ErrorResponse{
        Message: "unauthorized",
    })
    return
}

if req.Force {
    if !user.IsAdmin() {
        renderJSON(w, http.StatusForbidden, lfs.ErrorResponse{
            Message: "admin access required for force delete",
        })
        return
    }
    if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil {
        // ...
    }
    renderJSON(w, http.StatusOK, l)
    return
}

Impact

Affected Deployments: Soft Serve instances with LFS enabled and repositories with multiple collaborators.

Exploitation Requirements: - Authenticated session - Write access to target repository

Consequences: - Unauthorized deletion of other users' locks - Bypass of LFS file coordination mechanisms - Potential workflow disruption in collaborative environments

Limitations: Does not grant file access, escalate repository permissions, or affect repositories where the attacker lacks write access.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/soft-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-08T21:01:54Z",
    "nvd_published_at": "2026-01-08T19:15:59Z",
    "severity": "MODERATE"
  },
  "details": "## LFS Lock Force-Delete Authorization Bypass\n\n### Summary\n\nAn authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the `force` flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely.\n\n### Severity\n\n- **CWE-863:** Incorrect Authorization\n- **CVSS 3.1:** 5.4 (Medium) \u2014 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L`\n\n### Affected Code\n\n**File:** `pkg/web/git_lfs.go`\n**Function:** `serviceLfsLocksDelete` (lines 831\u2013945)\n**Endpoint:** `POST /\u003crepo\u003e.git/info/lfs/locks/:lockID/unlock`\n\nThe control flow processes `req.Force` at line 905 before retrieving user context at line 919:\n\n```go\n// Line 905-916: Force delete executes immediately without authorization\nif req.Force {\n    if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil {\n        // ...\n    }\n    renderJSON(w, http.StatusOK, l)\n    return  // Returns here, never reaching user validation\n}\n\n// Line 919: User context retrieved after force path has exited\nuser := proto.UserFromContext(ctx)\n```\n\n### Proof of Concept\n\n**Setup:** Two users with write access to the same repository\u2014User A (lock owner) and User B (attacker).\n\n1. **User A creates a lock:**\n   ```bash\n   curl -X POST http://localhost:23232/repo.git/info/lfs/locks \\\n     -H \"Authorization: Basic \u003cuser_a_token\u003e\" \\\n     -H \"Content-Type: application/vnd.git-lfs+json\" \\\n     -d \u0027{\"path\": \"protected-file.bin\"}\u0027\n   ```\n\n2. **User B deletes User A\u0027s lock using force flag:**\n   ```bash\n   curl -X POST http://localhost:23232/repo.git/info/lfs/locks/1/unlock \\\n     -H \"Authorization: Basic \u003cuser_b_token\u003e\" \\\n     -H \"Content-Type: application/vnd.git-lfs+json\" \\\n     -d \u0027{\"force\": true}\u0027\n   ```\n\n3. **Result:** Lock deleted successfully with `200 OK`. Expected: `403 Forbidden`.\n\n### Suggested Fix\n\nRetrieve user context and validate authorization before processing the force flag:\n\n```go\nuser := proto.UserFromContext(ctx)\nif user == nil {\n    renderJSON(w, http.StatusUnauthorized, lfs.ErrorResponse{\n        Message: \"unauthorized\",\n    })\n    return\n}\n\nif req.Force {\n    if !user.IsAdmin() {\n        renderJSON(w, http.StatusForbidden, lfs.ErrorResponse{\n            Message: \"admin access required for force delete\",\n        })\n        return\n    }\n    if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil {\n        // ...\n    }\n    renderJSON(w, http.StatusOK, l)\n    return\n}\n```\n\n### Impact\n\n**Affected Deployments:** Soft Serve instances with LFS enabled and repositories with multiple collaborators.\n\n**Exploitation Requirements:**\n- Authenticated session\n- Write access to target repository\n\n**Consequences:**\n- Unauthorized deletion of other users\u0027 locks\n- Bypass of LFS file coordination mechanisms\n- Potential workflow disruption in collaborative environments\n\n**Limitations:** Does not grant file access, escalate repository permissions, or affect repositories where the attacker lacks write access.",
  "id": "GHSA-6jm8-x3g6-r33j",
  "modified": "2026-01-08T21:37:08Z",
  "published": "2026-01-08T21:01:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-6jm8-x3g6-r33j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22253"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/commit/000ab5164f0be68cf1ea6b6e7227f11c0e388a42"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/soft-serve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Soft Serve is missing an authorization check in LFS lock deletion"
}

GHSA-6JRF-4JV4-R9MW

Vulnerability from github – Published: 2025-04-09 13:01 – Updated: 2025-04-09 13:01
VLAI
Summary
tendermint-rs's Light Client Verifier allows malicious validators to spoof votes from other validators
Details

Name: ISA-2025-003: Malicious validator can spoof votes from other validators Component: tendermint-rs Criticality: High (Catastrophic Impact; Rare Likelihood per ACMv1.2) Affected versions: <= v0.40.2 Affected users: Everyone

Description

tendermint-rs contains a critical vulnerability in its light client implementation due to insecure handling of corrupted validator sets. Because it doesn't check that the validator address is correctly derived from the validator's public key when counting votes, it is possible to spoof votes from other validators. The result is being able to construct the malicious block and cheat the light client. The light client will accept such a block, seemingly signed by 2/3+ majority.

Patches

The new tendermint-rs release v0.40.3 fixes this issue.

Unreleased code in the main branch is patched as well.

Workarounds

There are no known workarounds for this issue.

Timeline

  • March 12, 2025, 13:41pm PST: Issue reported
  • March 12, 2025, 03:00am PST: Core team completes validation of issue

This issue was reported by Felix Wilhelm from Asymmetric Research.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tendermint-light-client-verifier"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.40.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-09T13:01:26Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Name: ISA-2025-003: Malicious validator can spoof votes from other validators \nComponent: tendermint-rs\nCriticality: High (Catastrophic Impact; Rare Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))\nAffected versions: \u003c= v0.40.2\nAffected users: Everyone\n\n### Description\n\ntendermint-rs contains a critical vulnerability in its light client implementation due to insecure handling of corrupted validator sets. Because it doesn\u0027t check that the validator address is correctly derived from the validator\u0027s public key when counting votes, it is possible to spoof votes from other validators. The result is being able to construct the malicious block and cheat the light client. The light client will accept such a block, seemingly signed by 2/3+ majority.\n\n### Patches\n\nThe new tendermint-rs release [v0.40.3](https://github.com/informalsystems/tendermint-rs/releases/tag/v0.40.3) fixes this issue.\n\nUnreleased code in the main branch is patched as well.\n\n### Workarounds\n\nThere are no known workarounds for this issue.\n\n### Timeline\n\n* March 12, 2025, 13:41pm PST: Issue reported\n* March 12, 2025, 03:00am PST: Core team completes validation of issue\n\nThis issue was reported by Felix Wilhelm from [Asymmetric Research](https://www.asymmetric.re/).",
  "id": "GHSA-6jrf-4jv4-r9mw",
  "modified": "2025-04-09T13:01:26Z",
  "published": "2025-04-09T13:01:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/informalsystems/tendermint-rs/security/advisories/GHSA-6jrf-4jv4-r9mw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/informalsystems/tendermint-rs/commit/1aabcfe6a3c0678db22097543f7f7a662f0db34b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/informalsystems/tendermint-rs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tendermint-rs\u0027s Light Client Verifier allows malicious validators to spoof votes from other validators "
}

GHSA-6JVQ-7CJ3-36WH

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:43
VLAI
Details

The /rest/api/2/user/picker rest resource in Jira before version 7.13.3, from version 8.0.0 before version 8.0.4, and from version 8.1.0 before version 8.1.1 allows remote attackers to enumerate usernames via an incorrect authorisation check.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The /rest/api/2/user/picker rest resource in Jira before version 7.13.3, from version 8.0.0 before version 8.0.4, and from version 8.1.0 before version 8.1.1 allows remote attackers to enumerate usernames via an incorrect authorisation check.",
  "id": "GHSA-6jvq-7cj3-36wh",
  "modified": "2024-04-04T00:43:58Z",
  "published": "2022-05-24T16:46:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3403"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-69242"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.