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-6PJ2-5FQQ-XVJC

Vulnerability from github – Published: 2022-01-06 20:56 – Updated: 2022-01-06 18:54
VLAI
Summary
Incorrect Authorization in latte/latte
Details

This affects the package latte/latte before 2.10.6. There is a way to bypass allowFunctions that will affect the security of the application. When the template is set to allow/disallow the use of certain functions, adding control characters (x00-x08) after the function will bypass these restrictions.

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": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "latte/latte"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.10.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-06T18:54:41Z",
    "nvd_published_at": "2021-12-17T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "This affects the package latte/latte before 2.10.6. There is a way to bypass allowFunctions that will affect the security of the application. When the template is set to allow/disallow the use of certain functions, adding control characters (x00-x08) after the function will bypass these restrictions.",
  "id": "GHSA-6pj2-5fqq-xvjc",
  "modified": "2022-01-06T18:54:41Z",
  "published": "2022-01-06T20:56:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23803"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nette/latte/issues/279"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nette/latte/commit/227c86eda9a8a6d060ea8501923e768b6d992210"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nette/latte"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-PHP-LATTELATTE-1932226"
    }
  ],
  "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"
    }
  ],
  "summary": "Incorrect Authorization in latte/latte"
}

GHSA-6PJF-3R9X-M592

Vulnerability from github – Published: 2026-05-04 20:48 – Updated: 2026-07-21 13:45
VLAI
Summary
Distribution's tag deletion bypasses `storage.delete.enabled` configuration
Details

Summary

Tag deletion via the DELETE /v2/<name>/manifests/<tag> endpoint bypasses the storage.delete.enabled: false configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.

Details

When storage.delete.enabled is configured to false, digest-based manifest deletion is correctly rejected by the guard in registry/storage/linkedblobstore.go:212-215.

However, tag deletion takes a separate code path that never checks this setting:

In registry/handlers/manifests.go:439-453, DeleteManifest detects a tag reference, calls tagService.Untag(), returns, never consulting registry.deleteEnabled.

In turn, tagStore.Untag() calls the storage driver directly to delete the tag path without checking whether deletes are enabled.

PoC

Using a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as config.yaml:

version: 0.1
storage:
  delete:
    enabled: false
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000

Start a local Distribution, mounting in the above configuration from the current directory:

docker run -p 5000:5000 -v "$(pwd)/config.yaml":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml

In a separate terminal session/tab, push alpine:3.23 into the running instance:

docker pull alpine:3.23
docker tag alpine:3.23 localhost:5000/alpine:3.23
docker push localhost:5000/alpine:3.23

Confirm that the tag shows up as expected:

curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":["3.23"]}

Issue a delete for the 3.23 tag:

curl -X DELETE 'http://localhost:5000/v2/alpine/manifests/3.23'

Observe that the tag is now gone, despite deletes being disabled:

curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":null}

Impact

