The HTTP/2 CONTINUATION flood tracked as CVE-2023-45288 is a serious HTTP/2 header‑parsing denial‑of‑service issue in Go’s net/http (and related golang.org/x/net/http2) that was fixed in Go releases 1.21.9 and 1.22.2 — and while Microsoft’s public advisory identifies Azure Linux as a Microsoft product that includes the affected open‑source library, that product‑level attestation does not prove Azure Linux is the only Microsoft artifact that could ship the vulnerable code.
CVE‑2023‑45288 abuses how HTTP/2 header blocks are split across HEADERS and CONTINUATION frames and how HPACK/Huffman decoding is performed. An attacker can send an excessive series of CONTINUATION frames so that a server — even after deciding a request’s headers exceed configured limits like MaxHeaderBytes — continues to parse and decode the remaining compressed header fragments. Because Huffman‑encoded fragments can be far more expensive to decode than they are to send, this parsing loop allows inexpensive client traffic to force expensive server CPU and memory work, potentially causing resource exhaustion and service degradation.
The Go project’s corrective approach was simple and pragmatic: stop parsing unlimited excess header data after a reasonable overflow threshold is reached and close the connection. Fixed Go releases set explicit upper bounds on excess header bytes or frames processed before terminating the connection; corresponding fixes were made in the x/net/http2 stacks used outside the Go standard library as well. If you run HTTP/2 endpoints built with vulnerable net/http or x/net/http2 versions, updating to the patched releases is the primary mitigation.
However, a product‑level attestation is an inventory statement — not a universal exclusion or proof that no other Microsoft product, service, or artifact could include the same vulnerable code. Microsoft’s wording confirms Azure Linux as a known carrier; it does not constitute a complete sweep of every Microsoft binary, container image, SDK, agent, or managed service that might embed the Go runtime or the net/http package. Independent analysis and internal artifact inventory are necessary before concluding other Microsoft offerings are unaffected. Security practitioners and customers should treat Microsoft’s attestation as a strong signal for the named product, and as an invitation to require the same artifact‑level verification for other Microsoft artifacts.
Why that distinction matters:
The essential truth for defenders is simple: trust Microsoft’s attestation for what it names (Azure Linux), but do not treat that attestation as a global guarantee for all Microsoft products. When in doubt, verify artifacts, rely on Microsoft’s expanding VEX/CSAF feed, and patch promptly.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2023‑45288 abuses how HTTP/2 header blocks are split across HEADERS and CONTINUATION frames and how HPACK/Huffman decoding is performed. An attacker can send an excessive series of CONTINUATION frames so that a server — even after deciding a request’s headers exceed configured limits like MaxHeaderBytes — continues to parse and decode the remaining compressed header fragments. Because Huffman‑encoded fragments can be far more expensive to decode than they are to send, this parsing loop allows inexpensive client traffic to force expensive server CPU and memory work, potentially causing resource exhaustion and service degradation.The Go project’s corrective approach was simple and pragmatic: stop parsing unlimited excess header data after a reasonable overflow threshold is reached and close the connection. Fixed Go releases set explicit upper bounds on excess header bytes or frames processed before terminating the connection; corresponding fixes were made in the x/net/http2 stacks used outside the Go standard library as well. If you run HTTP/2 endpoints built with vulnerable net/http or x/net/http2 versions, updating to the patched releases is the primary mitigation.
Why Microsoft’s Azure Linux attestation matters — and what it does not mean
Microsoft’s security pages and update guides sometimes include a concise product‑level mapping such as “Azure Linux includes this open‑source library and is therefore potentially affected.” That language means Microsoft has completed inventory work for the named product family (Azure Linux) and attested that those images contain the upstream code mapped to the CVE. Microsoft has also committed to publishing machine‑readable CSAF/VEX attestations and to expand those attestations as inventory work progresses.However, a product‑level attestation is an inventory statement — not a universal exclusion or proof that no other Microsoft product, service, or artifact could include the same vulnerable code. Microsoft’s wording confirms Azure Linux as a known carrier; it does not constitute a complete sweep of every Microsoft binary, container image, SDK, agent, or managed service that might embed the Go runtime or the net/http package. Independent analysis and internal artifact inventory are necessary before concluding other Microsoft offerings are unaffected. Security practitioners and customers should treat Microsoft’s attestation as a strong signal for the named product, and as an invitation to require the same artifact‑level verification for other Microsoft artifacts.
Technical summary of the vulnerability (concise)
- Vulnerability class: HTTP/2 header parsing / DoS (CONTINUATION frame flood).
- Root cause: servers continue to parse HPACK/Huffman‑encoded header fragments after MaxHeaderBytes is exceeded, without allocating storage but still performing expensive decode work.
- Principal impact: CPU and memory exhaustion on endpoints handling HTTP/2, possible denial of service.
- Where it lives: Go net/http (stdlib) and golang.org/x/net/http2 and downstream projects using those stacks.
- Go stdlib: update to 1.21.9 (or later) for the 1.21 line; 1.22.2 for affected 1.22 snapshots.
- golang.org/x/net/http2: update to v0.23.0 or later.
Is Azure Linux the only Microsoft product that could be affected?
Short answer: No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the vulnerable Go HTTP/2 library for this CVE (i.e., the known carrier they’ve inventoryed and published), but that attestation does not prove exclusivity across Microsoft’s entire product portfolio. Any Microsoft product, service, SDK, container image, agent, or binary that ships a Go runtime or Go‑built binaries compiled with the vulnerable stdlib/x/net/http2 versions could also be affected. Determining whether a specific Microsoft artifact is affected requires an artifact‑level check or an explicit Microsoft VEX/CSAF attestation naming that product.Why that distinction matters:
- Microsoft’s VEX/CSAF program improves transparency by publishing per‑product attestations, but it is (by design) an inventory of what Microsoft has checked so far.
- Absent an explicit attestation for a given Microsoft artifact, you cannot assume it is unaffected: you must either confirm via Microsoft’s published VEX/CSAF feed or verify the artifact yourself.
Practical examples — where vulnerable net/http code commonly shows up
It helps to think of where the Go stdlib and x/net/http2 might be embedded in Microsoft ecosystems:- Azure Linux images (confirmed attested carrier). Microsoft builds and publishes these images and has indicated they include the upstream open‑source components Microsoft has mapped for the CVE.
- Container images you run on Azure services (AKS, ACI) — any container that contains a Go binary using the vulnerable stdlib or x/net/http2 version is at risk, regardless of whether it’s stacked on Azure Linux or another base image.
- Microsoft‑maintained open‑source Go projects, SDKs, or CLI tools (for example, Azure SDKs for Go or in‑house Go tools) — if they vendor or statically link the vulnerable net/http code, they would be impacted.
- Customer‑supplied Go applications running on Microsoft infrastructure — these are not Microsoft products, but they are in‑scope for operators running workloads on Microsoft services and must be inventoried and patched by the workload owners.
How defenders should respond — concrete, prioritized steps
Below is an operational checklist you can use to confirm exposure and remediate — applicable to both Microsoft‑provided artifacts (where you should consult Microsoft’s VEX/CSAF first) and your own environments.- Check Microsoft’s published VEX/CSAF and CVE entries first
- Consult Microsoft’s MSRC update guide and their VEX/CSAF attestations to see whether the product in question is explicitly listed as Known Affected, Not Affected, or Under Investigation. Microsoft announced machine‑readable VEX in October 2025 and is using that channel to expand per‑product attestations. If a Microsoft product isn’t listed, the absence is not proof of safety — it may simply mean it hasn’t been inventory‑checked yet.
- Inventory binaries and images that run on your estate
- For containerized workloads: scan images for Go runtime artifacts and vulnerable package versions. Use image scanners (SCA tools) that report embedded Go package versions and the presence of net/http or x/net/http2. Look for the specific vulnerable versions (pre‑1.21.9 / 1.22.0-0 < 1.22.2 / x/net < v0.23.0).
- For Linux/VMs: search installed packages (rpm/dpkg) and locations where Go packages may be installed. For example:
- rpm -qa | grep -i golang
- dpkg -l | grep -i golang
- For Windows: check installed services and directories for Go executables or vendorized Go libraries.
- Inspect executables for Go build metadata
- Many Go binaries embed build information and a Go version string. Useful techniques:
- file /path/to/executable to see if it’s a Go static binary.
- strings /path/to/executable | grep -E 'go1.[0-9]+' to find embedded Go version markers.
- run go version -m /path/to/executable (on systems with the Go toolchain installed) to extract module and build metadata when present.
- If you find binaries compiled with an affected Go version, assume the binary’s net/http implementation may be vulnerable until proven otherwise.
- For container images, extract layers and search for vendor directories
- Look inside /usr/local/go/pkg/mod, /go/pkg/mod, or vendor directories to find module versions for net/http and golang.org/x/net/http2. If modules are vendored, the version may be visible in go.mod or in the folder path naming. Use SCA tools or a simple tar extraction to inspect layers.
- If you find exposure, patch or rebuild
- For Go applications you control: rebuild with updated Go (1.21.9+, or 1.22.2+) and updated x/net/http2 (v0.23.0+).
- For third‑party images or Microsoft artifacts you consume: check MSRC/VEX for vendor patches or guidance. If a Microsoft product you rely upon is listed as Known Affected, follow Microsoft’s remediation guidance (patch the image/service or apply vendor fixes).
- For edge mitigation while patches are applied: consider disabling HTTP/2 where acceptable, or apply upstream web proxy protections (rate limits, upstream parse timeouts) that reduce the attack surface. Beware that disabling HTTP/2 may have application compatibility impacts.
- Monitor and tune resource thresholds
- Watch for spikes in CPU/huffman decode hotspots on HTTP/2 endpoints and instrument the code paths that perform HPACK decoding.
- Harden MaxHeaderBytes conservatively where possible and ensure other throttles are in place (connection-level and frame‑rate limits).
Why Microsoft’s attestathelps — and its limits
Microsoft’s move to publish per‑product CSAF and VEX attestations increases transparency by telling customers which Microsoft products were inventory‑checked and what the result was for each CVE. This is valuable because:- It reduces noisy CVE alerts for Microsoft packages that don’t actually ship the vulnerable component.
- It gives automation-friendly signals (machine‑readable attestations) to orchestration and vulnerability management tools.
- It lets customers prioritize remediation where Microsoft has confirmed a product is Known Affected.
- Microsoft’s early VEX rollout started with Azure Linux and will be expanded to other products over time; lack of an attestation is inconclusive.
- The only authoritative way to know whether a Microsoft artifact is affected is either:
- Microsoft publishes a VEX/CSAF attestation listing that artifact as affected, or
- you perform artifact‑level verification (inspect the binary/image or rely on Microsoft support confirmations).
What Microsoft customers (and enterprise defenders) should ask Microsoft and vendors
When operating in an environment that relies on vendor‑supplied images or SaaS platforms, ask vendors these three precise questions:- Did you inventory this CVE against all product artifacts, and where can I find the CSAF/VEX attestation? — If the vendor lists the product as Known Affected or Fixed, that is decisive; if the product is Under Investigation, treat it as uncertain.
- Which exact binary or image versions carry the vulnerable component? — Ask for module names and exact versions (e.g., net/http version X, golang.org/x/net/http2 v0.22.x).
- What is the recommended remediation path and timeline for affected artifacts under your support? — Ask for patch timelines, mitigations, and compensation controls you can apply until a fix is available.
Case studies and precedents: why product‑scoped attestations must be read carefully
The pattern we see across multiple CVEs is consistent: vendors (including Microsoft) often publish product‑level attestations once they’ve completed inventory for particular artifacts (for example, Azure Linux). That attestation is authoritative for the named product family, but it has historically not been a proof of non‑existence across an entire vendor’s ecosystem. Community analyses and research notes repeatedly emphasize that absence of an attestation is not proof of absence of the vulnerable code; you should verify Microsoft’s attestations alongside your own artifact scans.Threat model: how attackers could exploit CVE‑2023‑45288 in the wild
- Attackers with the ability to open an HTTP/2 connection to a target server can craft a stream of HEADERS + many CONTINUATION frames with Huffman‑heavy header fragments.
- The attack is cheap for the client but expensive for the server because HPACK/Huffman decoding is CPU‑intensive.
- Even rejected requests (those exceeding MaxHeaderBytes) could force the endpoint to keep decoding fragments unless the implementation enforces an overflow cap.
- The vulnerability is most useful to attackers as an amplification technique against publicly reachable HTTP/2 endpoints without mitigations like frame rate limits, connection limits, upstream parsing timeouts, or WAF/proxy protections.
Auditor’s checklist — verifying Microsoft artifacts specifically
When you need to verify whether a Microsoft product or image you consume is affected:- Check Microsoft’s MSRC update guide and VEX feed for the CVE and the named product. Ask Microsoft support if you need confirmation for a particular SKU or image if it is not listed.
- If you manage Azure VM images or marketplace images: ensure you’re running the patched Azure Linux image or have applied Microsoft’s image updates.
- For Azure Platform services (PaaS): consult the service’s security advisories and Microsoft’s published VEX attestations. If a service is not in the VEX inventory, open a support case requesting artifact disclosure.
- For Microsoft‑published container images: inspect the image or request vendor confirmation of included Go versions and module versions.
Final assessment and recommendations
- CVE‑2023‑45288 is a credible, high‑impact HTTP/2 parsing DoS vulnerability in Go’s net/http/x/net stacks and is fixed in the Go releases and module versions referenced above. Patch and rebuild where you control code; update dependencies and images from vendors.
- Microsoft’s public statement that Azure Linux includes this open‑source library and is therefore potentially affected is an accurate product‑scoped attestation for the Azure Linux images Microsoft has inventory‑checked. It should be relied on for that product family. However, it is not a categorical guarantee no other Microsoft product could ship the same vulnerable code. Treat the attestation as informative and authoritative for the named product — and continue to require artifact‑level verification for any other Microsoft artifact you depend on.
- The practical next steps for operators:
- Immediately check Microsoft’s VEX/CSAF and the CVE tracker for updates if you depend on Microsoft images or services.
- Inventory and scan your binaries and images for the vulnerable Go versions and modules (1.21.x < 1.21.9; 1.22.0-0 < 1.22.2; x/net/http2 < v0.23.0).
- If you find vulnerable artifacts, patch or rebuild with fixed Go versions, and use upstream mitigations (disable HTTP/2 if feasible, add frame limits, proxy protections) until fully patched.
The essential truth for defenders is simple: trust Microsoft’s attestation for what it names (Azure Linux), but do not treat that attestation as a global guarantee for all Microsoft products. When in doubt, verify artifacts, rely on Microsoft’s expanding VEX/CSAF feed, and patch promptly.
Source: MSRC Security Update Guide - Microsoft Security Response Center
