Cyber Resilience

CVE-2025-61778

Critical

Published: 06 October 2025

Published
06 October 2025
Modified
15 April 2026
KEV Added
Patch
CVSS Score v4 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
EPSS Score 0.0008 23.9th percentile
Risk Priority 19 60% EPSS · 20% KEV · 20% CVSS

Summary

CVE-2025-61778 is a critical-severity Authentication Bypass by Spoofing (CWE-290) vulnerability. Its CVSS base score is 9.3 (Critical).

Operationally, ranked at the 23.9th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

EU & UK References

Vulnerability details

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…

more

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.

CWE(s)

Related Threats

No named actor attribution yet. ATT&CK technique mapping in progress for this CVE.

Affected Assets

Previous
inferred from references and description; NVD did not file a CPE for this CVE

Mitigating Controls

Likely Mitigating Controls AI

Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.

addresses: CWE-306 CWE-290

Requires authentication of devices prior to connection, preventing exploitation of missing authentication for critical network functions.

addresses: CWE-306 CWE-290

Requires authentication for non-organizational users, preventing access to critical functions without proper identification and authentication.

addresses: CWE-306 CWE-290

Mandates authentication prior to establishing communications with services, preventing missing authentication for this critical function.

addresses: CWE-306

Requires established identification and authentication to unlock, mitigating missing authentication for continued system access.

addresses: CWE-306

Requiring identification and rationale for actions allowed without authentication ensures critical functions are not left unprotected by forcing review of authentication requirements.

addresses: CWE-306

Authorizing mobile device connections to organizational systems ensures authentication is performed for this critical access function.

addresses: CWE-306

Guarantees critical functions are protected by mandatory invocation of the access control mechanism.

addresses: CWE-290

Reveals spoofed logon attempts through unexpected previous logon timestamps upon legitimate login.

References