Teku

The `bls` module has two implementations of BLS. One of them is based on the unaudited `blst` library: supranational/blst: BLS12-381 signature library (https://github.com/supranational/blst). This might introduce additional attack vectors.

This is an admin endpoint, but it does not seem to be authenticated in any way. As it stands, it appears that an unauthorized party would be able to change the logging configuration for the application. While changing the logging level does not seem to expose any sensitive information, it is an undesirable action that should be reserved only to authorized admins.

In `BeaconRestApi`, `import 'com.google.common.io.Resources'` is marked unstable with `@Beta`.

Class: io.libp2p.discovery.mdns.* The minimal multicast DNS implementation is a clone of certain parts of the JMDNS library (see [https://github.com/jmdns/jmdns](https://github.com/jmdns/jmdns)), without any reference to what commit head was used. As a negative side-effect, any updates or vulnerability fixes in the upstream repository must be manually tracked, pulled, and merged by Teku developers, which if not done regularly, could lead to bugs or security issues being left unfixed.

There is no rate limiting on the API/RPC calls. While this may be intentional, excessive calls may result in poor or denied service.

On line 25 and 26, `Remote_fault` and `Remote_unresponsive` share the same `enum` number. Therefore, `fromReasonCode` will have `.filter` provide a stream of `REMOTE_FAULT` and `UNRESPONSIVE`, and `findAny` will non-deterministically provide out `REMOTE_FAULT` or `UNRESPONSIVE `for code `3`.

In lines 169 and 170 the function `getDepositsWithProof()` casts `long`s to `int`s. For a number of deposits large enough this may result in a loss of precision.

According to the Eth2 p2p spec: “Nodes operating behind a NAT, or otherwise undialable by default (e.g. container runtime, firewall, etc.), MUST have their infrastructure configured to enable inbound traffic on the announced public listening endpoint” This issue is not supposed to be handled by the existing code, but rather by instructing node operators on how to configure their deployment. In the given repository, we did not find any information related to the given matter. If users are unaware of this issue, the node will not receive any inbound traffic on its announced public endpoint.