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.

5501 vulnerabilities reference this CWE, most recent first.

GHSA-XQHM-WM3P-7WV9

Vulnerability from github – Published: 2024-08-13 12:30 – Updated: 2024-08-13 12:30
VLAI
Details

Incorrect Authorization vulnerability in WPWeb Docket (WooCommerce Collections / Wishlist / Watchlist) allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Docket (WooCommerce Collections / Wishlist / Watchlist): from n/a before 1.7.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T11:15:18Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization vulnerability in WPWeb Docket (WooCommerce Collections / Wishlist / Watchlist) allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Docket (WooCommerce Collections / Wishlist / Watchlist): from n/a before 1.7.0.",
  "id": "GHSA-xqhm-wm3p-7wv9",
  "modified": "2024-08-13T12:30:53Z",
  "published": "2024-08-13T12:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43131"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-collections/wordpress-docket-woocommerce-collections-wishlist-watchlist-plugin-1-6-6-unauthenticated-arbitrary-post-page-deletion-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQQX-3G3G-99GR

Vulnerability from github – Published: 2024-03-17 09:30 – Updated: 2024-03-17 09:30
VLAI
Details

A vulnerability was found in kishor-23 Food Waste Management System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/admin.php. The manipulation leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257056. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-2557"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-17T09:15:07Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in kishor-23 Food Waste Management System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/admin.php. The manipulation leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257056. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-xqqx-3g3g-99gr",
  "modified": "2024-03-17T09:30:45Z",
  "published": "2024-03-17T09:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2557"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vanitashtml/CVE-Dumps/blob/main/Execute%20After%20Redirect%20-%20Food%20Management%20System.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.257056"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.257056"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQVX-2258-GFP2

Vulnerability from github – Published: 2023-12-05 03:30 – Updated: 2023-12-05 03:30
VLAI
Details

Improper authorization verification vulnerability in AR Emoji prior to SMR Dec-2023 Release 1 allows attackers to read sandbox data of AR Emoji.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-42569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-05T03:15:17Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization verification vulnerability in AR Emoji prior to SMR Dec-2023 Release 1 allows attackers to read sandbox data of AR Emoji.",
  "id": "GHSA-xqvx-2258-gfp2",
  "modified": "2023-12-05T03:30:23Z",
  "published": "2023-12-05T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42569"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQWW-45WW-CW2P

Vulnerability from github – Published: 2024-11-04 15:31 – Updated: 2024-11-06 18:31
VLAI
Details

Akamai SIA (Secure Internet Access Enterprise) ThreatAvert, in SPS (Security and Personalization Services) before the latest 19.2.0 patch and Apps Portal before 19.2.0.3 or 19.2.0.20240814, has incorrect authorization controls for the Admin functionality on the ThreatAvert Policy page. An authenticated user can navigate directly to the /#app/intelligence/threatAvertPolicies URI and disable policy enforcement.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T14:15:14Z",
    "severity": "HIGH"
  },
  "details": "Akamai SIA (Secure Internet Access Enterprise) ThreatAvert, in SPS (Security and Personalization Services) before the latest 19.2.0 patch and Apps Portal before 19.2.0.3 or 19.2.0.20240814, has incorrect authorization controls for the Admin functionality on the ThreatAvert Policy page. An authenticated user can navigate directly to the /#app/intelligence/threatAvertPolicies URI and disable policy enforcement.",
  "id": "GHSA-xqww-45ww-cw2p",
  "modified": "2024-11-06T18:31:05Z",
  "published": "2024-11-04T15:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45164"
    },
    {
      "type": "WEB",
      "url": "https://notes.netbytesec.com/2024/11/cve-2024-45164-broken-access-control.html"
    },
    {
      "type": "WEB",
      "url": "https://www.akamai.com/global-services/support/vulnerability-reporting"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQXC-X6P3-W683

Vulnerability from github – Published: 2025-06-04 21:13 – Updated: 2025-07-02 18:29
VLAI
Summary
Deno run with --allow-read and --deny-read flags results in allowed
Details

Summary

deno run --allow-read --deny-read main.ts results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as --allow-* --deny-*.

Details

Caused by the fast exit logic in #22894.

PoC

Run the above command expecting no permissions to be passed.

Impact

This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.41.3"
            },
            {
              "fixed": "2.1.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "deno_runtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.150.0"
            },
            {
              "fixed": "0.212.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-04T21:13:44Z",
    "nvd_published_at": "2025-06-04T20:15:23Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`deno run --allow-read --deny-read main.ts` results in allowed, even though \u0027deny\u0027 should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.\n\n### Details\n\nCaused by the fast exit logic in #22894.\n\n### PoC\n\nRun the above command expecting no permissions to be passed.\n\n### Impact\n\nThis only affects a nonsensical combination of flags, so there shouldn\u0027t be a real impact on the userbase.",
  "id": "GHSA-xqxc-x6p3-w683",
  "modified": "2025-07-02T18:29:57Z",
  "published": "2025-06-04T21:13:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-xqxc-x6p3-w683"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/pull/22894"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/pull/29213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/2f0fae9d9071dcaf0a689bc7097584b1b9ebc8db"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/9d665572d3cd39f997e29e6daac7c1102fc5c04f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/ef315b56c26c9ef5f25284a5100d2ed525a148cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Deno run with --allow-read and --deny-read flags results in allowed"
}

