emp3r0r has an unauthenticated HTTP Polling DoSGHSA-4595-rvpx-4q34
HIGHGHSA-4595-rvpx-4q34 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in github.com/jm33-m0/emp3r0r/core. A fix is available for github.com/jm33-m0/emp3r0r/core — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-4595-rvpx-4q34.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/jm33-m0/emp3r0r/coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The http_poll C2 transport accepts attacker-controlled HTTP polling sessions before CBOR MsgAuth authentication is completed. A remote unauthenticated attacker can create arbitrary polling sessions and send request bodies that are forwarded into the C2 dispatch path. This can consume server resources and trigger pre-auth C2 processing.
Details
The plain HTTP C2 server starts the HTTP polling listener and forwards requests into HandleHTTPServerSession:
// core/internal/cc/server/c2_http_server.go
mux.HandleFunc(c2Path, func(w http.ResponseWriter, req *http.Request) {
stream, err := transport.HandleHTTPServerSession(w, req, &live.RuntimeConfig.MalleableC2)
...
if stream != nil {
go cborStreamAccept(transport.NewStreamTransport(stream, req.RemoteAddr))
}
})
The HTTP polling handler accepts an attacker-supplied sessionID and init=1 cookie, then creates and stores a server-side stream before authentication:
// core/internal/transport/c2channel_http.go
if isInit {
stream = newHTTPServerStream(sessionID)
w.WriteHeader(http.StatusOK)
return stream, nil
}
POST bodies for that unauthenticated session are read and queued before CBOR authentication rejects them:
// core/internal/transport/c2channel_http.go
case http.MethodPost:
data, err := io.ReadAll(req.Body)
if err == nil && len(data) > 0 {
select {
case stream.readCh <- data:
w.WriteHeader(http.StatusOK)
...
}
}
Authentication only happens later in the C2 dispatch layer:
// core/internal/cc/server/dispatcher.go
secureConn := transport.NewSecureConn(t)
...
n, err := secureConn.Read(authFrame)
PoC
- Start the C2 server in a lab environment with the HTTP polling transport exposed, for example with
--http-port 12345. - Send an unauthenticated HTTP POST to the default polling path
/api/v1/telemetrywith a randomsessionIDcookie and theinit=1cookie value. - Send a second unauthenticated HTTP POST to
/api/v1/telemetryusing the samesessionID, with a request body containing repeatedAbytes. - Observe that both unauthenticated requests return HTTP
200. - Observe the C2 server log showing attacker-controlled bytes reaching the encrypted C2 frame parser, for example:
read: invalid encrypted chunk length: 1094795585. 1094795585is0x41414141, which corresponds toAAAA, confirming unauthenticated request body data reachedcborProtocolDispatchbefore CBORMsgAuthauthentication.- Repeat the request sequence concurrently to increase server resource usage and log volume.
Impact
- Remote unauthenticated attackers can create arbitrary HTTP polling sessions.
- Attacker-controlled request bodies reach pre-auth C2 dispatch handling.
- Repeated requests can consume server memory, goroutines, request handling capacity, and log volume.
- C2 service availability and operator reliability may be degraded under sustained traffic.
Remediation
- Require authentication before creating long-lived HTTP polling sessions.
- Do not forward request bodies into the C2 stream before validation.
- Add strict request body limits.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/jm33-m0/emp3r0r/core | all versions | 0.0.0-20260531142011-aed3d81641abgo get github.com/jm33-m0/emp3r0r/core@v0.0.0-20260531142011-aed3d81641ab |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/jm33-m0/emp3r0r/core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/jm33-m0/emp3r0r/core to 0.0.0-20260531142011-aed3d81641ab or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4595-rvpx-4q34 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is GHSA-4595-rvpx-4q34 in your dependencies?
Find it across Go, including transitive dependencies.