This is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/distribution/distribution/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/distribution/distribution"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:48:57Z",
    "nvd_published_at": "2026-05-14T18:16:47Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nTag deletion via the `DELETE /v2/\u003cname\u003e/manifests/\u003ctag\u003e` endpoint bypasses the `storage.delete.enabled: false` configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.\n\n### Details\n\nWhen `storage.delete.enabled` is configured to false, digest-based manifest deletion is correctly rejected by the guard in [registry/storage/linkedblobstore.go:212-215](https://github.com/distribution/distribution/blob/main/registry/storage/linkedblobstore.go#L213-L215). \n\nHowever, tag deletion takes a separate code path that never checks this setting:\n\nIn [`registry/handlers/manifests.go:439-453`](https://github.com/distribution/distribution/blob/main/registry/handlers/manifests.go#L439-L453), `DeleteManifest`  detects a tag reference, calls `tagService.Untag()`, returns,  never consulting `registry.deleteEnabled`.\n\nIn turn, [`tagStore.Untag()`](https://github.com/distribution/distribution/blob/main/registry/storage/tagstore.go#L111-L121) calls the storage driver directly to delete the tag path without checking whether deletes are enabled.\n\n### PoC\n\nUsing a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as `config.yaml`:\n\n```yaml\nversion: 0.1\nstorage:\n  delete:\n    enabled: false\n  filesystem:\n    rootdirectory: /var/lib/registry\nhttp:\n  addr: :5000\n```\n\nStart a local Distribution, mounting in the above configuration from the current directory:\n\n```shell\ndocker run -p 5000:5000 -v \"$(pwd)/config.yaml\":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml\n```\n\nIn a separate terminal session/tab, push `alpine:3.23` into the running instance:\n```shell\ndocker pull alpine:3.23\ndocker tag alpine:3.23 localhost:5000/alpine:3.23\ndocker push localhost:5000/alpine:3.23\n```\n\nConfirm that the tag shows up as expected:\n```shell\ncurl \u0027http://localhost:5000/v2/alpine/tags/list\u0027\n{\"name\":\"alpine\",\"tags\":[\"3.23\"]}\n```\n\nIssue a delete for the `3.23` tag:\n```shell\ncurl -X DELETE \u0027http://localhost:5000/v2/alpine/manifests/3.23\u0027\n```\n\nObserve that the tag is now gone, despite deletes being disabled:\n```shell\ncurl \u0027http://localhost:5000/v2/alpine/tags/list\u0027\n{\"name\":\"alpine\",\"tags\":null}\n```\n\n### Impact\n\nThis is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.",
  "id": "GHSA-6pjf-3r9x-m592",
  "modified": "2026-07-21T13:45:53Z",
  "published": "2026-05-04T20:48:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/security/advisories/GHSA-6pjf-3r9x-m592"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41888"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/distribution/distribution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Distribution\u0027s tag deletion bypasses `storage.delete.enabled` configuration"
}

GHSA-6PV2-VJ8W-6FQG

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-03-11 18:31
VLAI
Details

A permissions issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.2. An app may be able to access a user’s Safari history.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-27T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A permissions issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.2. An app may be able to access a user\u2019s Safari history.",
  "id": "GHSA-6pv2-vj8w-6fqg",
  "modified": "2025-03-11T18:31:58Z",
  "published": "2023-07-06T19:24:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23510"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213605"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6PWG-GG6J-5CRM

Vulnerability from github – Published: 2024-03-26 21:30 – Updated: 2024-03-27 21:59
VLAI
Summary
Ignite Realtime Openfire privilege escalation vulnerability
Details

An issue in Ignite Realtime Openfire v.4.8.0 and before allows a remote attacker to escalate privileges via the ROOM_CACHE component.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.igniterealtime.openfire:xmppserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-27T21:59:25Z",
    "nvd_published_at": "2024-03-26T21:15:52Z",
    "severity": "HIGH"
  },
  "details": "An issue in Ignite Realtime Openfire v.4.8.0 and before allows a remote attacker to escalate privileges via the ROOM_CACHE component.",
  "id": "GHSA-6pwg-gg6j-5crm",
  "modified": "2024-03-27T21:59:25Z",
  "published": "2024-03-26T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25421"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/commit/d66bddd29dbf56aa9b822635619fa66cca6f2112"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/igniterealtime/Openfire"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/blob/main/xmppserver/src/main/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoomManager.java"
    },
    {
      "type": "WEB",
      "url": "https://www.hackthebox.com/blog/openfire-cves-explained-CVE-2024-25420-CVE-2024-25421"
    },
    {
      "type": "WEB",
      "url": "https://www.igniterealtime.org/projects/openfire"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Ignite Realtime Openfire privilege escalation vulnerability"
}

GHSA-6PX8-5R5J-C9F2

Vulnerability from github – Published: 2025-12-28 09:30 – Updated: 2025-12-28 09:30
VLAI
Details

