CVE-2024-28110 CloudEvents Go SDK Leaks Tokens via Default HTTP Client

The CloudEvents Go SDK vulnerability tracked as CVE-2024-28110 exposes a subtle but serious supply-chain risk: prior to version v2.15.2, using cloudevents.WithRoundTripper to construct a client with an authenticated http.RoundTripper causes the SDK to inadvertently modify http.DefaultClient, which in turn can send Authorization tokens to arbitrary endpoints. This bug has been patched upstream, Microsoft’s advisory language identifies Azure Linux as a product that includes the implicated open-source component, and Microsoft has said it will update its attestation if other products are later found to ship the library.

Background / Overview​

CloudEvents is an open specification and set of SDKs used to represent and transport event data between producers and consumers. The Go implementation—github.com/cloudevents/sdk-go/v2—is widely used in cloud-native services, event routers, and microservice code that emits or receives CloudEvents. The vulnerability in question is not a crypto bug or memory-safety flaw; it is a logic/regression issue in how the HTTP transport is wired when code calls cloudevents.WithRoundTripper with an already-authenticated transport.
In short technical terms: when the SDK is handed an authenticated RoundTripper (for example one returned by an OAuth2 or ID token client), a code path in the CloudEvents HTTP protocol adapter ends up assigning that transport to http.DefaultClient.Transport. Because http.DefaultClient is a global, shared client, any subsequent uses of the default client elsewhere in the same program will inherit the authenticated transport and will therefore send Authorization headers to endpoints that were never intended to receive them. That cross-cutting side effect is the root cause of the credential leak. The upstream project fixed the behavior in the 2.15.2 release.

What the vendor (Microsoft) has said​

Microsoft’s security update guide contains a short, consistent FAQ phrase that has appeared in multiple product entries: essentially, “Azure Linux includes this open‑source library and is therefore potentially affected.” That wording is an explicit product-level attestation: Microsoft has inspected the Azure Linux product artifacts, found the upstream component, and placed Azure Linux in the set of Microsoft products the company has confirmed to carry the vulnerable code (or its patched/unpatched descendants). Microsoft also states that it began publishing CSAF/VEX machine-readable attestation data in October 2025 and that it will update the CVE entry if impact to additional Microsoft products is identified. This is Microsoft’s public posture: Azure Linux — yes; other Microsoft products — only if and when Microsoft’s inventory discovers them.
That formulation is accurate as a statement of Microsoft’s inventory today, but it’s also important to understand exactly what that sentence means (and what it does not mean): it does not mathematicalr Microsoft product contains the same open-source library or binary; it only confirms the company has verified that particular product. Several community analyses and forum explainers have emphasized this distinction: an MSRC product attestation is authoritative for the product named, but absence of attestation is not proof of absence elsewhere in Microsoft’s software portfolio.

---

Technical deep dive: why this bug matters​

How global clients become a failure mode​

The Go standard library exposes http.DefaultClient as a convenient, global *http.Client that many libraries and applications use implicitly. Mutating global state is inexpensive and convenient, but when a shared global acquires credentials it becomes a stepping-stone for credential leakage. In this case, an authenticated RoundTripper was assigned to a global location that other, unrelated code paths used without expectation of carrying authentication. The consequence: Authorization tokens intended for a specific API are sent to endpoints such as:

• health-check endpoints,
• third-party services reachable from the host,
• attacker-controlled endpoints triggered by an application.

Because Authorization headers typically carry bearer tokens with access scopes, the confidentiality impact of this mistake is high. Multiple independent vulnerability trackers classify the issue as a high-severity credential exposure and assign it a CVSS v3.1 base score of 7.5.

Example scenario (attack surface)​

• A service builds an authenticated HTTP transport to call an internal metadata or identity endpoint and passes that transport into cloudevents.WithRoundTripper to produce a CloudEvents client.
• The CloudEvents adapter assigns the authenticated transport into http.DefaultClient.Transport.
• Elsewhere in the same binary, a library or helper uses http.Get("[url]https://unrelated.example/[/url]")[/url] or otherwise uses the default client; the default client now attaches an Authorization header.
• If unrelated.example is attacker-controlled, the attacker receives tokens and can attempt token replay or token-exchange attacks against the identity provider or cloud APIs.

This chain makes the vulnerability easy to trigger in practice because the precondition—using an authenticated transport with WithRoundTripper—is a common integration pattern for cloud-native services.

---

Who is affected: packages, binaries, and Microsoft products​

At the open-source and application level​

