CVE Vulnerability Catalog

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.

A repository's external issue tracker regular expression containing alternating capture groups could produce invalid slice indexes when Gitea rendered issue references, causing a runtime panic that terminated the Gitea process. A user who can edit a repository's external issue tracker settings could make any later rendering of matching content, such as viewing a README, crash the instance for all users.

When processing issue and comment bodies, Gitea scanned the entire preceding text for action keywords such as "closes" or "fixes" once per Markdown link, giving processing time quadratic in the input size. An authenticated user able to submit issue or comment content could send a crafted body of about 1 MB that keeps a CPU core busy for several minutes while holding a database transaction open.

Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned.

Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.

In Apache Commons BCEL before 6.13.0, there is an issue with symbolic name mapping to correct class. BCEL caches attacker-controlled classes under their self-declared names without validating the requested name, allowing subsequent lookups and name-keyed verification results to refer to a different class.

Gitea validated a push mirror's remote address against the `[migrations]` allow and block lists only when the mirror was created. Each synchronization passed the stored address directly to `git push`, so a name that later resolved to a blocked or internal address was still reached. A user with administrator access to a repository, which includes repositories they create themselves, could aim push mirror synchronization at internal Git services and force-push the repository's contents to them.