Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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-57J5-QWP2-VQP6

Vulnerability from github – Published: 2026-04-22 19:43 – Updated: 2026-04-22 19:43
VLAI
Summary
OpenFGA has Improper Policy Enforcement
Details

Description

In OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.

Am I Affected?

Users are affected if their applications meet the following preconditions:

  • The model has relations which rely on condition evaluation.
  • Caching is enabled.

Fix

Upgrade to OpenFGA v1.14.1.

Acknowledgement

OpenFGA would like to thank @bugbunny-research for the detailed report.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T19:43:36Z",
    "nvd_published_at": "2026-04-22T00:16:29Z",
    "severity": "MODERATE"
  },
  "details": "### Description\nIn OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.\n\n### Am I Affected?\nUsers are affected if their applications meet the following preconditions:\n\n* The model has relations which rely on condition evaluation.\n* Caching is enabled.\n\n### Fix\nUpgrade to OpenFGA v1.14.1.\n\n### Acknowledgement\nOpenFGA would like to thank @bugbunny-research for the detailed report.",
  "id": "GHSA-57j5-qwp2-vqp6",
  "modified": "2026-04-22T19:43:36Z",
  "published": "2026-04-22T19:43:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-57j5-qwp2-vqp6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41131"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/releases/tag/v1.14.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenFGA has Improper Policy Enforcement"
}

GHSA-57J8-WCPX-W45W

Vulnerability from github – Published: 2025-01-31 18:31 – Updated: 2025-02-03 18:30
VLAI
Details

