Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The BST name-lookup loop in DirectoryTree.TryGetDirectoryEntry (OpenMcdf/DirectoryTree.cs:35-46) walks directory entries by repeatedly calling directories.TryGetSibling(child, siblingType, validateColor). A crafted CFB file with cyclic Left/Right sibling links among directory entries - constructed so the per-step BST-order check in TryGetSibling (DirectoryEntries.cs:84-85) is satisfied at every step - drives this while (child is not null) loop forever. There is no cycle detection in TryGetDirectoryEntry. Details The recent Brent's-algorithm commit (24f445a) protects DirectoryTreeEnumerator and works correctly for both attached repros - pure EnumerateEntries() throws FileFormatException: Directory tree contains a loop cleanly. The unprotected code path is the lookup-by-name loop, which is reached from multiple public APIs: - RootStorage.OpenStorage(name) / TryOpenStorage(name) - RootStorage.OpenStream(name) / TryOpenStream(name) The second one matters most: typical consumers…
Recommended action: Upgrade to 3.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenMcdf does not detect cycles in the directory entry red-black tree of a Compound File Binary (CFB) document. A crafted CFB file with a cycle in the LeftSiblingID / RightSiblingID chain causes Storage.EnumerateEntries() and Storage.OpenStream() to loop indefinitely, consuming the calling thread with no possibility of recovery via try/catch. Details CFB directory entries form a red-black tree linked by LeftSiblingID and RightSiblingID fields. OpenMcdf's DirectoryTreeEnumerator and DirectoryTree.TryGetDirectoryEntry traverse this tree without tracking visited node IDs, so a crafted cycle (e.g. entry A's RightSiblingID points to entry B, and entry B's LeftSiblingID points back to entry A) causes traversal to loop indefinitely. Two distinct code paths are affected: - Storage.EnumerateEntries() - DirectoryTreeEnumerator.MoveNext() never returns false; the same entry is yielded on every iteration and the caller's foreach never exits. Heap grows unboundedly as entries accumulate.…
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.