CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
Windows NTLM V1 Elevation of Privilege Vulnerability |
The CraftCMS plugin Two-Factor Authentication through 3.3.3 allows reuse of TOTP tokens multiple times within the validity period. |
ESPHome is a system to control microcontrollers remotely through Home Automation systems. In version 2025.8.0 in the ESP-IDF platform, ESPHome's web_server authentication check can pass incorrectly when the client-supplied base64-encoded Authorization value is empty or is a substring of the correct value. This allows access to web_server functionality (including OTA, if enabled) without knowing any information about the correct username or password. This issue has been patched in version 2025.8.1. |
An authentication bypass vulnerability has been identified in the REST and SOAP API components of Tripwire Enterprise (TE) 9.1.0 when TE is configured to use LDAP/Active Directory SAML authentication and its optional "Auto-synchronize LDAP Users, Roles, and Groups" feature is enabled. This vulnerability allows unauthenticated attackers to bypass authentication if a valid username is known. Exploitation of this vulnerability could allow remote attackers to gain privileged access to the APIs and lead to unauthorized information disclosure or modification. |
An authentication bypass vulnerability was present in the GitHub Enterprise Server (GHES) when utilizing SAML single sign-on authentication with the optional encrypted assertions feature. This vulnerability allowed an attacker to forge a SAML response to provision and/or gain access to a user with site administrator privileges. Exploitation of this vulnerability would allow unauthorized access to the instance without requiring prior authentication. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13.0 and was fixed in versions 3.9.15, 3.10.12, 3.11.10 and 3.12.4. This vulnerability was reported via the GitHub Bug Bounty program. |
Asterisk is an open source private branch exchange and telephony toolkit. After upgrade to 18.23.0, ALL unauthorized SIP requests are identified as PJSIP Endpoint of local asterisk server. This vulnerability is fixed in 18.23.1, 20.8.1, and 21.3.1.
|
eLabFTW is an open source electronic lab notebook for research labs. A vulnerability has been found starting in version 4.6.0 and prior to version 5.1.0 that allows an attacker to bypass eLabFTW's built-in multifactor authentication mechanism. An attacker who can authenticate locally (by knowing or guessing the password of a user) can thus log in regardless of MFA requirements. This does not affect MFA that are performed by single sign-on services. Users are advised to upgrade to at least version 5.1.9 to receive a fix. |
Inappropriate implementation in File Picker in Google Chrome prior to 139.0.7258.127 allowed a remote attacker who convinced a user to engage in specific UI gestures to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
D-Link DIR-2640 HNAP PrivateLogin Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the web management interface, which listens on TCP port 80 by default. A crafted XML element in the login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system.
. Was ZDI-CAN-19545. |
D-Link DIR-2640 HNAP LoginPassword Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of D-Link DIR-2640 routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the web management interface, which listens on TCP port 80 by default. A specially crafted login request can cause authentication to succeed without providing proper credentials. An attacker can leverage this vulnerability to bypass authentication on the system.
. Was ZDI-CAN-19549. |
Multiple Zoho ManageEngine on-premise products, such as ServiceDesk Plus through 14003, allow remote code execution due to use of Apache Santuario xmlsec (aka XML Security for Java) 1.4.1, because the xmlsec XSLT features, by design in that version, make the application responsible for certain security protections, and the ManageEngine applications did not provide those protections. This affects Access Manager Plus before 4308, Active Directory 360 before 4310, ADAudit Plus before 7081, ADManager Plus before 7162, ADSelfService Plus before 6211, Analytics Plus before 5150, Application Control Plus before 10.1.2220.18, Asset Explorer before 6983, Browser Security Plus before 11.1.2238.6, Device Control Plus before 10.1.2220.18, Endpoint Central before 10.1.2228.11, Endpoint Central MSP before 10.1.2228.11, Endpoint DLP before 10.1.2137.6, Key Manager Plus before 6401, OS Deployer before 1.1.2243.1, PAM 360 before 5713, Password Manager Pro before 12124, Patch Manager Plus before 10.1.2220.18, Remote Access Plus before 10.1.2228.11, Remote Monitoring and Management (RMM) before 10.1.41. ServiceDesk Plus before 14004, ServiceDesk Plus MSP before 13001, SupportCenter Plus before 11026, and Vulnerability Manager Plus before 10.1.2220.18. Exploitation is only possible if SAML SSO has ever been configured for a product (for some products, exploitation requires that SAML SSO is currently active). |
Microsoft SharePoint Server Elevation of Privilege Vulnerability |
Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass authentication of the admin panel. |
immich is a high performance self-hosted photo and video management solution. Prior to 1.132.0, immich is vulnerable to account hijacking through oauth2, because the state parameter is not being checked. The oauth2 state parameter is similar to a csrf token, so when the user starts the login flow this unpredictable token is generated and somehow saved in the browser session and passed to the identity provider, which will return the state parameter when redirecting the user back to immich. Before the user is logged in that parameter needs to be verified to make sure the login was actively initiated by the user in this browser session. On it's own, this wouldn't be too bad, but when immich uses the /user-settings page as a redirect_uri, it will automatically link the accounts if the user was already logged in. This means that if someone has an immich instance with a public oauth provider (like google), an attacker can - for example - embed a hidden iframe in a webpage or even just send the victim a forged oauth login url with a code that logs the victim into the attackers oauth account and redirects back to immich and links the accounts. After this, the attacker can log into the victims account using their own oauth credentials. This vulnerability is fixed in 1.132.0. |
Mattermost versions 10.5.x <= 10.5.1, 10.4.x <= 10.4.3, 9.11.x <= 9.11.9 fail to invalidate the cache when a user account is converted to a bot which allows an attacker to login to the bot exactly one time via normal credentials. |
Mattermost versions 10.7.x <= 10.7.0, 10.6.x <= 10.6.2, 10.5.x <= 10.5.3, 9.11.x <= 9.11.12 fail to clear Google OAuth credentials when converting user accounts to bot accounts, allowing attackers to gain unauthorized access to bot accounts via the Google OAuth signup flow. |
A state machine transition flaw in the Bluetooth Low Energy (BLE) stack of Cypress PSoC4 v3.66 allows attackers to bypass the pairing process and authentication via a crafted pairing_failed packet. |
Mattermost versions 10.7.x <= 10.7.0, 10.6.x <= 10.6.2, 10.5.x <= 10.5.3, 9.11.x <= 9.11.12 fails to properly invalidate personal access tokens upon user deactivation, allowing deactivated users to maintain full system access by exploiting access token validation flaws via continued usage of previously issued tokens. |
An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. DTLS servers allow remote attackers to reuse the same epoch number within two times the TCP maximum segment lifetime, which is prohibited in RFC6347. This vulnerability allows remote attackers to obtain sensitive application (data of connected clients). |
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary:
Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].
Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.
However, Kafka's SCRAM implementation did not perform this validation.
Impact:
This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly
discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].
Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted:
If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.
To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details:
The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions:
Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions:
3.9.0
3.8.1
3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation:
Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication:
Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms:
Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security. |