Skip to content
Fencer Vulns
critical 9.3

CVE-2025-61778 json

Akka.Remote TLS did not properly implement certificate-based authentication

published 2025-10-06 13 mo ago modified 2026-10-09 31 d ago also GHSA-jhpv-4q4f-43g5 , EUVD-2025-31919

cvss
9.3
version 4.0, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 23%
public exploits
0
none known

Summary

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.

Patch / fix

  • nuget Akka.Remote 1.5.52
  • nuget Akka.Cluster 1.5.52

CISA SSVC

Exploitation
none
Automatable
yes
Technical impact
partial
Assessed
13 mo ago

Exploit prediction

0.31% chance of exploitation in the next 30 days, higher than 23% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 4.0 9.3 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
CNA 4.0 9.3 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:X/V:X/RE:X/U:X

Affected packages

ecosystem package affected fixed in
nuget Akka.Remote
>=1.2.0, <1.5.52
1.5.52
nuget Akka.Cluster
>=1.2.0, <1.5.52
1.5.52

Affected products

  • akkadotnet akka.net

Classification

Weakness
  • CWE-290 Authentication Bypass by Spoofing
  • CWE-295 Improper Certificate Validation
  • CWE-306 Missing Authentication for Critical Functionality

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.