GHSA-XQXV-4JC2-X56X

Vulnerability from github – Published: 2026-06-18 13:52 – Updated: 2026-06-18 13:52
VLAI
Summary
ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)
Details

Summary

Zitadel's OAuth2 / OIDC CodeExchange and RefreshToken implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.

Impact

This flaw creates potential vulnerabilities in two main authentication phases, provided specific external preconditions are met:

  • Authorization Code Injection: An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (ClientB) registered on the same Zitadel instance. Zitadel will authenticate ClientB and issue tokens for the victim user without verifying the client binding.
  • Refresh Token Cross-Use: An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token's format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.
  • Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.

Scope and Mitigation Factors:

  • External Preconditions: It is critical to note that exploiting either vector requires a pre-existing vulnerability or data leak within the target application environment to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.
  • Multi-tenant risk: On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant's clients if they are successfully intercepted.
  • PKCE protection: Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the code_verifier. However, PKCE does not protect against refresh token cross-use.

Affected Versions

Systems running one of the following versions are affected:

  • 4.x: 4.0.0 through 4.15.1 (including RC versions)
  • 3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the CodeExchange and RefreshToken grants.

Please upgrade to one of the following secure versions:

Workarounds

The recommended solution is to upgrade to a patched version.

To reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of PKCE for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to kodareef5, Shubham Raj / Causal Security, and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.80.0-v2.20.0.20260616131956-0973b074b488"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55672"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:52:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nZitadel\u0027s OAuth2 / OIDC `CodeExchange` and `RefreshToken` implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.\n\n### Impact\n\nThis flaw creates potential vulnerabilities in two main authentication phases, **provided specific external preconditions are met**:\n\n* **Authorization Code Injection:** An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (`ClientB`) registered on the same Zitadel instance. Zitadel will authenticate `ClientB` and issue tokens for the victim user without verifying the client binding.\n* **Refresh Token Cross-Use:** An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token\u0027s format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.\n* Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.\n\n**Scope and Mitigation Factors:**\n\n* **External Preconditions:** It is critical to note that exploiting either vector **requires a pre-existing vulnerability or data leak within the target application environment** to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.\n* **Multi-tenant risk:** On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant\u0027s clients if they are successfully intercepted.\n* **PKCE protection:** Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the `code_verifier`. However, PKCE does not protect against refresh token cross-use.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x:** `4.0.0` through `4.15.1` (including RC versions)\n* **3.x:** `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the `CodeExchange` and `RefreshToken` grants.\n\nPlease upgrade to one of the following secure versions:\n\n- **4.x**: Upgrade to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n- **3.x**: Update to $\\ge$[3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version.\n\nTo reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of **PKCE** for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to [kodareef5](https://github.com/kodareef5), Shubham Raj / Causal Security, and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.",
  "id": "GHSA-xqxv-4jc2-x56x",
  "modified": "2026-06-18T13:52:18Z",
  "published": "2026-06-18T13:52:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-xqxv-4jc2-x56x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/0973b074b48816757c47fe732b06d2488d3d284c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v3.4.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v4.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": " ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)"
}

