| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Affected versions of MISP allow a collection element to be created from a bare UUID without consistently checking whether the acting user is allowed to access the referenced object.
The commit explains that collection elements themselves only store UUIDs, while the collection view later resolves those UUIDs into their underlying objects. Before this fix, the generic add() path could therefore persist a UUID for an Event or Galaxy Cluster that the caller could not normally read. The patch explicitly notes that this made collections a way to reference another organisation’s private data and had caused disclosure of organisation-only events in the beta collection view.
The fix centralizes authorization in __assertCanUseElements(). Event UUIDs are validated through Event::fetchSimpleEvent() under the current user’s ACL, while Galaxy Cluster UUIDs are checked through GalaxyCluster::fetchGalaxyClusters(). The check is applied both to the CRUD add() path and to addElementToCollection().
Version affected: ≤2.5.45 |
| Affected versions of MISP fail to authorize a submitted sharing group in a specific event-edit path.
The vulnerable logic checked whether the acting user could use a sharing_group_id only when the request explicitly supplied distribution = 4. If the attacker instead omitted distribution but supplied a different sharing_group_id, that authorization branch was skipped. Later, MISP’s field-recovery logic restored the existing event distribution from storage. For events already configured with sharing-group distribution, the unauthorized sharing-group ID could therefore be saved.
The fix adds authorization checks in both the controller and Event::_edit() whenever a non-empty sharing_group_id is supplied without distribution. The model now calls SharingGroup::checkIfAuthorised() before persisting the change.
Version affected: ≤2.5.45 |
| A deployment mode intended to expose only read access to a bundled packet-analysis component's interface denies a list of write-capable routes by pattern, but the pattern omits routes that modify tags attached to stored session records, and the proxy configuration otherwise permits the request method those routes use. This allows an authenticated user on a deployment intended to be read-only to add or remove tags on stored session records. |
| A deployment mode intended to expose only read access to stored data proxies a set of application programming interface routes without restricting which request methods are allowed. One such route accepts a request that creates or overwrites a stored record, including an attacker-chosen identifier, using the application's own elevated backend credentials. This allows an authenticated user on a deployment intended to be read-only to forge or overwrite stored records that should not be modifiable in that deployment mode. |
| PraisonAI is a multi-agent teams system. Prior to 4.6.58, praisonai.jobs.server.create_app mounts praisonai.jobs.router.create_router under /api/v1/runs without authentication or per-job authorization. Network clients can submit attacker-controlled prompts and agent configuration, list and read jobs, stream results, and cancel or delete other jobs, exposing service credentials and connected tool capabilities to unauthorized agent execution. This vulnerability is fixed in 4.6.58. |
| Alchemy is an open source content management system engine written in Ruby on Rails. Prior to 7.4.15, 8.0.15, 8.1.14, and 8.2.6, the unauthenticated GET /api/pages/nested endpoint implemented by Api::PagesController#nested in app/controllers/alchemy/api/pages_controller.rb returns an unfiltered page tree because it performs no authorization and does not scope descendants by the caller's ability. Anonymous callers can retrieve restricted and unpublished page metadata that the sibling show action denies. When elements=true is supplied, PageTreeSerializer also returns element and ingredient content from restricted pages because PageTreePreloader and the serializer do not apply an ability check to those records. This issue is fixed in versions 7.4.15, 8.0.15, 8.1.14, and 8.2.6. |
| backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.15 and 7.0.47, HasMany and MorphMany handling through attachManyRelation during CRUD create and update operations accepts submitted child primary keys without consistently restricting updates to records belonging to the current parent or permitted by the developer-defined relation scope. An authenticated low-privilege administrator who can edit a parent form exposing an affected multiple-relation field can cause unrelated child records to be reassigned, detached, nulled, or deleted across ownership or tenant boundaries. Exploitation requires related records that should not be attachable or removable by that administrator and the absence of additional application-level authorization around submitted relation values. This issue is distinct from earlier direct main-entity CRUD scoping fixes because it affects secondary models modified by relationship-saving logic. This issue is fixed in versions 6.8.15 and 7.0.47. |
| SPIP before version 4.4.18 contains a missing authorization vulnerability in sensitive actions under ecrire/action/ that allows unauthenticated attackers to invoke privileged actions by supplying only a valid CSRF nonce without any server-side permission check. Attackers can bypass template-level authorization guards through direct HTTP requests to invoke actions such as editer_auteur, enabling arbitrary account password rewrites including administrator accounts and resulting in full account takeover. |
| Yao through v1.0.0-rc22 authenticates but fails to authorize the GET /user/teams/:id endpoint, allowing any logged-in user to read full team records. Attackers can supply a known team identifier to retrieve sensitive team data including name, description, owner information, and settings without membership verification. |
| Really Simple Security plugin for WordPress before 9.8.2 contains a missing authorization check vulnerability that allows authenticated low-privileged attackers to bypass enforced two-factor authentication indefinitely by exploiting an unguarded code path in the profile-page update handler. Attackers can submit a crafted POST request without the two-factor-authentication field to skip nonce verification and trigger delete_two_fa_meta(), which resets the grace period anchor timestamp on every login cycle, causing mandatory 2FA enforcement to be deferred indefinitely. |
| In Concrete CMS 9.2.0 through 9.5.2, the REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) did not enforce page-property, page-template, or page-type authorization. A user granted only content-editing rights on a page could therefore alter its properties, template, and type through the API, and could set the header_extra_content attribute, which is rendered unescaped into the head element of every page, to persist JavaScript that executed in the browser of every visitor, including higher-privileged reviewers who approve the page version. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.2 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, visionOS 27. A malicious app may be able to gain root privileges. |
| Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, an HTTPRoute can use an extension-managed custom backendRef to reference a backend resource in another namespace without a matching Gateway API ReferenceGrant in the target namespace. The custom-backend branch in internal/gatewayapi/route.go omits validateBackendNamespace, allowing the route-owning namespace to bind to and use the resource without the backend namespace owner's consent and violating the Gateway API cross-namespace authorization model. This issue is fixed in versions 1.7.4 and 1.8.1. |
| An authenticated supplicant on an adjacent network may bypass intended network authorization policy and send unrestricted traffic during a brief window (milliseconds to seconds) between the completion of the authentication phase and the full enforcement of its assigned ACL. |
| In Akaunting versions <= 3.1.21, low‑privileged authenticated users can modify their own account to assign themselves the admin role ID, granting full administrator privileges. This vulnerability is caused by a flaw in the `UpdateUser` job, which processes user-supplied role assignments via an unconditional `roles()->sync()` call without verifying whether the caller is authorized to manage roles. Users only require the default `update-auth-profile` permission to access the self-update path and assign themselves as admins. The API endpoints are properly permission‑gated and are not affected by this issue. This vulnerability has been remediated in v3.2.0, commit 80ef6d3b154a. |
| IBM WebSphere Application Server 9.0, and 8.5 could allow a remote attacker to bypass authentication and obtain sensitive information by sending a crafted unauthenticated request. |
| IBM WebSphere Application Server 9.0, and 8.5 could allow a remote attacker to bypass authentication on an admin console servlet. |
| IBM Cloud Pak for Business Automation could allow a remote attacker to bypass authorization and invoke restricted endpoints due to improper validation of HTTP headers. |
| ThemeAtelier Domain For Sale plugin for WordPress before 3.5.2 contains a missing authorization vulnerability in its REST API endpoints that allows unauthenticated attackers to access and manipulate protected resources. Attackers can retrieve stored offer records, delete arbitrary offers by numeric identifier, and access dashboard statistics to disclose bidder contact information, offer details, messages, verification tokens, and business data. |
| Missing authorization vulnerability has been discovered in 2Checkout payment gateway of WHMCS from 8.13.0 before 8.13.7, from 9.0.0 before 9.0.8, all other EOL versions from 4.5.0. The vulnerability allows an unauthenticated user to get WHMCS customer's data via 2Checkout payment gateway's endpoint under specific conditions. |
