Done well, not really. As I said, it is not that hard and not that big, a thousand lines of code maybe, maybe two or three if you support a few extensions. There are some footguns, but most of them related to reading the documentation of system calls carefully. And we are in the age of LLMs, and LLMs are very good at noticing edge cases you forgot, especially if you didn't vibe-code the thing in the fist place. That's in addition to traditional tools, such as sanitizers, linters, and fuzzers.
What you gain by rolling your own instead of using a battle tested solution is a reduced attack surface. For example, an off-the-shelf HTTP server may be tricked into revealing the content of a file the user should not have access to, but if your custom server doesn't read files at all (you don't even make a open()) because everything is in RAM, or hardcoded in the executable itself, then such a vulnerability cannot exist. You may also decide to allocate most of your memory statically, because you know in advance how much you will need, and doing that, eliminate an entire class of potential vulnerabilities. An off-the-shelf HTTP server doesn't have this luxury.
And with one less dependency, you are also less vulnerable to supply chain attacks.
What you gain by rolling your own instead of using a battle tested solution is a reduced attack surface. For example, an off-the-shelf HTTP server may be tricked into revealing the content of a file the user should not have access to, but if your custom server doesn't read files at all (you don't even make a open()) because everything is in RAM, or hardcoded in the executable itself, then such a vulnerability cannot exist. You may also decide to allocate most of your memory statically, because you know in advance how much you will need, and doing that, eliminate an entire class of potential vulnerabilities. An off-the-shelf HTTP server doesn't have this luxury.
And with one less dependency, you are also less vulnerable to supply chain attacks.