SIGHUP on dev server causes SIGSEGV since 1.19 in docker

[TheDJVG]

Describe the bug
When someone tries to send the HUP signal to vault while running in docker dev mode it segfaults. This was working in 1.18 and lower.

To Reproduce
Steps to reproduce the behavior:

1. Start a docker container like this: docker run --rm --name vault hashicorp/vault:latest server -dev
2. Sned the HUP signal like docker kill --signal=HUP vault / docker exec vault killall -HUP vault
3. See the error:

==> Vault reload triggered
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x961ac56]

goroutine 1 [running]:
github.com/hashicorp/vault/command.(*ServerCommand).Run(0xc0012acd88, {0xc0003a01a0, 0x4, 0x4})
        /home/runner/work/vault/vault/command/server.go:1692 +0x5a76
github.com/hashicorp/cli.(*CLI).Run(0xc000dfb180)
        /home/runner/go/pkg/mod/github.com/hashicorp/cli@v1.1.7/cli.go:265 +0x4ed
github.com/hashicorp/vault/command.RunCustom({0xc0003a0190?, 0x5?, 0x5?}, 0xc000002380?)
        /home/runner/work/vault/vault/command/main.go:245 +0x995
github.com/hashicorp/vault/command.Run(...)
        /home/runner/work/vault/vault/command/main.go:147
main.main()
        /home/runner/work/vault/vault/main.go:13 +0x47

Expected behavior
Vault processes the signal correctly and doesn't crash.

Environment:

• Vault Server Version (retrieve with vault status): Vault v1.21.3, built 2026-02-03T14:56:30Z
• Vault CLI Version (retrieve with vault version): N/A
• Server Operating System/Architecture: amd64. Tried debian trixie and arch, also docker desktop on macos aarch64. Docker version 29.2.1.

[TheDJVG]

While looking into this a bit more it looks like this happens when -config argument is not a "file". Can also be reproduced with the vault binary directly with a simple one liner:

› vault server -config=/dev/null -dev -log-level=error & PID=$!; sleep 1; kill -HUP $PID
[1] 2084438
==> Vault server configuration:

Administrative Namespace: 
             Api Address: http://127.0.0.1:8200
                     Cgo: enabled
         Cluster Address: https://127.0.0.1:8201
   Environment Variables: COLORTERM, DBUS_SESSION_BUS_ADDRESS, DEBUGINFOD_URLS, DESKTOP_SESSION, DESKTOP_STARTUP_ID, DISPLAY, DOCKER_HOST, EDITOR, GDMSESSION, GDM_LANG, GOTRACEBACK, GPG_TTY, HOME, I3SOCK, KITTY_INSTALLATION_DIR, KITTY_PID, KITTY_PUBLIC_KEY, KITTY_WINDOW_ID, LANG, LESS, LOGNAME, LSCOLORS, LS_COLORS, MAIL, MOTD_SHOWN, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, NVM_INC, OLDPWD, PAGER, PATH, PWD, ROCM_PATH, SHELL, SHLVL, SSH_AUTH_SOCK, SWAYSOCK, TERM, TERMINFO, TERM_PROGRAM, TERM_PROGRAM_VERSION, TMUX, TMUX_PANE, TMUX_PLUGIN_MANAGER_PATH, USER, USERNAME, WAYLAND_DISPLAY, XCURSOR_SIZE, XDG_CURRENT_DESKTOP, XDG_DATA_DIRS, XDG_RUNTIME_DIR, XDG_SEAT, XDG_SESSION_CLASS, XDG_SESSION_DESKTOP, XDG_SESSION_ID, XDG_SESSION_TYPE, XDG_VTNR, ZSH, _
              Go Version: go1.25.7 X:nodwarf5
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", disable_request_limiter: "false", max_json_array_element_count: "10000", max_json_depth: "300", max_json_object_entry_count: "10000", max_json_string_value_length: "1048576", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: error
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: inmem
                 Version: Vault v1.21.3, built 2025-02-24T04:23:32Z

==> Vault server started! Log data will stream in below:

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variables:

    $ export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: YAjJCn/LnI1+ZF8yEz/KI8eCXKZl+09Vy3LnhM7qafc=
Root Token: hvs.SnudhmWYPwiOdHbf5lSDvjIH

Development mode should NOT be used in production installations!

==> Vault reload triggered                                                                                                                                                      
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x5573dfe98116]

[dosubot]

This looks like a bug caused by a missing nil pointer check in the SIGHUP reload handler. The panic occurs at server.go line 1708 where the code does:

config.Seals = core.GetCoreConfigInternal().Seals

The GetCoreConfigInternal() method can return nil, but there's no defensive check before accessing .Seals. This differs from other similar code paths in the same reload handler that properly check for nil before accessing (for example, the ServiceRegistration check at line 1746).

Several changes were made to SIGHUP handling since v1.18, including PR #30266 and PR #31067, which touched this area of the code. The nil pointer check appears to have been missed.

This is a valid bug report - a defensive nil check should be added before line 1708 similar to the pattern used elsewhere in the reload handler. We will get it to our engineers.

Written by @dosu, edited by heatherezell

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[themavik]

Fix submitted in #31843.