CVE Vulnerability Catalog

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.

Backstage prior to 1.54.6 does not consistently enforce credential boundaries in scaffolder source-control actions. 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.

In @backstage/plugin-scaffolder-backend prior to 4.1.0, incorrect authorization in scaffolder task listing allows an authenticated internal user to view metadata for tasks outside the intended visibility. Stored task secrets are not included, and no integrity or availability impact was identified. Fixed in version 4.1.0.

In @backstage/plugin-auth-node from 0.3.0 to 0.6.15 and 0.7.5, explicit negative email verification was not consistently honored during shared OAuth profile normalization. In affected configurations, a user may assume another catalog identity and obtain its associated access and permissions. Fixed in versions 0.6.15 and 0.7.5.

The @backstage/plugin-scaffolder-backend-module-sentry package from 0.3.0 until 0.3.8 has improper input validation in Sentry scaffolder actions. An authenticated internal user who can execute the affected actions may cause the backend to contact unintended destinations and disclose Sentry integration credentials.

In @backstage/plugin-catalog-backend-module-bitbucket-server from 0.4.0 to 0.5.15, inconsistent repository filtering in Bitbucket Server catalog event updates may allow ingestion of locations from repositories excluded by filters. Fixed in version 0.5.15.

In @backstage/plugin-auth-backend-module-cloudflare-access-provider from 0.1.0 to 0.5.0, insufficient audience validation in the Cloudflare Access auth provider allows a user with a valid token for another Access application to authenticate to Backstage. Fixed in version 0.5.0.

In @backstage/plugin-proxy-backend from 0.5.0 to 0.6.18, inconsistent credential enforcement for overlapping proxy routes allows an unauthenticated caller to reach a nested upstream. Fixed in version 0.6.18.

The @backstage/plugin-techdocs-node package from 0.11.12 until 1.14.7 and 1.15.5 has improper validation of mkdocs plugin configuration in TechDocs. An authenticated attacker with control over a TechDocs source repository could cause a documentation build to retrieve and publish data from network locations reachable by the build environment.

A heap-based buffer overflow exists in GIMP's DirectDraw Surface (DDS) loader. When loading a crafted DDS image, buffer sizes derived from width, height, and pitch can overflow 32-bit arithmetic, causing the allocated buffer to be too small for the pixel data written through GEGL. This may lead to heap corruption and, in the worst case, arbitrary code execution in the context of the GIMP process.

In Amazon Bedrock AgentCore Starter Toolkit before 0.3.14, server-side request forgery in OpenAPI schema processing of the agent import functionality might allow an authenticated remote actor to cause arbitrary outbound requests and read arbitrary local files. Fixed in version 0.3.14; migration to @aws/agentcore is recommended.

Improper control of code generation in the agent import functionality of Amazon Bedrock AgentCore Starter Toolkit before 0.3.14 might allow an authenticated same-account actor to execute arbitrary code when a user imports and runs or deploys a Bedrock Agent, via crafted configuration values incorporated into generated Python source without safe literal encoding.

In the optional Amazon Q Business Lambda hook sample (q-business-lambda-hook) available with QnABot on AWS versions 7.0.0 through 7.4.5, an authorization bypass through a user-controlled key might allow an authenticated remote user to read arbitrary S3 objects. Fixed in version 7.4.6, but requires redeployment of the hook stack.

In SSSD (System Security Services Daemon), a flaw exists where pre-authentication requests retain state in memory without being cleared or timed out. A local attacker can repeatedly initiate authentication flows without completing them, causing unbounded memory consumption, potentially leading to DoS.

In SSSD, a race condition in the autofs responder between asynchronous enumeration completion and map invalidation can be exploited by a local user to cause memory leaks, leading to excessive memory consumption that can disrupt or crash the autofs service.

A flaw in Ghostscript allows bypassing the -dSAFER sandbox and executing arbitrary shell commands in the context of the Ghostscript process when rendering a crafted PostScript or EPS document. The issue chains memory corruption in document parsing with disabling of internal path access controls at runtime.

When a private repository is transferred to a user without access, Gitea grants temporary read access as a collaborator. Rejecting or cancelling the transfer did not revoke this collaboration, so the recipient kept persistent read access to the private repository, including code, issues, pull requests, and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while pre-existing collaborations are preserved.

Gitea expanded a workflow's static `strategy.matrix` into its full Cartesian product without a size limit when creating a run, before the fork pull request approval gate applied. A user who can open a pull request from a fork could submit a small workflow file whose matrix expands to a very large number of jobs, consuming server memory and potentially terminating the Gitea process. No runner is required. Static matrices above 256 combinations are now rejected before expansion.

When Gitea's web installer is reachable against a database that already contains users, such as after `INSTALL_LOCK` has been reset to `false`, submitting the install form with an administrator username matching an existing account issued an authenticated session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation.

With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected.