CVE-2025-29909 is a critical (CVSS 9.8) heap buffer overflow in NASA CryptoLib 1.3.3 and earlier. A crafted telecommand frame can cause out-of-bounds memory writes in Crypto_TC_ApplySecurity(), leading to denial of service or possibly code execution. The advisory lists no patched release, so check it for the fix.
What's affected
The record and the project advisory list NASA CryptoLib versions 1.3.3 and prior as affected. CryptoLib is a software only implementation of the CCSDS Space Data Link Security Protocol, Extended Procedures (SDLS-EP), used to secure links between a spacecraft running the core Flight System (cFS) and a ground station.
The advisory page I reviewed shows no patched release version. The record links to a fix commit for some of these issues, but a commit is not a release. Check the CryptoLib releases page and the advisory for the first fixed release before you decide that you are covered.
The record does not flag this CVE as known exploited (not in the CISA KEV catalog at the time of writing).
How to check if you're exposed
CryptoLib is usually built from source and linked into flight or ground software, so there may be no package manager entry to query.
- Search your build tree and your software bill of materials for CryptoLib, and note the version or commit you build from.
- If you vendor the source, look at the git history for the project's fix commit and see whether it is included in your tree.
- List every program that links the library and receives frames from a radio link, simulator or test harness.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project's dependency list includes an affected component, and the Gold directory lets you look up the CVE and its related weaknesses.
What to do now
- Find every build that includes CryptoLib 1.3.3 or earlier, including ground segment tools and test benches.
- Check the CryptoLib advisory and releases for a fixed version, or for the fix commit referenced in the record, and plan the update.
- Until you have a fix, validate frame length fields and header sizes in your own code before passing frames to CryptoLib, and drop frames that fail those checks.
- Run the affected components with the least privilege your platform allows, and keep them away from networks that untrusted parties can reach.
- Add fuzz tests for frame parsing to your pipeline, since the advisories describe issues found that way.
Why it matters
The record maps the flaw to CWE-191 (Integer Underflow) and CWE-787 (Out-of-bounds Write). The advisory explains that the telecommand frame payload length is computed from a length field supplied in the incoming frame. If that field is very small, the subtraction wraps to a large number, and a later memory copy then writes far more data than the buffer holds.
This is a classic length calculation bug. The input is attacker controlled, the arithmetic uses unsigned numbers, and nothing checks the result before it is used as a copy size. Denial of service is the likely outcome, and the record says code execution is possible under certain conditions.
For space and ground systems, a crash may be as costly as an intrusion. Telecommand processing is also where authenticated command traffic is handled, which makes careful bounds checking essential. This CVE belongs to a group of related CryptoLib issues, including CVE-2025-29912 and CVE-2025-30356, so patching one does not mean the others are covered.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a fixed version available?
The advisory page showed no patched release when I reviewed it. The record links to a fix commit, so check the project's releases and advisory.
Do I need to be on a radio link to be at risk?
The record says any system that processes telecommand frames with CryptoLib and does not strictly validate them is at risk. Think about every path that frames can arrive from.
Sources
Last reviewed: 19 October 2026.
