CVE-2023-35945: Azure Linux Attestation and Envoy nghttp2 Risk Mitigation

Microsoft’s short advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a product‑scoped attestation, not a categorical guarantee that no other Microsoft product or service ships the same vulnerable code. erview
CVE‑2023‑35945 is a denial‑of‑service class vulnerability that surfaced in mid‑2023 within Envoy’s HTTP/2 handling: a cleanup path in the HTTP/2 codec (ultimately traced to nghttp2 behavior) can skip de‑allocation of bookkeeping structures when RST_STREAM is followed immediately by GOAWAY, leading to a gradual memory leak and eventual process exhaustion. The upstream advisories and vulnerability databases list the affected Envoy releases and the fixed versions.
Microsoft’s public guidance for this CVE — the same concise FAQ language you quoted — names Azure Linux as the Microsoft product the company has confirmed to include the implicated open‑source component. Microsoft also states it will update the CVE/VEX record if additional Microsoft products are identified as carriers, and points customers toward its CSAF/VEX attestation program. That program, Microsoft says, began publishing in October 2025.
This combination — a targeted upstream bug in widely reused open‑source code, plus a product‑level attestation from a major vendor — raises two immediate questions for defenders: (1) is any Microsoft product beyond Azure Linux at risk, and (2) what practical steps should organizations take to confirm, mitigate, and close exposure?

---

What the technical record actually says about the bug​

• The defect is a cleanup memory leak triggered by a particular HTTP/2 frame sequence: RST_STREAM immediately followed by GOAWAY. An Envoy instance that relies on nghttp2 can therefore leak header maps and bookkeeping structures under repeated or high‑rate exploitation attempts, producing a progressive memory exhaustion DoS.
• Envoy fixed the behavior in the 1.23., 1.24., 1.25. and 1.26. branches with respective security releases (for example, 1.23.11, 1.24.9, 1.25.8 and 1.26.3). Upgrading Envoy to a patched release is the canonical remediation. nghttp2 upstream also published related fixes; downstream distributions and packagers published fixed nghttp2 packages where relevant.
• Exploit complexity is low in principle (a remote attacker can drive the sequence across a network path), but practical exploitation depends on whether the attacker can cause the required frames and on service topology (who terminates HTTP/2 and where). Rate limiting and HTTP/2 termination choices influence real‑world risk.

---

What Microsoft’s Azure Linux attestation means — and what it does not mean​

Microsoft’s phrasing — “Azure Linux includes this open‑source library and is therefore potentially affected” — performs a specific function: it signals Microsoft has completed an inventory for that product and found ource component in the Azure Linux distro. This is useful and important information for customers who run Azure Linux images, because it tells them that a vendor-maintained image they run is known to carry the component and therefore needs patching or mitigation.
However, it is not a universal negative statement about the entire Microsoft product portfolio. In other words:

• The attestation is product‑scoped. Microsoft explicitly reserves the right to update the CVE/VEX record if more of its products are found to include the same upstream code. That implies the attestation is an inventory statement, not a blanket claim that Azure Linux is the single and only Microsoft product that could ever include the vulnerable component.
• Many Microsoft cloud services and platforms incorporate open‑source building blocks in different layers. Some Azure platform components (and managed platform services) include Envoy or other CNCF projects as part of their implementation; in those cases the same upstream library (nghttp2) could be present somewhere in the service stack even if Microsoft has not yet published a per‑product attestation confirming that fact.

Put plainly: Microsoft’s advisory is authoritative about Azure Linux, and it is the only Microsoft product Microsoft has publicly attested to include the implicated library for the CVE at the time of publication — but it is not a proof that no other Microsoft product carries the vulnerable code.

---

Where Envoy and nghttp2 commonly appear in Microsoft stacks (and why that matters)​

Understanding which Microsoft products might carry the vulnerable code requires thinking like a supply‑chain investigator: Envoy is a popular data‑plane proxy and is embedded in many cloud‑native control planes and managed services. A few concrete, verifiable signals:

• Microsoft documents that Azure Container Apps is built on Kubernetes primitives and explicitly identifies Envoy — alongside Dapr and KEDA — as bundled CNCF components in the service control plane. That means Envoy is present in the implementation of that managed service and could, depending on build and packaging choices, transitively bring nghttp2 or Envoy binaries that use nghttp2 into the runtime stack.
• Security scanners and plugin feeds that enumerate distribution packages show Azure Linux images shipping nghttp2 packages; Tenable/Nessus plugins specifically flag Azure Linux 3.0 instances for nghttp2/Envoy CVE checks tied to CVE‑2023‑35945. That’s independent confirmation that the Azure Linux distro bundle historically included nghttp2 packages until patched.
• Outside of vendor‑managed services, customers run Envoy and nghttp2 widely on AKS, on VMs, and inside container images uploaded to Azure Container Registry. Those customer‑controlled artifacts are outside Microsoft’s product inventory and must be inventoried and patched by owners. In short: the Microsoft ecosystem contains multiple likely locations for Envoy/nghttp2 to be present — both in Microsoft‑managed platform code and in customer‑deployed workloads.