SSH Communication Security PrivX versions between 18.0-36.0 implement insufficient validation on public key signatures when using native SSH connections via a proxy port. This allows an existing PrivX "account A" to impersonate another existing PrivX "account B" and gain access to SSH target hosts to which the "account B" has access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-47857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T17:15:14Z",
    "severity": "CRITICAL"
  },
  "details": "SSH Communication Security PrivX versions between 18.0-36.0 implement insufficient validation on public key signatures when using native SSH connections via a proxy port. This allows an existing PrivX \"account A\" to impersonate another existing PrivX \"account B\" and gain access to SSH target hosts to which the \"account B\" has access.",
  "id": "GHSA-57j8-wcpx-w45w",
  "modified": "2025-02-03T18:30:39Z",
  "published": "2025-01-31T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47857"
    },
    {
      "type": "WEB",
      "url": "https://info.ssh.com/impersonation-vulnerability-privx"
    },
    {
      "type": "WEB",
      "url": "https://ssh.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-57PR-FGR5-WQVX

Vulnerability from github – Published: 2026-04-17 18:31 – Updated: 2026-05-12 15:31
VLAI
Details

An access control vulnerability was discovered in the Threat Intelligence functionality due to a specific access restriction not being properly enforced for users with view-only privileges. An authenticated user with view-only privileges for the Threat Intelligence functionality can perform administrative actions on it, altering the rules configuration, and/or affecting their availability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-40897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-15T09:16:29Z",
    "severity": "HIGH"
  },
  "details": "An access control vulnerability was discovered in the Threat Intelligence functionality due to a specific access restriction not being properly enforced for users with view-only privileges. An authenticated user with view-only privileges for the Threat Intelligence functionality can perform administrative actions on it, altering the rules configuration, and/or affecting their availability.",
  "id": "GHSA-57pr-fgr5-wqvx",
  "modified": "2026-05-12T15:31:15Z",
  "published": "2026-04-17T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40897"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-827968.html"
    },
    {
      "type": "WEB",
      "url": "https://security.nozominetworks.com/NN-2026:1-01"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-57Q6-FVP4-PQMM

Vulnerability from github – Published: 2026-05-14 20:21 – Updated: 2026-05-15 23:53
VLAI
Summary
Open WebUI's API key endpoint restrictions bypassed via `x-api-key` header — full message processing on restricted endpoints
Details

Summary

Open WebUI allows admins to restrict which API endpoints an API key can access. When an API key is restricted from /api/v1/messages, requests using the Authorization: Bearer sk-... header are correctly blocked with 403. However, the same key sent via the x-api-key header bypasses the restriction entirely — the request is authenticated, the model is invoked, and a full response is returned.

Details

Open WebUI's Anthropic-compatible API path accepts authentication via x-api-key header (standard for the Anthropic API). The endpoint restriction check only applies to keys presented via the Authorization header. When the same sk-... key is supplied in x-api-key, the restriction check is skipped but the key is still valid for authentication.

This means any API key, regardless of its configured endpoint restrictions, can access any API endpoint by simply using x-api-key instead of Authorization.

PoC

Verified against Open WebUI v0.8.11.

Setup: Admin creates a user with an API key that has endpoint restrictions (not allowed on /api/v1/messages). A mock OpenAI-compatible model (mock-model) is configured.

API_KEY="sk-dc56016d720e49ba9e95584d602b79bb"

# Test 1: Authorization header — BLOCKED (endpoint restriction enforced)
curl -s -X POST http://target:8080/api/v1/messages \
  -H "Authorization: Bearer $API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"mock-model","messages":[{"role":"user","content":"via Authorization header"}]}'

# Test 2: x-api-key header — BYPASS (same key, restriction skipped)
curl -s -X POST http://target:8080/api/v1/messages \
  -H "x-api-key: $API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"mock-model","messages":[{"role":"user","content":"via x-api-key header"}]}'

Verified output:

# Authorization header:
{"detail":"API key not allowed to access this endpoint."}

# x-api-key header (SAME key):
{"id":"chatcmpl-mock","type":"message","role":"assistant","content":[{"type":"text","text":"MOCK-CHAT-RESPONSE"}],"model":"mock-model","usage":{"input_tokens":1,"output_tokens":1}}

The same API key is rejected via Authorization (403) but fully processed via x-api-key (200 with model response).

Impact

Any API key with endpoint restrictions can bypass those restrictions by using the x-api-key header instead of Authorization. This undermines the entire API key permission model:

  • Keys restricted from chat/completion endpoints can still send messages and receive LLM responses
  • Keys restricted from admin endpoints may access admin functionality
  • The operator's intended access control is silently ineffective
  • API credit spend cannot be controlled through endpoint restrictions
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T20:21:26Z",
    "nvd_published_at": "2026-05-15T20:16:48Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nOpen WebUI allows admins to restrict which API endpoints an API key can access. When an API key is restricted from `/api/v1/messages`, requests using the `Authorization: Bearer sk-...` header are correctly blocked with 403. However, the same key sent via the `x-api-key` header bypasses the restriction entirely \u2014 the request is authenticated, the model is invoked, and a full response is returned.\n\n### Details\n\nOpen WebUI\u0027s Anthropic-compatible API path accepts authentication via `x-api-key` header (standard for the Anthropic API). The endpoint restriction check only applies to keys presented via the `Authorization` header. When the same `sk-...` key is supplied in `x-api-key`, the restriction check is skipped but the key is still valid for authentication.\n\nThis means any API key, regardless of its configured endpoint restrictions, can access any API endpoint by simply using `x-api-key` instead of `Authorization`.\n\n### PoC\n\n**Verified against Open WebUI v0.8.11.**\n\n**Setup:** Admin creates a user with an API key that has endpoint restrictions (not allowed on `/api/v1/messages`). A mock OpenAI-compatible model (`mock-model`) is configured.\n\n```bash\nAPI_KEY=\"sk-dc56016d720e49ba9e95584d602b79bb\"\n\n# Test 1: Authorization header \u2014 BLOCKED (endpoint restriction enforced)\ncurl -s -X POST http://target:8080/api/v1/messages \\\n  -H \"Authorization: Bearer $API_KEY\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"model\":\"mock-model\",\"messages\":[{\"role\":\"user\",\"content\":\"via Authorization header\"}]}\u0027\n\n# Test 2: x-api-key header \u2014 BYPASS (same key, restriction skipped)\ncurl -s -X POST http://target:8080/api/v1/messages \\\n  -H \"x-api-key: $API_KEY\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"model\":\"mock-model\",\"messages\":[{\"role\":\"user\",\"content\":\"via x-api-key header\"}]}\u0027\n```\n\n**Verified output:**\n\n```\n# Authorization header:\n{\"detail\":\"API key not allowed to access this endpoint.\"}\n\n# x-api-key header (SAME key):\n{\"id\":\"chatcmpl-mock\",\"type\":\"message\",\"role\":\"assistant\",\"content\":[{\"type\":\"text\",\"text\":\"MOCK-CHAT-RESPONSE\"}],\"model\":\"mock-model\",\"usage\":{\"input_tokens\":1,\"output_tokens\":1}}\n```\n\nThe same API key is rejected via `Authorization` (403) but fully processed via `x-api-key` (200 with model response).\n\n### Impact\n\nAny API key with endpoint restrictions can bypass those restrictions by using the `x-api-key` header instead of `Authorization`. This undermines the entire API key permission model:\n\n- Keys restricted from chat/completion endpoints can still send messages and receive LLM responses\n- Keys restricted from admin endpoints may access admin functionality\n- The operator\u0027s intended access control is silently ineffective\n- API credit spend cannot be controlled through endpoint restrictions",
  "id": "GHSA-57q6-fvp4-pqmm",
  "modified": "2026-05-15T23:53:55Z",
  "published": "2026-05-14T20:21:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-57q6-fvp4-pqmm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45339"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI\u0027s API key endpoint restrictions bypassed via `x-api-key` header \u2014 full message processing on restricted endpoints"
}

GHSA-57R5-PMVW-W26W

Vulnerability from github – Published: 2025-01-09 21:31 – Updated: 2025-01-10 18:31
VLAI
Details

Incorrect Authorization vulnerability in Drupal Advanced PWA inc Push Notifications allows Forceful Browsing.This issue affects Advanced PWA inc Push Notifications: from 0.0.0 before 1.5.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-13253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-09T19:15:19Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect Authorization vulnerability in Drupal Advanced PWA inc Push Notifications allows Forceful Browsing.This issue affects Advanced PWA inc Push Notifications: from 0.0.0 before 1.5.0.",
  "id": "GHSA-57r5-pmvw-w26w",
  "modified": "2025-01-10T18:31:39Z",
  "published": "2025-01-09T21:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13253"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2024-017"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-57RX-38PP-C45G

Vulnerability from github – Published: 2024-06-27 21:32 – Updated: 2025-11-04 00:30
VLAI
Details

IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could disclose sensitive information to a local user to do improper permission controls. IBM X-Force ID: 261195.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-38368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-276",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-27T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Access Manager Docker 10.0.0.0 through 10.0.7.1 could disclose sensitive information to a local user to do improper permission controls.  IBM X-Force ID:  261195.",
  "id": "GHSA-57rx-38pp-c45g",
  "modified": "2025-11-04T00:30:50Z",
  "published": "2024-06-27T21:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38368"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/261195"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7158790"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Nov/0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-57V4-M9JX-MH8R

Vulnerability from github – Published: 2021-06-08 23:05 – Updated: 2023-02-13 17:29
VLAI
Summary
Improper Input Validation
Details

A vulnerability was found in OVN Kubernetes in versions up to and including 0.3.0 where the Egress Firewall does not reliably apply firewall rules when there is multiple DNS rules. It could lead to potentially lose of confidentiality, integrity or availability of a service

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ovn-org/ovn-kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3499"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-28T21:24:52Z",
    "nvd_published_at": "2021-06-02T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in OVN Kubernetes in versions up to and including 0.3.0 where the Egress Firewall does not reliably apply firewall rules when there is multiple DNS rules. It could lead to potentially lose of confidentiality, integrity or availability of a service",
  "id": "GHSA-57v4-m9jx-mh8r",
  "modified": "2023-02-13T17:29:53Z",
  "published": "2021-06-08T23:05:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3499"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ovn-org/ovn-kubernetes/pull/2169"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2021:1550"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3499"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1949188"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Input Validation"
}

GHSA-5824-CM3X-3C38

Vulnerability from github – Published: 2023-08-09 14:27 – Updated: 2024-10-11 14:04
VLAI
Summary
Vyper has incorrectly allocated named re-entrancy locks
Details

Impact

In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:

  • A .vy contract compiled with either of the following vyper versions: 0.2.15, 0.2.16, 0.3.0
  • A primary function that utilizes the @nonreentrant decorator with a specific key and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates)
  • A secondary function that utilizes the same key and would be affected by the improper state caused by the primary function

Patches

https://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514

Workarounds

Upgrade to 0.3.1 or higher

References

Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2

