CVE-2025-55089 is a critical buffer overflow in the RAM disk driver of FileX, the file system module for Eclipse ThreadX. Versions before 6.4.2 are affected, and the record says a crafted sequence of packets could lead to remote code execution. Version 6.4.2 contains the fix.
What's affected
- Product: FileX, the FAT compatible file system module for Eclipse Foundation ThreadX.
- Component: the FileX RAM disk driver.
- Affected: versions up to and including 6.4.1, per the GitHub advisory. The advisory also names a specific git commit as tested vulnerable.
- Fixed: 6.4.2.
- Impact: the advisory says a specially crafted set of network packets can lead to code execution.
FileX works on its own, but in a networked product it is often combined with a network stack or a file service. A device that exposes file access over the network is the case to look at first. The advisory's wording shows the issue was confirmed by the vendor.
How to check if you're exposed
ThreadX modules are usually compiled into firmware, so there is no package manager to ask. Work from your build.
git submodule status
git -C path/to/module describe --tags
Run these in the repository that vendors the module, and substitute the real path. If your firmware comes from a chip vendor SDK, the SDK may carry its own copy of the module, so check the SDK release notes and ask the vendor which module version it ships. Your firmware bill of materials, if you keep one, is the quickest place to answer the question for a whole product line.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that checks a manifest or lockfile against known vulnerabilities, and the Gold directory lists affected packages for each CVE.
Then look at whether the RAM disk driver is part of your build, and whether any network service lets a remote party reach file system functions.
What to do now
- List every product that includes FileX and the version in each.
- Update to FileX 6.4.2 or later, rebuild and test, then ship a firmware update.
- Check whether your product exposes any file service to the network, and restrict it to trusted segments.
- Ask suppliers who give you firmware or SDKs whether they include FileX and when a fixed build will arrive.
- Record the module in your firmware bill of materials.
Why it matters
The record lists improper restriction of operations within the bounds of a memory buffer. A copy into a RAM disk structure did not respect the size of its target, so data from a remote sequence of requests could overwrite adjacent memory. Memory corruption in firmware tends to be more dangerous than on a desktop, because many embedded targets lack address randomization or other mitigations.
The remedy at the code level is bounds checking on every copy. At the product level it is patching quickly, and making sure the device is reachable only by the systems that need it. This is an embedded component, which means the practical risk depends on whether the affected feature is compiled in and reachable on a given device. It is not on the CISA KEV list.
The weakness is classed as CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer). Severity in the CVE record: critical, CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
Quick check
Which versions are affected?
FileX up to and including 6.4.1. Version 6.4.2 contains the fix.
Is the whole device at risk?
The advisory says crafted packets can lead to code execution, so yes if the vulnerable driver is compiled in and a path to it is reachable. Check your build and network exposure.
Sources
Last reviewed: 18 October 2026.