These data points show the practical reality: even when Microsoft names one of its own products as carrying the library, the same code can exist elsewhere in the cloud, either in Azure services or in customer images and clusters.

---

Short answer to the user’s question​

Is Azure Linux the only Microsoft product that includes the open‑source library and is therefore potentially affected by CVE‑2023‑35945?

• Short, careful answer: No — Azure Linux is not proven to be the only Microsoft product that could include the vulnerable library. It is the only Microsoft product Microsoft has publicly attested to include the implicated component for this CVE at the time of their advisory. Microsoft has committed to updating the CVE/VEX entry if additional Microsoft products are identified as carriers.
• Practical consequence: treat Azure Linux as a known carrier (patch it). At the same time, expand your inventory and scanning to other places where Envoy or nghttp2 might appear (managed services like Azure Container Apps, AKS clusters, container images, and custom VM installs), because the upstream library and Envoy proxy are commonly reused and may be present in other Microsoft artifacts or customer artifacts hosted on Azure.

---

Recommended action plan for security teams (practical, sequential)​

• Inventory — find all possible carriers
• Search your Azure subscriptions for instances of Azure Linux images and apply the vendor guidance to update those images immediately. Microsoft’s attestation gives you a starting point to prioritize.
• List managed services you use (e.g., Azure Container Apps, AKS clusters, API gateways, ingress controllers) and ask whether any of those services use Envoy or terminate HTTP/2 for customer workloads. Azure Container Apps explicitly bundles Envoy and therefore should be part of your risk assessment.
• Inventory containers and container registries for Envoy/nghttp2 in image manifests and SBOMs. If you don’t have SBOMs, scan image layers for envoy, nghttp2, or package names such as libnghttp2 using tools like trivy, grype, or your vulnerability scanner.
• Patch — apply fixes where available
• If you run Envoy directly, upgrade to a patched Envoy release (e.g., 1.23.11, 1.24.9, 1.25.8 or 1.26.3 — match your branch). Upstream advisories and NVD list these patched versions.
• If you ship or rely on nghttp2 packages from your distro, install the distributor’s patched nghttp2 (upstream nghttp2 fixes are referenced by vendor advisories; some packagers list the fixed nghttp2 package version 1.55.1 or later).
• For Azure Linux images, apply Microsoft’s Azure Linux security updates as published in their update channel. Scanners such as Nessus/Tenable added checks for Azure Linux related to CVE‑2023‑35945; use those detections to verify patch status.
• Mitigate — where immediate patching is infeasible
• Consider terminating HTTP/2 at a boundary you control (for example, at a perimeter proxy that you can harden or patch independently), or rate‑limit the number of new HTTP/2 streams and abnormal frame patterns to reduce the ability to exploit the sequence that triggers the leak. Rate limiting and WAF controls won’t fix the root cause but can reduce risk while you patch.
• Reduce attack surface by restricting which upstream services can return GOAWAY sequences to critical proxies; add monitoring to detect repeated RST_STREAM + GOAWAY sequences in HTTP/2 traces.
• Detect — monitor and alert
• Add alerts for unexpected and sustained increases in Envoy process memory or for abnormal HTTP/2 frame sequences at proxies where you terminate HTTP/2.
• Use vulnerability scanner plugins and image scanners (Nessus plugin IDs and Tenable CVE fingerprints were updated to detect this issue in Azure Linux and other distributions) to periodically verify remediation.
• Document and communicate — use CSAF/VEX and SBOMs
• Track Microsoft’s VEX/CSAF entries and per‑product attestasaid it will update CVE/VEX if more products are impacted, and began publishing CSAF/VEX in October 2025. Use those artifacts to maintain an authoritative inventory of which Microsoft products the vendor has attested include the affected code.
• Generate or collect SBOMs for your container images and VM images so you can quickly map vulnerable components to services and application owners.

---

Why the vendor attestation model can be both helpful and misleading​

Vendor product‑scoped attestations (like Microsoft’s Azure Linux statement) are a major step forward for supply‑chain transparency. They let customers quickly triage which vendor‑maintained images or managed products are known carriers, and that accelerates prioritized patching.
But there are limitations and risks:

• Attestations are only as good as the inventory they represent. Microsoft’s attestation covers Azure Linux because Microsoft has audited that product. It does not automatically prove the absence of the component in other Microsoft products or in customer‑managed stacks. Treat an absence‑of‑attestation as unknown, not as definitive proof of safety.
• Cloud services are layered and complex. Managed control planes can include third‑party components (Envoy is commonly embedded in managed service control planes). The presence of a component in a managed service does not always translate to direct customer exposure, but it can create transitive exposure (for example, if the service runs shared control‑plane code that handles customer traffic).
• Hidden dependencies inside container images and third‑party base images are a frequent source of surprise during incident response. Scanners occasionally flag vulnerable packages in base images and language runtimes long after an upstream advisory is published.

