CVE-2025-61778

{"id": "CVE-2025-61778", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2025-61778", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "partial"}], "version": "2.0.3", "timestamp": "2025-10-06T17:05:20.929457Z"}}], "cvssMetricV40": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 9.3, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "valueDensity": "NOT_DEFINED", "vectorString": "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED"}}]}, "affected": [{"source": "security-advisories@github.com", "affectedData": [{"vendor": "akkadotnet", "product": "akka.net", "versions": [{"status": "affected", "version": ">= 1.2.0, < 1.5.52"}]}]}], "published": "2025-10-06T17:16:08.297", "references": [{"url": "https://getakka.net/articles/remoting/security.html", "source": "security-advisories@github.com"}, {"url": "https://github.com/akkadotnet/akka.net/pull/7847", "source": "security-advisories@github.com"}, {"url": "https://github.com/akkadotnet/akka.net/pull/7851", "source": "security-advisories@github.com"}, {"url": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52", "source": "security-advisories@github.com"}, {"url": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5", "source": "security-advisories@github.com"}], "vulnStatus": "Deferred", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-290"}, {"lang": "en", "value": "CWE-295"}, {"lang": "en", "value": "CWE-306"}]}], "descriptions": [{"lang": "en", "value": "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."}, {"lang": "es", "value": "Akka.NET es un puerto .NET del proyecto Akka de la comunidad Scala / Java. En todas las versiones de Akka.Remote desde la v1.2.0 hasta la v1.5.51, TLS pod\u00eda habilitarse a trav\u00e9s de nuestro transporte 'akka.remote.dot-netty.tcp' y esto aplicar\u00eda correctamente la validaci\u00f3n de clave privada en el lado del servidor de las conexiones entrantes. Akka.Remote, sin embargo, nunca pidi\u00f3 al cliente de conexi\u00f3n saliente que presentara SU certificado; por lo tanto, es posible que partes no confiables se conecten a un cl\u00faster de Akka.NET con clave privada y comiencen a comunicarse con \u00e9l sin ning\u00fan certificado. El problema aqu\u00ed es que para que la autenticaci\u00f3n basada en certificados funcione correctamente, asegurando que todos los miembros de la red Akka.Remote est\u00e9n protegidos con la misma clave privada, Akka.Remote necesitaba implementar TLS mutuo. Este no era el caso antes de Akka.NET v1.5.52. Aquellos que ejecutan Akka.NET dentro de una red privada que controlan completamente o que nunca usaron TLS en primer lugar ahora est\u00e1n afectados por el error. Sin embargo, aquellos que usan TLS para proteger sus redes deben actualizar a Akka.NET V1.5.52 o posterior. Un parche fuerza la sem\u00e1ntica de 'fallo r\u00e1pido' si TLS est\u00e1 habilitado pero la clave privada falta o es inv\u00e1lida. Las versiones anteriores solo verificar\u00edan eso una vez que ocurrieran los intentos de conexi\u00f3n. El segundo parche, una correcci\u00f3n cr\u00edtica, aplica TLS mutuo (mTLS) por defecto, por lo que ambas partes deben estar cifradas usando el mismo certificado. Como soluci\u00f3n alternativa, evite exponer la aplicaci\u00f3n p\u00fablicamente para evitar que la vulnerabilidad tenga un impacto pr\u00e1ctico en la aplicaci\u00f3n de uno. Sin embargo, los mantenedores a\u00fan recomiendan actualizar a la versi\u00f3n 1.5.52."}], "lastModified": "2026-10-09T10:10:00.193", "sourceIdentifier": "security-advisories@github.com"}