CVE-2022-30635: Stack exhaustion when decoding certain messages in encoding/gob
Summary
CVE-2022-30635: Stack exhaustion when decoding certain messages in encoding/gob. Affects stdlib across 2 version ranges.
< 1.17.12
>= 1.18.0-0, < 1.18.4
Fixed in 1.17.12 or 1.18.4, depending on the release line you run. How to fix ↓
Also tracked for
- golang · Bitnami
- golang-1.15 · Debian:11
The same CVE-2022-30635 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
The encoding/gob package in the Go standard library is responsible for encoding and decoding Go values in a binary format. It is commonly used for serializing and deserializing data structures. The package provides the Encoder and Decoder types for this purpose. The vulnerability identified as CVE-2022-30635 affects the Decoder.Decode method in the encoding/gob package. This method can cause a panic due to stack exhaustion when decoding messages that contain deeply nested structures.
Vulnerability Detail
The vulnerability arises from the Decoder.Decode method's inability to handle deeply nested structures efficiently. When decoding a message with such structures, the method exhausts the stack, leading to a panic. This can result in a denial-of-service (DoS) condition, where an attacker can craft a malicious message that triggers the panic and causes the application to crash. The impact of this vulnerability depends on the context in which the encoding/gob package is used. Applications that deserialize untrusted input using the affected package are particularly vulnerable.
How To Fix
Latest published version: go1.25.5 as of 22 Oct 2026
go get stdlib@vgo1.25.5Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.
If you can't move to the latest
The minimum fixed version depends on the release line you run.
-
< 1.17.121.17.12go get stdlib@v1.17.12 -
>= 1.18.0-0, < 1.18.41.18.4go get stdlib@v1.18.4
Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →
Workaround
As a workaround, developers can consider implementing their own deserialization logic instead of relying on the encoding/gob package. By manually parsing and constructing the data structures from the serialized format, developers can avoid triggering the stack exhaustion vulnerability. However, this workaround requires careful implementation and thorough testing to ensure correctness and security.
Conclusion
The CVE-2022-30635 vulnerability in the encoding/gob package can lead to a denial-of-service condition due to stack exhaustion when decoding certain messages. To mitigate this vulnerability, developers should update their Go installations to versions 1.17.12 or 1.18.4. Additionally, implementing custom deserialization logic can serve as a workaround. For further support on vulnerability remediation, contact DevNack.com.
See every vulnerability recorded for stdlib →
FAQ
The encoding/gob package is a part of the Go standard library and provides functionality for encoding and decoding Go values in a binary format. It is commonly used for serialization and deserialization of data structures.
The vulnerability can lead to a denial-of-service (DoS) condition, where an attacker can craft a malicious message that triggers a panic and crashes the application. The impact depends on the context in which the encoding/gob package is used.
To fix this vulnerability, update your Go installation to versions 1.17.12 or 1.18.4, which include the necessary fixes. Thoroughly test your application after the update to ensure compatibility and stability.
As a workaround, you can implement your own deserialization logic instead of using the encoding/gob package. This requires careful implementation and testing.
Yes, you can use the Vulert Playground at Vulert Scanner to check if your application is affected by this vulnerability. Vulert monitors and alerts in real-time for open-source vulnerabilities, using Gopkg.lock to analyze your software.
References
Related vulnerabilities
Recent vulnerabilities recorded for stdlib.
