Memory leak under Slowloris attack

[ghostdevxd]

Version info:

• Go: go1.23.10 windows/amd64
• Fasthttp: v1.63.0

What happened

When running a simple fasthttp server and testing it using a Slowloris attack (via goloris), the memory usage of the fasthttp process increases rapidly and does not decrease for many minutes even after the attack ends.

Code

package main

import (
	"github.com/valyala/fasthttp"
)

func main() {
	requestHandler := func(ctx *fasthttp.RequestCtx) {
		switch string(ctx.Path()) {
		case "/":
			ctx.SetStatusCode(fasthttp.StatusOK)
			ctx.SetBody([]byte("Hello, World!"))
		default:
			ctx.SetStatusCode(fasthttp.StatusNotFound)
			ctx.SetBody([]byte(""))
		}
	}

	if err := fasthttp.ListenAndServe(":3000", requestHandler); err != nil {
		panic("Server Error: " + err.Error())
	}
}

Task Manager

PPROF

flat	flat%	sum%	cum	cum%	Function
231.30MB	98.93%	98.93%	231.30MB	98.93%	github.com/valyala/fasthttp.appendBodyFixedSize
0	0%	98.93%	231.30MB	98.93%	github.com/valyala/fasthttp.(*Request).ContinueReadBody
0	0%	98.93%	231.30MB	98.93%	github.com/valyala/fasthttp.(*Request).ReadBody
0	0%	98.93%	231.30MB	98.93%	github.com/valyala/fasthttp.(*Request).readLimitBody
0	0%	98.93%	232.81MB	99.57%	github.com/valyala/fasthttp.(*Server).serveConn
0	0%	98.93%	232.81MB	99.57%	github.com/valyala/fasthttp.(*workerPool).getCh.func1
0	0%	98.93%	232.81MB	99.57%	github.com/valyala/fasthttp.(*workerPool).workerFunc
0	0%	98.93%	231.30MB	98.93%	github.com/valyala/fasthttp.readBody

[erikdubbelboer]

That makes sense. The defaults for fasthttp are not about being safe, they are about being fast.

If you want to prevent something like this you should set Server.MaxConnsPerIP and Server.ReadTimeout.

[ghostdevxd]

That makes sense. The defaults for fasthttp are not about being safe, they are about being fast.

If you want to prevent something like this you should set Server.MaxConnsPerIP and Server.ReadTimeout.

IdleTimeout, ReadTimeout etc. settings do not work, ram usage suddenly increases and crashes frameworks such as net/http, silverlinining (as fast as fasthttp) do not have this problem

[erikdubbelboer]

Did you test it with ReadTimeout? It doesn't get reset between reads, so it should prevent a client from sending one byte at a time to keep a connection open for long. That combined with MaxConnsPerIP should completely stop the attack.

[erikdubbelboer]

If you're only concerned about memory. That is normal, fasthttp will reuse memory and keep buffers for that even if connections have been closed. Memory usage will only go down after the system runs our of memory and Go starts releasing the memory.

[ghostdevxd]

Read Timeout (3 * time.Second):

Goloris Error:

2025/07/15 10:28:52 Unexpected response read from the server: [HTTP/1.1 408 Request Timeout
Server: fasthttp
Date: Tue, 15 Jul 2025 07:28:51 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 15
Connection: close

Request timeout]

• Despite the ReadTimeout error, the attack can still continue.
• Can still memory overflow by opening more connections

MaxConnsPerIP:

• Can be bypassed using proxy

[ghostdevxd]

Stage	Connections	RAM Usage
1	3000	2 GB
2	3000	2 GB
3	6000	4 GB

it is possible to achieve this attack again by increasing the number of connections

[guno1928]

import (
	"fmt"
	"os"
	"time"

	"github.com/gofiber/fiber/v2"
)

func main() {
	if len(os.Args) < 2 {
		fmt.Println("Usage: ./webserver <IP>")
		os.Exit(1)
	}
	ip := os.Args[1]
	app := fiber.New(fiber.Config{
		DisableStartupMessage:    false,
		DisableHeaderNormalizing: true,
		IdleTimeout:              5 * time.Second,
		Concurrency:              999999999,
		ReadTimeout:              6 * time.Second,
		WriteTimeout:             6 * time.Second,
		ReadBufferSize:           18024,
		WriteBufferSize:          18024,
	})

	app.Get("/", func(c *fiber.Ctx) error {
		return c.SendString("Hello, World!")
	})

	addr := fmt.Sprintf("%s:8000", ip)
	if err := app.Listen(addr); err != nil {
		fmt.Printf("Error starting server: %v\n", err)
		os.Exit(1)
	}
}

