← Vulnerability feed

Vulnerability record · CVE-2025-61778 · published 6 October 2025

CVE-2025-61778: Authentication bypass by spoofing vulnerability

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.

9.3 CVSS 4.0 Critical EPSS 0.31% · top 78.8% CWE-290 · Authentication bypass by spoofingCWE-295 · Improper certificate validation Deferred
9.3CVSS 4.0 base score
0.31%EPSS exploitation probability, 30 days
NoNot in CISA KEV
0Affected product versions listed by NVD
5References
17 Jun 2026Last modified by NVD

Description

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.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:

References

LinkTags
https://getakka.net/articles/remoting/security.html
https://github.com/akkadotnet/akka.net/pull/7847
https://github.com/akkadotnet/akka.net/pull/7851
https://github.com/akkadotnet/akka.net/releases/tag/1.5.52
https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5

Track CVE-2025-61778 inside VULONE

Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.

Start free Open in platform

Related vulnerabilities

Same products first, then exploited flaws of the same weakness class.

6.5CVE-2023-50224TP-Link router httpd authentication bypass exposes stored credentialsThe httpd service on affected TP-Link router firmware contains an improper authentication flaw (CWE-290) that lets a network-adjacent attacker bypass…KEVEPSS 16%analysed10.0CVE-2024-54085AMI MegaRAC SPx BMC authentication bypass via Redfish Host InterfaceAMI's SPx BMC implementation contains an authentication bypass reachable remotely through the Redfish Host Interface, classified as CWE-290 (authenti…KEVEPSS 61%analysed9.8CVE-2024-4358Progress Telerik Report Server authentication bypass via spoofingTelerik Report Server 2024 Q1 (10.0.24.305) and earlier on IIS contains an authentication bypass by spoofing (CWE-290). An unauthenticated remote att…KEVEPSS 97%analysed9.8CVE-2022-24112Apache APISIX batch-requests plugin auth bypass enables RCEThe batch-requests plugin in Apache APISIX can be abused to bypass the Admin API IP restriction because a code bug defeats the check that overrides t…KEVEPSS 96%analysed9.8CVE-2022-23131Zabbix Frontend SAML SSO authentication bypass via session spoofingZabbix Frontend fails to verify the user login stored in the session when SAML SSO authentication is enabled, allowing session data to be modified. A…KEVEPSS 96%analysed

Source: NIST National Vulnerability Database (record CVE-2025-61778), CISA KEV, FIRST EPSS (scores of 2026-09-26). This page is refreshed as NVD updates the record.