| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Applications that use spring-boot-loader or spring-boot-loader-classic and contain custom code that performs signature verification of nested jar files may be vulnerable to signature forgery where content that appears to have been signed by one signer has, in fact, been signed by another. |
| Oqtane Framework 6.0.0 is vulnerable to Incorrect Access Control. By manipulating the entityid parameter, attackers can bypass passcode validation and successfully log into the application or access restricted data without proper authorization. The lack of server-side validation exacerbates the issue, as the application relies on client-side information for authentication. |
| Bypass vulnerability in the authentication method in the GTT Tax Information System application, related to the Active Directory (LDAP) login method.
Authentication is performed through a local WebSocket, but the web application does not properly validate the authenticity or origin of the data received, allowing an attacker with access to the local machine or internal network to impersonate the legitimate WebSocket and inject manipulated information.
Exploiting this vulnerability could allow an attacker to authenticate as any user in the domain, without the need for valid credentials, compromising the confidentiality, integrity, and availability of the application and its data. |
| Authentication Bypass by Spoofing vulnerability in wpdevart Coming soon and Maintenance mode allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Coming soon and Maintenance mode: from n/a through 3.7.3. |
| fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 5.0.6, the fast-jwt library does not properly validate the iss claim based on the RFC 7519. The iss (issuer) claim validation within the fast-jwt library permits an array of strings as a valid iss value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an iss claim structured as ['https://attacker-domain/', 'https://valid-iss']. Due to the permissive validation, the JWT will be deemed valid. Furthermore, if the application relies on external libraries like get-jwks that do not independently validate the iss claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the iss array, alongside the legitimate issuer, and bypass the intended security checks. This issue is fixed in 5.0.6. |
| A Secure Boot Bypass Vulnerability exists in affected Access Points that allows an adversary to bypass the hardware root of trust verification in place to ensure only vendor-signed firmware can execute on the device. An adversary can exploit this vulnerability to run modified or custom firmware on affected Access Points. |
| Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable. |
| Wi-SUN unexpected 4- Way Handshake packet receptions may lead to predictable keys and potentially leading to Man in the middle (MitM) attack |
| Francois Jacquet RosarioSIS v12.0.0 was discovered to contain a content spoofing vulnerability in the Theme configuration under the My Preferences module. This vulnerability allows attackers to manipulate application settings. |
| On IROAD X5 devices, a Bypass of Device Pairing can occur via MAC Address Spoofing. The dashcam's pairing mechanism relies solely on MAC address verification, allowing an attacker to bypass authentication by spoofing an already-paired MAC address that can be captured via an ARP scan. |
| Stroom is a data processing, storage and analysis platform. A vulnerability exists starting in version 7.2-beta.53 and prior to versions 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2 that allows authentication bypass to a Stroom system when configured with ALB and installed in a way that the application is accessible not through the ALB itself. This vulnerability may also allow for server-side request forgery which may lead to code execution or further privileges escalations when using the AWS metadata URL. This scenario assumes that Stroom must be configured to use ALB Authentication integration and the application is network accessible. The vulnerability has been fixed in versions 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2. |
| Improper session management in GCOM EPON 1GE ONU version C00R371V00B01 allows attackers to execute a session hijacking attack via spoofing the IP address of an authenticated user. |
| Authentication Bypass by Spoofing vulnerability in 10up Restricted Site Access allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Restricted Site Access: from n/a through 7.4.1. |
| Authentication Bypass by Spoofing vulnerability in Stefano Lissa & The Newsletter Team Newsletter allows Functionality Bypass.This issue affects Newsletter: from n/a through 8.2.0. |
| On affected platforms running Arista EOS, maliciously formed UDP packets with source port 3503 may be accepted by EOS. UDP Port 3503 is associated with LspPing Echo Reply. This can result in unexpected behaviors, especially for UDP based services that do not perform some form of authentication. |
| A security vulnerability was identified in Obsidian Scheduler's REST API 5.0.0 thru 6.3.0. If an account is locked out due to not enrolling in MFA (e.g. after the 7-day enforcement window), the REST API still allows the use of Basic Authentication to authenticate and perform administrative actions. In particular, the default admin account was found to be locked out via the web interface but still usable through the REST API. This allowed creation of a new privileged user, bypassing MFA protections. This undermines the intended security posture of MFA enforcement. |
| Yealink RPS before 2025-06-27 allows unauthorized access to information, including AutoP URL addresses. This was fixed by deploying an enhanced authentication mechanism through a security update to all cloud instances. |
| Akka.NET is a .NET port of the Akka project from the Scala / Java community. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. Those who run Akka.NET inside a private network that they fully control or who were never using TLS in the first place are now affected by the bug. However, those who use TLS to secure their networks must upgrade to Akka.NET V1.5.52 or later. One patch forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. The second patch, a critical fix, enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. As a workaround, avoid exposing the application publicly to avoid the vulnerability having a practical impact on one's application. However, upgrading to version 1.5.52 is still recommended by the maintainers. |
| An issue was discovered in Kurmi Provisioning Suite 7.9.0.33. If an X-Forwarded-For header is received during authentication, the Kurmi application will record the (possibly forged) IP address mentioned in that header rather than the real IP address that the user logged in from. This fake IP address can later be displayed in the My Account popup that shows the IP address that was used to log in. |
| A cryptographic authentication bypass vulnerability exists in OneLogin AD Connector prior to 6.1.5 due to the exposure of a tenant’s SSO JWT signing key via the /api/adc/v4/configuration endpoint. An attacker in possession of the signing key can craft valid JWT tokens impersonating arbitrary users within a OneLogin tenant. The tokens allow authentication to the OneLogin SSO portal and all downstream applications federated via SAML or OIDC. This allows full unauthorized access across the victim’s SaaS environment. |
