CVE-2024-43799 Explained: Node Send XSS Risk and Azure Linux Attestation

Microsoft’s short answer — no: the MSRC note that “Azure Linux includes this open‑source library and is therefore potentially affected” is a product‑scoped attestation, not a technical guarantee that no other Microsoft product or image could carry the same vulnerable component. The CVE in question (CVE‑2024‑43799) tracks a template‑injection / XSS weakness in the widely used Node.js package send (the module many Express apps and static‑file pipelines use to stream files). The vulnerability was fixed in the upstream package, but understanding Microsoft’s wording, the practical exposure for your estate, and the right response steps requires separating three things: what Microsoft has attested, what is technically possible, and what practitioners should do now to find and fix any vulnerable carriers in their environment.

Background / Overview​

The Node.js package send is a small, focused library whose job is to look up a path on disk and stream it as an HTTP response. It’s frequently pulled into applications directly or indirectly through frameworks (notably Express), static file middleware, and many container images. In September 2024 a vulnerability was disclosed and assigned CVE‑2024‑43799: certain input passed to SendStream.redirect() could be handled in a way that enables template injection that can lead to cross‑site scripting (XSS) under specific runtime conditions. The maintainers released a patch (starting at version 0.19.0) to change how the library sanitizes or constructs redirect targets and templates; downstream distributions and packagers subsequently began shipping fixes or backports.
Microsoft’s MSRC update guide for the CVE includes a short FAQ line stating that Azure Linux (the Microsoft‑published Linux distribution) “includes this open‑source library and is therefore potentially affected,” and that Microsoft is publishing machine‑readable CSAF/VEX attestations and will update the CVE mapping if additional Microsoft products are found to ship the component. That phrasing is precise and actionable for Azure Linux customers — but it does not mean Azure Linux is the only Microsoft product that could include or ship the vulnerable Node.js package.

---

What CVE‑2024‑43799 actually is — technical summary​

• Affected component: the Node.js package send (used for streaming static files).
• Affected versions: versions prior to the patched release (upstream fix shipped in send 0.19.0 and corresponding downstream updates/backports).
• Root cause: untrusted input was passed into SendStream.redirect() and into page/template rendering paths without sufficient context‑specific escaping or validation; that allowed an attacker, under constrained conditions, to inject markup or scripts that a browser could execute when the victim user interacted with the rendered template.
• Exploit preconditions: the attacker needs to control the value passed to response.redirect(), the web framework must not complete an immediate redirect before the vulnerable template is rendered, the browser must present the vulnerable template to the victim, and the victim must interact (for example, click a crafted link) while still in the vulnerable page — that is, the exploit requires user interaction and specific execution ordering.
• Impact: the bug is classed in the XSS/CWE‑79 family; upstream advisories scored it moderate (CVSS around the mid range) because of the required user interaction and complex timing. Nevertheless, successful exploitation of XSS in the right context can lead to session theft, credential theft, or further client‑side compromise.

This vulnerability differs from a blind, unauthenticated remote code execution on the server — it’s primarily an XSS / template injection vector exposed via how send constructs redirects/templates. But because send is commonly embedded in many different application stacks (express, static file servers, middleware) the blast radius can be large if vulnerable versions are widely deployed and reachable.

---

Where the risk appears in Microsoft ecosystems — what Microsoft’s statement means (and doesn’t mean)​

Microsoft’s MSRC phrasing — “Azure Linux includes this open‑source library and is therefore potentially affected” — is best read as an inventory attestation for a specific product family, not a claim of exclusivity.

• What it does mean: Microsoft scanned the build/artifacts for Azure Linux, found the implicated open‑source component, and therefore marked Azure Linux as a carrier for the purposes of their vulnerability tracking and remediation plan. If you run Azure Linux images supplied by Microsoft, treat that attestation as a confirmed scope for remediation and follow Microsoft’s guidance for updating the distribution packages or images.
• What it does not mean: Microsoft has not said “no other Microsoft product includes this library.” There are many other Microsoft‑distributed Linux artifacts and runtime artifacts that could, depending on how they were built or composed, include the vulnerable package:
• Container base images published by Microsoft (for example, images used in Azure container registries or the Microsoft Build of OpenJDK images) can include Node.js stacks or application layers that pull npm packages.
• Platform services (Azure App Service on Linux, Azure Functions with Node.js runtimes, managed containers and platform images) may carry the vulnerable package in service stacks or in customer images cached by the platform.
• Developer tools and SDK images, Marketplace images, or partner VM images delivered through Microsoft channels might also include Node.js packages.
• WSL2 kernels and derivatives are not likely to ship Node.js server packages by default, but WSL or other developer‑focused images that include distribution package sets could include vulnerable consumer packages if the image includes Node/npm artifacts.

In short: Microsoft attested Azure Linux because it’s an owned, published distribution with a clear build pipeline — a practical starting point for public, machine‑readable attestations. But the absence of an MSRC attestation for other Microsoft products should never be treated as proof those artifacts are free of the vulnerable component.

---

