CWE-863: Incorrect Authorization vulnerabilities

Kibana Agent Builder determines whether a caller owns a private agent by comparing a stable user identifier when one is recorded, and falling back to a comparison of the username when it is not. A username is not unique across Elasticsearch authentication realms, so two distinct principals that share a username in different realms are treated as the same owner. This discloses the configuration and instructions of an agent the caller does not own, and allows that agent to be altered or removed.

Incorrect Authorization (CWE-863) in Kibana can lead to unauthorized deletion of Synthetics private locations via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Synthetics private locations can be shared with more than one space, and deleting one removes it from every space it is shared with. The safeguard that prevented the deletion of a private location still in use evaluated only the monitors visible in the requesting user's own space, so monitors that depend on the private location in other spaces were not taken into account. As a result, an authenticated Kibana user holding the Synthetics write privilege in a single space could delete a private location that other spaces still depend on, even where the user has no access to those spaces. Deleting the private location removes the shared configuration and stops the monitors in the other spaces from running, which suppresses the availability monitoring those spaces rely on.

The Elastic Security capability that suggests existing field values while a user authors endpoint policy artifacts queries Elastic Defend event data with Kibana's internal Elasticsearch account instead of the account of the requesting user. Only Kibana feature privileges are verified, and the caller's Elasticsearch index privileges are not. An authenticated user who holds Elastic Security feature privileges but no read access to the Elastic Defend event indices can therefore retrieve field values from that data, including process command line arguments, which commonly contain tokens, credentials, connection strings, and other sensitive operational detail from protected hosts.

Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes

CVE-2026-58444 is a vulnerability in Gitea Open Source Git Server where personal access token scope enforcement can be bypassed on the repository home page. This flaw allows disclosure of private repository contents without proper authorization. The issue affects versions prior to 1.27.0 and has a medium severity rating with a CVSS score of 4.3.

CVE-2026-58443 is a critical vulnerability in Gitea Open Source Git Server versions up to 1.26.4. It allows public-only repository tokens to update private pull request head branches, potentially leading to unauthorized code changes. The vulnerability has a high CVSS score of 9.1, indicating severe impact on integrity and availability. No public exploits or patches are currently documented.

CVE-2026-58431 is a medium-severity vulnerability in Gitea Open Source Git Server where the public-only API token restriction is not enforced on team API routes. This allows API tokens intended for public-only access to potentially interact with team-specific API endpoints, which may lead to unauthorized information disclosure.

CVE-2026-58427 is a high-severity vulnerability in Gitea Open Source Git Server where private organization member lists are leaked via the /members API endpoint. This issue represents an incomplete fix for a previous pull request (#38145), resulting in unauthorized disclosure of sensitive membership information. The vulnerability affects Gitea versions up to and including 1.26.4.

CVE-2026-58425 is a vulnerability in Gitea Open Source Git Server where OAuth token introspection improperly returns metadata of tokens issued to other clients, violating RFC 7662 section 4. This can lead to unauthorized disclosure of token metadata. The vulnerability affects Gitea versions up to and including 1.26.4. The CVSS score is 4.3, indicating a medium severity impact primarily on confidentiality.

CVE-2026-58416 is a high-severity vulnerability in Gitea Open Source Git Server versions up to 1.26.4. It involves a missing fork-PR guard that allows Fork-PR Actions tasks to read a third private repository via the collaborative-owner branch. This flaw can lead to unauthorized read access to private repository data.

CVE-2026-57897 is a medium severity vulnerability in Gitea Open Source Git Server versions up to 1.26.4. It involves cross-repository information disclosure via organization-level actions using the Run/Job APIs. The vulnerability allows an attacker with limited privileges to access sensitive information across repositories within an organization without proper authorization.

CVE-2026-56443 is a critical vulnerability in Gitea Open Source Git Server affecting versions up to 1.26.4. It involves a bypass of token public-only scope restrictions on limited-visibility owners in repository and package categories. This issue is a residual problem following a previous vulnerability CVE-2026-25714. The flaw allows unauthorized elevation of privileges leading to high impact on integrity and availability without affecting confidentiality.

CVE-2026-55987 is a vulnerability in Gitea Open Source Git Server where OAuth2 sign-in can reactivate an administrator-deactivated account on authentication sources that do not use refresh tokens. This issue is due to an incomplete fix of a previous vulnerability (#38009). The flaw allows an attacker with limited privileges to regain access to accounts that were intended to be disabled by an administrator.

An authorization bypass vulnerability exists in Zimbra Collaboration (ZCS) before 10.1.17 due to improper authorization validation in delegated email sending functionality. An authenticated attacker can send specially crafted SOAP requests to impersonate another user and send emails without possessing the required delegation or send-as permissions. This occurs in the SaveDraftRequest SOAP handler.

CVE-2026-70463 is an authorization bypass vulnerability in rsync versions 3.1.0 through 3.4.4. The flaw arises from incorrect parsing of the auth users directive, specifically when group names contain spaces. This causes deny rules associated with such groups to be discarded, allowing authenticated users who should be denied access to connect to restricted modules.

Rsync versions 3.1.0 through 3.4.4 contain an access control bypass vulnerability due to improper handling of DNS resolution failures during hostname-based access control evaluation. When a DNS lookup fails for a hostname-based deny rule, the rsync daemon incorrectly skips the deny rule instead of denying access, allowing remote attackers to bypass IP-based access controls and gain unauthorized access to restricted module file trees.

CVE-2026-53786 is a medium severity vulnerability in rsync before version 3.5.0. It allows authenticated clients to bypass module-level filter restrictions by injecting malicious --filter merge file directives. This enables attackers to override intended file access restrictions and gain access to files that should be excluded by the module filter.

An incorrect authorization check in the v2 Alarm REST API in OpenNMS Meridian and Horizon allows a low-privileged authenticated user (ROLE_REST) to acknowledge, escalate, or clear alarms recorded as an arbitrary username, and, when also assigned ROLE_READONLY, to modify alarm state despite the read-only restriction. A credential check that should restrict these operations is guarded by an inverted condition, so it never executes for a real (non-blank) username. This can potentially allow an attacker to compromise the integrity of alarm state and audit records. The solution is to upgrade to Meridian 2024.3.12, 2025.0.9 and Horizon 36.0.3 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet.

CVE-2026-49473 affects the @cedar-policy/authorization-for-expressjs middleware versions prior to 0.3.0. The vulnerability arises from a mismatch in how the middleware and Express.js handle request URLs: the middleware uses req.originalUrl (including query strings) for authorization checks, while Express routes requests based only on the path component. This discrepancy allows an attacker to bypass stricter authorization policies by appending query strings to requests, causing the middleware to authorize less restrictive actions incorrectly. The issue is fixed in version 0.3.0.

In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.