CVE-2023-38562 is a high severity (CVSS 8.7) double free in the IP header loopback parsing of Weston Embedded uC-TCP-IP version 3.06.01. A crafted series of unauthenticated packets can corrupt memory and potentially run code. I could not confirm a fixed version, so ask the vendor.
What's affected
The affected product is the uC-TCP-IP network stack from Weston Embedded, version 3.06.01 according to the record. The flaw is a double free in the IP header loopback parsing functionality. The record says a specially crafted set of network packets can lead to memory corruption, potentially resulting in code execution, and that an attacker can send a sequence of unauthenticated packets to trigger it. The record is dated 2024-02-20 and scores 8.7, High, with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H.
The record references Talos report TALOS-2023-1829. Talos's site blocked my request, so I could not read the report or check its timeline and any fixed version. Because uC-TCP-IP is a library embedded in other vendors' products, the fix reaches you through your device or firmware vendor. Ask them whether their build uses 3.06.01 and whether a patched build exists.
Weakness class: CWE-415.
How to check if you're exposed
Because this is an embedded component, you check the firmware, not a package manager. Look for the product's software bill of materials, release notes or vendor security page and search them for uC-TCP-IP or Micrium, the earlier name of the stack.
If your own team builds firmware, search the source tree.
grep -r "uC-TCP-IP" --include=*.h --include=*.c -l .
Then check the version defined in the stack's configuration headers.
What to do now
- List devices and products whose firmware includes uC-TCP-IP, using SBOMs or vendor statements.
- Ask each vendor whether version 3.06.01 is used and whether a fixed build exists.
- If you build firmware yourself, move to a patched version of the stack as the vendor documents.
- Limit exposure of affected devices to the networks that need them, and filter unneeded traffic at the boundary.
- Track the issue per device so you can close it as updates arrive.
Why it matters
A double free releases the same memory block twice. Allocators keep records of free blocks, and a second free can corrupt those records, which an attacker may turn into control over later allocations. Here it is reached through packet parsing, so the attacker needs only network reach.
The high attack complexity in the vector reflects how hard it is to turn the memory error into reliable code execution on an embedded target. Embedded stacks are hard to patch because the fix has to travel through every product maker that uses them. That is the case for knowing what is inside your devices. The CVE is not on the CISA Known Exploited Vulnerabilities list.
A double free means the same block of memory is released twice. Allocators keep internal bookkeeping, and freeing twice can corrupt it, which an attacker may turn into control over later allocations. Memory-safe languages avoid the class entirely, and in C code, careful ownership rules and tools such as AddressSanitizer find it during testing.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan covers the dependencies a code project declares. It does not see firmware, desktop software or vendor appliances, so keep this item in your asset inventory and track the vendor's advisory.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Where do I get the fix?
From the vendor of your device or firmware. I could not confirm a patched version of the library from the sources I could load.
Can I find this with a package manager?
No. It is compiled into firmware, so use SBOMs, vendor statements or a source search.
Sources
Last reviewed: 19 October 2026.
