CVE Vulnerability Catalog

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.

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.

A vulnerability in an API interface of ClearPass Policy Manager could allow an unauthenticated remote attacker to circumvent existing authentication controls. Successful exploitation could allow an attacker to obtain sensitive information from the affected system.

A sensitive information disclosure vulnerability exists in the client software of HPE Networking ClearPass Policy Manager. Successful exploitation could allow an attacker with local access to the affected system to obtain sensitive information.

A vulnerability in a client interface of HPE Networking ClearPass Policy Manager could allow an unauthenticated remote attacker to conduct a DOM-based cross-site scripting (XSS) attack against a user of the affected client interface. Successful exploitation could allow an attacker to execute arbitrary script code in a victim's browser context.