| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Mattermost versions 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 fail to apply the internal-connection filter to OAuth endpoint requests, which allows a System Administrator to make the server issue requests to internal network addresses and read the responses via the configured OAuth token and userinfo endpoints.. Mattermost Advisory ID: MMSA-2026-00776 |
| Backstage is an open framework for building developer portals. Prior to 1.14.6 and 1.15.4, the @backstage/plugin-techdocs-node package did not sufficiently validate TechDocs Markdown extension configuration. An authenticated user who can register or modify documentation sources may cause a TechDocs build to access resources outside the intended documentation boundary, potentially exposing backend-host data or internal network resources. This issue is fixed in versions 1.14.6 and 1.15.4 when pymdown-extensions 10.21.3 or later is also used, normally through mkdocs-techdocs-core 1.7.0 or later. |
| Server-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. |
| A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path. By abusing this path, a remote unauthenticated attacker could potentially exploit this vulnerability to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations. |
| 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 vulnerability in the web-based management interface of Cisco Finesse could allow an unauthenticated, remote attacker to conduct server-side request forgery (SSRF) attacks through an affected device.
This vulnerability is due to improper input validation for specific HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain limited sensitive information for services that are associated with the affected device. |
| Gophish 0.11.0 through 0.12.1 contains a server-side request forgery vulnerability that allows authenticated low-privileged users to reach loopback and private hosts via POST /api/import/site. Attackers can submit internal URLs, which the default dialer deny list does not block, to read service responses and enumerate internal hosts and ports through error messages. |
| A security vulnerability was discovered in Fleet's Helm template preprocessing where templates evaluated by the Fleet controller could reach network resources outside the management cluster. A user who can supply bundle content to a repository referenced by a `GitRepo` resource can cause the Fleet controller to:
- Disclose cluster metadata available to the templating context.
- Reveal information about hosts reachable from the controller's network position.
Because the disclosure channel is name resolution, it may remain effective in environments where outbound traffic is otherwise restricted. The disclosed information is limited to values exposed to the Fleet templating context and to name resolution results. Integrity and availability of managed clusters are not affected.
This issue affects Fleet:
from 0.12.0 before 0.12.19,
from 0.13.0 before 0.13.15,
from 0.14.0 before 0.14.10,
from 0.15.0 before 0.15.6, and
from 0.16.0 before 0.16.1. |
| 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. |
| The PowerPress Podcasting plugin by Blubrry WordPress plugin before 11.17.11 does not validate the destination of redirects when fetching a user-supplied media URL, allowing users with the contributor role and above to perform Server-Side Request Forgery attacks against internal services. |
| Feehi CMS 2.1.1 contains a Server-Side Request Forgery (SSRF) vulnerability in the UEditor catchimage endpoint. The private-IP validation does not block loopback or link-local addresses, allowing an attacker to make the server probe internal HTTP services through response differences. |
| An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18.
An incomplete fix for CVE-2026-15307 in Django spatial lookups allows an attacker who can supply `bytes` values to cause the Django process to make network requests via a crafted VRT document referencing an external raster source.
Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.
Django would like to thank sicksec for reporting this issue. |
| Microsoft UFO is an open-source framework for intelligent automation across devices and platforms. Prior to 3.0.9, authenticated device registration through /api/devices can supply a permitted attacker-controlled WebSocket endpoint while aip/transport/websocket.py applies pinned_addresses only to the initial destination. The pinned websockets.connect() client follows cross-origin redirects and opens a new TCP connection before Galaxy performs its post-handshake peer-IP validation, allowing WebSocket upgrade requests to internal hosts reachable from the server. The confirmed impact is the internal connection and handshake request, and does not establish arbitrary HTTP methods, response-body disclosure, a completed AIP session, or cloud metadata access. This issue is fixed in version 3.0.9. |
| A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed a repository contributor to cause the appliance to issue requests to attacker-controlled internal hosts, which could be chained to achieve remote code execution on the appliance. The secret scanning validator for GCP service account credentials trusted the token endpoint embedded in a committed credential and issued a request to it without restricting the destination. Exploitation required an authenticated user with permission to push to a repository on an instance with GitHub Advanced Security and secret scanning validity checks enabled, a non-default configuration. This vulnerability affected GitHub Enterprise Server 3.20, 3.21, and 3.22 and was fixed in versions 3.20.9, 3.21.7, and 3.22.2. This vulnerability was reported through the GitHub Bug Bounty program. |
| 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. |
| Backstage 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. |
| 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. |
| Backstage 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. |
| 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. |
| 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. |
