Insecure direct object reference (IDOR) vulnerability in Publications in Liferay Portal 7.4.1 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 allows remote authenticated attackers to view publication comments via the _com_liferay_change_tracking_web_portlet_PublicationsPortlet_value parameter. Publications comments in Liferay Portal 7.4.1 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 does not properly check user permissions, which allows remote authenticated users to edit publication comments via crafted URLs.

Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions does not properly restrict membership of a child site when the "Limit membership to members of the parent site" option is enabled, which allows remote authenticated users to add users who are not a member of the parent site to a child site. The added user may obtain permission to perform unauthorized actions in the child site.

Improper Authentication in Liferay Portal 7.4.0 through 7.4.3.132, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to send malicious data to the Liferay Portal 7.4.0 through 7.4.3.132, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions that will treat it as trusted data via unauthenticated cluster messages.

In Liferay Portal 7.1.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions, the default membership type of a newly created site is “Open” which allows any registered users to become a member of the site. A remote attacker with site membership can potentially view, add or edit content on the site.

Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA through update 35, and older unsupported versions does not limit access to APIs before a user has changed their initial password, which allows remote users to access and edit content via the API.

In Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions the `doAsUserId` URL parameter may get leaked when creating linked content using the WYSIWYG editor and while impersonating a user. This may allow remote authenticated users to impersonate a user after accessing the linked content.

Privilege escalation vulnerability in Liferay Portal 7.0.3 through 7.3.4, and Liferay DXP 7.1 before fix pack 20, and 7.2 before fix pack 9 allows remote authenticated users with permission to update/edit users to take over a company administrator user account by editing the company administrator user.

Blogs in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions does not check permission of images in a blog entry, which allows remote attackers to view the images in a blog entry via crafted URL.

JSON Web Services in Liferay Portal 7.4.0 through 7.4.3.119, and Liferay DXP 2024.Q1.1 through 2024.Q1.9, 7.4 GA through update 92 published to OSGi are registered and invoked directly as classes which allows Service Access Policies get executed.

Batch Engine in Liferay Portal 7.4.0 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.7, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 does not properly check permission with import and export tasks, which allows remote authenticated users to access the exported data via the REST APIs.

In Liferay Portal 7.4.3.27 through 7.4.3.42, and Liferay DXP 2024.Q1.1 through 2024.Q1.20, 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10, 7.4 update 27 through update 42 (Liferay PaaS, and Liferay Self-Hosted), the Objects module does not restrict the use of Groovy scripts in Object actions for Admin Users. This allows remote authenticated admin users with the Instance Administrator role to execute arbitrary Groovy scripts (i.e., remote code execution) through Object actions. In contrast, in Liferay DXP (Liferay SaaS), the use of Groovy in Object actions is not allowed due to the high security risks it poses. Starting from Liferay DXP 2024.Q2 and later, a new feature has been introduced in Instance Settings that allows administrators to configure whether Groovy scripts are allowed in their instances.

The workflow component in Liferay Portal 7.3.2 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, 7.4 GA through update 92 and 7.3 GA through update 36 does not properly check user permissions before updating a workflow definition, which allows remote authenticated users to modify workflow definitions and execute arbitrary code (RCE) via the headless API.

Improper Access Control vulnerability in Liferay Portal 7.4.0 through 7.4.3.124, and Liferay DXP 2024.Q2.0 through 2024.Q2.8, 2024.Q1.1 through 2024.Q1.12 and 7.4 GA through update 92 allows guest users to obtain object entries information via the API Builder.

Liferay Portal 7.2.0 through 7.4.3.4, and older unsupported versions, and Liferay DXP 7.4.13, 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions does not properly check user permissions, which allows remote authenticated users with the VIEW user permission to edit their own permission via the User and Organizations section of the Control Panel.

OpenSupports exposes an endpoint that allows the list of 'supervised users' for any account to be edited, but it does not validate whether the actor is the owner of that list. A Level 1 staff member can modify the supervision relationship of a third party (the target user), who can then view the tickets of the added 'supervised' users. This breaks the authorization model and filters the content of other users' tickets.This issue affects OpenSupports: 4.11.0.

A flaw was found in Moodle. An authorization logic flaw, specifically due to incomplete role checks during the badge awarding process, allowed badges to be granted without proper verification. This could enable unauthorized users to obtain badges they are not entitled to, potentially leading to privilege escalation or unauthorized access to certain features.

Under certain conditions, an authenticated user request may execute with stale privileges following an intentional change by an authorized administrator. This issue affects MongoDB Server v5.0 version prior to 5.0.31, MongoDB Server v6.0 version prior to 6.0.24, MongoDB Server v7.0 version prior to 7.0.21 and MongoDB Server v8.0 version prior to 8.0.5.

Frappe Learning is a learning system that helps users structure their content. Starting in version 2.0.0 and prior to version 2.41.0, when admins revoked a role from the user, the effect was not immediate because of caching. The issue has been fixed in version 2.41.0 by ensuring the cache is cleared after roles are updated.

The WebChannel API, which is used to transport various information across processes, did not check the sending principal but rather accepted the principal being sent. This could have led to privilege escalation attacks. This vulnerability was fixed in Firefox 134, Firefox ESR 128.6, Thunderbird 134, and Thunderbird 128.6.

1Password Connect server before 1.2 is missing validation checks, permitting users to create Secrets Automation access tokens that can be used to perform privilege escalation. Malicious users authorized to create Secrets Automation access tokens can create tokens that have access beyond what the user is authorized to access, but limited to the existing authorizations of the Secret Automation the token is created in.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. It improperly handled account blocks for certain automatically created MediaWiki user accounts, thus allowing nefarious users to remain unblocked.

Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. Prior to version 0.48.0, Omni Wireguard SideroLink has the potential to escape. Omni and each Talos machine establish a peer-to-peer (P2P) SideroLink connection using WireGuard to mutually authenticate and authorize access. The WireGuard interface on Omni is configured to ensure that the source IP address of an incoming packet matches the IPv6 address assigned to the Talos peer. However, it performs no validation on the packet's destination address. The Talos end of the SideroLink connection cannot be considered a trusted environment. Workloads running on Kubernetes, especially those configured with host networking, could gain direct access to this link. Therefore, a malicious workload could theoretically send arbitrary packets over the SideroLink interface. This issue has been patched in version 0.48.0.

OpenClaw versions before 2026.5.18 contain an authorization bypass vulnerability in skill command dispatch that allows lower-trust callers to execute or persist actions beyond their intended authorization. Attackers can bypass tool policy restrictions through configured input paths to perform unauthorized actions when the affected feature is enabled and reachable.

OpenClaw 2026.5.12 before 2026.5.26 contain an incorrect authorization vulnerability in the ClickClack allowFrom feature. When the affected feature is enabled and reachable, a lower-trust caller or configured input path could execute or persist actions beyond the caller's intended authorization, including running non-allowlisted commands.

Improper authorization in GitLab CE/EE affecting all versions since 12.6 allowed guest users to create issues for Sentry errors and track their status

OpenRemote (org.openremote:openremote) versions <= 1.26.2 contain an insecure direct object reference vulnerability in the setAssetLinks endpoint of AlarmResourceImpl. The realm access check validates only a single realm obtained via realms.stream().findFirst() on a HashSet of realms from the request, rather than all realms. Because HashSet iteration order is non-deterministic, an authenticated attacker who includes alarm-asset links from both their own realm and a victim realm can, with roughly 50% probability per request (retryable), persist cross-tenant links and disclose victim asset names (returned via @Formula fields) through GET requests on the attacker's own alarm. Fixed in 1.27.0.

NanoClaw before 2.1.0 contains a privilege escalation vulnerability in the channel-registration approval flow where handleChannelApprovalResponse fails to validate admin privileges over target agent groups. Scoped admins can submit forged or stale connect callback values to wire messaging channels into out-of-scope agent groups, exposing unauthorized groups to unapproved channels and enabling unauthorized observation or control of restricted agent group activity.

The WP JobHunt plugin for WordPress, used by the JobCareer theme, is vulnerable to authorization bypass in all versions up to, and including, 7.6. This is due to insufficient login restrictions on inactive and pending accounts. This makes it possible for authenticated attackers, with Candidate- and Employer-level access and above, to log in to the site even if their account is inactive or pending.

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly validate channel membership when retrieving playbook run metadata, allowing authenticated users who are playbook members but not channel members to access sensitive information about linked private channels including channel name, display name, and participant count through the run metadata API endpoint.

Insecure permissions in RuoYi v4.8.0 allows authenticated attackers to escalate privileges by assigning themselves higher level roles.

Discourse is an open source discussion platform. In versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, an endpoint lets any authenticated user bypass the ai_discover_persona access controls and gain ongoing DM access to personas that may be wired to staff-only categories, RAG document sets, or automated tooling, enabling unauthorized data disclosure. Because the controller also accepts arbitrary user_id, an attacker can impersonate other accounts to trigger unwanted AI conversations on their behalf, generating confusing or abusive PM traffic. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. No known workarounds are available.

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly enforce channel member management permissions when adding participants to playbook runs. This allows authenticated users with member-level permissions to bypass system admin restrictions and add or remove users to/from private channels via the playbook run participants feature, even when the 'Manage Members' permission has been explicitly removed. This can lead to unauthorized access to sensitive channel content and allow guest users to gain channel management privileges.

A flaw was found in KubeVirt's Role-Based Access Control (RBAC) evaluation logic. The authorization mechanism improperly truncates subresource names, leading to incorrect permission evaluations. This allows authenticated users with specific custom roles to gain unauthorized access to subresources, potentially disclosing sensitive information or performing actions they are not permitted to do. Additionally, legitimate users may be denied access to resources.

OpenClaw MS Teams before 2026.5.12 contain an authorization bypass vulnerability where the allowFrom feature binds to mutable display names. Attackers with lower-trust access can perform actions requiring stronger authorization by exploiting the mutable display name binding in the affected feature.

OpenClaw versions 2026.5.28 before 2026.6.6 contain an authorization bypass vulnerability in native web search that allows lower-trust callers to perform actions requiring stronger policy checks. Attackers can exploit misconfigured input paths to bypass intended authorization controls and execute restricted operations.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to modify hidden merge requests due to incorrect authorization enforcements.

