CVE-2016-5285

What it actually does

A null pointer dereference in NSS functions PK11_SignWithSymKey and ssl3_ComputeRecordMACConstantTime allows remote attackers to trigger a crash during cryptographic signature or MAC operations without authentication.

Why it matters to the business

Availability loss for Vault deployments that depend on the vulnerable NSS library, resulting in service outages and operational disruption; the issue has remained unexploited in the wild for years with stable low exploit probability.

How an attack unfolds

An attacker sends crafted network traffic to a Vault instance that invokes the vulnerable NSS code paths, bypassing the missing NULL check and causing an immediate process crash that denies service to legitimate users.

How to fix it

Upgrade github.com/hashicorp/vault (go) and github.com/hashicorp/vault/vault (go) to version 1.3.4 or later; restart affected services after the upgrade.

How to confirm the fix worked

Confirm running Vault binary reports version 1.3.4 or newer; perform connectivity tests that exercise TLS and cryptographic signing paths to verify absence of crashes.

Typical attack path

1. Scan for publicly reachable Vault instances running versions before 1.3.4
2. Craft a TLS handshake or symmetric-key operation payload that reaches PK11_SignWithSymKey or ssl3_ComputeRecordMACConstantTime
3. Transmit the malicious request over the network
4. Observe denial of service from the resulting null dereference crash

How to detect it

Review Vault and system logs for unexpected terminations or segmentation faults occurring during TLS or cryptographic operations; correlate with inbound network connections that precede the crash.

What your security team should do

• Apply the 1.3.4 upgrade to all Vault deployments within standard change windows
• Inventory all downstream dependents that embed the affected Vault packages
• Enable process monitoring for NSS-related crashes as a temporary compensating control