What component is actually vulnerable?

The Azure azure-uamqp-c library, a general-purpose C implementation of AMQP 1.0. The use-after-free is in open_get_offered_capabilities and triggers when a memory allocation fails during connection communication. It is most commonly pulled in transitively by the Azure IoT device SDK for C.

● Critical · CVSS 9.8

How to Fix CVE-2024-25110: azure-uamqp-c Use-After-Free RCE

Q: Is CVE-2024-25110 actively exploited?

No. CVE-2024-25110 is not on the CISA Known Exploited Vulnerabilities catalog and CISA's SSVC assessment records Exploitation as none, meaning no in-the-wild exploitation has been confirmed. No public exploit or Metasploit module is linked in the advisory. Because the flaw is unauthenticated, network-reachable and CVSS 9.8, patch it on a critical schedule anyway.

Q: What is the CVSS severity of CVE-2024-25110?

Critical, CVSS 3.1 base score 9.8 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. It is remotely exploitable with no privileges or user interaction and full confidentiality, integrity and availability impact.

⚡ At a glance

Severity	CVSS 3.1 base 9.8, Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Actively exploited?	No (CISA SSVC Exploitation: none, not on KEV)
Affected	Azure azure-uamqp-c before the 2024-01-01 build
Fixed in	azure-uamqp-c submodule updated to commit `30865c9c`
Type (CWE)	CWE-94: Improper Control of Generation of Code, via a use-after-free that reaches RCE

Exploitation status

There is no CISA KEV entry for CVE-2024-25110 at present, so active in-the-wild exploitation has not been officially confirmed for this CVE. Do not wait for a KEV entry to act, since the catalog commonly lags real attacks, so patch on the usual severity-based schedule.

Public exploit availability: the primary references list no public exploit or Metasploit module as of writing. Private or unpublished exploit code may still exist, so do not downgrade the risk on that basis alone.

Authoritative references:

https://github.com/Azure/azure-uamqp-c/security/advisories/GHSA-c646-4whf-r67v

CVE-2024-25110 is a critical, unauthenticated remote code execution flaw in azure-uamqp-c, the Azure team's general-purpose C library implementing the AMQP 1.0 messaging protocol. The GitHub Security Advisory titles it the "Azure IoT Platform Device SDK Remote Code Execution Vulnerability," which tells you where it usually lands in practice: azure-uamqp-c is rarely installed on its own. It is pulled in as a git submodule by the Azure IoT C device SDK and by other native AMQP clients, so most teams who are exposed do not even have "azure-uamqp-c" on their dependency list by name. The fix is a one-commit submodule bump, and there is no clean release version to chase, so this page focuses on identifying the embedded copy and updating it correctly.

What is the vulnerability in CVE-2024-25110?

The root cause is a use-after-free. During a call to open_get_offered_capabilities, a memory allocation can fail. When it does, the code paths in the AMQP open performative handling leave a freed pointer reachable, and that freed memory can later be referenced again. If a peer on the other end of the connection drives this during normal connection communication, the dangling pointer can be steered into remote code execution on the host running the vulnerable client.

CISA's vulnrichment classifies the weakness as CWE-94: Improper Control of Generation of Code ("Code Injection"). That is the outcome classification: a memory-corruption primitive (the use-after-free) that an attacker turns into attacker-controlled execution. The two are not in conflict. The use-after-free is the mechanism, and code execution is the impact CWE the assigner chose to record.

The CVSS 3.1 vector tells the whole exposure story in one line: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base score 9.8 Critical. Network attack vector, low complexity, no privileges required, and no user interaction. In plain terms, anything that can speak AMQP to a vulnerable client during connection setup can attempt this without authenticating first, and a win gives full confidentiality, integrity and availability loss. For an IoT fleet where devices dial out to a broker, the practical worry is a malicious or compromised broker (or a machine-in-the-middle on the AMQP path) reaching back into the device.

Am I affected?

You are affected if you ship or run a native build of azure-uamqp-c from before the 2024-01-01 build, i.e. any copy that does not include commit 30865c9c. Because the library is almost always vendored as a submodule, the version you care about is the commit your build actually compiled, not anything in a package manager database.

Concretely, check these places:

Azure IoT device SDK for C. The azure-iot-sdk-c tree carries azure-uamqp-c under its dependency submodules. If your firmware or gateway links the C SDK for AMQP transport, you almost certainly have it.
Any direct submodule. Run git submodule status in your project and look for an azure-uamqp-c entry; the 40-character hash next to it is the exact build you shipped.
Statically linked native services. Server-side AMQP 1.0 clients written in C/C++ that embedded uamqp before 2024 are equally in scope, not just constrained IoT devices.

If you only consume AMQP through a managed SDK in another language (the .NET, Java, Python or JavaScript IoT SDKs), this specific C-library CVE does not apply to that code path. Confirm what your firmware image actually links rather than assuming.

How to fix CVE-2024-25110

The advisory's instruction is exact: update the submodule to commit 30865c9c (full SHA 30865c9ccedaa32ddb036e87a8ebb52c3f18f695). There is no apt, dnf, winget or npm package to upgrade here, and there is no published semantic version that maps cleanly to the fix, so do not look for one. The remediation is a source-level submodule bump followed by a rebuild and redeploy.

If you vendor azure-uamqp-c directly as a submodule:

cd path/to/your/project/deps/azure-uamqp-c
git fetch origin
git checkout 30865c9ccedaa32ddb036e87a8ebb52c3f18f695
cd -
git add deps/azure-uamqp-c
git commit -m "Bump azure-uamqp-c to 30865c9c (fixes CVE-2024-25110)"