Cross‑checking the upstream and distribution landscape​

Independent vulnerability trackers and distribution maintainers corroborated the upstream issue and the patch timeline. Upstream maintainers released a fix in a new minor version of send; security vendors and Linux distribution maintainers (for example, Debian LTS and package security teams) subsequently published advisories and backports for distribution packages. The practical consequence: if you run any Linux distribution image or package that contains node‑send older than the patched release, you should remediate.
This is a typical supply‑chain lifecycle: a vulnerability is discovered and fixed upstream, then distributors package and ship fixes on their own cadence. Microsoft’s attestation for Azure Linux is one part of that ecosystem; Debian, upstream npm, and security scanners are the others. For any production environment, rely on both upstream advisories and your distro/provider patch notices.

---

Practical, operational guidance — how you should respond now​

If you manage infrastructure or applications that run Node.js, containers, or Microsoft distributed images, follow this prioritized checklist to find and remediate potential exposure.

1. Confirm whether you run the vulnerable package​

• App code and servers:
• Search your application code repositories and deployment pipelines for the dependency “send” or for direct usage of response.redirect() patterns that pass user‑controlled input.
• Run npm dependency queries in build environments:
• In application source: run npm ls send (or the equivalent Yarn command) to see whether an installed tree contains send and which version.
• For installed production nodes, inspect node_modules or run a package introspection step in the container image.
• Container images and VM images:
• Scan container registries and image repositories (including Microsoft‑published base images you use) with a vulnerability scanner (SCA tools such as Syft, Grype, Trivy, or your enterprise scanners) that can detect Node.js packages and versions in layered images.
• Check image SBOMs if you maintain them; look for “send” entries and the version numbers.
• Platform services:
• If you use managed layers (App Service, Functions, etc.), verify whether those managed runtime images include your app artifacts or dependencies that might contain send; consult platform inventory features or ask your platform provider account team to confirm.

2. Prioritize remediation based on exposure and attack surface​

• High priority:
• Publicly reachable web servers that serve dynamic templates or redirects and that include the vulnerable send package.
• Multi‑tenant services or images used as templates for many deployments.
• Environments where user‑supplied input is passed to redirect or template rendering code paths.
• Medium priority:
• Internal services with limited exposure but that still process untrusted inputs.
• Lower priority:
• Development or sandbox images where the vulnerability does not impact production.

3. Patch / upgrade​

• Upgrade the send package to the patched upstream version (>= 0.19.0) in your application dependency manifests and rebuild images.
• If you rely on a distribution package (for example, a Node.js runtime packaged by your distribution), apply vendor security updates or backports provided by the distro (patch releases often appear as distribution security advisories in the distro’s package management channels).
• Rebuild and redeploy container images after dependency upgrades; ensure your CI/CD pipeline produces fresh artifacts.

4. Apply mitigations when patching is delayed​

• Avoid passing unsanitized user input directly to response.redirect() or the templating paths. Replace redirect calls that include arbitrary user input with allow‑lists or canonicalization logic.
• If immediate code changes are difficult, consider temporary access controls:
• Restrict public access to vulnerable endpoints behind a web application firewall (WAF) or network access control.
• Add monitoring and alerting for suspicious redirect patterns or unusual template rendering actions.
• Use runtime policy enforcement (for example, platform WAF rules, ingress filters in Kubernetes) to block suspicious payloads while you remediate.

5. Verify fixes and confirm remediation​

• After upgrading, re-scan images and artifact registries to confirm no legacy versions remain.
• Perform regression testing, especially around redirects and file streaming behavior, because patched send behavior can subtly change how redirects or range requests behave.
• For Microsoft environments: check that Azure Linux images you use have been updated; when MSRC or your provider publishes VEX/CSAF attestations, ingest them into your vulnerability management platform to automate verification.

---

How to inventory Microsoft artifacts for this issue​

Microsoft’s public attestation for Azure Linux is helpful but limited in scope; you must verify the artifacts you actually run.

• Inventory the Microsoft‑provided artifacts you consume:
• List the Azure Marketplace images, Azure VM SKUs, container base images, and platform runtime images you run or pull from Microsoft or partner registries.
• For each artifact, obtain the SBOM (where available) or scan the artifact content to locate Node.js packages and their versions.
• For WSL2 and developer artifacts:
• If your developer machines use WSL2 images or Microsoft‑published Linux distributions, scan those images locally or rely on package manager metadata to find node‑send.
• For managed services (App Service, Functions, container apps):
• Confirm whether the platform uses customer images (your responsibility) or provider‑managed images (provider responsibility). If provider‑managed, request or consult provider attestation or documentation; if customer images, treat them as any other container and scan them.
• Automate the process:
• Integrate SBOM generation and SCA scanning into CI/CD to catch vulnerable dependencies before deployment.
• Ingest machine‑readable VEX/CSAF attestations (once available) into your vulnerability management tooling so you receive automatic signals about which provider images Microsoft has scanned and confirmed.

---

A critical look at Microsoft’s transparency move — strengths and limitations​