GHSA-XR38-W74Q-R8JV

Vulnerability from github – Published: 2021-12-06 23:57 – Updated: 2024-09-23 16:02
VLAI
Summary
Permissions not properly checked in Invenio-Drafts-Resources
Details

Impact

Invenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. cannot change a record from restricted to public.

Details

The service's publish() method contains the following permission check:

def publish(..):
    self.require_permission(identity, "publish")

However, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.

def publish(..):
    self.require_permission(identity, "publish", record=record)

The bug is activated in Invenio-RDM-Records which has a need generator called RecordOwners(), which when no record is passed in defaults to allow any authenticated user:

class RecordOwners(Generator):
    def needs(self, record=None, **kwargs):
        if record is None:
            return [authenticated_user]
    # ...

Patches

The problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.

You can verify the version installed of Invenio-Drafts-Resources via PIP:

cd ~/src/my-site
pipenv run pip freeze | grep invenio-drafts-resources

References

For more information

If you have any questions or comments about this advisory: * Chat with us on Discord: https://discord.gg/8qatqBC

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-drafts-resources"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-app-rdm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-rdm-records"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.32.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-drafts-resources"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.0"
            },
            {
              "fixed": "0.14.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-rdm-records"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.33.0"
            },
            {
              "fixed": "0.33.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-app-rdm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0.dev0"
            },
            {
              "fixed": "7.0.0.dev5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-12-06T22:15:02Z",
    "nvd_published_at": "2021-12-06T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nInvenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. *cannot* change a record from restricted to public.\n\n### Details\n\nThe service\u0027s ``publish()`` method contains the following permission check:\n\n```python\ndef publish(..):\n    self.require_permission(identity, \"publish\")\n```\nHowever, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.\n\n```python\ndef publish(..):\n    self.require_permission(identity, \"publish\", record=record)\n```\nThe bug is activated in Invenio-RDM-Records which has a need generator called ``RecordOwners()``, which when no record is passed in defaults to allow any authenticated user:\n\n```python\nclass RecordOwners(Generator):\n    def needs(self, record=None, **kwargs):\n        if record is None:\n            return [authenticated_user]\n    # ...\n```\n\n### Patches\n\nThe problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.\n\nYou can verify the version installed of Invenio-Drafts-Resources via PIP:\n\n```console\ncd ~/src/my-site\npipenv run pip freeze | grep invenio-drafts-resources\n```\n\n### References\n\n- [Security policy](https://invenio.readthedocs.io/en/latest/community/security-policy.html)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Chat with us on Discord: https://discord.gg/8qatqBC\n\n",
  "id": "GHSA-xr38-w74q-r8jv",
  "modified": "2024-09-23T16:02:05Z",
  "published": "2021-12-06T23:57:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/inveniosoftware/invenio-drafts-resources/security/advisories/GHSA-xr38-w74q-r8jv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43781"
    },
    {
      "type": "WEB",
      "url": "https://github.com/inveniosoftware/invenio-drafts-resources/commit/039b0cff1ad4b952000f4d8c3a93f347108b6626"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-app-rdm/PYSEC-2021-837.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-drafts-resources/PYSEC-2021-836.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Permissions not properly checked in Invenio-Drafts-Resources"
}

GHSA-XR44-7HQV-MRGR

Vulnerability from github – Published: 2025-12-04 21:31 – Updated: 2025-12-04 21:31
VLAI
Details

