Azure Linux Attestation on CVE-2024-35176 REXML: What Microsoft Signals Mean

Microsoft’s public attestation that Azure Linux includes the REXML library is accurate and authoritative for that product, but it is not proof that no other Microsoft product contains the vulnerable open‑source component; absence of attestations is not proof of absence. Treat the Azure Linux VEX/CSAF statement as a confirmed product‑level signal, and treat everything else in your Microsoft estate as unverified until you inspect it or Microsoft publishes an attestation or patch for it.

Background / Overview​

On May 16, 2024 Ruby maintainers disclosed a denial‑of‑service (DoS) vulnerability in the REXML gem (assigned CVE‑2024‑35176). The bug causes REXML’s tree parser to expend excessive CPU (and possibly memory) when parsing specially crafted XML attribute values containing many repeated angle‑bracket characters, allowing an attacker who can submit untrusted XML to induce resource exhaustion. The upstream fix was released in REXML 3.2.7. Multiple vulnerability databases (NVD, vendor advisories and the Ruby project itself) list the flaw and the fixed version. The vulnerability’s practical impact is limited: an application must parse untrusted XML with the vulnerable REXML tree APIs to be exposed. If a Microsoft product bundles or uses the vulnerable REXML version and exposes an XML‑accepting surface, it could be affected.
Microsoft’s Microsoft Security Response Center (MSRC) entry and the company’s VEX/CSAF attestations (published as part of their transparency work beginning in October 2025) explicitly show that Azure Linux is a known affected Microsoft product for certain open‑source components in general. For CVE‑2024‑35176 specifically, Microsoft has publicly attested Azure Linux’s relationship to upstream packages; MSRC also stated that they will update the CVE record (and associated attestations) if additional Microsoft products are confirmed affected. That is an important and deliberate operational stance: Microsoft is publishing product‑scoped attestations rather than trying to enumerate every possible artifact at once.

---

What CVE‑2024‑35176 actually is (technical summary)​

• The vulnerability is in the REXML gem — an XML toolkit for Ruby.
• The problem occurs when the REXML tree parser (for example, code using REXML:ocument.new and the tree API) encounters attribute values that contain a large number of angle‑bracket characters; this causes the parser to consume excessive CPU/time processing a comparatively small input.
• Affected versions: REXML versions before 3.2.7 are identified as vulnerable in the original advisory; upstream advised upgrading to REXML 3.2.7 or later to fix the issue.
• Exploitation requires the ability to supply XML that is parsed by the vulnerable code path — i.e., the application must accept untrusted XML input and use the affected tree parsing APIs.
• CVSS and other scoring: vulnerability databases list this as a medium‑severity DoS (CVSSv3 ≈ 5.3), reflecting that the impact is availability‑only and exploitation complexity is low given the right attack surface.

These technical facts are confirmed by the Ruby project advisory published May 16, 2024 and mirrored in major vulnerability databases and vendor advisories.

---

Is Azure Linux the only Microsoft product that includes REXML?​

Short answer:

• No — Azure Linux is not necessarily the only Microsoft product that could include REXML, but it is the only Microsoft product Microsoft has publicly attested (via VEX/CSAF or product advisories) as including the particular upstream component for which Microsoft has provided an attestation. Microsoft has said it will update CVE records and attestations if additional Microsoft products are found to be affected.

Longer explanation and reasoning:

• Microsoft’s VEX/CSAF attestations are product‑scoped. Where Microsoft has published a “Known Affected / Fixed / Not Affected” attestation for a product, that attestation is authoritative for the listed product artifact.
• Azure Linux (the Microsoft‑maintained Linux distribution supplied for many Azure images and services) has been a focal point for Microsoft’s VEX rollout; MSRC has published machine‑readable attestations and CSAF feeds beginning in October 2025 to improve transparency about which upstream open‑source components are included in their product builds.
• However, Microsoft’s public attestations do not prove the negative for other Microsoft artifacts. Many Microsoft products (or Microsoft‑owned companies’ products) can and do include Ruby runtimes or Ruby‑based services, and REXML is a widely used Ruby library — it appears in many upstream SBOMs and packaged product manifests across the ecosystem.
• Therefore: unless Microsoft has explicitly attested that a product is “Not Affected” or “Known Affected,” you should treat any Microsoft binary, container image, appliance, or cloud image as unverified. The right operational stance is to either rely on Microsoft’s published attestations for the products they have covered, or to run artifact‑level checks (SBOM inspection, package inventory, or binary scanning) for the products you rely on.