Microsoft’s approach to publishing CSAF/VEX attestations and explicitly naming Azure Linux as a product that contains the implicated component is a net positive for security transparency. The benefits are tangible:

• Machine‑readable attestations enable automated triage and can dramatically shorten the time between disclosure and remediation for confirmed carriers.
• Publicly attesting a specific Microsoft product (Azure Linux) gives customers a clear, actionable remediation target: if you run Azure Linux, take the Microsoft‑published mitigation actions.
• The approach scales: Microsoft can extend attestations to additional product artifacts as inventories are completed.

At the same time, there are important limitations and hazards to understand:

• Attestation scope vs. exhaustiveness: an attestation is a statement about what Microsoft has inspected — not an exhaustive guarantee that no other Microsoft product includes the same upstream component. Treat absence of an attestation as “unknown,” not “safe.”
• Long‑tail risk: supply‑chain components can be repackaged across images, services, and products. A vulnerable upstream component can surface in unexpected places (partner images, cached images in registries, or internal appliance images) and should be hunted for.
• Operational inertia: customers who see a single MSRC attestation may incorrectly assume their entire Microsoft‑delivered estate is safe if not named. That assumption increases risk.

Good security practice is therefore to use the MSRC attestation as a confirmed signal for the attested product, and independently verify other artifacts you rely on rather than assuming non‑mention implies non‑inclusion.

---

Detection and hunting recipes (practical commands and checks)​

Below are hands‑on steps you can adapt to your environment. Replace sample commands with your organization’s automation.

• Node projects (source code repos)
• In each repository: run npm ls send or yarn why send to detect presence and version of the send package.
• Search code for response.redirect( or direct uses of send(req, ...) and treat those files as higher risk for template/redirect follow‑up testing.
• Container images
• Use a scanner like Syft/Grype/Trivy to generate a software bill and vulnerability report for each image: produce SBOMs and search for package:send or node_modules/send.
• Example: run syft <image> -o json and grep the JSON for the package name and version.
• Linux/VM images and distributions
• If you run Azure Linux images, check the distribution package updates from the platform or your image inventory. Apply the distro patches or rebuild custom images with updated npm dependencies.
• Web application tests
• Test any endpoints that use redirects or display templates with user‑supplied input. Look for reflected content that might not be correctly escaped.
• If you have a web application scanner, run focused XSS templates against candidate endpoints.
• Logging and monitoring
• Add alerting for suspicious redirect parameters or for unexpected template content being returned with unescaped user inputs.
• Monitor WAF logs for attempted injection payloads around redirect endpoints.

---

Risk assessment — who should worry most​

• Application owners running public Node.js HTTP servers that serve dynamic templates or accept user input in redirect parameters — high risk.
• Operators using Microsoft‑published images that include web stacks and Node.js artifacts — medium to high risk until image inventories are confirmed and patched.
• Large fleets with many container images or automated pipeline images that reuse base images — higher aggregate risk because a single vulnerable base image can cascade.
• Organizations that rely on manual patching or lack SBOM/CI integration — these groups are more likely to have unpatched images lingering in registries or cached by orchestration platforms.

---

Final analysis and guidance​

CVE‑2024‑43799 was a concrete, fixable template‑injection issue in a commonly used Node.js library. Upgrading to the patched upstream release resolves the vulnerability; distribution security teams and downstream packagers have already produced fixes and advisories. Microsoft’s public statement that Azure Linux includes the open‑source library and is therefore potentially affected is an important, machine‑actionable attestation for Azure Linux customers — but it does not, and should not, be read as an exclusivity claim.
Operationally, treat Microsoft’s attestation as a confirmed signal for the named product and act quickly if you run Azure Linux images. Simultaneously, treat every Microsoft artifact you consume (images, runtime environments, managed platforms) as potentially unverified until you confirm otherwise. The right approach is pragmatic: use automation (SBOMs, image scanning, CI integration) to locate and upgrade any instances of send < 0.19.0, apply short‑term mitigations where patching is delayed, and adopt a repeatable inventory process so that future attestations can be matched against your running artifacts automatically.
Security transparency — attesting that a named product includes a vulnerable component and publishing machine‑readable VEX/CSAF data — is progress. But defenders still must close the loop: inventory, verify, patch, and validate. Follow the detection recipes above, prioritize publicly reachable services that use redirects or templates, and weld MSRC attestations into your existing vulnerability management workflows rather than treating them as the whole answer.

---

Conclusion: Azure Linux is the Microsoft product Microsoft has publicly attested to include the affected open‑source library for CVE‑2024‑43799, and that attestation is a meaningful, actionable signal. It is not, however, a technical guarantee that no other Microsoft product includes the same vulnerable component — operators must independently inventory, scan, and remediate additional Microsoft artifacts (container images, Marketplace images, managed runtime images, and anything else they run). Patch send to the fixed upstream release in any affected application or image, harden redirect handling in application code, and automate future verification by integrating SBOMs and VEX/CSAF ingestion into your vulnerability tooling.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center