GHSA-2HP7-65R3-WV54: Critical Improper Network Binding in NornicDB Bolt Server

NornicDB utilizes a dual-interface architecture, exposing an HTTP API for native communications and a Bolt server for Neo4j driver compatibility. The vulnerability, tracked as GHSA-2HP7-65R3-WV54, is a CWE-1327 (Improper Binding of a Socket to a Network Interface) flaw affecting the Bolt server implementation. The defect causes the Bolt server to listen on all available network interfaces automatically.

The flaw negates intended network-level isolation established by system administrators. A user explicitly configuring the NornicDB service to bind exclusively to the loopback interface (127.0.0.1) remains unknowingly exposed on TCP port 7687. This secondary listening socket silently bypasses configuration intent and exposes the database to the local network or the public internet.

Unauthenticated attackers with network line-of-sight to port 7687 can interact directly with the exposed endpoint. Because the Bolt component may lack robust authentication protocols by default, this accessibility directly translates to the execution of arbitrary Cypher queries. An attacker achieves persistent read and write access to the underlying graph and vector data stores.

The root cause of this vulnerability resides within the initialization parameters of the pkg/bolt/server.go module. The NornicDB HTTP server component correctly implements configuration parsing to respect the --address command-line flag. Conversely, the Bolt server implementation utilized a configuration structure (bolt.Config) that completely lacked a Host definition.

During service startup, the ListenAndServe method initiated the listener socket by invoking net.Listen("tcp", ":7687"). The Go standard library specifies that omitting the host prefix in the address string explicitly instructs the network listener to bind to the wildcard address. This results in the socket listening on 0.0.0.0 for IPv4 and :: for IPv6 networks.

The application fundamentally bifurcated its network binding logic, creating a secure boundary for the HTTP API while hardcoding the Bolt API to an insecure state. The lack of a unified configuration hierarchy meant environment variables and command-line flags intended to secure the instance were silently dropped by the Bolt subsystem.

The remediation implemented in commit adce4f9a9fc7b6aada07c0bfa2d737cd7a6efaca resolves the binding issue by introducing explicit host resolution. The bolt.Config struct was updated to include a Host string, which defaults to 127.0.0.1. The implementation of pkg/bolt/server.go was subsequently modified to utilize this configuration field.

// Vulnerable Implementation (pkg/bolt/server.go)
func (s *Server) ListenAndServe() error {
    // Binds to all interfaces (0.0.0.0)
    listener, err := net.Listen("tcp", fmt.Sprintf(":%d", s.config.Port))
    if err != nil {
        return err
    }
    // ...
}
 
// Patched Implementation (pkg/bolt/server.go)
func (s *Server) ListenAndServe() error {
    // Safely joins host and port, binding only to the specified interface
    address := net.JoinHostPort(s.config.Host, strconv.Itoa(s.config.Port))
    listener, err := net.Listen("tcp", address)
    if err != nil {
        return err
    }
    // ...
}

The patch also centralizes address resolution by introducing the resolveBindAddress helper function in cmd/nornicdb/main.go. This function enforces a strict precedence hierarchy for determining the correct interface address. CLI flags supersede configuration file settings, which supersede environment variables, ultimately falling back to the 127.0.0.1 default.

To ensure durability of the fix, developers added regression tests in cmd/nornicdb/main_address_test.go. These unit tests validate that the resolved address accurately prioritizes secure defaults and respects administrative overrides across all database interfaces.

Exploiting this vulnerability does not require complex payloads, memory corruption techniques, or evasion of modern mitigation controls. The attacker initiates the exploitation sequence by performing standard TCP port scanning across target environments to discover exposed NornicDB instances listening on port 7687.

Upon locating a vulnerable host, the attacker establishes a connection using the standard Neo4j Bolt driver or the open-source cypher-shell utility. The attacker supplies the target IP address and initiates the connection handshake. Since the socket is bound to all interfaces, the operating system accepts the inbound connection and routes it to the NornicDB Bolt service.

Once the connection is established, the attacker issues Cypher queries to the database endpoint. Due to the lack of strict authentication enforced on this specifically exposed endpoint, the application processes the queries with full administrative privileges. The attacker extracts or manipulates vector data and relational graph datasets at will.

The CVSS v3.1 base score of 9.8 (Critical) reflects the severe nature of this vulnerability. An attacker requires zero privileges, no user interaction, and utilizes a network-based attack vector with low complexity. The vulnerability directly compromises the Confidentiality, Integrity, and Availability of the database instance.

For NornicDB instances deployed in public cloud environments without restrictive Security Groups, this flaw exposes the database directly to the public internet. Organizations hosting sensitive embeddings, vector metadata, or proprietary knowledge graphs face immediate and total data compromise.

Instances deployed strictly within internal corporate networks remain highly susceptible to lateral movement. An attacker who breaches a low-privileged system on the internal network can pivot to the NornicDB instance, escalating their access to mission-critical data assets without generating authentication failure logs.

The definitive remediation for this vulnerability is upgrading NornicDB to version v1.0.42-hotfix or a subsequent release. This version permanently modifies the net.Listen calls and implements secure default binding to the loopback interface (127.0.0.1). Administrators must restart the database daemon following the package upgrade to apply the new socket configurations.

Administrators operating in environments where immediate patching is prohibited must implement network-level access controls. Operating system firewalls, such as iptables or ufw, must be configured to drop inbound connections to TCP port 7687 from untrusted network segments. Cloud environments must utilize VPC Security Groups to restrict access to the Bolt port exclusively to authorized application servers.

Security and operations teams must audit current network bindings to verify exposure. Executing netstat -tlnp | grep 7687 or ss -tlnp | grep 7687 provides immediate verification of the socket state. A securely configured instance returns a local address of 127.0.0.1:7687, whereas a vulnerable instance returns 0.0.0.0:7687 or *:7687.