neon --help printed my NEON_API_KEY value in CI logs
Fixes the leak where older neonctl printed the NEON_API_KEY value inside --help output in CI logs. Use when you spot the raw key in build logs. Upgrades neonctl to the fixed version, rotates the exposed key, and scrubs the logs. Not for keys leaked through other commands.
neon --help printed my NEONAPIKEY value in CI logs
TL;DR: older neonctl versions interpolated the actual NEONAPIKEY value into --help output, so any CI step that printed help leaked the key into logs. Upgrade neonctl to a version with the fix (help shows the variable name, not the value), then treat the old key as compromised: revoke it in the Neon console and issue a new one. Scrub or expire the affected build logs.
neon --help printed the NEON_API_KEY valueSteps
- Upgrade neonctl to the latest version. Verify:
neon --helpnow shows the variable name where the key value used to appear. - In the Neon console, revoke the exposed key and create a replacement. Update the CI secret to the new value.
- Expire or redact the build logs that contain the old key; anyone with log access had the key.
- Rerun the pipeline. Expected: help output is clean and commands authenticate with the new key.
When this applies
- NEONAPIKEY visible in CI logs after a --help or --version step
- any credential-adjacent output printed by an old CLI version
- post-incident rotation after a log leak
When it doesn't
- keys leaked via other commands or misconfigured logging — rotate but the upgrade does not apply
- invalid-key 401s with no leak involved
- local terminal history leaks (different cleanup)
Compatibility
neonctl; Neon console key revocation; CI log retention controls. Verified against the neon-pkgs neonctl changelog.
Variant phrasings
- neonctl help printed api key
- NEONAPIKEY leaked CI logs
- neonctl changelog help api key
Root cause
Old neonctl built help text by interpolating live config values, including the secret. The fixed version prints the variable name as documentation instead of the value. Upgrading stops future leaks but cannot un-leak the old value, so rotation is mandatory.
Edge cases
- assume any exposed key is compromised even if logs look private; rotate first, investigate second
- check forks/caches of logs (artifacts, mirrors) for the same leak
- pin a minimum neonctl version in CI setup so the old behavior cannot regress