CVE-2025-61778
BaseFortify
Publication date: 2025-10-06
Last updated on: 2025-10-08
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| akkadotnet | akka.remote | 1.5.52 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-306 | The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. |
| CWE-290 | This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. |
| CWE-295 | The product does not validate, or incorrectly validates, a certificate. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-61778 is a critical security vulnerability in Akka.Remote (part of Akka.NET) versions 1.2.0 to 1.5.51 where TLS was enabled but mutual TLS (mTLS) was not enforced. While the server side validated its private key for inbound connections, the client side was never required to present its certificate. This allowed untrusted clients to connect to a private key-protected Akka.NET cluster without proper certificate-based authentication, enabling unauthorized communication within the cluster. The root cause was the lack of mutual TLS enforcement, which is necessary to ensure all nodes authenticate each other using certificates. The vulnerability was fixed in Akka.NET v1.5.52 by enforcing mutual TLS by default and adding fail-fast validation of private key access at startup to prevent misconfigurations and unauthorized access. [1, 3, 4]
How can this vulnerability impact me? :
This vulnerability can allow unauthorized and untrusted clients to connect to an Akka.NET cluster that is supposed to be protected by TLS, bypassing certificate-based authentication. This can lead to unauthorized access and communication within the cluster, potentially exposing sensitive data or allowing malicious actors to interfere with cluster operations. Additionally, if the private key is missing or inaccessible, the server may fail silently during TLS handshakes, causing operational issues. The impact is critical in environments where Akka.Remote is exposed or TLS is enabled without mutual authentication. Users running Akka.NET in private networks without TLS or those not exposing the application publicly are less affected, but upgrading to v1.5.52 or later is strongly recommended to mitigate these risks. [1, 3, 5]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability undermines proper authentication and encryption controls required by common security standards and regulations such as GDPR and HIPAA. Without mutual TLS, unauthorized parties can access and communicate within the Akka.NET cluster, potentially leading to unauthorized data access or data breaches. This violates principles of data confidentiality and integrity mandated by these regulations. The fix in Akka.NET v1.5.52, which enforces mutual TLS by default, aligns with compliance requirements by ensuring strong authentication and encrypted communication between all cluster nodes. The maintainers recommend enabling mutual TLS especially in compliance-sensitive environments like PCI-DSS and HIPAA to meet regulatory security standards. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves verifying the TLS and mutual TLS configuration of Akka.Remote nodes. You should check if your Akka.NET version is prior to 1.5.52 and if TLS is enabled without mutual TLS enforcement. On the system, ensure that the server has access to the private key by checking certificate permissions. For Windows, use commands like `icacls` to verify ACLs on private key files. Additionally, monitor for unexpected inbound connections from clients without certificates, which indicates lack of mutual TLS. There are no specific Akka.NET CLI commands provided, but general network scanning tools (e.g., `openssl s_client` to test TLS handshake and certificate presentation) can be used to test if mutual TLS is enforced. For example, you can attempt a TLS connection to the Akka.Remote endpoint and observe if the client certificate is requested or required. [1, 5]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Akka.NET to version 1.5.52 or later, which enforces mutual TLS by default and validates private key access at startup. If upgrading is not immediately possible, avoid exposing Akka.Remote services publicly and restrict access to private networks secured by VPNs. Configure Akka.Remote to enable mutual TLS (`require-mutual-authentication = true`) and ensure `suppress-validation = false` to enforce proper certificate validation. Verify that the application has read access to the private key in the certificate store (on Windows, adjust ACLs using `icacls` if necessary). Use secure certificate management practices such as using the Windows Certificate Store or properly secured certificate files. Avoid using insecure settings like `suppress-validation = true` in production. [1, 2, 3, 5]