• Any application that imports github.com/cloudevents/sdk-go/v2 and uses WithRoundTripper while depending on a version earlier than v2.15.2 is directly at risk.
• Containers and images that stage this library without upgrading inherit the risk.
• Static binaries produced by building Go programs that vendor or depend on the vulnerable module will carry the behavior into runtime, even if the binary is later executed on another host or OS.

Upstream tooling, OSV, and NVD entries all point to the same affected range (versions before 2.15.2). These independent trackers and the upstream GitHub advisory provide the definitive technical mapping for vulnerable versions.

At the vendor (Microsoft) level — what Microsoft has attested​

Microsoft’s public guidance for the CVE states that Azure Linux contains the implicated open-source component and is therefore potentially affected. That is the authoritative product-level declaration Microsoft has published for the library at the time of the advisory; Microsoft also promises to update the CVE/page if other products ship the library. In plain operational terms, Microsoft checked its Azure Linux artifacts and found the component; that product is in-scope.
However, critical nuance is required: product attestati to exhaustive absence of the component elsewhere inside Microsoft. Other Microsoft artifacts—container base images, agents, SDKs, cloud-native components, or even other distributions maintained by Microsoft—could in principle include the same vulnerable library or a binary built with a vulnerable toolchain. Microsoft’s attestation is an inventory answer for Azure Linux, not a universal safety certificate across the entire Microsoft portfolio. Community analyses and multiple vendor advisories reiterate that Azure Linux is currently the product Microsoft has publicly attested; absence of attestations for other SKUs is not technical proof that they are unaffected.

---

Verification: cross-referencing the public evidence​

To avoid relying on a single source, defenders should cross-check at least two independent references:

• The National Vulnerability Database (NVD) entry for CVE-2024-28110 documents the issue and points to the upstream advisory; it summarizes the impact and affected range.
• The CloudEvents project published a GitHub security advisory and a patch commit that resolves the defect; the advisory and commit message explain the code path change in the HTTP protocol adapter and identify version v2.15.2 as the patched release. The Go vulnerability trackers and package vulnerability databases (OSV / vuln.go.dev) mirror that mapping.
• Security vendors and vulnerability databases (Snyk, Tenable, OSS Index) independently recorded the flaw, severity, and recommended fix (upgrade to v2.15.2 or later). These third-party write-ups help validate the technical details and provide additional context for exploitability and remediation urgency.

Where specific claims (for example, “Azure Linux includes this open-source library”) come from Microsoft’s own update guide, the best practice is to treat Microsoft’s statement as the authoritative inventory for the named product and to monitor MSRC/CSAF/VEX feeds for updates if Microsoft expands its attested product list.

---

Practical remediation and detection guidance​

If you are responsible for applications, images, or a Microsoft-hosted environment, treat this as an actionable supply-chain triage exercise.

• Inventory and identify:
• Generate an SBOM for your services and containers. Look for github.com/cloudevents/sdk-go/v2 in module lists or vendor directories.
• Search built binaries for evidence of the SDK (e.g., strings and symbol patterns), and scan dependency manifests (go.mod, go.sum, vendor folders). This helps find indirect or transitive uses in large codebases.
• Update and rebuild:
• If your app imports sdk-go and your dependency resolution pulls a version before v2.15.2, upgrade to at least v2.15.2 and rebuild. Releasing a patched binary eliminates the vulnerable code path.
• Rebuild container images after updating dependencies and redeploy. Do not rely on image layering to automatically pick up the fixed module.
• Runtime mitigations (short-term):
• Avoid passing authenticated transports into helper APIs that may mutate global state; prefer constructing dedicated, non-global http.Client instances with specific transports.
• Audit code to ensure that libraries and helper functions do not depend on http.DefaultClient for operations that should be unauthenticated.
• Detect abuse:
• Monitor outgoing requests from hosts and containers for unexpected Authorization headers to non-whitelisted endpoints.
• Implement egress filtering where possible to reduce the blast radius of accidental credential leakage (block egress to untrusted networks, restrict outbound connectivity for service accounts).
• For Microsoft customers using Azure Linux:
• Follow Microsoft’s remediation guidance for Azure Linux images as published in the MSRC update guide and VEX/CSAF artifacts. Where Microsoft provides patched images or package updates, apply them via your standard image/update pipeline. Microsoft’s attestation names Azure Linux as the product it has validated; if you run Azure Linux images, prioritize those updates.
• For organizations with large estates:
• Use automated dependency scanners, SBOM ingestion, and continuous build policies to catch vulnerable module versions in CI pipelines before deployment.
• For third-party or vendor-provided binaries where source-level updates are not possible, require vendors to attest to patched builds or provide patched artifacts.

