The website has slowed down, even though visitor numbers haven’t gone up. The CPU stays busy at night, unfamiliar messages keep appearing in the mail queue, and the provider reports suspicious requests from the server’s IP address. The first assumption is usually simple: something has broken. But it may be more serious than that. A server can still look perfectly normal while somebody else is already using it to send spam, attack other systems, or reach stored data.
As soon as the server gets a public IP address, automated scanners start checking it. They look for open SSH or RDP access, exposed databases, common passwords, and outdated services. This is a routine mass search for poorly protected systems, not necessarily an attack aimed specifically at your website.
Sometimes a website starts behaving as if it is under a heavy DDoS attack: pages open slowly, the API responds with delays, 502 or 503 errors appear in the logs, and web server processes suddenly start consuming much more memory. But at the same time, there is no huge stream of requests, the channel is not saturated, and the load may come from a small number of connections. This is how HTTP/2 Bomb works. It is a DoS attack on HTTP/2 – the protocol through which a website or application exchanges data with the server. The attacker sends a relatively small amount of data but forces the server to spend much more memory processing it. As a result, the web server or proxy may freeze, start using disk instead of RAM, restart processes, or stop serving regular users properly.
At the end of April 2026, the Linux community started talking about a flaw in the algif_aead kernel module. The issue is local, but critical: an attacker with minimal privileges inside the system can escalate to root. In practice, this means losing control over the server. After obtaining root access, a third-party user can extract databases, configuration files, SSH keys, or completely rebuild the system for their own purposes. The situation became much more dangerous because ready-made instructions and exploitation tools appeared in public access almost at the same time as the vulnerability itself became known. Script kiddies and automated scanners usually start using things like this within the first days.