In short: Azure Linux = attested. Other Microsoft products = unverified until attested or inspected.

---

Why Microsoft’s attestation model matters (operational detail)​

Microsoft’s product‑scoped attestations are useful but have operational consequences you must understand:

• An attestation speaks only to the specific product artifact Microsoft examined. Different product artifacts (an Azure VM image, an Azure Marketplace image, a customer‑supplied appliance, a GitHub Enterprise Server virtual appliance, a container image) can contain different bundled packages and different library versions.
• Microsoft cannot, practically, attest every package in every product variant at once; they prioritize high‑impact, high‑visibility product families (such as Azure Linux), and add attestations over time.
• Therefore, a statement that “Azure Linux includes component X” is authoritative for Azure Linux, but does not prove that GitHub Enterprise Server, Visual Studio Team Services, Azure DevOps Server appliances, or other Microsoft products do not include component X.
• The correct security posture is to treat Microsoft’s attestations as trusted, but scoped signals, and to perform your own inventory for everything else in your environment.

---

How to determine whether a Microsoft product in your environment is affected​

If you run Microsoft products (or Microsoft‑built images) and want to know if REXML or another vulnerable component is present, follow this prioritized checklist:

• Check vendor attestations and SBOMs
• Look for MSRC/CSAF/VEX attestations for the specific product and build. If Microsoft has published VEX for that product and it lists the component as Not Affected or Fixed, you can rely on that attestation.
• Obtain the product SBOM or vendor manifest
• Many enterprise products publish SBOMs (Software Bill of Materials) or package manifests. If you can obtain the SBOM for the exact product release you run, scan it for rexml / rubygem‑rexml entries.
• Inspect the installed packages on the running artifact
• On Linux appliances or VM images use package management and gem tools:
• rpm‑based: rpm -qa | grep -i rexml (or rpm -ql rubygem-rexml)
• deb‑based: dpkg -l | grep -i rexml
• Ruby gems: gem list --local | grep rexml
• Inspect vendor/bundle or /usr/lib/ruby/gems directories for rexml files and version strings.
• Scan container images and virtual appliance filesystem
• Use SCA (Software Composition Analysis) tools or simple grep/strings to search for rexml version identifiers inside images and appliances.
• Examine application dependency manifests (Gemfile, Gemfile.lock, .gemspec)
• For Ruby‑based apps included in an appliance, check their Gemfile.lock or installed bundle to see if rexml is present and which version.
• If you cannot obtain SBOMs or inspect binaries, ask Microsoft/GitHub for a VEX/CSAF attestation and a fixed‑version statement for the product build you run.

Be explicit in your requests: provide the exact product name and release/build identifier; attestations and SBOMs are artifact‑specific.

---

Practical detection commands and checks (examples)​

Use the following checks as starting points; adapt to your environment:

• On a Linux image or VM:
• rpm systems (RHEL/CentOS/Azure Linux): sudo rpm -qa | grep -i rexml
• dpkg systems (Debian/Ubuntu): dpkg -l | grep -i rexml
• Ruby gems (any system with Ruby installed): gem list --local | grep -i rexml
• Search the filesystem: sudo grep -R "rexml" /usr/lib /usr/local /opt /var/www 2>/dev/null
• For container images:
• docker image save, then inspect layers; or run a short container and run gem list inside it.
• Use SCA tools like Trivy, Grype, or an SBOM scanner to enumerate gems and versions.
• For Windows or appliance images:
• If the product runs a Linux VM internally (for example, many appliances do), mount the filesystem and run the same package/gem checks.
• If you cannot inspect, ask the vendor for the SBOM or a VEX/CSAF attestation.

If you find rexml: confirm the installed version. Anything prior to the fixed release (REXML < 3.2.7 for CVE‑2024‑35176) should be considered vulnerable until patched.

