Listen to this Post
The vulnerability exists because the `–address` CLI flag (and `NORNICDB_ADDRESS` / `server.host` config key) is properly applied to the HTTP server but never passed to the Bolt database server. In pkg/bolt/server.go:774-776, the `ListenAndServe()` function constructs the listen address as fmt.Sprintf(":%d", s.config.Port), which omits any host value. When Go’s `net.Listen(“tcp”, “:7687”)` is called with an empty host, it binds to the wildcard address `0.0.0.0` (all network interfaces). The `bolt.Config` struct (line 474) contains only a `Port` field, no Host/Address field. In cmd/nornicdb/main.go, the `–address` value is stored in a local variable (line 80) and used only for user‑facing log output (lines 637–644). When initializing the Bolt server (lines 600–609), the `address` variable is never copied into boltConfig. As a result, the Bolt listener always binds to `:7687` regardless of configuration. The HTTP server binds correctly because its configuration does receive the host value. A user running `nornicdb serve –address 127.0.0.1` sees log output claiming “Bolt server listening on bolt://localhost:7687”, but `netstat -an -p tcp | grep 7687` reveals .7687 LISTEN. Another host on the same LAN can connect to port 7687 and, because NornicDB ships with default `admin:password` credentials, execute arbitrary Cypher queries (read/write/delete nodes). Setting `NORNICDB_BOLT_ADDRESS=127.0.0.1` or `server.host: “127.0.0.1”` in `config.yaml` has no effect because those keys are not wired to the Bolt subsystem. The root cause is a missing `Host` field in `bolt.Config` and failure to propagate the address from CLI/config to the Bolt server initialization.
dailycve form:
Platform: NornicDB
Version: v1.0.39
Vulnerability: Wildcard Bolt binding
Severity: High
date: 2026-04-23
Prediction: 2026-05-07
What Undercode Say:
Analytics
Show wildcard binding on Bolt port 7687
netstat -an -p tcp | grep 7687
Expected output: tcp46 0 0 .7687 . LISTEN
Verify HTTP port binds correctly to localhost
netstat -an -p tcp | grep 7474
Expected: tcp4 127.0.0.1.7474 . LISTEN
Confirm reachability from another LAN host
nc -z 192.168.x.y 7687
Go code snippet showing the bug (pkg/bolt/server.go:774-776)
addr := fmt.Sprintf(":%d", s.config.Port)
listener, err := net.Listen("tcp", addr)
Workaround using pf firewall on macOS
echo "block in proto tcp from any to port 7687" | sudo pfctl -f -
Exploit:
From another host on same LAN: `cypher-shell -a bolt://192.168.x.y:7687 -u admin -p password “MATCH (n) DETACH DELETE n”`
Protection from this CVE
Apply host firewall to block port 7687 on non‑loopback interfaces, or upgrade to patched version (once released) that adds `Host` field to `bolt.Config` and wires `–address` correctly.
Impact:
Default `admin:password` credentials + wildcard binding → any device sharing the LAN can execute arbitrary Cypher queries, leading to full database read, write, and deletion of nodes. Assumption that `–address 127.0.0.1` binds both protocols to localhost is false, exposing data inadvertently.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
