CVE-2026-46597

What it actually does

This vulnerability is a remotely reachable denial-of-service condition in the AES-GCM packet decoder in golang crypto. An incorrectly placed cast from bytes to int can cause the server-side decoder to panic when it processes specially crafted encrypted packet input. The CVSS vector indicates network exploitability, low attack complexity, no required privileges, and no user interaction, with impact limited to availability rather than confidentiality or integrity.

Why it matters to the business

A vulnerable service that accepts attacker-controlled AES-GCM packet data could be crashed repeatedly, causing service outages, degraded availability, failed client connections, and operational disruption. The issue is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, but the affected crypto component may be embedded in many Go applications and services, so exposure depends on whether products statically include the vulnerable package and expose the affected decoder over a network path.

How an attack unfolds

An attacker first identifies a network-accessible service or protocol implementation that uses the vulnerable golang crypto AES-GCM packet decoder on untrusted input. The attacker then sends a deliberately malformed or boundary-condition packet that triggers the incorrect bytes-to-int cast during decoding. When the vulnerable code path is reached, the decoder panics server-side. If the application does not recover cleanly from the panic, the process, worker, or request handler can terminate, producing a denial of service. Repeating the request can keep the service unstable or unavailable until the vulnerable dependency is updated or defensive input handling/recovery is added.

How to fix it

Upgrade golang crypto to a version that contains the upstream fix as soon as a fixed version is available from the project or from the vendor distributing the affected software. Because no fixed versions were provided in the input, track the upstream golang.org/x/crypto advisory/release notes and rebuild/redeploy all statically linked Go applications that vendor or compile this dependency. Where immediate upgrade is not possible, reduce exposure by limiting network access to affected protocol endpoints, enforcing rate limits, rejecting malformed or oversized packets before decode, adding panic recovery around untrusted packet decoding paths, and ensuring process supervisors restart crashed services while permanent fixes are deployed.

How to confirm the fix worked

Confirm whether applications import or vendor the affected golang crypto package by reviewing go.mod, go.sum, vendored modules, SBOMs, and build manifests. Validate remediation by confirming the deployed binary was rebuilt with a fixed golang.org/x/crypto version once available, not merely that source code was updated. Exercise negative test cases with malformed AES-GCM packet inputs in a staging environment and verify the service returns controlled errors rather than panicking or terminating. Monitor runtime telemetry after deployment for absence of panic stack traces associated with AES-GCM packet decoding.

Typical attack path

1. Identify an externally reachable Go-based service or product that processes AES-GCM encoded packets using the affected golang crypto component.
2. Craft packet data that reaches the AES-GCM packet decoder and triggers the faulty bytes-to-int cast condition.
3. Send the crafted input to the vulnerable service without authentication or user interaction.
4. Cause a server-side panic in the decoder.
5. Repeat the request to cause recurring crashes, dropped connections, or service unavailability.

How to detect it

Look for evidence of prior exploitation in application logs, process supervisor logs, container orchestration events, crash dumps, and centralized observability data. Relevant signals include Go panic messages, stack traces referencing AES-GCM packet decoding, repeated service restarts, crash loops, abrupt connection resets immediately after malformed encrypted packet traffic, and spikes in failed decode errors from a single source or small set of sources. Network logs may show repeated short sessions or anomalous packet sizes to the affected protocol endpoint preceding process termination. If binaries were built with symbols, inspect crash dumps and stack traces for functions in golang.org/x/crypto related to AES-GCM packet decoding. No named threat actors or ransomware campaigns are currently associated with this vulnerability based on the supplied data.

• panic: runtime error
• panic serving
• goroutine
• golang.org/x/crypto
• AES-GCM
• aes-gcm
• GCM packet decoder
• packet decoder
• server-side panic
• CrashLoopBackOff
• Back-off restarting failed container
• segmentation violation
• fatal error: runtime
• runtime error: integer overflow
• runtime error: index out of range
• runtime error: slice bounds out of range

What your security team should do

• Inventory Go applications and third-party products that include golang.org/x/crypto or related vendored crypto code, prioritizing internet-facing services.
• Determine whether any exposed service accepts untrusted AES-GCM packet input that reaches the vulnerable decoder.
• Track upstream and vendor advisories for the fixed golang crypto release, then rebuild and redeploy affected Go binaries because Go dependencies are commonly statically compiled.
• Apply temporary compensating controls such as network allowlisting, rate limiting, malformed packet rejection, and crash-loop monitoring for exposed endpoints.
• Create detections for panic stack traces and abnormal restart patterns in services using AES-GCM packet decoding.
• Prioritize patching based on exposure and availability requirements; although EPSS is currently low and the issue is not in KEV, exploitation requires no credentials and can directly affect uptime.