CVE Database

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.

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.

The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag. A collaborator with Code write access and without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion.

When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service.

Gitea's OAuth2 token endpoint verified the signature and grant of a token submitted with the `refresh_token` grant type, but not that the token was a refresh token. An unexpired access token for the same OAuth2 application and grant could be exchanged for a new access token and refresh token. Whoever holds such an access token could keep access beyond the token's original lifetime.

Improper input validation in the AMD ROCm Communication Collectives Library (RCCL) could allow a compromised peer rank or network-adjacent attacker to dereference an attacker-controlled pointer, potentially resulting in remote code execution.

A heap-based buffer over-read in H5Z__filter_scaleoffset() in src/H5Zscaleoffset.c in HDF5 through 2.2.0 lets an attacker cause a denial of service (application crash) with a crafted HDF5 file. When the stored minimum bits equal the full precision of the datatype, the decoder copies d_nelmts * size bytes from the compressed chunk without checking that the chunk holds that many bytes. Both values come from attacker-controlled scale-offset filter parameters in the dataset's filter pipeline message.

In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.

In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.

In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.

In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 "Crossing the Streams" findings.

In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.

In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.

In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.

Mozilla's Node-convict (version 6.2.2 and later) is vulnerable to a Denial of Service vulnerability caused by incomplete prototype‑pollution protections in config.set(). An attacker controlling the configuration key can write arbitrary properties to constructor.<key>, which walk() resolves to the global Object function. This allows overwriting core JavaScript methods such as Object.assign, leading to persistent process-wide failures and requiring a restart. The issue bypasses existing filters that only block constructor.prototype.* and __proto__.*. Exploitation requires an endpoint that forwards attacker-controlled keys into config.set().

A heap-based buffer overflow in H5VM_array_fill() in src/H5VM.c in HDF5 before 2.2.0 lets a remote attacker cause an application crash and possibly execute arbitrary code with a crafted HDF5 file. When a dataset's unallocated chunks are read, H5D__fill_init() fills the fill-value buffer from datatype and dataspace metadata in the file. If that metadata is inconsistent with the buffer's allocated size, the write goes past the end of the buffer. The attacker can control the content written through the fill value stored in the file.

Backstage is an open framework for building developer portals. Prior to 0.17.8, the @backstage/backend-defaults package is affected by improper input validation in cloud storage url readers. An attacker with write access to a cloud storage bucket used by Backstage could craft object names that could collide with protected files in the output directory. In certain deployment configurations, this could lead to content injection. This issue is fixed in version 0.17.8.

Backstage is an open framework for building developer portals. Prior to 1.54.6, cloud storage catalog providers did not sufficiently validate object paths. A principal able to create or rename objects in a configured Azure Blob Storage or AWS S3 catalog source could cause catalog descriptors to be read from outside the intended storage boundary, limited to locations reachable with the backend's configured credentials. This issue is fixed in 1.54.6.

Backstage is an open framework for building developer portals. Prior to 0.16.1 and 0.17.8, the @backstage/backend-defaults package is affected by improper preservation of access restrictions during service credential delegation. An external service credential configured with access restrictions (e.g., read-only) could bypass those restrictions by routing requests through plugin delegation paths. This could allow a restricted service to perform operations beyond its intended scope, including write operations on plugins it was restricted to read-only access for. This issue is fixed in versions 0.16.1 and 0.17.8.

Backstage is an open framework for building developer portals. Prior to 0.6.17, the @backstage/plugin-proxy-backend package is affected by improper input validation in proxy-backend. An authenticated Backstage user could craft a request URL that causes the proxy-backend to forward the request to a path outside the configured base path on the target server. This is limited to target servers already configured as proxy endpoints and requires Backstage authentication by default. This issue is fixed in version 0.6.17.

Backstage is an open framework for building developer portals. Prior to 2.2.4, the @backstage/plugin-techdocs-backend package is affected by improper input validation in techdocs static content requests. When using the Azure Blob Storage provider, an authenticated Backstage user may be able to read restricted TechDocs content when entity-level permissions are enabled. Deployments that intentionally disable the default backend authentication policy may have broader exposure. This issue is fixed in version 2.2.4.

Backstage is an open framework for building developer portals. Prior to 2.2.4, the @backstage/plugin-techdocs-backend package is affected by improper authorization enforcement for techdocs static content. An authenticated user with access to one TechDocs documentation site could craft a URL able to read documentation belonging to a different entity. This only affects deployments using the external TechDocs builder with an external storage provider (S3, GCS, etc.) and the permission framework enabled. Instances that do not use the permission framework are unaffected, since TechDocs content is visible to all authenticated users by design. This issue is fixed in version 2.2.4.

Backstage is an open framework for building developer portals. Prior to 0.4.20, the @backstage/plugin-auth-backend-module-oidc-provider package is affected by improper authentication in the oidc provider. Deployments using OIDC email-based identity resolution with a provider that permits unverified email addresses may allow an authenticated provider user to assume another catalog identity. This may grant access and permissions associated with that user. No direct availability impact is demonstrated. This issue is fixed in version 0.4.20.

Backstage is an open framework for building developer portals. Prior to 0.21.10, the @backstage/plugin-kubernetes-backend package is affected by unsupported catalog cluster authentication mode in kubernetes backend. Deployments using catalog cluster discovery may be affected when catalog contributors can create or modify kubernetes-cluster Resource entities. With the required endpoint permissions and pod RBAC, the backend can use its local in-cluster identity, potentially exposing Kubernetes resources readable by that identity. The credential is used only with the local in-cluster API endpoint and is not sent to the catalog-supplied endpoint. This issue is fixed in version 0.21.10.