A vulnerability was discovered in GitLab versions before 12.2. GitLab was vulnerable to a SSRF attack through the Outbound Requests feature.
When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab CE/EE affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is limited
For GitLab Runner before 13.0.12, 13.1.6, 13.2.3, by replacing dockerd with a malicious server, the Shared Runner is susceptible to SSRF.
A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. GitLab was vulnerable to a blind SSRF attack through the repository mirroring feature.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.5 prior to 16.9.7, starting from 16.10 prior to 16.10.5, and starting from 16.11 prior to 16.11.2. GitLab was vulnerable to Server Side Request Forgery when an attacker uses a malicious URL in the markdown image value when importing a GitHub repository.
An issue was discovered in GitLab Community and Enterprise Edition before 11.6.10, 11.7.x before 11.7.6, and 11.8.x before 11.8.1. It allows SSRF.
An issue was discovered in GitLab Enterprise Edition before 11.5.8, 11.6.x before 11.6.6, and 11.7.x before 11.7.1. The Jira integration feature is vulnerable to an unauthenticated blind SSRF issue.
A flawed DNS rebinding protection issue was discovered in GitLab CE/EE 10.2 and later in the `url_blocker.rb` which could result in SSRF where the library is utilized.
An issue was discovered in GitLab Community and Enterprise Edition 12.0 through 12.2.1. Non-members were able to comment on merge requests despite the repository being set to allow only project members to do so.
An issue was discovered in GitLab Community and Enterprise Edition 10.1 through 12.2.1. Protections against SSRF attacks on the Kubernetes integration are insufficient, which could have allowed an attacker to request any local network resource accessible from the GitLab server.
An issue was discovered in GitLab Enterprise Edition 10.6 through 12.0.2. The GitHub project integration was vulnerable to an SSRF vulnerability which allowed an attacker to make requests to local network resources. It has Incorrect Access Control.
GitLab Community and Enterprise Editions version 8.3 up to 10.x before 10.3 are vulnerable to SSRF in the Services and webhooks component.
For GitLab before 13.0.12, 13.1.6, 13.2.3 user controlled git configuration settings can be modified to result in Server Side Request Forgery.
An issue was discovered in GitLab Community and Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. There is Server-Side Request Forgery (SSRF) via a loopback address to the validate_localhost function in url_blocker.rb.
An issue was discovered in GitLab Community and Enterprise Edition before 11.4.13, 11.5.x before 11.5.6, and 11.6.x before 11.6.1. It allows SSRF.
An issue was discovered in GitLab Community and Enterprise Edition before 11.x before 11.4.13, 11.5.x before 11.5.6, and 11.6.x before 11.6.1. It allows SSRF.
An issue was discovered in GitLab Community and Enterprise Edition before 11.3.11, 11.4.x before 11.4.8, and 11.5.x before 11.5.1. There is an SSRF vulnerability in the Prometheus integration.
GitLab CE/EE, versions 8.18 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an SSRF vulnerability in webhooks.
A blind SSRF vulnerability was identified in all versions of GitLab EE prior to 15.4.6, 15.5 prior to 15.5.5, and 15.6 prior to 15.6.1 which allows an attacker to connect to a local host.
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4.4 has SSRF.
GitLab EE/CE 8.0.rc1 to 12.9 is vulnerable to a blind SSRF in the FogBugz integration.
GitLab 8.10 and later through 12.9 is vulnerable to an SSRF in a project import note feature.
GitLab EE 3.0 through 12.8.1 allows SSRF. An internal investigation revealed that a particular deprecated service was creating a server side request forgery risk.
GitLab Enterprise Edition (EE) 6.7 and later through 12.5 allows SSRF.
An issue was discovered in GitLab Community and Enterprise Edition 10.2 through 11.11. Multiple features contained Server-Side Request Forgery (SSRF) vulnerabilities caused by an insufficient validation to prevent DNS rebinding attacks.
An issue was discovered in GitLab Community and Enterprise Edition before 11.2.7, 11.3.x before 11.3.8, and 11.4.x before 11.4.3. It allows SSRF.
An issue was discovered in GitLab Community and Enterprise Edition 8.14 through 12.2.1. The Jira integration contains a SSRF vulnerability as a result of a bypass of the current protection mechanisms against this type of attack, which would allow sending requests to any resources accessible in the local network by the GitLab server.
An issue was discovered in GitLab Community and Enterprise Edition before 11.1.7, 11.2.x before 11.2.4, and 11.3.x before 11.3.1. There is Server-Side Request Forgery (SSRF) via the Kubernetes integration, leading (for example) to disclosure of a GCP service token.
An issue has been discovered in GitLab EE affecting all versions starting from 15.10 prior to 17.2.9, from 17.3 prior to 17.3.5, and from 17.4 prior to 17.4.2. Instances with Product Analytics Dashboard configured and enabled could be vulnerable to SSRF attacks.
An external service interaction vulnerability in GitLab EE affecting all versions from 15.11 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2 allows an attacker to send requests from the GitLab server to unintended services.
A vulnerability was discovered in GitLab starting with version 12. GitLab was vulnerable to a blind SSRF attack since requests to shared address space were not blocked.
A vulnerability was discovered in GitLab versions 10.5 to 14.5.4, 14.6 to 14.6.4, and 14.7 to 14.7.1. GitLab was vulnerable to a blind SSRF attack through the Project Import feature.
A DNS rebinding vulnerability in the Irker IRC Gateway integration in all versions of GitLab CE/EE since version 7.9 allows an attacker to trigger Server Side Request Forgery (SSRF) attacks.
A server-side request forgery issue has been discovered in GitLab EE affecting all versions starting from 16.8 prior to 17.1.7, from 17.2 prior to 17.2.5, and from 17.3 prior to 17.3.2. It was possible for an attacker to make requests to internal resources using a custom Maven Dependency Proxy URL
In all versions of GitLab CE/EE since version 8.15, a DNS rebinding vulnerability in Gitea Importer may be exploited by an attacker to trigger Server Side Request Forgery (SSRF) attacks.
In all versions of GitLab CE/EE since version 8.0, a DNS rebinding vulnerability exists in Fogbugz importer which may be used by attackers to exploit Server Side Request Forgery attacks.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.5 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2. Unauthorized external users could perform Server Side Requests via the CI Lint API
The Canto plugin 1.3.0 for WordPress contains blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/tree.php?subdomain=SSRF.
The Canto plugin 1.3.0 for WordPress contains a blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/detail.php?subdomain=SSRF.
The Canto plugin 1.3.0 for WordPress contains blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/get.php?subdomain=SSRF.
The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).
SAP Commerce Cloud (Accelerator Payment Mock), versions - 1808, 1811, 1905, 2005, allows an unauthenticated attacker to submit a crafted request over a network to a particular SAP Commerce module URL which will be processed without further interaction, the crafted request leads to Server Side Request Forgery attack which could lead to retrieval of limited pieces of information about the service with no impact on integrity or availability.
Microstrategy Web 10.4 is vulnerable to Server-Side Request Forgery in the Test Web Service functionality exposed through the path /MicroStrategyWS/. The functionality requires no authentication and, while it is not possible to pass parameters in the SSRF request, it is still possible to exploit it to conduct port scanning. An attacker could exploit this vulnerability to enumerate the resources allocated in the network (IP addresses and services exposed). NOTE: MicroStrategy is unable to reproduce the issue reported in any version of its product
memos is a privacy-first, lightweight note-taking service. In memos 0.13.2, an SSRF vulnerability exists at the /api/resource that allows authenticated users to enumerate the internal network. Version 0.22.0 of memos removes the vulnerable file.
Umbraco is an ASP.NET CMS. Failing webhooks logs are available when solution is not in debug mode. Those logs can contain information that is critical. This vulnerability is fixed in 13.1.1.
SAP NetWeaver application, due to insufficient input validation, allows an attacker to send a crafted request from a vulnerable web application targeting internal systems behind firewalls that are normally inaccessible to an attacker from the external network, resulting in a Server-Side Request Forgery vulnerability. Thus, having a low impact on confidentiality.
Tuta is an encrypted email service. In versions prior to 119.10, an attacker can attach an image in a html mail which is loaded from external resource in the default setting, which should prevent loading of external resources. When displaying emails containing external content, they should be loaded by default only after confirmation by the user. However, it could be recognized that certain embedded images (see PoC) are loaded, even though the "Automatic Reloading of Images" function is disabled by default. The reloading is also done unencrypted via HTTP and redirections are followed. This behavior is unexpected for the user, since the user assumes that external content will only be loaded after explicit manual confirmation. The loading of external content in e-mails represents a risk, because this makes the sender aware that the e-mail address is used, when the e-mail was read, which device is used and expose the user's IP address. Version 119.10 contains a patch for this issue.
All versions of the package github.com/greenpau/caddy-security are vulnerable to Server-side Request Forgery (SSRF) via X-Forwarded-Host header manipulation. An attacker can expose sensitive information, interact with internal services, or exploit other vulnerabilities within the network by exploiting this vulnerability.
A vulnerability in the web-based management interface of Cisco Finesse could allow an unauthenticated, remote attacker to conduct an SSRF attack on an affected system. This vulnerability is due to insufficient validation of user-supplied input for specific HTTP requests that are sent to an affected system. An attacker could exploit this vulnerability by sending a crafted HTTP request to the affected device. A successful exploit could allow the attacker to obtain limited sensitive information for services that are associated to the affected device.
The Starter Templates by FancyWP plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in all versions up to, and including, 2.0.0 via the 'http_request_host_is_external' filter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.