Q:

iText and Shadow attacks

I want to know if iText is researching or have already patched shadow attacks described here: https://www.pdf-insecurity.org/
Shadow Attacks: Hiding and Replacing Content in Signed PDFs (July 2020)
I've just found information about vulnerabiities discovered in 2019
https://itextpdf.com/en/blog/technical-notes/avoiding-pdf-digital-signature-vulnerabilities-itext

A:

First of all, iText does not need to be patched, neither in versions 7.x nor in versions 5.5.x. 
In either case the method that checks whether any changes were made to a signed PDF by means of incremental updates, SignatureUtil.signatureCoversWholeDocument and AcroFields.signatureCoversWholeDocument respectively, reports false in case of the manipulated examples provided on the pdf-insecurity site, i.e. it reports that some kind of changes were added after signing. 
Furthermore, in either case the method that retrieves the signed revision, SignatureUtil.extractRevision and AcroFields.extractRevision respectively, also returns the original, not yet manipulated, signed revision for those examples. 
This behavior is not surprising.  The description of the shadow attacks clearly indicates that these attacks are applied to the PDF by means of an incremental update (called an Incremental Saving in the vulnerability report by the RUB researchers).  The signatureCoversWholeDocument method now checks exactly whether the file has no content after the signed revision; thus, it detects the incremental update added by shadow attacks.  And the extractRevision method returns the file up to the end of the corresponding signed ranges; thus, it does not return any addition from the incremental update applied by the shadow attack. 
Just to be sure I checked the iText 7 signatureCoversWholeDocument output for the manipulated example documents, see this ShadowAttacks unit test, and as expected the method reported that the signature in question did not cover the whole document. 

The vulnerability report can be read to call a behavior like that of iText a "limited vulnerability" described as

the same warning is raised in case
of an allowed modification (e.g., commenting) as well as in case of unallowed
modifications (attacks).  Victims are unable to distinguish between both cases. 

(Vulnerability Report - Attacks bypassing the signature validation in PDF - 2020-03-02)
In my opinion this terminology only makes sense if the software in question promised otherwise, i.e. to differentiate between allowed and disallowed changes and to report accordingly.  Otherwise it's not a vulnerability but a (hopefully documented) behavior, and vulnerable only is a user who incorrectly expects a different behavior. 
As far as I know iText has not promised to analyse the changes in incremental updates (in excess to retrieving LTV information).  Bruno Lowagie in his iText whitepaper on digital signatures for PDFs wrote that an analysis had been put onto the development roadmap; to my knowledge, though, there is no (public) implementation thereof available currently. 
Thus, I wouldn't call the behavior of iText in particular a "limited vulnerability". 
Of course, if some software is based on iText for signature validation and does promise to recognize allowed and disallowed changes based on the validation results of iText explained above, that software indeed has at least a limited vulnerability to shadow attacks unless reporting them as disallowed changes. 

It is very likely that at least the widely used validators reported as vulnerable, foremost Adobe Acrobat Reader, will quickly try to correct their code to at least indicate the presence of changes or even to report them as disallowed.  Nonetheless, it may make sense to try and implement some methods that check for signs of preparations for shadow attacks.  I'm currently playing around with some proofs-of-concepts in this regard.