CVE-2025-61778: Akka.Remote TLS did not properly implement certificate-based authentication

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.3%, percentile 22: FIRST’s model estimates a 0.3% chance of exploitation activity in the next 30 days, higher than 22% of all scored CVEs (low). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes Akka.Remote (NuGet) >= 1.2.0, < 1.5.52, fixed in 1.5.52; Akka.Cluster (NuGet) >= 1.2.0, < 1.5.52, fixed in 1.5.52. Check your lockfile, including transitive dependencies.

What it is

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.

From the GitHub advisory

Impact

This is a critical network security vulnerability for Akka.Remote users who have SSL / TLS enabled on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network.

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.

If you are running Akka.NET inside a private network you fully control or you were never using TLS in the first place, then this bug has no impact on you. However: if you are using TLS to secure your network YOU MUST upgrade to Akka.NET V1.5.52 or later.

Weakness type: CWE-290, CWE-295, CWE-306.

Product: Akka.Remote (NuGet) · Assigned by: GitHub_M · Published: 2025-10-06

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Attack requirements: none
• Privileges required: none (no login)
• User interaction: none

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable yes, technical impact partial.
• FIRST EPSS (model of 2026-10-21): 0.31% probability of exploitation activity in the next 30 days; percentile 22.

Timeline

• 2025-10-06 — CVE record last updated
• 2025-10-06 — CVE record published by GitHub_M
• 2025-10-07 — GitHub-reviewed advisory GHSA-jhpv-4q4f-43g5 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-jhpv-4q4f-43g5 github.com
2. CVE.org record CVE-2025-61778 cve.org
3. NVD entry CVE-2025-61778 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. getakka.net getakka.net
5. github.com github.com

Critical NuGet advisories · Today’s Security Digest