CVE Feed

Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). A low-privileged authenticated user can submit a specially crafted query that causes uncontrolled memory growth in the query processing engine, resulting in an out-of-memory condition that terminates the Elasticsearch node. The condition can be triggered repeatedly, including by queries embedded in shared resources, causing persistent cluster unavailability.

When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while collaborations that existed before the transfer 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 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.

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.

Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess independently resolves the hostname when connecting. An attacker who can start a migration and control the destination's DNS can change the address between validation and connection to reach a blocked internal address. The affected path is the Git clone operation; validation in the migration HTTP client's dialer does not protect the independently connecting Git subprocess.

Gitea validated the initial remote URL for push mirrors, wiki remote checks, and fetches of migrated pull request heads, but the subsequent raw Git operations followed HTTP redirects without revalidating the destination. A repository administrator using a policy-allowed endpoint that redirects could make Gitea's Git client send requests to an address that the outbound host policy would otherwise block. The impact depends on the configured policy and the internal services reachable from the server.

A flaw was found in CRI-O's `bind_mount_prefix` handling. When configured with a non-empty `bind_mount_prefix`, a malicious container or local attacker could use a Container Runtime Interface (CRI) hostPath containing an intermediate absolute symlink. This could cause the bind mount source to resolve outside the intended prefixed root, potentially leading to unauthorized access to files or privilege escalation on the host system.

Changing an organization team's permission through the API with only the `permission` field did not rebuild the team's per-unit access, and the requested level was not applied as a cap. After an organization owner demoted a team, for example from admin to read, the team's members kept their previous unit permissions, including write access to the team's repositories. The web form was not affected.

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 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 Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval. Because fork pull request runs are inserted under the base repository, a user who can open a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind.

Gitea's container registry served blob downloads with a `Content-Type` taken from the media type declared in pushed image manifests, without a `Content-Disposition` or restrictive content security policy. A user who can push container images can publish a blob containing HTML and JavaScript with a `text/html` media type. When a victim who is authenticated to the instance opens the blob URL in a browser, the script runs on the Gitea origin and can perform actions as the victim, such as creating API tokens.

Gitea's repository migration and pull mirror egress checks could be bypassed with a hostname that returns multiple DNS answers, because the address that was validated was not necessarily the address Git later connected to. A low-privileged user who can create migrations or mirrors could direct the server to internal services, reading from and writing to reachable internal Git or HTTP endpoints. Content from internal responses could additionally be disclosed through migration and mirror error messages.

When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostname could make it resolve to loopback or private addresses and bypass `ALLOW_LOCALNETWORKS = false`, reaching internal services from the Gitea server. Instances without `ALLOWED_DOMAINS` configured are not affected by this specific bypass.

A user who can open a fork pull request can place workflow content with a shared run-level concurrency group into a Gitea Actions run that is awaiting approval. When a later run in that group cancels the blocked job, the run becomes terminal while still marked as needing approval. If a maintainer later approves the run, Gitea passed the already-cancelled job back through concurrency preparation, set it to waiting, and made it claimable by a matching runner, executing fork-controlled workflow code. Exploitation requires the maintainer's later approval action, Actions to be enabled, and a runner that accepts the repository's jobs.

When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint.

Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval.

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 within the affected client interface.

A command injection vulnerability in the OnGuard agent of ClearPass Policy Manager could allow an authenticated remote attacker to inject arbitrary commands. Successful exploitation could allow an attacker to execute commands with elevated privileges on the affected Windows endpoint.

An arbitrary file write vulnerability in the ClearPass Policy Manager OnGuard agent could allow malicious users on a local instance to elevate their user privileges if certain preconditions outside of the attacker's control are met. Successful exploitation could allow a local attacker to execute arbitrary code with elevated privileges on the affected system.

A local privilege escalation vulnerability exists in the ClearPass client software. Successful exploitation could allow a low-privileged local user to execute commands with elevated privileges on the affected system, if certain conditions outside of the attacker's control are met.

A denial of service vulnerability exists in the OnGuard agent of HPE Networking ClearPass Policy Manager. Successful exploitation could allow an authenticated local attacker to interrupt the normal operation of the agent service.

A SQL injection vulnerability in the API of ClearPass Policy Manager could allow a remote authenticated attacker with administrative privileges to conduct SQL injection attacks against the ClearPass Policy Manager instance. Successful exploitation could allow an attacker to execute arbitrary database commands.

