CVE Vulnerability Catalog

The Gitea API endpoint GET /api/v1/repos/{owner}/{repo}/media/{filepath} wrote files up to 1 KiB stored directly in Git (not LFS) to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was rendered by the browser on the Gitea origin. A user with push access could run JavaScript in the session of a victim opening the media URL and act with the victim's permissions.

With [repository] FORCE_PRIVATE = true, Gitea creates new repositories as private, but the post-receive hook still applied the repo.private=false push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected.

NVIDIA TensorRT contains a vulnerability that allows an attacker to cause an out-of-bounds read. Successful exploitation may lead to denial of service.

Backstage is an open framework for building developer portals. Prior to 1.15.4, the @backstage/plugin-techdocs-node package is affected by potential file exposure through the local techdocs publisher. When using the local TechDocs publisher, the documentation serving endpoint could follow filesystem references outside the intended documentation tree, potentially exposing host files to authenticated users. This is mitigated by the fact that exploration requires preconditions not arising through normal MkDocs operation. Cloud-based publishers are not affected. Fixed in version 1.15.4.

Backstage is an open framework for building developer portals. Prior to 1.15.4, the @backstage/plugin-techdocs-node package is affected by arbitrary file read via mkdocs snippets. Unsafe path resolution in TechDocs source tree handling allows an authenticated user who can register documentation sources to include content from outside the intended documentation boundary. Depending on deployment, this may expose files readable by the build process. Fixed in version 1.15.4.

Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by improper input validation in scaffolder task list ordering. An authenticated Backstage user with permission to create and read relevant scaffolder tasks may be able to infer confidential task data under specific conditions. Successful exploitation requires retained task secrets, visibility of a target task, knowledge of the secret structure, and repeated requests. Fixed in version 4.1.0.

Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by sensitive information exposure in scaffolder task logs. An authenticated user who can create and read scaffolder tasks may be able to observe sensitive values in task logs in deployments with restrictive action permissions and affected templates. Exploitation requires a denied action whose input contains such a value. Fixed in version 4.1.0.

Backstage is an open framework for building developer portals. Prior to 4.1.0, the @backstage/plugin-scaffolder-backend package could expose sensitive information in Scaffolder task failure events. Under specific template and failure conditions, an authenticated user may retrieve backend-managed credentials used during task execution from affected task events. Fixed in version 4.1.0.

Backstage before version 4.1.0 in the @backstage/plugin-scaffolder-backend package could expose secret-derived values in Scaffolder task logs. Deployments that configure sensitive scaffolder.defaultEnvironment.secrets and allow an attacker to create or modify Scaffolder templates are affected. A template author could cause secret-derived values used during template iteration to be persisted and exposed to users who can access the resulting task logs.

Backstage before version 3.9.1 in the @backstage/plugin-catalog-backend package has 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.

The Gitea API routes for issue attachments 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.

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.

In HDF5 through version 2.2.0, there is a heap-based buffer over-read in H5Z__filter_scaleoffset() in src/H5Zscaleoffset.c. An attacker can 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.

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

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

Backstage before version 0.17.8 in the @backstage/backend-defaults package has 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.

Backstage before version 0.6.17 in the @backstage/plugin-proxy-backend package has 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.

Backstage before version 2.2.4 in the @backstage/plugin-techdocs-backend package has 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.

Backstage before version 2.2.4 in the @backstage/plugin-techdocs-backend package has 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.

Backstage before version 0.8.7 in the @backstage/plugin-catalog-backend-module-gitlab package has 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.