| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An unrestricted file upload vulnerability exists in Ivanti Avalanche before 6.3.3 allows an attacker with access to the Inforail Service to write dangerous files. |
| An issue was discovered in Zammad before 4.1.1. The Form functionality allows remote code execution because deserialization is mishandled. |
| Thales Safenet Authentication Client (SAC) for Linux and Windows through 10.7.7 creates insecure temporary hid and lock files allowing a local attacker, through a symlink attack, to overwrite arbitrary files, and potentially achieve arbitrary command execution with high privileges. |
| A vulnerability has been identified in ModelSim Simulation (All versions), Questa Simulation (All versions). The RSA white-box implementation in affected applications insufficiently protects the built-in private keys that are required to decrypt electronic intellectual property (IP) data in accordance with the IEEE 1735 recommended practice. This could allow a sophisticated attacker to discover the keys, bypassing the protection intended by the IEEE 1735 recommended practice. |
| A vulnerability has been identified in Mendix Applications using Mendix 7 (All versions < V7.23.26), Mendix Applications using Mendix 8 (All versions < V8.18.12), Mendix Applications using Mendix 9 (All versions < V9.6.1). Applications built with affected versions of Mendix Studio Pro do not prevent file documents from being cached when files are opened or downloaded using a browser. This could allow a local attacker to read those documents by exploring the browser cache. |
| Apache Superset up to and including 1.3.1 allowed for database connections password leak for authenticated users. This information could be accessed in a non-trivial way. |
| Apache Karaf allows monitoring of applications and the Java runtime by using the Java Management Extensions (JMX). JMX is a Java RMI based technology that relies on Java serialized objects for client server communication. Whereas the default JMX implementation is hardened against unauthenticated deserialization attacks, the implementation used by Apache Karaf is not protected against this kind of attack. The impact of Java deserialization vulnerabilities strongly depends on the classes that are available within the targets class path. Generally speaking, deserialization of untrusted data does always represent a high security risk and should be prevented. The risk is low as, by default, Karaf uses a limited set of classes in the JMX server class path. It depends of system scoped classes (e.g. jar in the lib folder). |
| An authentication bypass (account takeover) vulnerability exists in Premiumdatingscript 4.2.7.7 due to a weak password reset mechanism in requests\user.php. |
| Deno <=1.14.0 file sandbox does not handle symbolic links correctly. When running Deno with specific write access, the Deno.symlink method can be used to gain access to any directory. |
| In Gradle Enterprise before 2021.1.3, a crafted request can trigger deserialization of arbitrary unsafe Java objects. The attacker must have the encryption and signing keys. |
| Hitachi Content Platform Anywhere (HCP-AW) 4.4.5 and later allows information disclosure. If authenticated user creates a link to a file or folder while the system was running version 4.3.x or earlier and then shares the link and then later deletes the file or folder without deleting the link and before the link expires. If the system has been upgraded to version 4.4.5 or 4.5.0 a malicious user with the link could browse and download all files of the authenticated user that created the link . |
| Leostream Connection Broker 9.0.40.17 allows administrators to conduct directory traversal attacks by uploading z ZIP file that contains a symbolic link. |
| A vulnerability has been identified in Climatix POL909 (AWB module) (All versions < V11.44), Climatix POL909 (AWM module) (All versions < V11.36). The handling of log files in the web application of affected devices contains an information disclosure vulnerability which could allow logged in users to access sensitive files. |
| QVIS NVR DVR before 2021-12-13 is vulnerable to Remote Code Execution via Java deserialization. |
| ECOA BAS controller’s special page displays user account and passwords in plain text, thus unauthenticated attackers can access the page and obtain privilege with full functionality. |
| ECOA BAS controller is vulnerable to weak access control mechanism allowing authenticated user to remotely escalate privileges by disclosing credentials of administrative accounts in plain-text. |
| ECOA BAS controller uses weak set of default administrative credentials that can be easily guessed in remote password attacks and gain full control of the system. |
| rails_multisite provides multi-db support for Rails applications. In affected versions this vulnerability impacts any Rails applications using `rails_multisite` alongside Rails' signed/encrypted cookies. Depending on how the application makes use of these cookies, it may be possible for an attacker to re-use cookies on different 'sites' within a multi-site Rails application. The issue has been patched in v4 of the `rails_multisite` gem. Note that this upgrade will invalidate all previous signed/encrypted cookies. The impact of this invalidation will vary based on the application architecture. |
| Pterodactyl is an open-source game server management panel built with PHP 7, React, and Go. A malicious user can modify the contents of a `confirmation_token` input during the two-factor authentication process to reference a cache value not associated with the login attempt. In rare cases this can allow a malicious actor to authenticate as a random user in the Panel. The malicious user must target an account with two-factor authentication enabled, and then must provide a correct two-factor authentication token before being authenticated as that user. Due to a validation flaw in the logic handling user authentication during the two-factor authentication process a malicious user can trick the system into loading credentials for an arbitrary user by modifying the token sent to the server. This authentication flaw is present in the `LoginCheckpointController@__invoke` method which handles two-factor authentication for a user. This controller looks for a request input parameter called `confirmation_token` which is expected to be a 64 character random alpha-numeric string that references a value within the Panel's cache containing a `user_id` value. This value is then used to fetch the user that attempted to login, and lookup their two-factor authentication token. Due to the design of this system, any element in the cache that contains only digits could be referenced by a malicious user, and whatever value is stored at that position would be used as the `user_id`. There are a few different areas of the Panel that store values into the cache that are integers, and a user who determines what those cache keys are could pass one of those keys which would cause this code pathway to reference an arbitrary user. At its heart this is a high-risk login bypass vulnerability. However, there are a few additional conditions that must be met in order for this to be successfully executed, notably: 1.) The account referenced by the malicious cache key must have two-factor authentication enabled. An account without two-factor authentication would cause an exception to be triggered by the authentication logic, thusly exiting this authentication flow. 2.) Even if the malicious user is able to reference a valid cache key that references a valid user account with two-factor authentication, they must provide a valid two-factor authentication token. However, due to the design of this endpoint once a valid user account is found with two-factor authentication enabled there is no rate-limiting present, thusly allowing an attacker to brute force combinations until successful. This leads to a third condition that must be met: 3.) For the duration of this attack sequence the cache key being referenced must continue to exist with a valid `user_id` value. Depending on the specific key being used for this attack, this value may disappear quickly, or be changed by other random user interactions on the Panel, outside the control of the attacker. In order to mitigate this vulnerability the underlying authentication logic was changed to use an encrypted session store that the user is therefore unable to control the value of. This completely removed the use of a user-controlled value being used. In addition, the code was audited to ensure this type of vulnerability is not present elsewhere. |
| Scrapy is a high-level web crawling and scraping framework for Python. If you use `HttpAuthMiddleware` (i.e. the `http_user` and `http_pass` spider attributes) for HTTP authentication, all requests will expose your credentials to the request target. This includes requests generated by Scrapy components, such as `robots.txt` requests sent by Scrapy when the `ROBOTSTXT_OBEY` setting is set to `True`, or as requests reached through redirects. Upgrade to Scrapy 2.5.1 and use the new `http_auth_domain` spider attribute to control which domains are allowed to receive the configured HTTP authentication credentials. If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.5.1 is not an option, you may upgrade to Scrapy 1.8.1 instead. If you cannot upgrade, set your HTTP authentication credentials on a per-request basis, using for example the `w3lib.http.basic_auth_header` function to convert your credentials into a value that you can assign to the `Authorization` header of your request, instead of defining your credentials globally using `HttpAuthMiddleware`. |