A vulnerability was identified in JeecgBoot up to 3.9.0. This impacts the function getParameterMap of the file /sys/sysDepartPermission/list. The manipulation of the argument departId leads to improper authorization. The attack can be initiated remotely. The attack's complexity is rated as high. The exploitability is said to be difficult. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-15124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-28T07:15:53Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was identified in JeecgBoot up to 3.9.0. This impacts the function getParameterMap of the file /sys/sysDepartPermission/list. The manipulation of the argument departId leads to improper authorization. The attack can be initiated remotely. The attack\u0027s complexity is rated as high. The exploitability is said to be difficult. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-6px8-5r5j-c9f2",
  "modified": "2025-12-28T09:30:27Z",
  "published": "2025-12-28T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Hwwg/cve/issues/37"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.338502"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.338502"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.711776"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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-6Q4W-9X56-RMWQ

Vulnerability from github – Published: 2024-03-06 17:04 – Updated: 2024-03-21 18:29
VLAI
Summary
Deno arbitrary file descriptor close via `op_node_ipc_pipe()` leading to permission prompt bypass
Details

Summary

Use of raw file descriptors in op_node_ipc_pipe() leads to premature close of arbitrary file descriptors, allowing standard input to be re-opened as a different resource resulting in permission prompt bypass.

Details

Node child_process IPC relies on the JS side to pass the raw IPC file descriptor to op_node_ipc_pipe(), which returns a IpcJsonStreamResource ID associated with the file descriptor. On closing the resource, the raw file descriptor is closed together.

Although closing a file descriptor is seemingly a harmless task, this has been known to be exploitable: - With --allow-read and --allow-write permissions, one can open /dev/ptmx as stdin. This device happily accepts TTY ioctls and pipes anything written into it back to the reader. - This has been presented in a hacking competition (WACON 2023 Quals "dino jail"). - However, the precondition of this challenge was heavily contrived: fd 0 has manually been closed by FFI and setuid() was used to drop permissions and deny access to /proc since global write permissions are usually equivalent to arbitrary code execution (/proc/self/mem).

As this vulnerability conveniently allows us to close stdin (fd 0) without any FFI, we can open any resource that when read returns y, Y or A as its first character (runtimes/permissions/prompter.rs) to bypass the prompt.

There is a caveat however - all stdio/stdin/stderr streams are locked, after which clear_stdin() is called. This invokes libc::tcflush(0, libc::TCIFLUSH) which fails on a non-TTY file descriptor.

This can be exploited by widening the race window between clear_stdin() and the next stdin_lock.read_line(). Notably, the prompt message contains the requested resource name (path) which is filtered by strip_ansi_codes_and_ascii_control(). This is also concatenated by write!() to make a single buffer printed out to stderr. Thus, if we request a very long resource name, the window will widen allowing us to easily and stably race another Worker that closes fd 0 and opens a resource starting with an A\n within the race window.

Note that attacker does not need any permissions to exploit this bug to a full permission prompt bypass, as Cache API can be used to create and open files with controlled content without any permissions. Refer to the Impact section for more details.

PoC

Testing environment is Docker image denoland/deno:alpine-1.39.0@sha256:95064390f2c115673762bfc4fe15b1a7f81c859038b8c02b277ede7cd8a2ccbf.

Below PoC closes stdout (fd 1) and then prints two lines, one on stdout and one on stderr. Only the latter line is shown as stdout file descriptor is closed.

const ops = Deno[Deno.internal].core.ops;

// open fd 1 as ipc stream resource
const rid = ops.op_node_ipc_pipe(1);

// close resource & fd 1
Deno.close(rid);

// this should not be seen (stdout)
console.log('not seen');

// but this is seen (stderr)
console.error('seen');

Below is /proc/$(pgrep deno)/fd right after executing the last line of the above PoC. We see that fd 1 is indeed missing.

