The following issue only occurs when secure boot is using encryption only. If the Hardware Root of Trust (i.e. RSA) is used, this is not an issue.
In an "Encrypted Only" boot mode, the ROM and FSBL are required to check the FORCE_USE_AES_ONLY eFuse and, when programmed, always decrypt the FSBL or partition.
The ROM performs this check correctly, the FSBL does not.
The FSBL does not check the FORCE_USE_AES_ONLY eFuse. The FSBL only checks the partition header to determine if the partition should be decrypted.
An adversary could change the value in the partition header, and because the partition header is not authenticated (because the HW Root of Trust is not being used) the change would not be detected, and an unencrypted partition could be loaded.
Xilinx recommends using the Hardware Root of Trust by programming the RSA_EN eFuses.
The FSBL and partitions will be authenticated, in addition to the partition headers.
Tampering done to the partition headers would then be detected.