CVE-2025-9901: Libsoup SoupCache Fails to Honor Vary Header

A libraries-layer bug in the GNOME HTTP stack has landed in the CVE database and in vendor advisories: CVE-2025-9901 describes a flaw in libsoup’s caching code, SoupCache, where the library can ignore the HTTP Vary header when deciding whether a cached response may be reused. The practical result is straightforward and worrying in the right conditions: cached responses that should differ by request header — for example, Authorization, Cookie, or Accept-Language — can be served to the wrong client, potentially exposing confidential responses in proxy or multi‑user setups. Microsoft’s public advisory specifically calls out the Azure Linux distribution as a product that includes the affected library and is therefore potentially affected; Microsoft also notes that it will expand its attestations if additional products are identified. This feature article explains what CVE‑2025‑9901 means technically and operationally, examines Microsoft’s statement, maps real‑world impact scenarios, and gives prescriptive detection and mitigation steps for admins responsible for Azure Linux, Microsoft artifacts, and heterogeneous fleets.

Background / Overview​

libsoup is a widely used C library that implements an HTTP client and server API commonly employed by GNOME applications, WebKitGTK, and various network-facing services in Linux distributions and container images. There are two active branches in common use today: libsoup-2.4 and libsoup-3. Both branches expose caching primitives (collectively known as SoupCache) that implement HTTP response caching semantics for efficiency and offline behavior.
The Vary header in HTTP is the canonical mechanism for telling caches which request header values must be considered when deciding whether a cached response applies to a later request. For example:

• Vary: Accept-Language — responses may differ by language negotiation.
• Vary: Authorization — responses may differ by authenticated user.

If a cache implementation incorrectly ignores the Vary header, it can serve a response intended for one set of request headers to a different set — producing cache-confidentiality failures (CWE class: use of cache containing sensitive information). In multi-user proxies, reverse proxies in shared environments, or servers that inadvertently persist cache objects between sessions, the consequences can be data leakage.
CVE‑2025‑9901 captures this precise problem: SoupCache fails to evaluate the Vary header when validating cached responses, which can cause cached content to be incorrectly reused across requests.

---

The vulnerability, in plain technical terms​

What goes wrong inside SoupCache​

libsoup’s caching mechanism maintains cached response objects associated with specific request keys. A correct cache key calculation includes request attributes indicated by Vary. When Vary is present, caches must incorporate the values of the listed request headers into the cache lookup key.
In the reported flaw:

• SoupCache compares cached entries to incoming requests but does not check the Vary header in the stored response.
• As a result, the cache lookup can ignore differences between request headers that were supposed to distinguish responses.
• The outcome is a false positive cache hit: a client receives a cached response that didn’t correspond to their header set.

This bug is not a classic memory‑corruption exploit; it is a logic error that creates confidentiality exposure under specific deployment topologies.

Attack surface and preconditions​

Exploitation requires a chain of conditions that are not always present on desktops:

• An application or intermediary that uses libsoup caching (SoupCache) to store responses.
• The server supplying the response sets a Vary header indicating per‑header difference (e.g., Authorization, Cookie).
• Multiple clients with different header values share the same cache instance (typical in proxy servers, shared service processes, or multi‑user container/images).
• Absent appropriate isolation, one client’s sensitive response can be served to another client.

Because desktop single‑user workflows often keep caches per user session and not shared across identities, many consumer scenarios see limited practical risk. The highest exposure is in shared caches: corporate proxies, web gateways, multi‑tenant services, or container hosts running multi‑user services that reuse a common libsoup process.

---

Vendor responses and status — what Microsoft said, and what that means​

Microsoft’s advisory explicitly states that Azure Linux (Microsoft’s maintained Linux distribution for Azure images) includes the implicated open-source library and is therefore potentially affected by CVE‑2025‑9901. The advisory further notes Microsoft’s transparency initiative — the company began publishing machine‑readable CSAF/VEX attestations in October 2025 — and that the CVE entry will be updated if Microsoft identifies impact to additional products.
What to read from that statement:

• Confirmed attestation for Azure Linux: Microsoft has completed an inventory check for Azure Linux artifacts and found libsoup in those images, so Azure Linux is a confirmed product-level hit for the vulnerable component.
• Not an explicit denial for other Microsoft products: The advisory’s wording is product-scoped. Microsoft is saying Azure Linux is confirmed; it is not promising that no other Microsoft product could contain the same library. Absence of mention for a product is absence of attestation, not evidence of absence.
• CSAF/VEX adoption: Microsoft’s rollout of VEX/CSAF means this and future CVE notices will increasingly include machine‑readable, product‑scoped attestations such as Known Affected, Under Investigation, Not Affected, or Fixed. This is intended to reduce ambiguity for downstream consumers.

This approach is operationally useful — it gives Azure Linux operators definitive, automated signals — but it requires other customers to perform independent checks for Microsoft artifacts they run (for example, Marketplace images, AKS node images, WSL kernels, or vendor-supplied appliances).

---

Cross‑vendor confirmation and severity assessment​

Multiple distribution security trackers and vulnerability databases report the same root cause and description: libsoup’s SoupCache ignores the HTTP Vary header, enabling cross-request reuse of cached content that should have been isolated by Vary. Several mainstream Linux distribution advisories and vulnerability trackers have already flagged packages as vulnerable or are tracking fixes; severity scores reported in public advisories vary, with many vendors classifying the issue as Medium or Low-to-Medium depending on their threat model.
Key operational facts verified across multiple sources:

• The bug is a caching logic vulnerability, not a memory‑safety corruption.
• Exploitation is remotely feasible only when a vulnerable libsoup instance performs shared caching across different request contexts.
• Distribution maintainers are tracking the issue actively; some distros have assigned the issue low-to-medium priority and are coordinating fixes into upcoming package updates or backports.

Note: the exact set of affected package versions and the timeline for fixes vary by distribution. Some vendors have already published patches or scheduled backports; others have marked the issue as pending upstream fixes. Administrators must consult the vendor advisory for the distribution they run to determine the precise fix version.

---

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

Short answer: Microsoft has publicly attested that Azure Linux includes the library and is therefore potentially affected, and it will update its VEX/CSAF attestations if additional Microsoft products are discovered to include the same component. That product-level attestation is authoritative for the named artifact but does not categorically exclude other Microsoft artifacts from shipping the same open‑source code.
How this plays out in practice:

• Microsoft publishes VEX/CSAF attestations on a phased, product-by-product basis. The Azure Linux inventory was one of the early targets of this program.
• Other Microsoft artifacts that may ship Linux userspace or packaged images — such as Azure Marketplace images, AKS node images, curated VM images, or WSL distributions provided by third parties — are separate artifacts that require their own inventory checks.
• A Microsoft binary that embeds or packages a Linux distribution may either include or exclude libsoup depending on the image build configuration and the packages installed. Therefore, each artifact must be verified separately.

Operational recommendation: treat Microsoft’s advisory as an authoritative confirmation that Azure Linux is in scope, and treat other Microsoft-supplied artifacts as unverified until Microsoft issues explicit attestations for them or you confirm via your own artifact inspection.

---

Practical impact scenarios — where the risk is highest​

• Shared reverse proxies or caching proxies built with libsoup or libsoup-based software in a multi‑tenant environment: High risk for confidential responses being leaked between tenants.
• Multi‑user desktop services where one system process services multiple user sessions and caches responses globally: Moderate risk.
• Single-user desktops or isolated containers with per‑container per‑user caches: Low risk in default configurations.
• Embedded appliances or vendor images that reuse a libsoup daemon for multiple clients: Elevated risk if Vary-sensitive responses are cached.