A security vulnerability has been detected in macrozheng mall-swarm up to 1.0.3. Affected is the function delete of the file /member/readHistory/delete. Such manipulation of the argument ids leads to improper authorization. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-04T19:16:03Z",
    "severity": "MODERATE"
  },
  "details": "A security vulnerability has been detected in macrozheng mall-swarm up to 1.0.3. Affected is the function delete of the file /member/readHistory/delete. Such manipulation of the argument ids leads to improper authorization. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-xr44-7hqv-mrgr",
  "modified": "2025-12-04T21:31:04Z",
  "published": "2025-12-04T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14016"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Hwwg/cve/issues/17"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.334257"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.334257"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.694797"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-XR4F-MJXJ-W6W5

Vulnerability from github – Published: 2026-07-02 16:55 – Updated: 2026-07-02 16:55
VLAI
Summary
OpenClaw: Non-owner chat senders could issue device-pairing bootstrap codes
Details

Summary

The bundled device-pair plugin exposed /pair on normal chat command surfaces. In affected releases, authorized non-owner chat senders could issue device-pairing bootstrap codes without having owner, admin, or pairing scope.

This issue does not affect unauthenticated users. The caller must already be allowed to send commands to the agent through a configured chat channel.

Affected configurations

This affects deployments where the bundled device-pair plugin is enabled and a non-owner sender is authorized to use normal chat commands, such as in a configured Telegram, Discord, or Slack agent.

Impact

A non-owner authorized sender could create a setup code and use it before expiry to enroll a device with operator/node capabilities. That device would then retain persistent credentials until removed.

Patched Versions

The first stable patched version is 2026.5.4.

Mitigations

Upgrade to openclaw@2026.5.4 or later. Review paired devices and remove any unexpected entries. In shared chat channels, keep command access limited to users who should be allowed to manage device pairing.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T16:55:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe bundled device-pair plugin exposed `/pair` on normal chat command surfaces. In affected releases, authorized non-owner chat senders could issue device-pairing bootstrap codes without having owner, admin, or pairing scope.\n\nThis issue does not affect unauthenticated users. The caller must already be allowed to send commands to the agent through a configured chat channel.\n\n### Affected configurations\n\nThis affects deployments where the bundled device-pair plugin is enabled and a non-owner sender is authorized to use normal chat commands, such as in a configured Telegram, Discord, or Slack agent.\n\n### Impact\n\nA non-owner authorized sender could create a setup code and use it before expiry to enroll a device with operator/node capabilities. That device would then retain persistent credentials until removed.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.4`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.4` or later. Review paired devices and remove any unexpected entries. In shared chat channels, keep command access limited to users who should be allowed to manage device pairing.",
  "id": "GHSA-xr4f-mjxj-w6w5",
  "modified": "2026-07-02T16:55:09Z",
  "published": "2026-07-02T16:55:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xr4f-mjxj-w6w5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Non-owner chat senders could issue device-pairing bootstrap codes"
}

GHSA-XR55-5XVM-9RW7

Vulnerability from github – Published: 2025-12-10 15:31 – Updated: 2025-12-10 18:30
VLAI
Details

Unauthenticated Telnet enablement via cstecgi.cgi (auth bypass) leading to unauthenticated root login with a blank password on factory/reset X5000R V9.1.0u.6369_B20230113 (arbitrary command execution). Earlier versions that share the same implementation, may also be affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-13184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-10T13:16:02Z",
    "severity": "CRITICAL"
  },
  "details": "Unauthenticated Telnet enablement via cstecgi.cgi (auth bypass) leading to unauthenticated root login with a blank password on factory/reset X5000R V9.1.0u.6369_B20230113 (arbitrary command execution). Earlier versions that share the same implementation, may also be affected.",
  "id": "GHSA-xr55-5xvm-9rw7",
  "modified": "2025-12-10T18:30:25Z",
  "published": "2025-12-10T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13184"
    },
    {
      "type": "WEB",
      "url": "https://hackingbydoing.wixsite.com/hackingbydoing/post/totolink-x5000r-ax1800-router-authentication-bypass"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/821724"
    }
  ],
  "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"
    }
  ]
}

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.