| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Fider is a feedback portal for feature requests and suggestions. Prior to version 0.36.0, in multi-tenant mode (HOST_MODE=multi), an attacker can use an email verification key issued by Tenant A to authenticate as the same email address on Tenant B. This completely bypasses tenant isolation and allows unauthorized account takeover across tenants. Single-host deployments (HOST_MODE=single, the default) are NOT affected. This issue has been patched in version 0.36.0. |
| OpsTree REMS through 1.0.0 contains an improper authorization vulnerability that allows authenticated users to set an incident's reporter to another user by supplying a client-controlled reporter field. Attackers can send crafted POST /api/v1/incidents or PATCH /api/v1/incidents/{id}/status requests to falsify incident attribution and corrupt the accountability audit trail. |
| Probo is a self-hostable governance, risk, and compliance (GRC) platform built for engineering and security teams. Prior to version 0.224.0, the public Trust Center GraphQL API exposes Query.node(id:) with @authentication(required: OPTIONAL) — an unauthenticated internet visitor to any published trust center can call it. Six of its type branches — Organization, Framework, Audit, ThirdParty (subprocessor), TrustCenter, and TrustCenterReference — resolve the object with a tenant scope derived from the client-supplied GID itself (coredata.NewScopeFromObjectID(id)) and load it with a bare Get(scope, id) that performs no comparison to the current trust center's OrganizationID and no showOnTrustCenter/visibility check. (The Document and File branches, by contrast, correctly pass trustCenter.OrganizationID and check visibility). This issue has been patched in version 0.224.0. |
| Probo is a self-hostable governance, risk, and compliance (GRC) platform built for engineering and security teams. Prior to version 0.224.0, the public Trust Center GraphQL API exposes acceptElectronicSignature and recordSigningEvent, both gated only by @authentication(required: PRESENT) @sessionOnly — any self-provisioned trust center identity can call them. The underlying esign.Service.AcceptSignature and esign.Service.recordEvent build the tenant scope from the client-supplied signatureId GID (coredata.NewScopeFromObjectID(req.SignatureID)) and load the signature by that GID. At no point do they verify that the signature belongs to the caller or that the caller's email matches the signature's SignerEmail. As a result, any authenticated trust-center visitor who possesses another visitor's signature GID can: (1) complete that visitor's NDA signature — overwriting signer name/IP/UA with attacker data and setting status to Accepted, which triggers the sealing worker to generate a completion certificate; (2) inject arbitrary audit-trail events into any signature's log. Both attacks defeat the non-repudiation and integrity guarantees of the e-signature system. This issue has been patched in version 0.224.0. |
| Probo is a self-hostable governance, risk, and compliance (GRC) platform built for engineering and security teams. Prior to version 0.223.1, Probo's console GraphQL API is a multi-tenant GRC platform where all data is scoped to an organization. A Finding can reference a Risk via finding.riskId. That reference is stored without validating that the risk belongs to the caller's organization, and the Finding.risk field resolver authorizes the finding (caller's org) instead of the risk, then loads the risk with a tenant scope derived from the risk's own global ID. As a result, an authenticated member of organization A can attach an arbitrary organization B risk GID to a finding they own and then read organization B's Risk (name, description, treatment, category, severity, owner) — with no membership in B. The stored cross-tenant reference also blocks B from deleting its own risk (ON DELETE RESTRICT), a cross-tenant integrity/DoS. This issue has been patched in version 0.223.1. |
| An authorization bypass in website-index.php in Revive Adserver 6.0.8 and earlier allows an authenticated manager restricted to one agency to view another agency's website listing by changing the agencyid request parameter. Disclosed information includes website names, identifiers and timestamps. Detailed website pages continue to enforce ownership checks. The issue is fixed in Revive Adserver 6.0.9 by obtaining the agency identifier from the authenticated account rather than the request. |
| An authorization bypass in campaign-zone linking in Revive Adserver 6.0.8 and earlier allows an authenticated manager, or a trafficker with zone-linking permissions, to associate another agency's campaign with their own zone. Campaign ownership checks are missing from the bulk-linking and single-link operations in zone-include.php and the XML-RPC campaign-linking method. Although agency filtering prevents foreign banners from being linked, the unauthorized association can expose the foreign campaign's name, type and identifier in the linked-campaign listing. The issue is fixed in Revive Adserver 6.0.9 by validating campaign ownership in the affected operations. |
| An authorization bypass in Revive Adserver 6.0.0 through 6.0.8 allows an authenticated manager restricted to one agency to access or modify resources belonging to another agency. Global input registration gives GET parameters precedence over POST parameters, while submitted administration forms use POST values. By supplying authorized object identifiers in the query string and different identifiers in the POST body, an attacker can cause permission checks and subsequent operations to target different objects. This permits unauthorized cross-agency changes, campaign ownership reassignment and disclosure of campaign and banner data. The regression was introduced in commit 156dee7bc3283c128f35e5a31bb305054cc8de1b and is fixed in Revive Adserver 6.0.9 by restoring POST precedence in global input registration. |
| An authorization bypass in channel-edit.php in Revive Adserver 6.0.8 and earlier allows an authenticated manager to create a delivery rule set belonging to another agency by changing the submitted agencyid parameter. The server trusts the submitted agency identifier when inserting the new rule set, allowing unauthorized creation of objects in another agency's account. The issue is fixed in Revive Adserver 6.0.9 by obtaining the agency identifier from the authenticated account rather than submitted form data and removing the agency identifier from the form's hidden fields. |
| SuperTokens Core is an open source authentication server. From 6.0.0 until 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, Multitenancy.checkPermissionsForCreateOrUpdate in src/main/java/io/supertokens/multitenancy/Multitenancy.java does not adequately authorize updates to a parent connection URI domain or the base tenant. In a licensed multi-tenant deployment with multiple applications under one non-default connection URI domain and separate api_keys, an attacker holding one application's valid API key can update the parent domain because the CUD-target branch checks the domain without requiring the source application and tenant to be public. Because api_keys is not protected, the attacker can replace the parent key and then sibling application keys, read or modify sibling users, obtain sessions as those users, establish persistence through a sibling dashboard user, and lock out the sibling application's own key. In the advisory's v2 create or update handlers, omitting the optional identifier produces a base-tenant target that skips the permission branches and enterprise-feature gate, allowing changes to firstFactors, required secondary factors, and recipe-enabled flags that affect login integrity and availability. The base-target variant still rejects coreConfig and does not establish key theft. This issue is fixed in versions 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1. |
| The Royal Addons for Elementor WordPress plugin before 1.7.1066 does not perform any capability or ownership check (relying only on a publicly-scrapeable nonce) before writing like-count and visitor-tracking post meta keyed on an arbitrary post ID, allowing unauthenticated users to modify that metadata on any post, including private and draft posts. |
| The Booking for Appointments and Events Calendar WordPress plugin before 9.8 does not verify that an authenticated employee (provider) owns the provider account being updated, allowing any employee with an Employee Panel login to overwrite another employee's cabinet password and take over their account. |
| The Project Manager WordPress plugin before 4.0.7 does not restrict several of its REST API routes to the projects a user belongs to, allowing any authenticated user, such as a subscriber, to read other projects' task content and user email addresses and to modify other projects' task boards. |
| The Project Manager WordPress plugin before 4.0.7 does not check that the user whose activity is being requested is the one making the request in one of its REST API routes, allowing any authenticated user, such as a subscriber, to read any other user's activity history along with their email address and the details of projects they have no access to. |
| The Document Embedder WordPress plugin before 2.3.1 does not check a document's status before issuing a download token and streaming the file, allowing unauthenticated attackers to download arbitrary Document Embedder WordPress plugin before 2.3.1 documents, including private and draft ones, by enumerating IDs. |
| The Mobile App for WooCommerce: ShopApper Mobile App Builder Service for WooCommerce WordPress plugin through 0.4.62 does not verify that the requesting user owns the customer profile being queried through one of its REST endpoints, allowing any authenticated user (e.g. a customer/subscriber) to retrieve other users' personal data, including their email address, name, and roles. |
| The Notifima WordPress plugin before 3.1.4 does not verify that the caller owns the subscription being modified on one of its REST endpoints in all versions up to, and including, 3.1.3, allowing authenticated attackers with Subscriber-level access to unsubscribe arbitrary customers from product stock-alert notifications. |
| The Quiz and Survey Master (QSM) WordPress plugin before 11.2.4 does not check authorisation when returning question bank entries through one of its REST API routes, allowing users with a role as low as Contributor to read the questions, hints and correct answer keys of quizzes belonging to other users. |
| The MotoPress Appointment Booking WordPress plugin before 2.4.8 does not perform an authorization or ownership check when handling a user-supplied booking identifier on an unauthenticated endpoint, allowing unauthenticated attackers to permanently delete other users' reservations. This is an incomplete fix of CVE-2026-9180: the deletion remains reachable on sites using payment confirmation, confirmed through version 2.4.7. |
| The WC Vendors WordPress plugin before 2.7.2.1 does not verify ownership or the object type of user-supplied IDs when saving product variations, allowing authenticated users with the vendor role to modify product variations belonging to other vendors, and to change the status and title of arbitrary posts, via IDOR. |
