| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Xiaongmai AHB7008T-MH-V2, AHB7804R-ELS, AHB7804R-MH-V2, AHB7808R-MS-V2, AHB7808R-MS, AHB7808T-MS-V2, AHB7804R-LMS, HI3518_50H10L_S39 V4.02.R11.7601.Nat.Onvif.20170420, V4.02.R11.Nat.Onvif.20160422, V4.02.R11.7601.Nat.Onvif.20170424, V4.02.R11.Nat.Onvif.20170327, V4.02.R11.Nat.Onvif.20161205, V4.02.R11.Nat.20170301, V4.02.R12.Nat.OnvifS.20170727 is affected by a backdoor in the macGuarder and dvrHelper binaries of DVR/NVR/IP camera firmware due to static root account credentials in the system. |
| DCS-5000L v1.05 and DCS-932L v2.17 and older are affecged by Incorrect Acess Control. The use of the basic authentication for the devices command interface allows attack vectors that may compromise the cameras configuration and allow malicious users on the LAN to access the device. NOTE: This vulnerability only affects products that are no longer supported by the maintainer |
| XSS Hunter Express before 2021-09-17 does not properly enforce authentication requirements for paths. |
| Affected versions of Atlassian Jira Server and Data Center allow authenticated but non-admin remote attackers to edit email batch configurations via an Improper Authorization vulnerability in the /secure/admin/ConfigureBatching!default.jspa endpoint. The affected versions are before version 8.20.7. |
| Affected versions of Atlassian Jira Server and Data Center allow a remote attacker who has had their access revoked from Jira Service Management to enable and disable Issue Collectors on Jira Service Management projects via an Improper Authentication vulnerability in the /secure/ViewCollectors endpoint. The affected versions are before version 8.19.1. |
| Affected versions of Atlassian Jira Server and Data Center allow attackers with access to an administrator account that has had its access revoked to modify projects' Users & Roles settings, via a Broken Authentication vulnerability in the /plugins/servlet/project-config/PROJECT/roles endpoint. The affected versions are before version 8.19.1. |
| Affected versions of Atlassian Jira Server and Data Center allow a user who has had their Jira Service Management access revoked to export audit logs of another user's Jira Service Management project via a Broken Authentication vulnerability in the /plugins/servlet/audit/resource endpoint. The affected versions of Jira Server and Data Center are before version 8.19.1. |
| Affected versions of Atlassian Jira Server and Data Center allow authenticated yet non-administrator remote attackers to edit the File Replication settings via a Broken Access Control vulnerability in the `ReplicationSettings!default.jspa` endpoint. The affected versions are before version 8.6.0, from version 8.7.0 before 8.13.12, and from version 8.14.0 before 8.20.1. |
| Apache Shiro before 1.8.0, when using Apache Shiro with Spring Boot, a specially crafted HTTP request may cause an authentication bypass. Users should update to Apache Shiro 1.8.0. |
| ECOA BAS controller is vulnerable to insecure direct object references that occur when the application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers with general user's privilege can remotely bypass authorization and access the hidden resources in the system and execute privileged functionalities. |
| ECOA BAS controller suffers from an authentication bypass vulnerability. An unauthenticated attacker through cookie poisoning can remotely bypass authentication and disclose sensitive information and circumvent physical access controls in smart homes and buildings and manipulate HVAC. |
| Omikron MultiCash Desktop 4.00.008.SP5 relies on a client-side authentication mechanism. When a user logs into the application, the validity of the password is checked locally. All communication to the database backend is made via the same technical account. Consequently, an attacker can attach a debugger to the process or create a patch that manipulates the behavior of the login function. When the function always returns the success value (corresponding to a correct password), an attacker can login with any desired account, such as the administrative account of the application. |
| FirstUseAuthenticator is a JupyterHub authenticator that helps new users set their password on their first login to JupyterHub. When JupyterHub is used with FirstUseAuthenticator, a vulnerability in versions prior to 1.0.0 allows unauthorized access to any user's account if `create_users=True` and the username is known or guessed. One may upgrade to version 1.0.0 or apply a patch manually to mitigate the vulnerability. For those who cannot upgrade, there is no complete workaround, but a partial mitigation exists. One can disable user creation with `c.FirstUseAuthenticator.create_users = False`, which will only allow login with fully normalized usernames for already existing users prior to jupyterhub-firstuserauthenticator 1.0.0. If any users have never logged in with their normalized username (i.e. lowercase), they will still be vulnerable until a patch or upgrade occurs. |
| FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. By default, SIP requests of the type SUBSCRIBE are not authenticated in the affected versions of FreeSWITCH. Abuse of this security issue allows attackers to subscribe to user agent event notifications without the need to authenticate. This abuse poses privacy concerns and might lead to social engineering or similar attacks. For example, attackers may be able to monitor the status of target SIP extensions. Although this issue was fixed in version v1.10.6, installations upgraded to the fixed version of FreeSWITCH from an older version, may still be vulnerable if the configuration is not updated accordingly. Software upgrades do not update the configuration by default. SIP SUBSCRIBE messages should be authenticated by default so that FreeSWITCH administrators do not need to explicitly set the `auth-subscriptions` parameter. When following such a recommendation, a new parameter can be introduced to explicitly disable authentication. |
| Minio is a Kubernetes native application for cloud storage. All users on release `RELEASE.2021-10-10T16-53-30Z` are affected by a vulnerability that involves bypassing policy restrictions on regular users. Normally, checkKeyValid() should return owner true for rootCreds. In the affected version, policy restriction did not work properly for users who did not have service (svc) or security token service (STS) accounts. This issue is fixed in `RELEASE.2021-10-13T00-23-17Z`. A downgrade back to release `RELEASE.2021-10-08T23-58-24Z` is available as a workaround. |
| 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. |
| October is a Content Management System (CMS) and web platform built on the the Laravel PHP Framework. In affected versions administrator accounts which had previously been deleted may still be able to sign in to the backend using October CMS v2.0. The issue has been patched in v2.1.12 of the october/october package. There are no workarounds for this issue and all users should update. |
| Wire-server is the backing server for the open source wire secure messaging application. In affected versions it is possible to trigger email address change of a user with only the short-lived session token in the `Authorization` header. As the short-lived token is only meant as means of authentication by the client for less critical requests to the backend, the ability to change the email address with a short-lived token constitutes a privilege escalation attack. Since the attacker can change the password after setting the email address to one that they control, changing the email address can result in an account takeover by the attacker. Short-lived tokens can be requested from the backend by Wire clients using the long lived tokens, after which the long lived tokens can be stored securely, for example on the devices key chain. The short lived tokens can then be used to authenticate the client towards the backend for frequently performed actions such as sending and receiving messages. While short-lived tokens should not be available to an attacker per-se, they are used more often and in the shape of an HTTP header, increasing the risk of exposure to an attacker relative to the long-lived tokens, which are stored and transmitted in cookies. If you are running an on-prem instance and provision all users with SCIM, you are not affected by this issue (changing email is blocked for SCIM users). SAML single-sign-on is unaffected by this issue, and behaves identically before and after this update. The reason is that the email address used as SAML NameID is stored in a different location in the databse from the one used to contact the user outside wire. Version 2021-08-16 and later provide a new end-point that requires both the long-lived client cookie and `Authorization` header. The old end-point has been removed. If you are running an on-prem instance with at least some of the users invited or provisioned via SAML SSO and you cannot update then you can block `/self/email` on nginz (or in any other proxies or firewalls you may have set up). You don't need to discriminate by verb: `/self/email` only accepts `PUT` and `DELETE`, and `DELETE` is almost never used. |
| Wire is an open source secure messenger. In affected versions if the an attacker gets an old but valid access token they can take over an account by changing the email. This issue has been resolved in version 3.86 which uses a new endpoint which additionally requires an authentication cookie. See wire-ios-sync-engine and wire-ios-transport references. This is the root advisory that pulls the changes together. |
| Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade limit access to the host to trusted users. Limit access to host volumes to trusted containers. |