Because of these points, do not rely on a single vendor attestation as your only source of truth. Combine vendor attestation with active scanning, SBOMs, image layer inspections, and runtime monitoring.

---

Technical checklist for engineers (concrete items)​

• If you run Envoy:
• Confirm version: envoy --version
• Upgrade to the nearest supported patched release (1.23.11 / 1.24.9 / 1.25.8 / 1.26.3 or later depending on your branch policy).
• If you run Linux distributions (including Azure Linux):
• Use your distro’s package manager to check nghttp2 and envoy packages and apply updates. Azure Linux customers should follow Microsoft’s published update channel and patch guidance. Nessus/Tenable plugins exist that detect older Azure Linux packages tied to CVE‑2023‑35945.
• If you use Azure managed services:
• Inventory usage of Azure Container Apps and check with Microsoft support or published release notes whether the service control plane or ingress layer has been updated for the Envoy/nghttp2 fix. Microsoft’s VEX/CSAF pages are the right place to look for product‑level attestations.
• If you operate AKS or self‑managed clusters:
• Scan cluster images and DaemonSets for envoy or nghttp2 components.
• Apply Envoy upgrades in sidecars/ingress cothe binary where necessary.
• If you can’t patch immediately:
• Rate limit HTTP/2 creation and new streams; terminate HTTP/2 in hardened, patched layers; use network egress rules and WAF to block suspicious traffic patterns.

---

Critical analysis — strengths and remaining risks​

Strengths:

• Microsoft’s decision to publish product‑scoped attestations and adopt CSAF/VEX is a measurable improvement in vendor transparency. Customers have a clear signal to prioritize patching for a Microsoft‑maintained product (Azure Linux) and, importantly, Microsoft promises to update the record should more products be affected. That commitment helps defenders allocate scarce remediation resources with confidence.
• Upstream fixes are available and straightforward: Envoy and nghttp2 teams produced patches and vendor/package maintainers have published updates. That means practical remediation is usually a matter of patch management, not redesign.

Risks and gaps:

• The product‑scoped attestation model leaves room for unknown carriers — Microsoft’s public statement is authoritative for Azure Linux but not exhaustive for all Microsoft‑managed services or customer images hosted on Azure. Attackers exploit the weakest link: an unpatched Envoy in an AKS pod, a stale container image, or a third‑party marketplace VM image can remain vulnerable even after Azure Linux images are patched.
• Automated scanning is still inconsistent across ecosystems. Some scanners and plugin feeds added checks months after the upstream advisory (Tenable/Nessus and Qualys updates were rolled out over 2024–2025), leaving windows where vulnerable artifacts might be missed. Relying solely on one scanner means you can miss exposures in other registries or artifact types.
• Managed services blur responsibility boundaries. Where Microsoft controls the control plane or a managed ingress layer, a vulnerability in a shared component might be remediated by Microsoft at the control plane level — but that does not absolve customers from scanning their own images and workloads for embedded vulnerable libraries.

---

Final recommendations (decision‑ready)​

• Treat Microsoft’s Azure Linux statement as actionable: patch Azure Linux images immediately and verify via your patch pipeline. Use the vendor’s update channel and confirm the installed package versions.
• Broaden your search: scan Azure Container Apps usage, AKS clusters, VM images, container registries, and orchestration manifests for Envoy/nghttp2 and remediate any instances found. Azure Container Apps publicly includes Envoy and should be part of your inventory review.
• Patch Envoy/nghttp2 where present. If you operate Envoy directly, upgrade to a patched Envoy release; if you rely on distro packages, update nghttp2 packages.
• Use layered mitigations until you can patch: HTTP/2 termination at a hardened, updatable boundary; stream rate limiting; memory/health probes that can detect runaway processes and recycle them; and WAF rules to block anomalous patterns.
• Operationalize vendor attestations: consume Microsoft CSAF/VEX outputs and maintain SBOMs so you can map vendor attestations to your deployed artifacts quickly. Microsoft’s move to publish CSAF/VEX is a helpful lever you should adopt into your vulnerability management workflows.

---

CVE‑2023‑35945 is an instructive example of modern supply‑chain risk: a subtle bug in a widely used library (nghttp2) manifests in a widely deployed proxy (Envoy) and then ripples through a complex cloud ecosystem. Microsoft’s Azure Linux attestation is a useful telemetry point — act on it — but it is not the whole picture. Pursue a combination of inventory, timely patching, smart mitigations, and vendor attestations (CSAF/VEX + SBOMs) to close the gap between a named vulnerable product and the real, distributed attack surface your organization actually runs.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center