Then rebuild from a clean tree so no stale object files linger, and reflash or redeploy the resulting binary:

git submodule update --init --recursive
# clean build so the old library object is not reused
rm -rf cmake/ build/
cmake -Bbuild -S. && cmake --build build

If azure-uamqp-c reaches you through the Azure IoT device SDK for C, update azure-iot-sdk-c to a release whose pinned uamqp submodule already includes 30865c9c, then recurse submodules and rebuild your firmware image the same way. After that, push the new image through your normal device-update channel (IoT Hub device update, your OTA pipeline, or a manual reflash for a small fleet).

There are no workarounds. The advisory explicitly states there are no known workarounds, so do not rely on network ACLs or broker allow-lists as a substitute for the code fix. Restricting which brokers a device will connect to and enforcing TLS with server-certificate validation reduces who can reach the vulnerable path, but it does not remove the bug. Treat those controls as defence in depth while you ship the patched build.

Verify the fix landed

Because the fix is a commit, your verification is also commit-based, not a CVE scanner string match. Confirm three things on a representative built artifact:

The submodule pointer. git submodule status should show 30865c9ccedaa32ddb036e87a8ebb52c3f18f695 (or a later commit that descends from it) for azure-uamqp-c.
The built binary is the new one. Rebuild from clean and confirm your deploy artifact's timestamp and hash changed, so you are not shipping a cached pre-patch object file. Half-patched fleets where the submodule was bumped but the image was never re-linked are the most common failure here.
Every device updated. For a fleet, query your device-update service for firmware version compliance and chase the stragglers. One unpatched gateway on the old build keeps the exposure open.

Frequently asked questions

Is CVE-2024-25110 actively exploited?

No. It is not on the CISA Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment records Exploitation as none, meaning no confirmed in-the-wild use. No public exploit or Metasploit module is referenced in the advisory. That said, KEV listings lag real exploitation and this is an unauthenticated network-reachable 9.8, so patch on a critical timeline regardless.

Which version fixes it?

There is no clean release version in the advisory. The fix is the azure-uamqp-c submodule updated to commit 30865c9c (any build dated 2024-01-01 or later). Pin to the commit, not a version number.

Is azure-uamqp-c the same thing as the Azure IoT SDK?

No, but they travel together. azure-uamqp-c is a standalone C library for AMQP 1.0 that the Azure IoT device SDK for C carries as a submodule. That is why the advisory is titled around the IoT Platform Device SDK even though the bug lives in the uamqp library.

Can I mitigate without rebuilding firmware?

Not fully. The advisory lists no workarounds. Enforcing TLS with certificate validation and restricting which AMQP endpoints a device trusts narrows who can reach open_get_offered_capabilities, but only the patched build removes the use-after-free.

What exactly triggers the bug?

A failed memory allocation inside open_get_offered_capabilities during AMQP connection communication leaves a freed pointer reachable. A peer that drives that path can turn the dangling reference into remote code execution on the client host.

References

Official vendor advisory: https://github.com/Azure/azure-uamqp-c/security/advisories/GHSA-c646-4whf-r67v
NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-25110
Fixing commit (30865c9c): https://github.com/Azure/azure-uamqp-c/commit/30865c9ccedaa32ddb036e87a8ebb52c3f18f695
CISA KEV catalog (confirm CVE-2024-25110 is not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Written by Sai Kiran Pandrala on 2026-05-25. Grounded in GitHub Security Advisory GHSA-c646-4whf-r67v and the CISA vulnrichment record for CVE-2024-25110.

Operational guidance for IoT fleets

The hard part of CVE-2024-25110 is rarely the one-line submodule bump. It is inventory and reach. azure-uamqp-c hides inside firmware images, so the first job is finding every build that links it. Walk your firmware build pipelines and grep the manifests for an azure-uamqp-c or azure-iot-sdk-c submodule entry, then record the pinned commit for each image you have in the field. Anything pointing at a commit older than 30865c9c goes on the patch list.

Prioritise by exposure to untrusted AMQP peers. A device that only connects outbound to a broker you control, over TLS with strict server-certificate validation, has a narrower attack surface than one that accepts connections from arbitrary endpoints. That does not lower the CVSS, but it does help you sequence a staged rollout: pin down the highest-reach builds first, validate the patched image on a canary cohort, then expand.

Because the patch is delivered as a firmware image rather than a package update, plan the rollout like any other firmware change. Stage the new image, confirm it boots and re-establishes its AMQP connection cleanly on the canary group, and only then widen the ring. Keep the previous good image available so you can roll a device back if the new build regresses something unrelated to the security fix.

Why the use-after-free to RCE chain matters here

It is worth being precise about why a failed allocation becomes a code-execution bug rather than a harmless crash. In C, when open_get_offered_capabilities hits an allocation failure mid-operation, the surrounding cleanup can free a buffer while a pointer to it stays live. The next use of that pointer reads or writes memory that the allocator may have already handed to something else. On a connection-handling path that an unauthenticated peer can drive, that dangling write is the foothold an attacker shapes into controlled execution, which is exactly why CISA tagged the outcome CWE-94.

The practical lesson for anyone running native AMQP clients: allocation-failure paths are security-relevant, not just reliability-relevant. You cannot reliably mitigate this one from the outside because the trigger is ordinary protocol traffic during connection setup, not a malformed jumbo frame you could filter. The clean removal is the patched library, which is why the advisory says there are no workarounds.

Related guides worth a look while you sort this one out: