Can an unauthorized login attempt occupy a MySQL connection for a long time?

My MySQL has a limited number of concurrent connections defined by the max_connections variable by my cloud provider. Currently limited to 151 connections.

There is only one web server using this database therefore it should be more than enough. However, I was surprised to see that I currently have 30+ active connections to my server:

mysql> show status where `variable_name` = 'Threads_connected';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 34    |
+-------------------+-------+

While there shouldn't be almost anything using it at the moment and I can verify it with show processlist: (only one connection here)

mysql> show processlist;
+--------+------------+--------------------+------------+---------+------+----------+------------------+-----------+---------------+
| Id     | User       | Host               | db         | Command | Time | State    | Info             | Rows_sent | Rows_examined |
+--------+------------+--------------------+------------+---------+------+----------+------------------+-----------+---------------+
| 272130 | ********** | ****************** | ********** | Query   |    0 | starting | show processlist |         0 |             0 |
+--------+------------+--------------------+------------+---------+------+----------+------------------+-----------+---------------+

I've been struggling to try to account for the remaining 33 connection's whereabouts and finally I realized: could those be mass brute-force attacks? Maybe 30-40 hackers are trying to guess my password and that blocks a thread per each attacker?

Is my assumption correct?

UPDATE 2021-07-07: Added more details of MySQL status

mysql> show status where `variable_name` like '%threads%' or `variable_name` like '%connection%';
+-----------------------------------+---------------------+
| Variable_name                     | Value               |
+-----------------------------------+---------------------+
| Connection_errors_accept          | 0                   |
| Connection_errors_internal        | 0                   |
| Connection_errors_max_connections | 0                   |
| Connection_errors_peer_address    | 8                   |
| Connection_errors_select          | 0                   |
| Connection_errors_tcpwrap         | 0                   |
| Connections                       | 482365              |
| Delayed_insert_threads            | 0                   |
| Max_used_connections              | 74                  |
| Max_used_connections_time         | 2021-07-05 09:10:27 |
| Slow_launch_threads               | 0                   |
| Threadpool_idle_threads           | 0                   |
| Threadpool_threads                | 0                   |
| Threads_cached                    | 5                   |
| Threads_connected                 | 36                  |
| Threads_created                   | 2882                |
| Threads_running                   | 1                   |
+-----------------------------------+---------------------+

• SHOW PROCESSLIST only shows connections for the user running that command. Be sure to connect as root to get the complete list. "root" is actually more powerful than you need; there may be some other user ("admin"?) that is powerful enough. In terms of GRANT, all the 'user' needs is PROCESS.

• Once you get the processlist, Time will indicate how many seconds since they connected.

• SHOW STATUS LIKE 'Threads_running'; will show how many connections are currently active.

• SHOW STATUS LIKE 'Max_used_connections'; is a high water mark. If it has not yet hit max_connections (you mentioned 151), then you have not yet (since restart) "run out of connections".

• The timeout may be large, leading to connections hanging around.