CVE-2020-37094
EspoCRM 5.7.0 prior to 5.9.0 contains an authentication token reuse vulnerability that allows authenticated attackers to bypass two-factor a
CVSS
8.1
Alto
EPSS
0.5%
p37
KEV
—
Exploit Today
11
0-100
Publicado: 3 feb 2026 · Última mod.: 15 jul 2026 · CWE-303
0.5%EPSS · 30 días0.5%
2026-06-302026-07-18
EspoCRM 5.7.0 prior to 5.9.0 contains an authentication token reuse vulnerability that allows authenticated attackers to bypass two-factor authentication by exploiting token-to-password-hash mapping in application/Espo/Core/Utils/Authentication/Espo.php. Attackers can obtain an authentication token for a controlled account and replay it against any victim account sharing the same password, since tokens are bound to password hashes rather than unique per-user values, bypassing the victim's 2FA protections.
- github.comhttps://github.com/espocrm/espocrm/commit/b299220dd0c7acdaa1ed8be8ffd79c7985093c7a
- www.espocrm.comhttps://www.espocrm.com
- www.exploit-db.comhttps://www.exploit-db.com/exploits/48376
- www.vulncheck.comhttps://www.vulncheck.com/advisories/espocrm-two-factor-auth-bypass-via-auth-token-reuse-between-accounts-with-identical-passwords
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-127737.3 ALT45.3%
——14A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.4dCVE-2026-335579.1 CRÍ43.9%
——13A possible security vulnerability has been identified in Apache Kafka.
By default, the broker property `sasl.oauthbearer.jwt.validator.class` is set to `org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator`. It accepts any JWT token without validating its signature, issuer, or audience. An attacker can generate a JWT token from any issuer with the `preferred_username` set to any user, and the broker will accept it.
We advise the Kafka users using kafka v4.1.0 or v4.1.1 to set the config `sasl.oauthbearer.jwt.validator.class` to `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator` explicitly to avoid this vulnerability. Since Kafka v4.1.2 and v4.2.0 and later, the issue is fixed and will correctly validate the JWT token.4dCVE-2026-473008.8 ALT41.7%
——13Incorrect implementation of authentication algorithm in ASP.NET Core allows an authorized attacker to elevate privileges over a network.3dCVE-2026-503608.8 ALT41.7%
——13Incorrect implementation of authentication algorithm in Windows SMB Server allows an authorized attacker to elevate privileges over a network.3dCVE-2026-355799.8 CRÍ40.1%
——12CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary.
An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.
This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only.4dCVE-2026-436408.1 ALT39.7%
——12Bitwarden Server prior to v2026.4.1 does not require master-password re-authentication when retrieving or rotating an organization's SCIM API key, allowing an authenticated user with SCIM management privileges to obtain the key using only a valid session.4d