CVE-2026-32952

What it actually does

The flaw is a denial-of-service condition in the Go go-ntlmssp NTLM/Negotiate HTTP authentication implementation before version 0.1.1. When code using ntlmssp.Negotiator as an HTTP transport processes a specially crafted NTLM challenge message, the parser can access a slice out of bounds and trigger a Go runtime panic. If the application does not recover from that panic, the entire Go process can terminate, interrupting any service or job that depends on the affected process. The issue does not provide code execution, data disclosure, or authentication bypass; the primary impact is process availability.

Why it matters to the business

Applications, agents, services, or integration jobs that use the affected NTLM HTTP transport can be crashed remotely by a malicious or compromised NTLM-speaking endpoint, causing outages, failed authentication workflows, interrupted automation, and degraded service reliability. The CVSS score is moderate and EPSS is low and flat, with no known CISA KEV listing or ransomware association, but internet-reachable or high-availability services that authenticate to NTLM endpoints should still prioritize patching because exploitation is simple once an attacker can present a malicious NTLM challenge.

How an attack unfolds

An attacker positions a malicious HTTP endpoint, compromises an upstream NTLM-authenticated service, or obtains a network position that allows them to return NTLM authentication challenges to a vulnerable Go client. The vulnerable application initiates an HTTP request using go-ntlmssp's ntlmssp.Negotiator transport. During the NTLM handshake, the attacker sends a malformed NTLM challenge message with fields that cause the package's parser to index beyond the bounds of a slice. The Go runtime raises a slice-bounds panic. Unless the application has a recovery boundary around the affected request path, the panic propagates and terminates the process, causing a denial of service. Repeated requests or connection attempts can keep the service unstable until the package is upgraded or the malicious endpoint is blocked.

How to fix it

Upgrade go-ntlmssp to version 0.1.1 or later in all Go applications, agents, and services that use NTLM/Negotiate authentication over HTTP. Because the advisory lists the fix in version 0.1.1 even though no structured fixed_versions field was provided, treat 0.1.1 as the minimum safe version. Regenerate dependency lock files, rebuild affected binaries, and redeploy all statically linked Go artifacts that include the vulnerable package. Where immediate upgrade is not possible, reduce exposure by restricting outbound HTTP authentication to trusted NTLM endpoints, blocking untrusted NTLM challenge sources, disabling NTLM authentication where feasible, and adding panic recovery around request-handling or background-job boundaries to reduce process-wide crashes. Panic recovery is a resilience mitigation, not a substitute for upgrading the dependency.

How to confirm the fix worked

Confirm that dependency manifests and resolved module versions show go-ntlmssp at version 0.1.1 or later. Use Go module tooling such as `go list -m all` and software composition analysis to identify binaries built with vulnerable versions. Rebuild and redeploy applications after the dependency update, since Go binaries are commonly statically linked. Validate the fix by running unit or integration tests that exercise NTLM authentication against normal and malformed challenge responses and confirming the process does not panic. Operationally, monitor after deployment for the absence of Go panic stack traces referencing go-ntlmssp or ntlmssp.Negotiator during NTLM authentication flows.

Typical attack path

1. Identify an application or service that uses the vulnerable go-ntlmssp package for NTLM/Negotiate authentication over HTTP.
2. Cause the vulnerable process to connect to an attacker-controlled or compromised HTTP endpoint that offers NTLM authentication, or intercept traffic where NTLM challenge messages can be manipulated.
3. Return a crafted NTLM challenge message during the authentication handshake.
4. Trigger a Go slice-bounds panic in the vulnerable NTLM challenge parsing logic.
5. Rely on the unhandled panic to crash the Go process and disrupt the dependent service or workflow.
6. Repeat the interaction as needed to sustain the denial of service until the vulnerable dependency is patched or traffic is blocked.

How to detect it

To determine whether exploitation already occurred, review application logs, crash dumps, container termination records, systemd or supervisor restart logs, Kubernetes pod restart events, and APM/error-monitoring traces for Go runtime panics during NTLM or Negotiate authentication. Focus on timestamps where services restarted unexpectedly or HTTP authentication to NTLM endpoints failed. Look for panic messages indicating slice-bounds errors, stack traces referencing go-ntlmssp, ntlmssp.Negotiator, NTLM challenge parsing, or HTTP transport authentication. Correlate crashes with outbound HTTP requests to unfamiliar or recently changed NTLM endpoints and with inbound responses containing `WWW-Authenticate: NTLM` or NTLMSSP challenge data. Network telemetry may show repeated NTLM handshakes followed by abrupt client connection resets or process restarts. There are no known public threat actors or KEV-listed exploitation campaigns for this issue, so detection should focus on crash artifacts and suspicious NTLM challenge sources rather than actor-specific infrastructure.

• panic: runtime error: slice bounds out of range
• panic: runtime error: index out of range
• github.com/Azure/go-ntlmssp
• go-ntlmssp
• ntlmssp.Negotiator
• WWW-Authenticate: NTLM
• Authorization: NTLM
• NTLMSSP
• Negotiate NTLM
• slice bounds out of range [:
• runtime.goexit

What your security team should do

• Inventory Go applications and binaries that perform NTLM/Negotiate authentication over HTTP and identify use of microsoft/go-ntlmssp or github.com/Azure/go-ntlmssp.
• Prioritize externally exposed services, high-availability workloads, authentication gateways, automation agents, and integrations that connect to NTLM-capable endpoints.
• Upgrade the dependency to go-ntlmssp version 0.1.1 or later, regenerate lock files, rebuild binaries, and redeploy affected services.
• Restrict vulnerable applications so they can authenticate only to trusted NTLM endpoints until patching is complete.
• Search centralized logs and crash reporting systems for Go panic messages and stack traces involving NTLM challenge handling, go-ntlmssp, or ntlmssp.Negotiator.
• Add service supervision, restart policies, and panic recovery where appropriate to limit outage duration, while treating these as compensating controls only.
• Because EPSS is low, flat, and the issue is not in CISA KEV, handle through normal vulnerability remediation SLAs unless the affected service is internet-facing, mission-critical, or exposed to untrusted NTLM endpoints.