* or if TLS is enabled with mutual authentication and the authentication keys of a host that is allowed to connect have been compromised, an attacker gained access to a valid certificate (e.g. by compromising a node with certificates issued by the same internal PKI tree to get access of the certificate)
* regardless of whether ``untrusted`` mode is enabled or not
Java deserialization is `known to be vulnerable <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_ to attacks when attacker can provide arbitrary types.
Akka Remoting uses Java serialiser as default configuration which makes it vulnerable in its default form. The documentation of how to disable Java serializer was not complete. The documentation of how to enable mutual authentication was missing (only described in reference.conf).
To protect against such attacks the system should be updated to Akka `2.4.17` or later and be configured with
:ref:`disabled Java serializer <disable-java-serializer-scala>`. Additional protection can be achieved when running in an
untrusted network by enabling :ref:`TLS with mutual authentication <remote-tls-scala>`.
Please subscribe to the `akka-security <https://groups.google.com/forum/#!forum/akka-security>`_ mailing list to be notified promptly about future security issues.
The `CVSS <https://en.wikipedia.org/wiki/CVSS>`_ score of this vulnerability is 6.8 (Medium), based on vector `AV:A/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:TF/RC:C <https://nvd.nist.gov/cvss.cfm?calculator&version=2&vector=(AV:A/AC:M/Au:N/C:C/I:C/A:C/E:F/RL:TF/RC:C)>`_.
We would like to thank Alvaro Munoz at Hewlett Packard Enterprise Security & Adrian Bravo at Workday for their thorough investigation and bringing this issue to our attention.
