Akka.Remote CVE-2025-61778

Exploitation requires that TLS/SSL be enabled on the akka.remote.dot-netty.tcp transport (certificate configured with suppress-validation/ssl settings) in an affected version (1.2.0 through 1.5.51) AND that the Akka.Remote endpoint be network-reachable by an untrusted party. By design the flaw needs no client certificate, no authentication, and no user interaction - that absence of mutual TLS is the vulnerability. It is strictly limited by deployment: it has no practical impact when the cluster runs only inside a fully-controlled private/trusted network, or when TLS was never enabled. The documented workaround is to avoid exposing the application publicly; the fix is upgrading to 1.5.52, which enforces mTLS by default and adds fail-fast validation of the private key at startup.

All signals point to a high-severity but conditionally-exploitable authentication bypass (CWE-290). The CVSS 4.0 base score of 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N) correctly reflects that an unauthenticated remote attacker needs only network reachability to the Akka.Remote endpoint to defeat the intended certificate check, gaining high confidentiality and integrity impact over cluster messaging. However, these signals are in tension with real-world exploitation likelihood: EPSS is only 0.31% (22nd percentile), there is no CISA KEV listing, and no public exploit code exists (the referenced GitHub artifacts are patch/test code, not a weaponized exploit). No SSVC decision data was provided in the input. The decisive mitigating factor is deployment-dependent: the vulnerability only has practical impact where operators (a) enabled TLS on the akka.remote.dot-netty.tcp transport expecting it to enforce peer authentication AND (b) exposed that endpoint to untrusted networks - a configuration that is contrary to Akka.NET's own guidance to keep clustering on trusted networks. Therefore this is a genuine high priority for the specific population using TLS as an authentication boundary on reachable endpoints, but a low practical risk for the much larger population running Akka.Remote on private/trusted networks or without TLS. Note a discrepancy: the NVD description text states that private-network and non-TLS users 'are now affected,' which contradicts the authoritative GHSA-jhpv-4q4f-43g5 statement that those deployments have 'no impact' - the GHSA wording should be treated as correct.

An Akka.NET cluster enabled TLS on its Akka.Remote transport expecting that only peers holding the shared certificate could join. An attacker who can reach the cluster's remoting port opens an outbound connection but is never asked to present a client certificate, so the server accepts the unauthenticated peer and the attacker can begin exchanging actor messages with the cluster - reading sensitive messages and injecting its own. No public exploit code exists; exploitation relies on standard Akka.Remote client connectivity.