An integer underflow was discovered in Fort 1.6.3 and 1.6.4 before 1.6.5. A malicious RPKI repository that descends from a (trusted) Trust Anchor can serve (via rsync or RRDP) a Manifest RPKI object containing an empty fileList. Fort dereferences (and, shortly afterwards, writes to) this array during a shuffle attempt, before the validation that would normally reject it when empty. This out-of-bounds access is caused by an integer underflow that causes the surrounding loop to iterate infinitely. Because the product is permanently stuck attempting to overshuffle an array that doesn't actually exist, a crash is nearly guaranteed.

A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI manifests are listings of relevant files that clients are supposed to verify. Assuming everything else is correct, the most recent version of a manifest should be prioritized over other versions, to prevent replays, accidental or otherwise. Manifests contain the manifestNumber and thisUpdate fields, which can be used to gauge the relevance of a given manifest, when compared to other manifests. The former is a serial-like sequential number, and the latter is the date on which the manifest was created. However, the product does not compare the up-to-dateness of the most recently fetched manifest against the cached manifest. As such, it's prone to a rollback to a previous version if it's served a valid outdated manifest. This leads to outdated route origin validation.

A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI Relying Parties (such as Fort) are supposed to maintain a backup cache of the remote RPKI data. This can be employed as a fallback in case a new fetch fails or yields incorrect files. However, the product currently uses its cache merely as a bandwidth saving tool (because fetching is performed through deltas). If a fetch fails midway or yields incorrect files, there is no viable fallback. This leads to incomplete route origin validation data.

FORT Validator versions prior to 1.5.2 will crash if an RPKI CA publishes an X.509 EE certificate. This will lead to RTR clients such as BGP routers to lose access to the RPKI VRP data set, effectively disabling Route Origin Validation.