Remote code execution vulnerabilities exist in the affected interface of HPE Networking ClearPass Policy Manager that could allow an authenticated remote attacker with high privileges to execute arbitrary code. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system.

An unauthenticated path traversal vulnerability exists in an API endpoint of ClearPass Policy Manager. Successful exploitation of this vulnerability allows an unauthenticated remote attacker to influence authorization decisions and be assigned an unintended role.

A buffer overflow vulnerability exists in the OnGuard agent of ClearPass Policy Manager. Successful exploitation could allow an authenticated local user to execute arbitrary code with elevated privileges on the affected host or to disrupt the availability of the affected service.

A missing integrity verification vulnerability in the Windows client software for ClearPass Policy Manager could allow malicious users on a local instance to elevate their user privileges. A successful exploit could allow these users to execute attacker-supplied code with elevated privileges on the local system.

A privilege escalation vulnerability in the ClearPass Policy Manager OnGuard Linux agent could allow malicious users on a Linux instance to elevate their user privileges. A successful exploit allows a malicious user to escalate to root privileges on the affected Linux client.

An authenticated path traversal vulnerability exists in ClearPass Policy Manager. Successful exploitation could allow an attacker to read and modify certain files on the underlying operating system.

A command injection vulnerability exists in the API of ClearPass Policy Manager. Successful exploitation could allow an authenticated remote attacker to escalate privileges and gain administrative control of the affected system.

A command injection vulnerability exists in the client software of ClearPass Policy Manager. Successful exploitation could allow an attacker who is able to supply crafted input to the affected software to execute arbitrary commands with elevated privileges on the affected host.

A missing integrity verification vulnerability in the client agent software of HPE Networking ClearPass Policy Manager could allow an unauthenticated remote attacker to introduce untrusted code. Successful exploitation could allow an attacker to execute arbitrary code on the affected client system.

An authenticated path traversal vulnerability exists in the command line interface of ClearPass Policy Manager. Successful exploitation could allow a low-privileged authenticated remote attacker to execute arbitrary code with elevated privileges on the underlying operating system.

A vulnerability in the web-based management interface of ClearPass Policy Manager could allow an unauthenticated remote attacker to conduct a stored cross-site scripting (XSS) attack against an administrative user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface.

SQL injection vulnerabilities in the web-based management interface of ClearPass Policy Manager could allow a low-privileged authenticated remote attacker to conduct SQL injection attacks against the ClearPass Policy Manager instance. Successful exploitation could allow an attacker to run arbitrary database commands.

An improper access control vulnerability exists in the Android client application for HPE Networking ClearPass Policy Manager, where application functionality may be invoked by untrusted sources. Successful exploitation could allow an unauthenticated remote attacker, with user interaction, to obtain sensitive information from the affected user.

Vulnerabilities have been identified in the affected interface of ClearPass Policy Manager that could potentially allow an unauthenticated remote attacker to circumvent existing authentication controls. Successful exploitation could allow an attacker to gain unauthorized access to the affected system.

A SQL injection vulnerability in the web-based management interface of ClearPass Policy Manager could allow an authenticated remote attacker to conduct SQL injection attacks against the ClearPass Policy Manager instance. Successful exploitation could allow an attacker to run arbitrary database commands.

A vulnerability in an affected interface of ClearPass Policy Manager could allow an unauthenticated remote attacker to conduct SQL injection attacks against the ClearPass Policy Manager instance. Successful exploitation could allow an attacker to run arbitrary database commands.

A format string vulnerability in an affected service interface of HPE Networking ClearPass Policy Manager could allow an unauthenticated remote attacker to corrupt process memory. Successful exploitation could allow an attacker to execute arbitrary code.

Authentication bypass vulnerabilities exist in the web-based management and API interfaces of HPE Networking ClearPass Policy Manager. Successful exploitation could allow an unauthenticated remote attacker to circumvent existing authentication controls and gain administrative access to the affected system.

A missing integrity verification vulnerability exists in the OnGuard agent of ClearPass Policy Manager. Successful exploitation could allow an unauthenticated, remote attacker to execute arbitrary code on the affected endpoint with the elevated privileges of the agent.

Deserialization of untrusted data vulnerabilities exist in the web interface of HPE Networking ClearPass Policy Manager. Successful exploitation could allow an unauthenticated remote attacker to execute arbitrary code on the affected system.