Severity
8.7 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
9.1 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.15"
            },
            {
              "fixed": "0.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-39363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-09T14:27:57Z",
    "nvd_published_at": "2023-08-07T19:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nIn versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:\n\n- A `.vy` contract compiled with either of the following `vyper` versions: `0.2.15`, `0.2.16`, `0.3.0`\n- A primary function that utilizes the `@nonreentrant` decorator with a specific `key` and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates)\n- A secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function\n\n### Patches\nhttps://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514\n\n### Workarounds\nUpgrade to 0.3.1 or higher\n\n### References\nTechnical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2",
  "id": "GHSA-5824-cm3x-3c38",
  "modified": "2024-10-11T14:04:46Z",
  "published": "2023-08-09T14:27:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-5824-cm3x-3c38"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39363"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/2439"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/2514"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-142.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@LlamaRisk/BJzSKHNjn"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@vyperlang/HJUgNMhs2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vyper has incorrectly allocated named re-entrancy locks"
}

GHSA-583H-X99P-FMCC

Vulnerability from github – Published: 2022-06-14 00:00 – Updated: 2022-06-28 00:00
VLAI
Details

Power Distribution Units running on Powertek firmware (multiple brands) before 3.30.30 allows remote authorization bypass in the web interface. To exploit the vulnerability, an attacker must send an HTTP packet to the data retrieval interface (/cgi/get_param.cgi) with the tmpToken cookie set to an empty string followed by a semicolon. This bypasses an active session authorization check. This can be then used to fetch the values of protected sys.passwd and sys.su.name fields that contain the username and password in cleartext.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-33174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-13T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Power Distribution Units running on Powertek firmware (multiple brands) before 3.30.30 allows remote authorization bypass in the web interface. To exploit the vulnerability, an attacker must send an HTTP packet to the data retrieval interface (/cgi/get_param.cgi) with the tmpToken cookie set to an empty string followed by a semicolon. This bypasses an active session authorization check. This can be then used to fetch the values of protected sys.passwd and sys.su.name fields that contain the username and password in cleartext.",
  "id": "GHSA-583h-x99p-fmcc",
  "modified": "2022-06-28T00:00:55Z",
  "published": "2022-06-14T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33174"
    },
    {
      "type": "WEB",
      "url": "https://gynvael.coldwind.pl/?lang=en\u0026id=748"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-584M-7R4M-8J6V

Vulnerability from github – Published: 2023-03-10 21:30 – Updated: 2024-01-04 12:13
VLAI
Summary
Incorrect Authorization in Jenkins Core
Details

When triggering a build from the Jenkins CLI, Jenkins creates a temporary file on the controller if a file parameter is provided through the CLI’s standard input.

Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and , and LTS prior to 2.387.1 creates this temporary file in the default temporary directory with the default permissions for newly created files.

If these permissions are overly permissive, they may allow attackers with access to the Jenkins controller file system to read and write the file before it is used in the build.

This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allows attackers to read the temporary file. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more restrictive permissions.

As a workaround, you can set a different path as your default temporary directory using the Java system property java.io.tmpdir, if you’re concerned about this issue but unable to immediately update Jenkins.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.376"
            },
            {
              "fixed": "2.387.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.375.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.388"
            },
            {
              "fixed": "2.394"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-27903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-16T16:00:59Z",
    "nvd_published_at": "2023-03-10T21:15:00Z",
    "severity": "LOW"
  },
  "details": "When triggering a build from the Jenkins CLI, Jenkins creates a temporary file on the controller if a file parameter is provided through the CLI\u2019s standard input.\n\nJenkins 2.393 and earlier, LTS 2.375.3 and earlier, and , and LTS prior to 2.387.1 creates this temporary file in the default temporary directory with the default permissions for newly created files.\n\nIf these permissions are overly permissive, they may allow attackers with access to the Jenkins controller file system to read and write the file before it is used in the build.\n\nThis vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allows attackers to read the temporary file.\nJenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more restrictive permissions.\n\nAs a workaround, you can set a different path as your default temporary directory using the Java system property java.io.tmpdir, if you\u2019re concerned about this issue but unable to immediately update Jenkins.",
  "id": "GHSA-584m-7r4m-8j6v",
  "modified": "2024-01-04T12:13:22Z",
  "published": "2023-03-10T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27903"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/554587b06db553ce35fa362d7a0b0aef33a57afb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CVEProject/cvelist/blob/master/2023/27xxx/CVE-2023-27903.json"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-03-08/#SECURITY-3058"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Jenkins Core"
}
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.

← Back to the CWE list