CVE-2026-70357
Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess indepe
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
0
0-100
Publicado: 6 oct 2026 · Última mod.: 6 oct 2026 · CWE-918
Sin historial EPSS suficiente todavía.
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.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1064987.7 ALT—
——0Backstage is an open framework for building developer portals. Prior to 3.5.1, 3.6.2, 3.7.2, 3.8.2 and 3.9.1, the @backstage/plugin-catalog-backend package is affected by improper url validation in catalog entity placeholder resolution. An authenticated Backstage user could craft a catalog entity with placeholder directives that reference resources outside the entity's source repository. Under certain configurations, this could allow access to data not intended to be available to the user. This issue is fixed in versions 3.5.1, 3.6.2, 3.7.2, 3.8.2 and 3.9.1.22hCVE-2026-1064598.5 ALT—
——0Backstage is an open framework for building developer portals. From 0.3.0 until 0.3.8, the @backstage/plugin-scaffolder-backend-module-sentry package is affected by 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. Subsequent impact depends on network reachability and the privileges granted to the configured token. This issue is fixed in version 0.3.8.23hCVE-2026-1064557.7 ALT—
——0Backstage is an open framework for building developer portals. From 0.11.12 until 1.14.7 and 1.15.5, the @backstage/plugin-techdocs-node package is affected by 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. Exposure depends on deployment topology, build mode, and target endpoint protections. Modern cloud metadata services that require tokens or special headers are not directly accessible through the affected behavior. This issue is fixed in @backstage/plugin-techdocs-node versions 1.14.7 and 1.15.5.23hCVE-2026-1060325.7 MED—
——0Server-side request forgery in the OpenAPI schema processing of the agent import functionality in Amazon Bedrock AgentCore Starter Toolkit before 0.3.14 might allow an authenticated remote actor in the same AWS account to cause the environment of a user importing a Bedrock Agent to issue arbitrary outbound requests and read arbitrary local files, via crafted external reference values in the OpenAPI content associated with a Bedrock Agent action group.
To remediate this issue, users should upgrade to version 0.3.14. Note that bedrock-agentcore-starter-toolkit is deprecated. The @aws/agentcore npm CLI is the supported replacement and does not contain this issue. Migration to @aws/agentcore is the recommended long-term path.23hCVE-2026-96400——
——0With `[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.1dCVE-2026-89430——
——0Gitea 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.1d