CVE-2025-61778 (GCVE-0-2025-61778)

Vulnerability from cvelistv5 – Published: 2025-10-06 16:53 – Updated: 2025-10-06 17:05
VLAI
Title
Akka.Remote TLS did not properly implement certificate-based authentication
Summary
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.
Severity
9.3 (Critical)
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
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2025-10-06 17:05 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
  • CWE-295 - Improper Certificate Validation
  • CWE-306 - Missing Authentication for Critical Function
Assigner
GitHub_M CNA under the mitre root
CNA scorecard C 72/100 over 7580 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
akkadotnet akka.net Affected: >= 1.2.0, < 1.5.52
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-61778",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-06T17:05:20.929457Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-06T17:05:33.450Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "akka.net",
          "vendor": "akkadotnet",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.2.0, \u003c 1.5.52"
            }
          ]
        }
      ],
      "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\u0027s possible for untrusted parties to connect to a private key\u0027d 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\u0027s application. However, upgrading to version 1.5.52 is still recommended by the maintainers."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-295",
              "description": "CWE-295: Improper Certificate Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306: Missing Authentication for Critical Function",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-10-06T16:53:41.707Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5"
        },
        {
          "name": "https://github.com/akkadotnet/akka.net/pull/7847",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/akkadotnet/akka.net/pull/7847"
        },
        {
          "name": "https://github.com/akkadotnet/akka.net/pull/7851",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/akkadotnet/akka.net/pull/7851"
        },
        {
          "name": "https://getakka.net/articles/remoting/security.html",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://getakka.net/articles/remoting/security.html"
        },
        {
          "name": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52"
        }
      ],
      "source": {
        "advisory": "GHSA-jhpv-4q4f-43g5",
        "discovery": "UNKNOWN"
      },
      "title": "Akka.Remote TLS did not properly implement certificate-based authentication"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-61778",
    "datePublished": "2025-10-06T16:53:41.707Z",
    "dateReserved": "2025-09-30T19:43:49.901Z",
    "dateUpdated": "2025-10-06T17:05:33.450Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-61778",
      "date": "2026-10-08",
      "epss": "0.00308",
      "percentile": "0.21705"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "akka.net",
                "vendor": "akkadotnet",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003e= 1.2.0, \u003c 1.5.52"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "cveTags": [],
        "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\u0027s possible for untrusted parties to connect to a private key\u0027d 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\u0027s 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 \u0027akka.remote.dot-netty.tcp\u0027 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 \u0027fallo r\u00e1pido\u0027 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."
          }
        ],
        "id": "CVE-2025-61778",
        "lastModified": "2026-10-09T10:10:00.193",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 9.3,
                "baseSeverity": "CRITICAL",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "NOT_DEFINED",
                "privilegesRequired": "NONE",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "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",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2025-61778",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-06T17:05:20.929457Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2025-10-06T17:16:08.297",
        "references": [
          {
            "source": "security-advisories@github.com",
            "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"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-290"
              },
              {
                "lang": "en",
                "value": "CWE-295"
              },
              {
                "lang": "en",
                "value": "CWE-306"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "current_release_date": "2025-10-07T17:35:28+00:00",
      "cve": "CVE-2025-61778",
      "id": "CVE-2025-61778",
      "initial_release_date": "2025-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "1",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "Akka.Remote TLS did not properly implement certificate-based authentication",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-61778.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2025-61778",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2025-10-06T17:05:20.929457Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2025-10-06T17:05:26.017Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "akka.net",
              "vendor": "akkadotnet",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003e= 1.2.0, \u003c 1.5.52"
                }
              ]
            }
          ],
          "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\u0027s possible for untrusted parties to connect to a private key\u0027d 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\u0027s application. However, upgrading to version 1.5.52 is still recommended by the maintainers."
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 9.3,
                "baseSeverity": "CRITICAL",
                "privilegesRequired": "NONE",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "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",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "HIGH"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-290",
                  "description": "CWE-290: Authentication Bypass by Spoofing",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-295",
                  "description": "CWE-295: Improper Certificate Validation",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-306",
                  "description": "CWE-306: Missing Authentication for Critical Function",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2025-10-06T16:53:41.707Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5"
            },
            {
              "name": "https://github.com/akkadotnet/akka.net/pull/7847",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/akkadotnet/akka.net/pull/7847"
            },
            {
              "name": "https://github.com/akkadotnet/akka.net/pull/7851",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/akkadotnet/akka.net/pull/7851"
            },
            {
              "name": "https://getakka.net/articles/remoting/security.html",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://getakka.net/articles/remoting/security.html"
            },
            {
              "name": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52"
            }
          ],
          "source": {
            "advisory": "GHSA-jhpv-4q4f-43g5",
            "discovery": "UNKNOWN"
          },
          "title": "Akka.Remote TLS did not properly implement certificate-based authentication"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2025-61778",
        "datePublished": "2025-10-06T16:53:41.707Z",
        "dateReserved": "2025-09-30T19:43:49.901Z",
        "dateUpdated": "2025-10-06T17:05:33.450Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.