In short, the risk is contextual. The vulnerability’s practical severity is determined not by a simple CVSS number alone but by deployment patterns: shared caching + Vary usage + lack of per-client isolation = meaningful exposure.

---

Detection: how to check your systems and images​

Start with inventory: find instances of libsoup in your images, hosts, containers, and VMs.
Common commands administrators can use:

• Debian/Ubuntu (APT):
  1. dpkg -l | grep libsoup
  2. apt-cache policy libsoup libsoup3
• RHEL/CentOS/Fedora (RPM):
  1. rpm -qa | grep libsoup
  2. dnf list installed *libsoup*
• Alpine:
  1. apk info | grep libsoup
• Containers (examples):
  1. docker run --rm imagename dpkg -l | grep libsoup
  2. docker run --rm imagename rpm -qa | grep libsoup
  3. skopeo inspect docker://imagename (to pull metadata)
  4. For many images, spawn a shell: docker run --rm -it imagename sh -c 'apk info | grep libsoup || dpkg -l | grep libsoup || rpm -qa | grep libsoup'
• Image scanning:
  1. Use your software composition analysis (SCA) or vulnerability scanner to search the SBOM for libsoup, libsoup2.4, or libsoup3 identifiers.
  2. Search your fleet’s package-management inventory for libsoup across all nodes.

If you find libsoup present, record the package version string and correlate it with the vendor advisory for your distribution. Vendor advisories provide the mapping from package versions to fixed releases (or indicate that fixes are pending).

---

Mitigation and temporary workarounds​

While waiting for vendor updates, you can reduce exposure with several mitigation steps:

• Apply distro vendor patches as soon as the vendors release them for your distribution and image combination. This is the single best step.
• If you operate a multi‑tenant proxy built on libsoup or an application that uses libsoup server-side:
  • Avoid caching responses that include sensitive headers until a patch is deployed.
  • Configure caches to honor the Vary header explicitly if the application or proxy provides configuration for cache-keying options.
  • Disable shared, global caching in processes that serve multiple identities.
  • Enforce per-tenant isolation: separate caches per authenticated user or session.
• For reverse proxies or CDN-like instances:
  • Strip the Vary header only when you intentionally control cache behavior — this is normally NOT recommended; instead, ensure caches evaluate Vary.
  • Apply fine-grained cache-control headers (Cache-Control: private/no-store) for sensitive endpoints.
• Short-term defensive measures:
  • Rotate tokens or session cookies for services that may have been indirectly impacted and where you suspect cached leakage.
  • Restrict untrusted clients from reaching services that may inadvertently cache authenticated responses.
  • Add logging to cache-hit/miss logic so you can detect suspicious cache reuse patterns and follow up with forensic inspection.

---

Specific recommendations for Azure Linux operators and Microsoft artifact owners​

1. Treat Microsoft’s Azure Linux VEX attestation as the authoritative starting point for any Azure Linux images you operate; prioritize patching those images.
2. For other Microsoft-supplied images (Marketplace, AKS base nodes, curated VMs), do not assume they are free of the library — perform the package inventory described above or request VEX/CSAF attestations for those artifacts.
3. Subscribe to vendor advisories (distribution security trackers) and Microsoft’s msrc guidance channel to be notified when fixes or VEX updates are published.
4. Add automated scans in CI/CD pipelines that build VM images, marketplace artifacts, or container images. Fail builds or gate deploys when a vulnerable package is present.
5. For WSL users: WSL distributions are effectively upstream-supplied Linux distributions running under Windows. If you install a third‑party distro (Ubuntu, Debian) within WSL, the distro maintainers supply libsoup packages and fixes; apply distro updates inside the WSL instance or update the distro image in-place.

---

How to prioritize remediation across a mixed estate​

• Priority 1: Public-facing shared proxies, multi‑tenant gateways, and services that run a single process serving multiple identities using libsoup caching.
• Priority 2: Internal shared services and middleware that may be reused across users (for example, a caching layer used by multiple microservices).
• Priority 3: Single-user desktop setups and single-tenant containers — lower practical risk but still update when vendor patches are available.
• Priority 4: Control-plane images, build hosts, and non‑network facing systems — patch according to normal cadence.

The triage should reflect the deployment’s threat model: higher tenancy and public exposure increases the urgency.

---

Operational checklist (step‑by‑step)​

1. Inventory: scan all images, VMs, and containers for libsoup presence using package and image scanning tools.
2. Identify: record package names and version strings for every found libsoup instance.
3. Correlate: check your distro vendor advisory to determine whether the installed package version is listed as vulnerable or fixed.
4. Patch: schedule updates for vulnerable images and hosts. For managed Azure Linux customers, apply vendor-provided patches or image updates as Microsoft publishes them.
5. Mitigate: where patching is delayed or impractical, implement cache isolation and configuration mitigations described earlier.
6. Monitor: add cache logging and post‑deployment verification that caches are not serving mismatched content across identities.
7. Document: update your SBOM and inventory records, and maintain the CSAF/VEX attestations where available.

---

Detection and forensic indicators​

• Unusual cache-hit attribution: logs showing cache hits for endpoints whose responses include differing Authorization or Cookie values.
• Cache key mismatches: when cache keys don’t incorporate Vary header values, investigate the cache implementation.
• Unexpected response content in multi-user contexts: alert on anomalies where user A receives content clearly belonging to user B.
• SCA results showing libsoup package versions flagged by vendor advisories.

If any of the above are observed, expedite forensic snapshotting of cache state and the affected process to preserve evidence and support vendor coordination.

---

Final analysis: strengths of vendor handling and residual risk​

• Strengths:
  • The vulnerability is a logic bug rather than a memory safety exploit, which simplifies mitigation paths (cache configuration and isolation can reduce exposure).
  • Multiple distributers and vendor trackers have already cataloged the issue and are coordinating patches.
  • Microsoft’s public CSAF/VEX rollout gives Azure Linux customers a transparent, machine‑readable attestation to automate remediation decisions for that product.
• Residual risks and caveats:
  • Microsoft’s attestation for Azure Linux is product‑scoped and does not guarantee all Microsoft artifacts are clean; absence of mention for a product is not the same as a “not affected” attestation.
  • Patch availability varies across ecosystems and images. Some distributions may schedule backports; others may await an upstream patch.
  • Detection of real-world exploitation is difficult: cache confidentiality leaks can be subtle and may be masked as legitimate behavior unless cache logs or anomaly detection are in place.

Where vendor transparency is measurable (CSAF/VEX), the operator’s burden shifts from guessing whether a product contains the component to acting quickly once an attestation or patch is published. The recommended posture is proactive inventory, automated scanning, and immediate patching for high‑exposure services.

---

Closing advice for administrators and security teams​

• For Azure Linux customers: treat Microsoft’s attestation as an immediate call to action. Prioritize patching and image updates for Azure Linux images in your environment.
• For operators of other Microsoft-supplied artifacts: do not assume immunity. Run the package inventory steps now, and request VEX/CSAF attestations from Microsoft for products you rely on if they have not already been issued.
• Add detection rules to your SIEM to look for caches serving responses across differing Authorization/Cookie headers and enable cache‑level logging.
• Integrate SBOM/SCA checks into CI/CD so new images are rejected if they include a vulnerable libsoup package.
• Keep an eye on vendor advisories from your distribution provider and on the upstream libsoup project for the formal fix and version numbers; schedule rapid rollouts after validation.

This is a reminder that supply‑chain hygiene — automated inventories, machine‑readable attestations, and continuous image scanning — is no longer optional. CVE‑2025‑9901 is a manageable, contextual issue, but one that emphasizes the need for precise, artifact‑level visibility in modern, mixed‑platform fleets.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center