These steps align with the upstream fix and the general mitigation guidance provided by vulnerability trackers and security vendors.oft’s “Azure Linux includes this library” wording matters — and where it falls short
Microsoft’s phrasing provides a practical signal: it tells Azure Linux customers they must be aware and take action. Publishing CSAF/VEX metadata (the machine-readable vulnerability-exposure statements) increases transparency and helps enterprises automate triage and remediation. Microsoft’s commitment to update the CVE if additional products are impacted is also important; it acknowledges the reality that large vendors maintain many artifacts and that discovery is an ongoing process.
But that wording also creates two common misunderstandings among defenders:

• Misinterpretation 1 — “Only Azure Linux is affected.” That reading is too literal. Microsoft has only publicly attested Azure Linux so far; this does not guarantee that other Microsoft products cannot include the vulnerable library. Other artifacts could ship the same library or a binary compiled with a vulnerable toolchain, especially in large ecosystems where Go binaries are embedded in containers, agents, or SDKs. Multiple community explainers emphasize this nuance and recommend organizations perform their own inventories.
• Misinterpretation 2 — “No action needed until Microsoft updates the CVE.” Waiting passively for vendor attestations increases operational risk. Organizations should treat vendor attestations as helpful signals but not as a substitute for internal discovery and mitigation. If you run any software that imports the CloudEvents Go SDK directly or indirectly, you should verify the version and apply the upstream fix where required.

---

Risk assessment and likely exploitation scenarios​

Credential leaks are attractive in the wild because bearer tokens can be reused or exchanged. The effortless nature of the exploit condition—passing an authenticated transport into an API that mutates global state—means that many real-world programs could inadvertently enable the leak without a developer’s awareness.

• Likelihood: Moderate. The precondition is common in cloud-native code, and the behavior happens at runtime without obvious crashes or logs, so it can go unnoticed.
• Impact: High for affected tokens. If sensitive tokens leak to an attacker-controlled endpoint, they may be used to access cloud resources or impersonate services.
• Detectability: Medium to low without explicit telemetry. Because the bug is behavioral (incorrect transport assignment), it does not leave an obvious signature unless teams are actively monitoring outbound Authorization headers or auditing their HTTP client usage.

Independent vulnerability databases assigned the issue a high severity and a CVSS v3.1 base score of 7.5, reflecting the relatively low complexity and the elevated confidentiality impact. That assessment aligns with the technical characterization and the remediation steps required.

---

Recommendations for Microsoft, maintainers, and ecosystem stakeholders​

• For Microsoft:
• Continue to expand product-level inventory and VEX/CSAF attestations beyond Azure Linux where feasible. Publicly mapping artifacts to known open-source components reduces customer uncertainty and speeds remediation. Microsoft has committed to do this, and ongoing expansion of VEX coverage will materially help enterprise defenders.
• For the CloudEvents project and Go maintainers:
• Favor API designs that avoid mutating global clients. Document the ownership semantics of transports and clients clearly in release notes and security advisories.
• Encourage downstream projects to prefer explicitly passed, non-global clients for authenticated calls.
• For operators and defenders:
• Treat vendor attestations as an authoritative sourcmed, but maintain your own SBOM-driven inventory and runtime egress controls.
• Incorporate automated checks for known vulnerable module versions in CI and build-time SBOM checks.

---

Final takeaway​

CVE-2024-28110 is a practical example of how innocuous-seeming code—assigning a transport to a client—can become a supply-chain and runtime-security hazard when global state is involved. The fix exists upstream in sdk-go v2.15.2; operators must upgrade, rebuild, or apply mitigations to eliminate the credential-leak risk in their environments. Microsoft’s public statement that Azure Linux includes the implicated library is an authoritative attestation for that product and a useful signal for customers; however, the attestation is product-scoped and should not be read as an exclusive assurance that no other Microsoft artifact could contain the vulnerable code. Defenders should therefore perform their own inventories, prioritize upgrades where the SDK is present, and monitor MSRC’s VEX/CSAF updates for any expansion of Microsoft’s product-level attestations.

---

Conclusion: Azure Linux is the Microsoft product Microsoft has publicly attested to include the vulnerable CloudEvents Go SDK for CVE-2024-28110; that attestation is accurate and actionable for Azure Linux customers, but it does not, by itself, prove other Microsoft products are free of the same library—organizations should therefore inventory, patch, and monitor their environments accordingly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center