| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by inconsistent catalog property permission evaluation. In deployments that use affected value-based catalog permission conditions as a confidentiality boundary, an authenticated user could receive catalog entity data that policy authors intended to restrict. This issue is fixed in version 3.9.1. |
| Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by inconsistent enforcement of allowed location types during catalog processing. Under certain configurations, the catalog backend could process location types that were not intended to be allowed, potentially leading to unintended file access on the backend host. This issue is fixed in version 3.9.1. |
| A flaw was found in Candlepin. The central authorization filter incorrectly grants access when any one of multiple @Verify-annotated parameters is accessible, instead of requiring access to every verified entity. A low-privilege authenticated attacker who can access the first referenced object can bypass authorization checks on subsequent objects. When target resource identifiers are known, this can enable unauthorized disclosure of consumer information and unauthorized modification of entitlements and related subscription resources, including across organizations. |
| Backstage is an open framework for building developer portals. Prior to 0.8.7, the @backstage/plugin-catalog-backend-module-gitlab package is affected by improper authorization in gitlab organizational user ingestion. Deployments that enable GitLab organization event ingestion and rely on scoped catalog users as an access boundary may admit an unintended catalog identity. Depending on sign-in and permission configuration, this may allow unauthorized access with the permissions of a standard authenticated user. This issue is fixed in version 0.8.7. |
| Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by incorrect authorization in scaffolder task listing. An authenticated internal user may be able to view metadata for scaffolder tasks outside the visibility intended by a deployment's permission policy. Stored task secrets are not included in the affected response, and no integrity or availability impact was identified. This issue is fixed in version 4.1.0. |
| Backstage is an open framework for building developer portals. From 0.4.0 until 0.5.15, the @backstage/plugin-catalog-backend-module-bitbucket-server package is affected by inconsistent repository filtering in bitbucket server catalog event updates. Deployments using event-driven updates in the Bitbucket Server catalog provider may ingest catalog locations from repositories that are excluded by the provider's configured project, repository, or archived-repository filters. An authenticated Bitbucket Server user who can push to a filtered-out repository that remains readable by the configured Backstage integration can trigger a legitimate repository event. The affected event path may then add a Location for that repository even though scheduled discovery excludes it. This issue is fixed in version 0.5.15. |
| The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachments could not be changed. |
| Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 Fail to sanitize Team objects returned by the data retention teams endpoint which allows an authenticated user holding only the read-only Data Retention Policy permission to obtain a private team's secret invite_id and email, and use it to join the team without authorization, via GET /api/v4/data_retention/policies/{policy_id}/teams.. Mattermost Advisory ID: MMSA-2026-00702 |
| RT-Labs AB C-Open CANopen contains a write protection bypass in the SDO (Service Data Object) server implementation 'src/co_sdo_server.c' that fails to properly validate write permissions when processing download-segment frames. An unauthenticated attacker on the CAN bus can initiate an SDO upload for a read-only Object Dictionary (OD) entry, which sets a data pointer to the read-only object, then send download-segment frames to write to that memory location. The download-segment handler does not verify that a download session is active, allowing any CANopen node to overwrite read-only OD entries using two SDO frames. Note that CANopen protocol operates over CAN bus and does not provide built-in authentication mechanisms. Fixed in 1.1.1. |
| Backstage is an open framework for building developer portals. Prior to 1.54.6, scaffolder source-control actions may not consistently enforce intended credential boundaries. An authenticated user could cause an affected action to fall back to broader integration credentials and perform operations with more access than intended. This issue is fixed in 1.54.6 when operators also enable scaffolder.requireScmUserCredentials after upgrading. |
| When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while collaborations that existed before the transfer are preserved. |
| When a push was authenticated with a deploy key, Gitea recorded the repository owner as the pusher, so permission checks in the push hook pipeline evaluated the owner instead of the deploy key. A holder of a writable deploy key could create protected tags without being on the tag allow list and change repository visibility through push options, for example making a private repository public. Pull requests created through the AGit flow with a deploy key were also attributed to the owner. |
| Obot 0.26.0 before 0.26.2 contains an authorization bypass vulnerability that allows authenticated users matching any vMCP profile to reach prompts and resources of ungranted components. Because profiles were enforced only on tools, attackers can access prompts, resources, and resource templates through the vMCP owner's shared component connection. |
| An authorization check in the large file exchange feature of Kiteworks Email Protection Gateway did not correctly establish that the requesting user was a party to the package being requested. An authenticated user of that optional feature could read the subject, message body, and attachments of packages they neither sent nor received. |
| Kiteworks did not correctly enforce which roles a shared folder's manager was permitted to assign. In a default configuration, an authenticated user holding the Manager role on a folder could grant the Owner role to themselves or to other members of that folder. |
| Incorrect authorization in DevTools in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in Search in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in WebAppInstalls in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in Transactions Platform in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in UI in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
