CVE-2022-30629: Go TLS Ticket Age Add Bug and Azure Linux Attestation

The Go standard library's TLS implementation shipped a small but consequential bug in 2022: session tickets created by crypto/tls omitted a randomly generated ticket_age_add value required by the TLS 1.3 specification. The result (tracked as CVE‑2022‑30629 / GO‑2022‑0531) is not a catastrophic break of confidentiality or integrity, but it does allow a network observer who can watch multiple TLS handshakes to correlate resumed sessions from the same client — in short, it weakens session privacy and makes tracking and linking of successive connections easier. Microsoft’s public guidance has repeatedly singled out Azure Linux (the company’s CBL‑Mariner‑derived distribution) as a product that includes the affected open‑source components; however, that attestation is a product-level disclosure, not a technical guarantee that no other Microsoft product could contain the vulnerable code. This article explains the technical problem, maps the real blast radius across the ecosystem, examines Microsoft’s wording and VEX/CSAF approach, and gives a practical, prioritized playbook for operators and developers who need to know whether they are genuinely affected.

Background: what went wrong in crypto/tls and why it matters​

TLS 1.3 session tickets include a 32‑bit field named ticket_age_add whose purpose is to obscure the actual age of a ticket that a client presents when resuming a session. The TLS 1.3 specification (RFC 8446) requires this field to be chosen uniformly at random for each ticket. When the server later verifies the client’s presented ticket age, it subtracts ticket_age_add to recover an estimate of the ticket’s real age; the randomness prevents an eavesdropper from learning the precise time the client originally connected or matching ticket timestamps across connections.
The Go crypto/tls implementation — in certain Go releases prior to the vendor’s patches — set newSessionTicketMsgTLS13.ageAdd to zero rather than generating a random 32‑bit value. Because multiple tickets produced by the server contained identical (non‑random) age_add values, an on‑path observer could compare the ticket_age values presented during resumption and correlate them to a single client or device. This is a privacy/correlation issue rather than an immediate key‑exposure flaw: attackers cannot decrypt TLS sessions as a result of this bug, but they can reduce the anonymity set for clients and link otherwise unlinkable sessions.
Key technical facts you should know:

• The vulnerability was publicly disclosed in mid‑2022; the upstream fix was applied in the Go project’s maintenance releases. The fix was backported to the 1.17 and 1.18 maintenance branches and included in releases after the fix dates.
• Affected code path: Go’s standard library crypto/tls, specifically the code that constructs TLS 1.3 new session tickets for servers.
• Practical exploitation requires an observer who can see TLS handshakes; it is not a remote network‑only zero‑click weapon that breaks encrypted payloads.

---

Timeline and vendor responses (concise)​

• Discovery and upstream fix: The Go project tracked the issue and committed a fix to generate proper randomness in the ticket_age_add field. The upstream bug was addressed in the Go maintenance releases that followed the disclosure.
• Distribution patching: Major Linux distributions (Debian/Ubuntu, Red Hat / CentOS / Oracle Linux, SUSE, Fedora and downstream vendor packages) issued advisories and rebuilt their Go packages or rebuilt dependent packages to consume the fixed Go runtime.
• CVE and scoring: The issue is tracked as CVE‑2022‑30629 (and referenced in Go’s vulnerability trackers). Various scoring authorities rated the issue low to moderate in impact because it enables session correlation rather than direct data leakage or code execution.

These corrections and advisories were rolled out across multiple OS vendors and downstream ecosystems over the months that followed the upstream fix.

---

Why the Microsoft Azure Linux attestation caused confusion​

When major vendors publish vulnerability attestations they commonly start with a conservative, authoritative statement of which products they have verified to include the affected upstream component. Microsoft followed that pattern: beginning in October 2025 the company published machine‑readable VEX/CSAF attestations for Microsoft products, starting with Azure Linux (the distribution Microsoft maintains for Azure host images and certain internal tooling). In many MSRC advisories and VEX/CSAF documents Microsoft’s FAQ-style language indicates that Azure Linux is the Microsoft product they have publicly identified as including the implicated open‑source library, and that they will update the CVE if additional Microsoft products are later discovered to include the same code.
That wording is intentional and operationally practical:

• It identifies, with high confidence, one Microsoft product that ships the affected upstream code and therefore gives customers an immediate operational target for patching (patch Azure Linux images).
• It does not assert that other Microsoft products categorically cannot contain the same vulnerable library or compiled binary. Absence of a published attestation is not proof of absence; it may reflect inventory sequencing, phased VEX rollout, or product scope decisions.

In plain language: Microsoft’s public attestation that Azure Linux includes the vulnerable crypto/tls variant should be read as a confirmed, authoritative statement for that product — but not a scientific proof that no other Microsoft binary or image ever contained the vulnerable Go code. Microsoft’s published VEX/CSAF files are the right place to check the current official inventory; Microsoft has also said it will update those records if more products are identified.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily. Long answer: Microsoft has publicly attested Azure Linux as containing the implicated library for a number of advisories, and for the purposes of initial disclosure that gives customers a clear remediation path. But other Microsoft products or services could be affected if they either:

• Ship or embed a Go runtime (the vulnerable crypto/tls is part of Go’s standard library), or
• Ship binaries that were compiled with an affected Go toolchain and that use TLS session tickets from crypto/tls (i.e., server components that create new TLS session tickets).

Concrete examples of Microsoft scenarios that warrant inspection:

• Azure Kubernetes Service (AKS) node images, Azure marketplace VM images, and other Microsoft‑provided images may include distro packages or Go‑built binaries. These images are assembled from many layers and packages; the presence of a vulnerable Go runtime or compiled binary is artifact‑specific.
• Internal Microsoft tools and services that are implemented in Go — whether or not they run on Azure Linux — could theoretically have included the vulnerable crypto/tls code prior to remediation if they were built with an affected Go version or linked against the vulnerable runtime.
• Windows components generally do not ship a Linux distro’s Go runtime, but Windows tooling that embeds or ships third‑party Linux binaries (for example, WSL2 kernel packaging or container tooling shipped in Windows images) could, depending on build choices, carry vulnerable code.

Important caveat: Microsoft’s public attestation process and the VEX/CSAF rollout cover Azure Linux first; they do not mean Microsoft has finished scanning every other product. You should treat the Azure Linux attestation as authoritative for Azure Linux and as informative for other Microsoft artifacts only insofar as you confirm presence via SBOMs, product VEX entries, or local inspection.

---

How broad is the real‑world blast radius?​

The vulnerability sits in the Go standard library, which means the potential blast radius is proportional to two things:

• How many products ship the Go runtime (or a copy of the crypto/tls source), and
• How many products are servers that issue TLS 1.3 session tickets and rely on the Go standard library for TLS.

In practice, the largest immediate impacts were in operating system packages (distributions shipping the Go toolchain) and in server software that is widely distributed as Go binaries or containers. Examples include:

• Linux distributions — vendors rebuilt and updated their golang packages to include the fix.
• Container runtimes, Kubernetes ecosystem components, and tooling written in Go — many of these are widely distributed and were rebuilt or repackaged by vendors.
• Storage and networking projects based on Go — vendors who bundle or ship those projects issued advisories and pushed updates.

Because many server components (and containerized apps) are written in Go, upstream fixes and downstream rebuilds were an essential mitigation path: a fixed Go runtime or rebuilding applications with a patched toolchain removes the problem at its source.

---

How Microsoft’s VEX / CSAF program changes the picture​

Microsoft’s public VEX/CSAF rollout — started in October 2025 and focused first on Azure Linux artifacts — makes vendor attestations machine‑readable and actionable. That matters because:

• Security teams can ingest VEX/CSAF data and automatically reduce false positives (for example, a scanner that flags a CVE but the vendor’s VEX attests “Not Affected” for a given product).
• Microsoft’s phased approach means Azure Linux was the first to receive formal attestations; other products will be added over time.
• The company’s public position is to update the VEX/CSAF metadata if it identifies additional Microsoft products that ship the same upstream component.

Operational implication: if your estate runs Azure Linux, act immediately on Microsoft’s attestation. If you run other Microsoft artifacts — AKS node pools, Windows images with Linux components, Marketplace images, or Microsoft‑distributed containers — do not assume “not affected” until you check the VEX/CSAF entry for that product or inspect the artifact locally.

---

