Unleash: A project member can reorder activation strategies belonging to any other project / environment (cross-project integrity write), bypassing project RBAC and the audit log

Unleash is an open-source feature management platform. Prior to 8.0.3, POST /api/admin/projects/:projectId/features/:featureName/environments/:environment/strategies/set-sort-order passes attacker-controlled strategy IDs to unprotectedUpdateStrategiesSortOrder and updateSortOrder without verifying that the IDs belong to the project, feature, and environment authorized by the URL. In a multi-project Pro or Enterprise deployment, an authenticated user with UPDATE_FEATURE_STRATEGY in one project who knows another project's strategy IDs can reorder those strategies, changing feature evaluation precedence while the operation is attributed to the attacker's URL context rather than the affected project. The single-project OSS edition lacks the cross-project dimension, although the missing context binding still permits unauthorized reordering across features or environments in the default project. The endpoint changes only sort_order and does not modify strategy parameters, constraints, or segments. This issue is fixed in version 8.0.3.

Vaultwarden through 1.37.3 Authorization Bypass via Missing Status Check

Vaultwarden through 1.37.3 omits organization membership status validation from three cipher access-restriction queries, allowing revoked and not-yet-confirmed members to retain read, write, delete, and attachment access to organization ciphers. Attackers with revoked or pending membership can exploit missing status filters in get_user_collections_access_flags, get_group_collections_access_flags, and is_in_full_access_group to access protected cipher data server-side.

automation-controller: automation-controller-container: automation-controller: workflow job template node execute permission check bypassed by creating a node with a null unified_job_template and then patching it, allowing a single workflow-admin to execute any other tenant's job template with the victim's credentials (cross-tenant privilege escalation)

A flaw was found in Red Hat Ansible Automation Platform's automation-controller. The execute-permission check on a workflow job template node's unified job template is skipped when the node's currently stored unified job template is empty: the check inspects only the existing value, not the incoming one, and a node can be created without a unified job template. An authenticated user who holds admin permission on a single workflow job template can create an empty node and then patch it to reference any job template, project, inventory source, system job, or workflow on the platform -- including ones in other organizations that they cannot otherwise read or launch. Running their own workflow then executes the victim template with the victim's attached credentials, inventory and project, resulting in cross-organization privilege escalation to arbitrary automation execution. The patch response also discloses the victim template's name and description.

automation-controller: automation-controller-container: automation-controller: constructed inventory input inventory attachment checks only read permission on the source inventory, allowing a read-only user to clone another tenant's hosts and secrets and run ad hoc commands against them

A flaw was found in Red Hat Ansible Automation Platform's automation- controller. When attaching a source inventory to a constructed inventory through the input_inventories relationship endpoint, the controller verifies only that the requesting user can read the source inventory, rather than that they hold use permission on it, unlike instance group attachment on the same access class. An authenticated user who can administer a constructed inventory and has read-only visibility of an inventory in another organization -- for example an organization or system auditor -- can attach that foreign inventory as an input. On synchronization the controller clones every host and host variable, including secrets, into the attacker's inventory, and because the attacker administers the constructed inventory they can run ad hoc commands against the cloned hosts, resulting in cross-tenant disclosure of inventory data and secrets and code execution against another tenant's managed hosts.

automation-controller: automation-controller-container: automation-controller: instance group attachment to schedules and workflow job template nodes checks only read permission, allowing use of restricted (controlplane / other-tenant) instance groups and privilege escalation to control-plane code execution

A flaw was found in Red Hat Ansible Automation Platform's automation- controller. When attaching an instance group to a schedule or a workflow job template node through the dedicated API relationship endpoint, the controller verifies only that the requesting user can read (view) the instance group, rather than that they hold use permission on it, unlike every other instance group assignment in the product. An authenticated user with read-only visibility of an instance group -- for example a system auditor -- can attach a use-restricted instance group, including the control plane group or another tenant's container group, to a schedule or workflow node they control. Their playbook then executes on the control plane node or within another tenant's execution environment, leading to privilege escalation and, in the control plane case, full compromise of the platform.

automation-controller: automation-controller-container: automation-controller: organization galaxy credential attachment checks only read permission on the credential, allowing an organization admin with read-only visibility to bind and server-side-use another tenant's Automation Hub API token

A flaw was found in Red Hat Ansible Automation Platform's automation- controller. When attaching a Galaxy or Automation Hub credential to an organization through the galaxy_credentials relationship endpoint, the controller verifies only that the requesting user can read the credential, rather than that they hold use permission on it, unlike other credential consumption in the product. An authenticated user who administers one organization and has read-only visibility of a credential in another organization -- for example a platform auditor -- can bind that foreign credential to their own organization. On the next project synchronization the controller decrypts the credential server-side and uses its token to authenticate to the credential owner's Automation Hub, allowing cross-tenant use of another organization's secret.

Access Control Bypass Allowing Unauthorized Data Modification in Oracle Hyperion Data Relationship Management

Vulnerability in the Oracle Hyperion Data Relationship Management product of Oracle Hyperion (component: Access and security). The supported version that is affected is 11.2.26.0.000. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hyperion Data Relationship Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Hyperion Data Relationship Management, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Hyperion Data Relationship Management accessible data as well as unauthorized update, insert or delete access to some of Oracle Hyperion Data Relationship Management accessible data. CVSS 3.1 Base Score 7.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).

Unauthorized Access via Access and Security Logic Flaw in Oracle Hyperion Data Relationship Management

Vulnerability in the Oracle Hyperion Data Relationship Management product of Oracle Hyperion (component: Access and security). The supported version that is affected is 11.2.26.0.000. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hyperion Data Relationship Management. While the vulnerability is in Oracle Hyperion Data Relationship Management, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Hyperion Data Relationship Management accessible data. CVSS 3.1 Base Score 7.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).

Vulnerability in the Oracle Hyperion Data Relationship Management product of Oracle Hyperion (component: Access and security). The supported version that is affected is 11.2.26.0.000. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Hyperion Data Relationship Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Hyperion Data Relationship Management, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Hyperion Data Relationship Management accessible data as well as unauthorized update, insert or delete access to some of Oracle Hyperion Data Relationship Management accessible data. CVSS 3.1 Base Score 7.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).

Permissions issue enabling application to access user‑sensitive data

A permissions issue was addressed with improved validation. This issue is fixed in Xcode 27, macOS Golden Gate 27. An app may be able to access user-sensitive data.

Improper Input Sanitization in Okta Access Gateway Protected Rules

The Okta Access Gateway improperly handles input sanitization and regular expression evaluation within its Protected Rule authorization check, resulting in an authorization bypass when an administrator has explicitly configured a Protected Rule policy on one or more application resources.

Failure to Properly Enforce Port ACLs on CPU generated packets in CX 9300 Switches

A vulnerability has been identified in the port ACL functionality of AOS-CX software running on the HPE Aruba Networking CX 9300 Switch Series only and affects: - AOS-CX 10.14.xxxx : All patches - AOS-CX 10.15.xxxx : 10.15.1000 and below The vulnerability is specific to traffic originated by the CX 9300 switch platform and could allow an attacker to bypass ACL rules applied to routed ports on egress. As a result, port ACLs are not correctly enforced, which could lead to unauthorized traffic flow and violations of security policies. Egress VLAN ACLs and Routed VLAN ACLs are not affected by this vulnerability.

Unauthenticated Traffic Handling Flaw Allows Packet Leakage on HPE Aruba Networking CX 10000 series switches

A vulnerability in the firewall component of HPE Aruba Networking CX 10000 Series Switches exists. It could allow an unauthenticated adjacent attacker to conduct a packet forwarding attack against the ICMP and UDP protocol. For this attack to be successful an attacker requires a switch configuration that allows packets routing (at layer 3). Configurations that do not allow network traffic routing are not impacted. Successful exploitation could allow an attacker to bypass security policies, potentially leading to unauthorized data exposure.

Supabase Realtime: Incorrect Authorization

Supabase Realtime provides Broadcast, Presence, and Postgres Changes via WebSockets. Prior to 2.111.2, Realtime authorization does not correctly honor the per-extension presence.read row-level security policy when a private-channel client is allowed presence.write but explicitly denied presence.read. Under that differential policy, the client can receive presence_diff messages containing other members' presence metadata, including application-defined location, online-status, roster, viewing, or typing information. Deployments with uniform presence visibility have no differential, and postgres_changes row data is unaffected. This issue is fixed in version 2.111.2.

Apache Airflow: Asset queued-events DELETE endpoints gated on Dag READ instead of Dag EDIT (asset-triggered scheduling suppression)

Apache Airflow's asset queued-events DELETE endpoints checked the caller's Dag-axis permission with `READ` instead of `EDIT`. Any authenticated user who could read a Dag could therefore delete that Dag's queued asset events, silently suppressing asset-triggered scheduling for it — a state-changing action gated on a read-only permission. Deployments are affected whenever asset-triggered scheduling is in use and Dag read access is granted more widely than Dag edit access, which is the normal RBAC arrangement; no special configuration is required. Upgrade to apache-airflow 3.3.2 or later.

WP Table Builder <= 2.2.1 - Incorrect Authorization to Authenticated (Subscriber+) Arbitrary Post Deletion via 'ids' Parameter

The WP Table Builder – Drag & Drop Table Builder plugin for WordPress is vulnerable to Incorrect Authorization in all versions up to, and including, 2.2.1. This is due to an operator precedence bug in the post-type guard within the trash_table_bulk() and restore_table_bulk() functions that causes the guard to never fire, combined with a permission callback that only verifies plugin role membership without per-post-type or ownership checks. This makes it possible for authenticated attackers, with subscriber-level access and above, to trash or restore any post, page, or custom post type on the site by supplying arbitrary post IDs.

An issue was discovered in Sonatype Nexus Repository Manager in versions 3.21.1 and 3.22.0. It is possible for a user with appropriate privileges to create, modify, and execute scripting tasks without use of the UI or API. NOTE: in 3.22.0, scripting is disabled by default (making this not exploitable).

Sonatype Nexus Repository Manager 3 Pro up to and including 3.30.0 has Incorrect Access Control.

Nexus Repository 3 - Incorrect Authorization Allows Disclosure of Member Repository Metadata via Group Repository Permissions

An authorization flaw in the REST API repository details endpoint (GET /service/rest/v1/repositories/{repositoryName}) in Sonatype Nexus Repository 3 allowed an account holding read or browse permission on a group repository to retrieve metadata for member repositories on which it held no direct permission, by requesting the endpoint directly for the member repository name. For proxy repositories, the disclosed metadata includes the configured remote URL, which may reveal internal upstream hostnames. This includes the anonymous user if it has been granted this permission; whether the anonymous user holds this permission depends on the role and permission configuration of the specific installation.

Nexus Repository 3 - Incorrect Authorization on Blobstore Group Endpoints

A vulnerability was identified in Sonatype Nexus Repository 3 in which two blobstore group management REST API endpoints did not correctly enforce the intended authorization check. A user granted only the nexus:blobstores:create permission could invoke these endpoints to convert an existing blobstore into a group blobstore, an action that should require the nexus:blobstores:update permission instead. This could result in unauthorized modification of blobstore configuration without administrator approval. The nexus:blobstores:create permission is a named permission that must be explicitly granted by an administrator; it is not held by default.