total 0
dr-x------ 2 root root 30 Dec 18 07:07 ./
dr-xr-xr-x 9 root root  0 Dec 18 07:07 ../
lrwx------ 1 root root 64 Dec 18 07:07 0 -> /dev/pts/0
l-wx------ 1 root root 64 Dec 18 07:07 10 -> 'pipe:[159305]'
lr-x------ 1 root root 64 Dec 18 07:07 11 -> 'pipe:[159306]'
l-wx------ 1 root root 64 Dec 18 07:07 12 -> 'pipe:[159306]'
lrwx------ 1 root root 64 Dec 18 07:07 13 -> /deno-dir/dep_analysis_cache_v1
l-wx------ 1 root root 64 Dec 18 07:07 14 -> 'pipe:[159305]'
l-wx------ 1 root root 64 Dec 18 07:07 15 -> 'pipe:[159306]'
lrwx------ 1 root root 64 Dec 18 07:07 16 -> /deno-dir/node_analysis_cache_v1
lrwx------ 1 root root 64 Dec 18 07:07 17 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 18 07:07 18 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 18 07:07 19 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 18 07:07 2 -> /dev/pts/0
lrwx------ 1 root root 64 Dec 18 07:07 20 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 21 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Dec 18 07:07 22 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 23 -> 'socket:[159302]'
lrwx------ 1 root root 64 Dec 18 07:07 24 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 25 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Dec 18 07:07 26 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 27 -> 'socket:[159302]'
lrwx------ 1 root root 64 Dec 18 07:07 28 -> 'socket:[159310]'
lrwx------ 1 root root 64 Dec 18 07:07 29 -> 'socket:[159308]'
lrwx------ 1 root root 64 Dec 18 07:07 3 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 30 -> 'socket:[159309]'
lrwx------ 1 root root 64 Dec 18 07:07 4 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Dec 18 07:07 5 -> 'anon_inode:[eventpoll]'
lrwx------ 1 root root 64 Dec 18 07:07 6 -> 'socket:[159302]'
lrwx------ 1 root root 64 Dec 18 07:07 7 -> 'socket:[159303]'
lrwx------ 1 root root 64 Dec 18 07:07 8 -> 'socket:[159302]'
lr-x------ 1 root root 64 Dec 18 07:07 9 -> 'pipe:[159305]'

Impact

Use of raw file descriptors in op_node_ipc_pipe() leads to premature close of arbitrary file descriptors. This allow standard input (fd 0) to be closed and re-opened for a different resource, which allows a silent permission prompt bypass. This is exploitable by an attacker controlling the code executed inside a Deno runtime to obtain arbitrary code execution on the host machine regardless of permissions.

This bug is known to be exploitable - there is a working exploit that achieves arbitrary code execution by bypassing prompts from zero permissions, additionally abusing the fact that Cache API lacks filesystem permission checks. The attack can be conducted silently as stderr can also be closed, suppressing all prompt outputs.

Note that Deno's security model is currently described as follows: - All runtime I/O is considered to be privileged and must always be guarded by a runtime permission. This includes filesystem access, network access, etc. - The only exception to this is runtime storage explosion attacks that are isolated to a part of the file system, caused by evaluated code (for example, caching big dependencies or no limits on runtime caches such as the Web Cache API).

Although it is ambiguous if the fundamental lack of file system permission checks on Web Cache API is a vulnerability or not, the reporter have not reported this as a vulnerability assuming that this is a known risk (or a feature).

Affected version of Deno is 1.39.0.

  • Introduced with commit 5a91a06
  • Fixed with commit 55fac9f
Severity
8.2 (High)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.39.0"
            },
            {
              "fixed": "1.39.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.39.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-27933"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-06T17:04:08Z",
    "nvd_published_at": "2024-03-21T02:52:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nUse of raw file descriptors in `op_node_ipc_pipe()` leads to premature close of arbitrary file descriptors, allowing standard input to be re-opened as a different resource resulting in permission prompt bypass.\n\n\n### Details\n\nNode child_process IPC relies on the JS side to pass the raw IPC file descriptor to `op_node_ipc_pipe()`, which returns a `IpcJsonStreamResource` ID associated with the file descriptor. On closing the resource, the raw file descriptor is closed together.\n\nAlthough closing a file descriptor is seemingly a harmless task, this has been known to be exploitable:\n- With `--allow-read` and `--allow-write` permissions, one can open `/dev/ptmx` as stdin. This device happily accepts TTY ioctls and pipes anything written into it back to the reader. \n  - This has been presented in a hacking competition (WACON 2023 Quals \"dino jail\").\n  - However, the precondition of this challenge was heavily contrived: fd 0 has manually been closed by FFI and `setuid()` was used to drop permissions and deny access to `/proc` since global write permissions are usually equivalent to arbitrary code execution (`/proc/self/mem`).\n\nAs this vulnerability conveniently allows us to close stdin (fd 0) without any FFI, we can open any resource that when read returns `y`, `Y` or `A` as its first character ([runtimes/permissions/prompter.rs](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L265)) to bypass the prompt.\n\nThere is a caveat however - all stdio/stdin/stderr streams are [locked](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L214), after which [`clear_stdin()`](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L220) is called. This invokes [`libc::tcflush(0, libc::TCIFLUSH)`](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L99) which fails on a non-TTY file descriptor.\n\nThis can be exploited by widening the race window between `clear_stdin()` and the next [`stdin_lock.read_line()`](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L256). Notably, the prompt message contains the requested resource name (path) which is filtered by [`strip_ansi_codes_and_ascii_control()`](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L225). This is also concatenated by [`write!()`](https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L241) to make a single buffer printed out to stderr. Thus, if we request a very long resource name, the window will widen allowing us to easily and stably race another Worker that closes fd 0 and opens a resource starting with an `A\\n` within the race window.\n\nNote that attacker does not need any permissions to exploit this bug to a full permission prompt bypass, as Cache API can be used to create and open files with controlled content without any permissions. Refer to the Impact section for more details.\n\n\n### PoC\n\nTesting environment is Docker image `denoland/deno:alpine-1.39.0@sha256:95064390f2c115673762bfc4fe15b1a7f81c859038b8c02b277ede7cd8a2ccbf`.\n\nBelow PoC closes stdout (fd 1) and then prints two lines, one on stdout and one on stderr. Only the latter line is shown as stdout file descriptor is closed.\n\n```js\nconst ops = Deno[Deno.internal].core.ops;\n\n// open fd 1 as ipc stream resource\nconst rid = ops.op_node_ipc_pipe(1);\n\n// close resource \u0026 fd 1\nDeno.close(rid);\n\n// this should not be seen (stdout)\nconsole.log(\u0027not seen\u0027);\n\n// but this is seen (stderr)\nconsole.error(\u0027seen\u0027);\n```\n\nBelow is `/proc/$(pgrep deno)/fd` right after executing the last line of the above PoC. We see that fd 1 is indeed missing.\n\n```text\ntotal 0\ndr-x------ 2 root root 30 Dec 18 07:07 ./\ndr-xr-xr-x 9 root root  0 Dec 18 07:07 ../\nlrwx------ 1 root root 64 Dec 18 07:07 0 -\u003e /dev/pts/0\nl-wx------ 1 root root 64 Dec 18 07:07 10 -\u003e \u0027pipe:[159305]\u0027\nlr-x------ 1 root root 64 Dec 18 07:07 11 -\u003e \u0027pipe:[159306]\u0027\nl-wx------ 1 root root 64 Dec 18 07:07 12 -\u003e \u0027pipe:[159306]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 13 -\u003e /deno-dir/dep_analysis_cache_v1\nl-wx------ 1 root root 64 Dec 18 07:07 14 -\u003e \u0027pipe:[159305]\u0027\nl-wx------ 1 root root 64 Dec 18 07:07 15 -\u003e \u0027pipe:[159306]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 16 -\u003e /deno-dir/node_analysis_cache_v1\nlrwx------ 1 root root 64 Dec 18 07:07 17 -\u003e /dev/pts/0\nlrwx------ 1 root root 64 Dec 18 07:07 18 -\u003e /dev/pts/0\nlrwx------ 1 root root 64 Dec 18 07:07 19 -\u003e /dev/pts/0\nlrwx------ 1 root root 64 Dec 18 07:07 2 -\u003e /dev/pts/0\nlrwx------ 1 root root 64 Dec 18 07:07 20 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 21 -\u003e \u0027anon_inode:[eventfd]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 22 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 23 -\u003e \u0027socket:[159302]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 24 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 25 -\u003e \u0027anon_inode:[eventfd]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 26 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 27 -\u003e \u0027socket:[159302]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 28 -\u003e \u0027socket:[159310]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 29 -\u003e \u0027socket:[159308]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 3 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 30 -\u003e \u0027socket:[159309]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 4 -\u003e \u0027anon_inode:[eventfd]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 5 -\u003e \u0027anon_inode:[eventpoll]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 6 -\u003e \u0027socket:[159302]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 7 -\u003e \u0027socket:[159303]\u0027\nlrwx------ 1 root root 64 Dec 18 07:07 8 -\u003e \u0027socket:[159302]\u0027\nlr-x------ 1 root root 64 Dec 18 07:07 9 -\u003e \u0027pipe:[159305]\u0027\n```\n\n\n### Impact\n\nUse of raw file descriptors in `op_node_ipc_pipe()` leads to premature close of arbitrary file descriptors. This allow standard input (fd 0) to be closed and re-opened for a different resource, which allows a silent permission prompt bypass. This is exploitable by an attacker controlling the code executed inside a Deno runtime to obtain arbitrary code execution on the host machine regardless of permissions.\n\nThis bug is **known to be exploitable** - there is a working exploit that achieves arbitrary code execution by bypassing prompts from zero permissions, additionally abusing the fact that Cache API lacks filesystem permission checks. The attack can be conducted silently as stderr can also be closed, suppressing all prompt outputs.\n\n\u003e Note that Deno\u0027s security model is currently described as follows:\n\u003e - All runtime I/O is considered to be privileged and must always be guarded by a runtime permission. This includes filesystem access, network access, etc.\n\u003e   - The only exception to this is runtime storage explosion attacks that are isolated to a part of the file system, caused by evaluated code (for example, caching big dependencies or no limits on runtime caches such as the Web Cache API).\n\u003e\n\u003e Although it is ambiguous if the fundamental lack of file system permission checks on Web Cache API is a vulnerability or not, the reporter have not reported this as a vulnerability assuming that this is a known risk (or a feature).\n\nAffected version of Deno is 1.39.0.\n\n- Introduced with commit 5a91a06\n- Fixed with commit 55fac9f\n",
  "id": "GHSA-6q4w-9x56-rmwq",
  "modified": "2024-03-21T18:29:15Z",
  "published": "2024-03-06T17:04:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-6q4w-9x56-rmwq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27933"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/55fac9f5ead6d30996400e8597c969b675c5a22b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/5a91a065b882215dde209baf626247e54c21a392"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L214"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L225"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L256"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L265"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/v1.39.0/runtime/permissions/prompter.rs#L99"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deno arbitrary file descriptor close via `op_node_ipc_pipe()` leading to permission prompt bypass"
}

GHSA-6Q5M-22MQ-Q2XV

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2023-08-07 20:57
VLAI
Summary
Istio Authorization Bypass Vulnerability
Details

Istio before 1.8.6 and 1.9.x before 1.9.5 has a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (%2F or %5C) could potentially bypass an Istio authorization policy when path based authorization rules are used.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "istio.io/istio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-11T16:53:41Z",
    "nvd_published_at": "2021-05-27T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Istio before 1.8.6 and 1.9.x before 1.9.5 has a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (%2F or %5C) could potentially bypass an Istio authorization policy when path based authorization rules are used.",
  "id": "GHSA-6q5m-22mq-q2xv",
  "modified": "2023-08-07T20:57:01Z",
  "published": "2022-05-24T19:03:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31920"
    },
    {
      "type": "WEB",
      "url": "https://istio.io/latest/news/security/istio-security-2021-005"
    }
  ],
  "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": "Istio Authorization Bypass Vulnerability",
  "withdrawn": "2023-08-07T20:57:01Z"
}

GHSA-6Q97-8V3G-RPXW

Vulnerability from github – Published: 2024-06-12 15:31 – Updated: 2025-02-13 18:41
VLAI
Summary
Apache Submarine Server Core Incorrect Authorization vulnerability
Details

Incorrect Authorization vulnerability in Apache Submarine Server Core.