Practical detection and validation steps (operator playbook)​

Below are prioritized actions administrators and devops teams can use to determine exposure and remediate rapidly.

• Inventory first: find hosts, images, containers and binaries that include Go or were built using Go.
• Check package managers on Linux hosts: list installed Go packages (for example, use your distro-native package tools to query installed golang packages).
• Inventory container images used in production: scan image manifests and layers for Go runtime packages or for Go-built binaries.
• For Windows and special images: inspect WSL2 kernels, Marketplace images, and any Microsoft-provided VM images your environment consumes.
• Verify Go versions and binary provenance:
• If a host uses a packaged golang (the OS-provided runtime), check the package version against the fixed versions published by the Go project or your OS vendor.
• For compiled binaries, try to determine the Go toolchain used to compile them. Where possible, inspect build metadata embedded in Go binaries (toolchain metadata is present in modern Go builds) or ask the vendor/SBOM for the build toolchain. When metadata is not available, consult the rebuild or CI pipeline that produced the binary.
• Patch and rebuild:
• Apply vendor/OS updates that upgrade Go to the fixed maintenance releases (patched 1.17.x and 1.18.x maintenance releases, or later stable releases).
• Rebuild any internal or third‑party Go binaries with a patched Go toolchain and redeploy them.
• Update and redeploy container images; do not assume a host-level update fixes containers that include an old runtime statically linked inside images.
• Temporary mitigations if you cannot patch immediately:
• Consider disabling TLS session resumption where possible or enforce short ticket lifetimes and frequent ticket rotation at your TLS termination points until binaries are patched. This reduces how useful ticket correlation is.
• Monitor session resume patterns from your perimeter infrastructure for suspicious correlation patterns or mass resumption behavior. While detection is not trivial, unusual patterns may hint at exploitation in high-value scenarios.
• Continuous verification:
• Ingest VEX/CSAF data from your vendors (including Microsoft’s published attestations) and map those machine‑readable statements to your inventory to automate affect/non‑affect decisions.
• Request SBOMs from product vendors and insist on build-toolchain metadata for any third‑party binary deployed into your estate.

---

Detection commands and quick checks (examples)​

The exact commands depend on environment and tooling, but here are practical, high‑value checks you can run quickly:

• Package-level checks (Linux):
• Query your package database for golang packages and Go toolchain versions. If you find golang packages older than the fixed maintenance release numbers, flag those hosts for patching.
• Inspect distro security advisories for your OS; many distros published packages that backported the Go fix.
• Container‑image checks:
• Use your image scanning tool to flag images that contain golang packages or that include Go-built binaries. If your scanner can read embedded build metadata, search for go toolchain versions in binary metadata.
• Binary inspection:
• On a sample binary you suspect was built with Go, look for embedded strings that contain the Go version (search for “go1.”). Modern Go builds may include build information which some tools can extract; where available use the language’s inspection utilities or tooling provided by your CI/CD system to confirm the toolchain used.

If you lack automation, prioritize hosts and images that terminate TLS sessions or operate at the edge — those are the places where session-ticket construction happens and where this vulnerability has operational relevance.

---

Why rebuilds matter: static vs dynamic linking and the path to safe state​

One common source of confusion with language‑level vulnerabilities is the difference between updating the runtime and rebuilding the application. With Go:

• When an application is compiled and statically linked into a single binary using an old Go toolchain, updating the host’s OS packages does not change that binary’s embedded crypto/tls code. You must rebuild the binary with a patched toolchain and redeploy.
• When the vulnerable code is shipped as a distribution runtime package (for example, as a dynamic library or the distro’s golang package used for builds), updating the package can be sufficient — but you must also inspect user binaries and containers that were built earlier.

Operational rule: if you build with Go, rebuild with an updated and fixed Go version. If you run distro-provided Go at runtime, update the distro package and restart affected services.

---

Risk analysis: who should worry most?​

This vulnerability is best understood as a privacy/correlation weakness rather than a traditional critical-availability or remote code execution vulnerability. That said, there are scenarios where it increases risk materially:

• High‑profile anonymity use cases (privacy‑oriented clients connecting to sensitive services) where session linking could reveal user identity or activity patterns.
• Large fleets of clients where an attacker can observe the network traffic (for example, a shared Wi‑Fi network, certain ISP‑level monitoring, or adversaries controlling on‑path visibility).
• Environments where session linkability can be combined with other metadata to deanonymize users or track particular devices over time.

For most enterprise internal services and typical cloud deployments, the immediate security impact is modest: the fix is available and patching is straightforward. However, organizations operating privacy‑sensitive services (or hosting services relied on by privacy‑sensitive users) should prioritize remediation and confirm that deployed TLS termination points have been updated or rebuilt.

---

What Microsoft customers should do, step by step​

• If you run Azure Linux images: apply Microsoft’s Azure Linux updates immediately for hosts that your environment uses. Treat Microsoft’s Azure Linux VEX/CSAF attestation as an authoritative indicator that those images contained the affected upstream code and require patching.
• For AKS and other managed Kubernetes services: ensure that node images and node pools have been updated to the fixed images; if you run custom node images, rebuild them with patched OS packages and updated container components.
• For container workloads: rebuild containers that were built with an affected Go toolchain; update base images and redeploy.
• For Windows customers: inspect any Windows‑hosted components that package or distribute Linux or container-based artifacts (WSL kernels, Marketplace images, etc.). If you use Microsoft‑published artifacts, consult MSRC VEX/CSAF entries and product advisories to determine status.
• For internal Go applications: patch your CI pipelines to use a fixed Go toolchain (or upgrade to a maintained stable Go release), rebuild artifacts, and deploy the rebuilt artifacts across environments.
• Automate: ingest vendor VEX/CSAF feeds, map attestations to your inventory, and automate remediation tasks where possible.

---

Strengths and limits of Microsoft’s public position​

Strengths:

• Microsoft’s decision to publish machine‑readable VEX/CSAF attestations (beginning with Azure Linux) improves transparency. It gives customers a clear, machine‑actionable statement about whether a given Microsoft product is affected.
• By naming Azure Linux as a product that includes the implicated upstream code in these attestations, Microsoft provides a tangible, prescriptive remediation target for customers that run those images.

Limits and caveats:

• The attestation is product‑scoped and phased; absence of a product name in a VEX attestation is not a reliable indicator that the product is free of upstream code — it may simply mean Microsoft has not yet completed that product’s inventory and attestation.
• The VEX rollout began with Azure Linux; customers who rely on other Microsoft artifacts should not assume non‑affect status and should do independent verification (SBOMs, build metadata, or direct vendor inquiry) until those product attestations are published.

Bottom line: Microsoft’s public attestation is helpful and welcome, but responsible operators must treat it as one input in their overall inventory and verification process.

---

Final verdict and recommendations​

CVE‑2022‑30629 is a privacy‑affecting bug in Go’s crypto/tls implementation that was fixed upstream and patched by operating system and package vendors. Microsoft’s published statements identifying Azure Linux as a product that shipped the implicated component are authoritative for that product; however, they are not a proof that no other Microsoft product ever included the vulnerable code.
If you manage infrastructure, prioritize your response as follows:

• Patch Azure Linux hosts and images immediately if you run them.
• Rebuild any Go‑based server binaries with a patched Go toolchain and redeploy.
• Update container base images, rebuild affected images, and redeploy to nodal fleets.
• Ingest vendor VEX/CSAF data and validate any “Not Affected” attestations by cross‑checking SBOMs or build metadata for high‑value artifacts.
• Consider temporary mitigations (disabling session resumption or reducing ticket lifetimes) for very high‑sensitivity deployments while you patch.

This vulnerability underscores a broader lesson: language standard libraries and compilers are part of the attack surface. When they change, the impact ripples through distributions, containers, and compiled binaries. The most reliable route to safety is a combination of vendor attestations (like Microsoft’s VEX/CSAF outputs), local artifact inspection (SBOMs and build metadata), and a DevOps practice that rebuilds and redeploys applications whenever foundational toolchains are updated.
Conclude actionably: treat Microsoft’s Azure Linux attestation as definitive for Azure Linux and as a prompt to inspect other Microsoft artifacts; do not assume exclusivity. Patch, rebuild, and automate verification — and use vendor VEX/CSAF attestations to reduce uncertainty while you complete the necessary checks across your estate.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center