Discourse is an open source discussion platform. In versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, non-admin moderators with the `moderators_change_post_ownership` setting enabled can change ownership of posts in private messages and restricted categories they cannot access, then export their data to view the content. This is a broken access control vulnerability affecting sites that grant moderators post ownership transfer permissions. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. The patch adds visibility checks for both the topic and posts before allowing ownership transfer. As a workaround, disable the `moderators_change_post_ownership` site setting to prevent non-admin moderators from using the post ownership transfer feature.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a client could be registered as the configured no_auth_user through a parser path used when the first client operation was not CONNECT, bypassing user-level connection restrictions such as allowed_connection_types or proxy_required that normal authentication would apply. This issue is fixed in versions 2.14.3 and 2.12.12.

Capgo before 12.128.2 contains a scope isolation vulnerability in the POST /webhooks/test endpoint that allows app-scoped API keys to invoke org-scoped webhook operations. Attackers with app-scoped credentials can trigger signed outbound webhook deliveries for arbitrary organization webhooks outside their declared app boundary, bypassing the limited_to_apps authorization check.

Coder allows organizations to provision remote development environments via Terraform. Starting in version 2.30.0 and prior to versions 2.32.7, 2.33.8, and 2.34.2, AI Bridge proxy endpoints authenticate via `Server.IsAuthorized` in `coderd/aibridgedserver`, which validates key format, expiry, secret and deleted or system users but does not check whether the account is suspended. Because suspension does not revoke existing API keys, a suspended user's unexpired token keeps working. Practical impact is limited to already-issued API keys of suspended users until those keys are deleted. Versions 2.32.7, 2.33.8, and 2.34.2 patch the issue. As a workaround, on suspension, delete the user's API keys via `DELETE /api/v2/users/{user}/keys`.

Improper Access Control (CWE-284) in Kibana can lead to unauthorized modification of Entity Analytics Watchlist configuration and potential information disclosure. A low-privileged authenticated user with read-only Security Solution access could perform write operations on watchlist data that should require elevated privileges. Under specific deployment conditions, this could also allow such a user to access data beyond their authorized scope.

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.57.4, multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true could allow an authenticated tenant to access default-scope workflow_versions backups instead of being confined to the tenant scope, exposing or deleting workflow-version backups from prior single-tenant deployments or migrations. This issue is fixed in version 2.57.4.

OpenClaw before 2026.5.7 contains a sender policy bypass vulnerability in BlueBubbles that allows participants to match allowlist entries through conversation metadata rather than stable sender identity. Attackers can influence conversation-level identifiers to receive agent responses intended for configured senders, potentially bypassing access controls.

This issue was addressed with improved URL validation. This issue is fixed in Safari 26, iOS 26 and iPadOS 26. Processing maliciously crafted web content may lead to unexpected URL redirection.

OpenClaw before 2026.3.31 contains an authorization bypass vulnerability in Discord slash command and autocomplete paths that fail to enforce group DM channel allowlist restrictions. Authorized Discord users can bypass channel restrictions by invoking slash commands, allowing access to restricted group DM channels.

SurrealDB is a scalable, distributed, collaborative, document-graph database for the realtime web. Prior to 3.1.0, Document::purge_edges in surrealdb/core/src/doc/delete.rs automatically removed graph edge records with permissions disabled through opt.clone().with_perms(false) when a connected node was deleted, bypassing the edge table's PERMISSIONS FOR delete and PERMISSIONS FOR select clauses. This issue is fixed in version 3.1.0.

Autolab is a course management service that enables auto-graded programming assignments. There is a vulnerability in version 3.0.1 where CAs can view or edit the grade for any submission ID, even if they are not a CA for the class that has the submission. The endpoints only check that the CAs have the authorization level of a CA in the class in the endpoint, which is not necessarily the class the submission is attached to. Version 3.0.2 contains a patch. No known workarounds are available.

Directus is a real-time API and App dashboard for managing SQL database content. In affected versions if there are two overlapping policies for the `update` action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies. E.g. have one policy allowing update access to `field_a` if the `id == 1` and one policy allowing update access to `field_b` if the `id == 2`. The user with both these policies is allowed to update both `field_a` and `field_b` for the items with ids `1` and `2`. Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item. The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the validateItemAccess DB query, instead of only verifying access to the item as a whole. This is done by, instead of returning the actual field value, returning a flag that indicates if the user has access to that field. This uses the same case/when mechanism that is used for stripping out non permitted field that is at the core of the permissions engine. As a result, for every item that the access is validated for, the expected result is an item that has either 1 or null for all the "requested" fields instead of any of the actual field values. These results are not useful for anything other than verifying the field level access permissions. The final check in validateItemAccess can either fail if the number of items does not match the number of items the access is checked for (ie. the user does not have access to the item at all) or if not all of the passed in fields have access permissions for any of the returned items. This is a vulnerability that allows update access to unintended fields, potentially impacting the password field for user accounts. This has been addressed in version 11.1.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability.