ALOS HTTP is a Linux-first Go web framework and application server built around a custom networking stack. Prior to 0.0.0-20260617230736-314b6783e196, core/utils.go::sanitizeRequestPath calls splitPathQuery on a request path beginning with a question mark and then performs the unchecked p[0] access without checking whether the resulting path is empty. An unauthenticated client can send a malformed request such as a question-mark-only path through h1_plain.go::ParseH1RequestHead, hpack.go::decodeSimpleGetPathHTTPSRequest, hpack.go::observeHeader, or h3_conn.go::handleRequestStream, causing an out-of-bounds panic before core.Recovery() middleware runs and terminating the server process. This issue is fixed in pseudo-version 0.0.0-20260617230736-314b6783e196.

Affected: Go: github.com/guno1928/alos-http

### Summary A single unauthenticated HTTP request to a path starting with `?` (e.g. `GET ? HTTP/1.1`) crashes the entire server process. The request line parser passes the path to `sanitizeRequestPath` which indexes the first byte of the path after stripping the query string. It does so without checking that it is non-empty, leading to an out-of-bounds panic. The panic occurs before any handler or middleware runs so `core.Recovery()` does not recover it. The entire process panics and every connection is dropped. It is reachable over HTTP/1.1, HTTP/2 and HTTP/3 if `ListenAndServeQUIC` is enabled

### Details **root cause**: `core/utils.go::sanitizeRequestPath` ```go // assume path := "?" if len(path) == 0 { // len(path) == 1 return "/" }

p, _ := splitPathQuery(path) // p == ""

if p[0] == '/' /*...*/ { // p[0] on empty string => panic: index out of range return p } ```

* when the path starts with "?" len(path) is not 0 so the early return does not fire * after `splitPathQuery` `p` is empty `""` * `p` is then indexed `p[0]` without a length check

Relevant calling sites:

* `h1_plain.go:ParseH1RequestHead` (HTTP/1.1) * `h1.go::ParseH1Request` (dead code) * `hpack.go::decodeSimpleGetPathHTTPSRequest` (HTTP/2) * `hpack.go::observeHeader` (HTTP/2) * `h3_conn.go::handleRequestStream` (HTTP/3)

these run in the connection-worker goroutine before the handler chain, which has no recover(), causing the entire http server to crash in case of a panic

### PoC

Minimal server, using…