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.

5678 vulnerabilities reference this CWE, most recent first.

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"
    }
  ]
}

GHSA-6JWJ-6H4R-9VR7

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-14 00:00
VLAI
Details

Forcepoint One Endpoint prior to version 22.01 installed on Microsoft Windows is vulnerable to registry key tampering by users with Administrator privileges. This could result in a user disabling anti-tampering mechanisms which would then allow the user to disable Forcepoint One Endpoint and the protection offered by it.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-27608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-04T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Forcepoint One Endpoint prior to version 22.01 installed on Microsoft Windows is vulnerable to registry key tampering by users with Administrator privileges. This could result in a user disabling anti-tampering mechanisms which would then allow the user to disable Forcepoint One Endpoint and the protection offered by it.",
  "id": "GHSA-6jwj-6h4r-9vr7",
  "modified": "2022-04-14T00:00:41Z",
  "published": "2022-04-05T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27608"
    },
    {
      "type": "WEB",
      "url": "https://help.forcepoint.com/security/CVE/CVE-2022-27608.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6JX2-3QQX-X2M4

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

Vulnerability in the Oracle Project Foundation product of Oracle E-Business Suite (component: Technology Foundation). Supported versions that are affected are 12.2.3-12.2.13. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Project Foundation. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Project Foundation accessible data as well as unauthorized access to critical data or complete access to all Oracle Project Foundation accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T21:15:15Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle Project Foundation product of Oracle E-Business Suite (component: Technology Foundation).  Supported versions that are affected are 12.2.3-12.2.13. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Project Foundation.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Project Foundation accessible data as well as  unauthorized access to critical data or complete access to all Oracle Project Foundation accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).",
  "id": "GHSA-6jx2-3qqx-x2m4",
  "modified": "2025-01-21T21:30:55Z",
  "published": "2025-01-21T21:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21506"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2025.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-6M3M-2Q88-9QC9

Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-07-13 00:00
VLAI
Details

Improper access control in kernel mode driver for some Intel(R) NUC 9 Extreme Laptop Kits before version 2.2.0.20 may allow an authenticated user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-0196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-11T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control in kernel mode driver for some Intel(R) NUC 9 Extreme Laptop Kits before version 2.2.0.20 may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-6m3m-2q88-9qc9",
  "modified": "2022-07-13T00:00:58Z",
  "published": "2022-05-24T19:10:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0196"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00553.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6M72-467W-94RH

Vulnerability from github – Published: 2024-01-31 23:11 – Updated: 2024-01-31 23:11
VLAI
Summary
Privilege Escalation in HashiCorp Consul
Details

HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed operators with operator:read ACL permissions to read the Connect CA private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/consul"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.0"
            },
            {
              "fixed": "1.6.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/consul"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/consul"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0"
            },
            {
              "fixed": "1.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-28053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-31T23:11:32Z",
    "nvd_published_at": "2020-11-23T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed operators with operator:read ACL permissions to read the Connect CA private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6.",
  "id": "GHSA-6m72-467w-94rh",
  "modified": "2024-01-31T23:11:32Z",
  "published": "2024-01-31T23:11:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28053"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/consul/pull/9240"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/consul/commit/ff5215d882ac51b49c2647aac46b42aa9c890ce3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#186-november-19-2020"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-09"
    },
    {
      "type": "WEB",
      "url": "https://www.hashicorp.com/blog/category/consul"
    }
  ],
  "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"
    }
  ],
  "summary": "Privilege Escalation in HashiCorp Consul"
}

GHSA-6M7H-74WG-GQ59

Vulnerability from github – Published: 2022-01-15 00:01 – Updated: 2022-07-15 00:00
VLAI
Details

An issue has recently been discovered in Arista EOS where the incorrect use of EOS's AAA API’s by the OpenConfig and TerminAttr agents could result in unrestricted access to the device for local users with nopassword configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-28501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue has recently been discovered in Arista EOS where the incorrect use of EOS\u0027s AAA API\u2019s by the OpenConfig and TerminAttr agents could result in unrestricted access to the device for local users with nopassword configuration.",
  "id": "GHSA-6m7h-74wg-gq59",
  "modified": "2022-07-15T00:00:16Z",
  "published": "2022-01-15T00:01:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28501"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisories/13449-security-advisory-0071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "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.