This issue affects Apache Submarine Server Core: from 0.8.0.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.submarine:submarine-server-core"
      },
      "versions": [
        "0.8.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-submarine"
      },
      "versions": [
        "0.8.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-12T19:45:11Z",
    "nvd_published_at": "2024-06-12T15:15:52Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect Authorization vulnerability in Apache Submarine Server Core.\n\nThis issue affects Apache Submarine Server Core: from 0.8.0.\n\nAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.\n\nNOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
  "id": "GHSA-6q97-8v3g-rpxw",
  "modified": "2025-02-13T18:41:54Z",
  "published": "2024-06-12T15:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36265"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/submarine"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-submarine/PYSEC-2024-98.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/prckhhst19qxof064hsm8cccxtofvflz"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/06/12/3"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Submarine Server Core Incorrect Authorization vulnerability"
}

GHSA-6Q9G-3VFQ-Q2QJ

Vulnerability from github – Published: 2022-04-30 00:00 – Updated: 2022-05-24 22:20
VLAI
Summary
Improper Authentication in moodle
Details

Insufficient capability checks could allow users with the moodle/site:uploadusers capability to delete users, without having the necessary moodle/user:delete capability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.0"
            },
            {
              "fixed": "3.11.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.10.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9"
            },
            {
              "fixed": "3.9.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-24T22:20:25Z",
    "nvd_published_at": "2022-04-29T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient capability checks could allow users with the moodle/site:uploadusers capability to delete users, without having the necessary moodle/user:delete capability.",
  "id": "GHSA-6q9g-3vfq-q2qj",
  "modified": "2022-05-24T22:20:25Z",
  "published": "2022-04-30T00:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0985"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/addd4f894d8173ec8ff0ae2212d51a1977e7bcad"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2064117"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Authentication in moodle"
}

GHSA-6QC9-MQVW-JG7X

Vulnerability from github – Published: 2026-07-22 22:10 – Updated: 2026-07-22 22:10
VLAI
Summary
n8n: Credential Authorization Bypass via Expression in HTTP Request Node `genericAuthType`
Details

Impact

An authenticated member with edit access to a shared workflow could reference another user's credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing the target credential's identifier.

Patches

The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Exclude the HTTP Request node by adding n8n-nodes-base.httpRequest to the NODES_EXCLUDE environment variable, if the node is not required. - Audit credential sharing and workflow access to limit exposure of credential IDs to untrusted users.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.123.67"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.32.0"
            },
            {
              "fixed": "2.32.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-rc.0"
            },
            {
              "fixed": "2.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:10:41Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nAn authenticated member with edit access to a shared workflow could reference another user\u0027s credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing the target credential\u0027s identifier.\n\n## Patches\n\nThe issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\n\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict n8n instance access to fully trusted users only.\n- Exclude the HTTP Request node by adding `n8n-nodes-base.httpRequest` to the `NODES_EXCLUDE` environment variable, if the node is not required.\n- Audit credential sharing and workflow access to limit exposure of credential IDs to untrusted users.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-6qc9-mqvw-jg7x",
  "modified": "2026-07-22T22:10:41Z",
  "published": "2026-07-22T22:10:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-6qc9-mqvw-jg7x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/f69dfc6dd2178a14ea1624d2e1d403c2e755042f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@1.123.67"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.31.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.32.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n: Credential Authorization Bypass via Expression in HTTP Request Node `genericAuthType`"
}
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