| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Files in the source code contain login credentials for the admin user and the property configuration password, allowing an attacker to get full access to the application. |
| All communication with the REST API is unencrypted (HTTP), allowing an attacker to intercept traffic between an actor and the webserver. This leads to the possibility of information gathering and downloading media files. |
| A remote unauthorized attacker may gather sensitive information of the application, due to missing authorization of configuration settings of the product. |
| The web application is susceptible to cross-site-scripting attacks. An attacker who can create new dashboard widgets can inject malicious JavaScript code into the Transform Function which will be executed when the widget receives data from its data source. |
| For failed login attempts, the application returns different error messages depending on whether the login failed due to an incorrect password or a non-existing username. This allows an attacker to guess usernames until they find an existing one. |
| The application is vulnerable to Server-Side Request Forgery (SSRF). An endpoint can be used to send server internal requests to other ports. |
| The application sends user credentials as URL parameters instead of POST bodies, making it vulnerable to information gathering. |
| Linked URLs during the creation of iFrame widgets and dashboards are vulnerable to code execution. The URLs get embedded as iFrame widgets, making it possible to attack other users that access the dashboard by including malicious code. The attack is only possible if the attacker is authorized to create new dashboards or iFrame widgets. |
| Certain requests pass the authentication token in the URL as string query parameter, making it vulnerable to theft through server logs, proxy logs and Referer headers, which could allow an attacker to hijack the user's session and gain unauthorized access. |
| The application discloses all used components, versions and license information to unauthenticated actors, giving attackers the opportunity to target known security vulnerabilities of used components. |
| Certain error messages returned by the application expose internal system details that should not be visible to end users, providing attackers with valuable reconnaissance information (like file paths, database errors, or software versions) that can be used to map the application's internal structure and discover other, more critical vulnerabilities. |
| The credentials of the users stored in the system's local database can be used for the log in, making it possible for an attacker to gain unauthorized access. This could potentially affect the confidentiality of the application. |
| JavaScript can be ran inside the address bar via the dashboard "Open in new Tab" Button, making the application vulnerable to session hijacking. |
| Multiple endpoints with sensitive information do not require authentication, making the application susceptible to information gathering. |
| For failed login attempts, the application returns different error messages depending on whether the login failed due to an incorrect password or a non-existing username. This allows an attacker to guess usernames until they find an existing one. |
| The application does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it possible for an attacker to guess user credentials. |
| When an error occurs in the application a full stacktrace is provided to the user. The stacktrace lists class and method names as well as other internal information. An attacker thus receives information about the technology used and the structure of the application. |
| It's possible to brute force folders and files, what can be used by an attacker to steal sensitve information. |
| A remote, unauthorized attacker can brute force folders and files and read them like private keys or configurations, making the application vulnerable for gathering sensitive information. |
| A user with the appropriate authorization can create any number of user accounts via an API endpoint using a POST request. There are no quotas, checking mechanisms or restrictions to limit the creation. |