i tried go fiber as i saw you actually post this problem in the gofiber discord but setting the read and write timeouts 100% stopped it and for your proxy problem thats just straight up a ddos attack so you would of course need a firewall in order to stop that and limit connections per ip etc, in this case it would be user error and nothing to do with fasthttp

[ghostdevxd]

import (
	"fmt"
	"os"
	"time"

	"github.com/gofiber/fiber/v2"
)

func main() {
	if len(os.Args) < 2 {
		fmt.Println("Usage: ./webserver <IP>")
		os.Exit(1)
	}
	ip := os.Args[1]
	app := fiber.New(fiber.Config{
		DisableStartupMessage:    false,
		DisableHeaderNormalizing: true,
		IdleTimeout:              5 * time.Second,
		Concurrency:              999999999,
		ReadTimeout:              6 * time.Second,
		WriteTimeout:             6 * time.Second,
		ReadBufferSize:           18024,
		WriteBufferSize:          18024,
	})

	app.Get("/", func(c *fiber.Ctx) error {
		return c.SendString("Hello, World!")
	})

	addr := fmt.Sprintf("%s:8000", ip)
	if err := app.Listen(addr); err != nil {
		fmt.Printf("Error starting server: %v\n", err)
		os.Exit(1)
	}
}

i tried go fiber as i saw you actually post this problem in the gofiber discord but setting the read and write timeouts 100% stopped it and for your proxy problem thats just straight up a ddos attack so you would of course need a firewall in order to stop that and limit connections per ip etc, in this case it would be user error and nothing to do with fasthttp

didn't work the problem persists
FastHTTP:

ReadTimeout etc.. imposes a certain limit, but slowloris still overflows ram when you increase the number of connections

and the whole problem is caused by fasthttp, silverlining (is fast like fasthttp) and other slow frameworks do not have this problem

[gaby]

Related

• appendBodyFixedSize memory gradually rising #667
• Migrate bytebufferpool to this repo #2032

[gaby]

@ghostdevxd Try setting max body limit:

srv := &fasthttp.Server{
    // refuse anything above 1 MiB
    MaxRequestBodySize: 1 << 20,
}

[ghostdevxd]

@ghostdevxd Try setting max body limit:

srv := &fasthttp.Server{
// refuse anything above 1 MiB
MaxRequestBodySize: 1 << 20,
}

it doesn't make sense to limit it, the problem persists, it only makes the attack more difficult

[gaby]

@ghostdevxd Try setting max body limit:
srv := &fasthttp.Server{
// refuse anything above 1 MiB
MaxRequestBodySize: 1 << 20,
}

it doesn't make sense to limit it, the problem persists, it only makes the attack more difficult

That's what I wanted to confirm, that it makes it more difficult. The default limit is 4MB.

[erikdubbelboer]

Can you show exactly which command line flags you use with goloris? I want to see if I can replicate this and see what is going on.

[gaby]

@erikdubbelboer I asked OpenAI o3 model about this and it suggested this:

Problem:

bodyBuf.B, err = readBody(r, contentLength, maxBodySize, bodyBuf.B)

Will allocate the content length, so it suggested changing appendBodyFixedSized to the following:

func appendBodyFixedSize(r *bufio.Reader, dst []byte, n int) ([]byte, error) {
    const step = 32 * 1024            // grow in small chunks
    for read := 0; read < n; {
        need := n - read
        if need > step { need = step }

        // ensure capacity only for the incoming chunk
        if len(dst)+need > cap(dst) {
            dst = append(dst, make([]byte, need)...)
        } else {
            dst = dst[:len(dst)+need]
        }

        if _, err := io.ReadFull(r, dst[len(dst)-need:]); err != nil {
            return dst[:len(dst)-need], err       // early EOF, etc.
        }
        read += need
    }
    return dst, nil
}

It's a solution, although probably not the best one to be allocating so often

[guno1928]

Can you show exactly which command line flags you use with goloris? I want to see if I can replicate this and see what is going on.

go run goloris.go -dialWorkersCount 150

It auto presets to local host and once you run this the ram will build up to around 100-150 mb you can than stop it wait 5 seconds start it back up and the ram will grow again and repeat or open 3 terminals and do it at the same time and it grows faster