---

Remediation and mitigation guidance​

If you confirm that a Microsoft product (or any product you run) includes a vulnerable REXML version or relies on Ruby runtimes with a vulnerable bundled gem, take the following actions, prioritized by risk and speed:
Immediate mitigations (fast, low‑risk)

• Where possible, block or limit routes that accept untrusted XML input from untrusted networks until the component is patched.
• Apply request size and rate limits on any interface that parses XML to reduce the impact of a DoS attempt.
• Configure process‑level resource limits (cgroups, systemd ResourceControl, ulimit) to constrain CPU or memory consumption of processes that parse XML.
• Use network protections: WAF rules that detect and block suspicious XML payloads can reduce exposure (look for patterns with many angle brackets or abnormal attribute values).

Patch and upgrade (definitive)

• Upgrade REXML to the fixed version: REXML 3.2.7 or later (for CVE‑2024‑35176). Upstream and advisories uniformly recommend upgrading to the fixed gem release.
• If the vendor (Microsoft or third party) supplies a patched appliance, image, or package, apply vendor patches per their instructions. Prefer vendor‑supplied patches for managed/distributed product installations.
• For in‑house Ruby apps: update Gemfile/Gemfile.lock, run bundle update rexml (or equivalent), and redeploy.

Code and configuration mitigations

• If you control the application code, switch from tree‑based parsing (REXML:ocument.new) to streaming/SAX parsing when handling untrusted XML; the stream/SAX APIs are less susceptible to this variant of resource exhaustion.
• Validate and sanitize XML before parsing where practical; reject inputs with suspiciously long attribute values or extreme repetition patterns.
• Consider replacing REXML with an alternative parser that provides safer streaming semantics if your workload requires processing untrusted XML at scale.

Operational follow‑up

• After patching, run SCA scans and dependency checks again to confirm the vulnerable version is no longer present in any deployed artifact.
• Update incident detection rules to look for abnormal CPU spikes in services that parse XML.
• If you run a fleet of VM images or containers, automate SBOM collection and SCA scanning as part of CI/CD, and require a remediation path for upstream vulnerabilities.

---

Special guidance for Azure Linux customers​

• Microsoft has published VEX/CSAF attestations for Azure Linux and is proactively publishing machine‑readable attestations for embedded components in that distribution. If MSRC’s attestations show Azure Linux includes a vulnerable upstream package, Azure Linux customers should treat that as authoritative for that product and follow Microsoft’s recommended remediation timeline.
• For Azure customers running marketplace images or Azure Marketplace appliances: check the specific image variant’s SBOM and the publisher’s VEX/CSAF attestation; the marketplace image may be a third‑party build rather than Azure Linux itself.
• If you use managed Azure services, check service‑specific advisories and service health notifications. Managed services may have their own remediation timelines and mitigations in place, but you should confirm whether those mitigations cover your particular usage scenario.

---

Why you should not rely solely on vendor attestations (risk analysis)​

Microsoft’s public statement that Azure Linux includes the impacted component is important and helpful, but it does not obviate your duty to inventory and verify:

• Vendor attestations are product‑scoped. They do not enumerate all supply‑chain variants of every product you run.
• Microsoft (like other vendors) cannot provide attestations for every third‑party product, container image, or bespoke appliance in customer environments.
• Many Microsoft services and Microsoft‑owned products (for example, GitHub) are large ecosystems with multiple codebases and release tracks; components such as REXML may appear in some places and not others.
• Attackers target the weakest link: even if Azure Linux is patched, other products you run that include vulnerable REXML might provide the exposure attackers need.

Operational recommendation: use vendor attestations as high‑confidence positive/negative signals where present, but maintain artifact‑level verification (SBOM scanning and runtime detection) across your environment.

---

Broader supply‑chain context: REXML and multiple advisories​

• REXML has had multiple related parser‑DoS reports across 2024–2025. This CVE (CVE‑2024‑35176) is one of several REXML advisories that have been issued as community researchers found different pathological inputs and parser behaviors.
• Because REXML is bundled or included in many Ruby runtime installs or applications, the same library version can appear in package repositories, Ruby application vendors, and appliance images. That makes it a classic software composition / SBOM problem.
• Keep in mind that some Linux distributions package their own rubygem‑rexml version; vendor packages may lag upstream gem releases. Always verify the vendor package version (not just the upstream gem version) when assessing exposure.

---

Threat model and realistic risk​

• Exploitation vector: network attacker or local attacker submits crafted XML to an exposed endpoint that uses the vulnerable REXML tree parser.
• Impact: denial of service (resource exhaustion, service unavailability). This is not a remote code execution or data‑exfiltration bug in its common form.
• Attacker prerequisites: ability to send XML to the vulnerable parser; no elevated privileges required beyond access to the input channel.
• Realistic risk depends on:
• Whether the product or application accepts untrusted XML from external or unauthenticated sources.
• Whether the product uses the REXML tree parser API (streaming parsers or SAX are less affected).
• Whether resource limits and mitigations (rate limiting, timeouts) are in place.

For many Microsoft customers, the immediate exposure surface will be small unless they run Ruby‑based services or appliances that accept XML. But do not assume absence of Ruby in your supply chain; it frequently appears indirectly (admin tooling, maintenance scripts, pre‑installed runtime packages, vendor appliances).

---

Concrete prioritized action plan (for security teams)​

• Inventory
• Collect SBOMs for every Microsoft product image and appliance you run, including marketplace images and vendor appliances.
• Run automated SCA scans (Trivy/Grype or vendor SCA) across images and artifacts to identify rubygem‑rexml or bundled rexml versions.
• Triage
• For each occurrence of rexml, record the exact version and the exact artifact (image SHA, product release number).
• Determine whether the application or service parses XML from untrusted sources.
• Immediate mitigations
• Apply network controls (rate limits, WAF) and process resource limits for vulnerable service endpoints.
• Patch
• If the artifact is managed by Microsoft or a vendor: request or apply the vendor patch; if Microsoft has published a VEX/CSAF update that lists the product as fixed, follow the vendor guidance.
• If the artifact is under your control: update the gem or rebuild the artifact with rexml >= 3.2.7 and redeploy.
• Verify
• Re‑scan the artifact to ensure vulnerable versions are gone and confirm via SBOM or bundle manifests.
• Monitor
• Add monitoring and alerting for abnormal CPU/time usage on XML parsing services.
• Subscribe to MSRC and vendor advisories for new attestations or expanded CVE product lists.

---

Final assessment and recommendations​

• Microsoft’s public statements and VEX attestations are a positive step toward transparency. Microsoft has attested Azure Linux’s relationship to upstream components and has committed to updating CVE records if other Microsoft products are impacted.
• That attestation means Azure Linux customers can rely on Microsoft’s signal for Azure Linux, but other Microsoft products and images should not be assumed safe unless either Microsoft has attested them or you have verified them yourself.
• Operationally, treat the Azure Linux attestation as an authoritative fix/signal for Azure Linux only. For any other Microsoft product you run, perform artifact‑level inventory (SBOMs or scanning) and apply the remediation checklist above if you detect rexml instances with vulnerable versions.
• Finally, because REXML is common across the Ruby ecosystem and because multiple parser issues have been found over time, adopt continuous SBOM and SCA scanning for all software artifacts you deploy — vendor attestations are helpful, but they must be complemented by your own verification to maintain an accurate and defensible security posture.

---

Checklist — What to do now (concise)​

• Confirm whether Azure Linux in your environment has been patched per Microsoft’s attestation; if you run Azure Linux images, follow Microsoft’s guidance.
• For each other Microsoft product or image you run: obtain SBOM / ask for a VEX attestation or scan the artifact yourself.
• If you find REXML < 3.2.7: prioritize patching or vendor remediation; if immediate patching is impossible, apply input filtering, rate limiting, and process resource caps.
• Add runtime checks to detect service‑level CPU spikes on XML parsing endpoints and monitor for abnormal XML payload patterns.

Conclusion: Azure Linux’s attestation is authoritative for that product; it is not a blanket statement about other Microsoft products. Defend your environment by combining vendor attestations with artifact‑level inventory and timely patching.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center