1 Trillion Dollar Refund – How To Spoof PDF SignaturesVladislav MladenovChristian [email protected] University Bochum, Chair forNetwork and Data [email protected] University Bochum, Chair forNetwork and Data SecurityMartin GrotheJörg [email protected] University Bochum, Chair forNetwork and Data [email protected] University Bochum, Chair forNetwork and Data SecurityABSTRACTsame year. This leads him to estimate that about 2.5 trillion PDF fileswere created since 2015. Whether this is correct or not, PDF filesare heavily used in everyone’s life – for exchanging information,for creating and archiving invoices and contracts, for submittingscientific papers, or for collaborating and reviewing texts.The Portable Document Format (PDF) is the de-facto standard fordocument exchange worldwide. To guarantee the authenticity andintegrity of documents, digital signatures are used. Several publicand private services ranging from governments, public enterprises,banks, and payment services rely on the security of PDF signatures.In this paper, we present the first comprehensive security evaluation on digital signatures in PDFs. We introduce three novel attackclasses which bypass the cryptographic protection of digitally signedPDF files allowing an attacker to spoof the content of a signed PDF.We analyzed 22 different PDF viewers and found 21 of them to bevulnerable, including prominent and widely used applications suchas Adobe Reader DC and Foxit. We additionally evaluated eightonline validation services and found six to be vulnerable. A possible explanation for these results could be the absence of a standardalgorithm to verify PDF signatures – each client verifies signaturesdifferently, and attacks can be tailored to these differences. We, therefore, propose the standardization of a secure verification algorithm,which we describe in this paper. All findings have been responsiblydisclosed, and the affected vendors were supported during fixing theissues. As a result, three generic CVEs for each attack class wereissued [50–52]. Our research on PDF signatures and more information is also online available at Meyer zu manit GmbHPDF Digital Signatures. The PDF specification supports digitalsignatures since 1999 in order to guarantee that the document wascreated or approved by a specific person and that it was not alteredafterward. PDF digital signatures are based on asymmetric cryptography whereby the signer possess a public and private key pair.The signer uses his private key to create the digital signature. Anydocument modification afterward invalidates the signature and leadsto an error message thrown by the corresponding PDF viewer orvalidation service. PDF digital signatures must not be confused withelectronic signatures, which are the electronic equivalent of handwritten signatures; this is done by basically adding an image of thesigner’s handwritten signature into the document. Electronic signatures do not provide any cryptographic protection so that spoofingattacks are trivial and not further considered.In 2000, President Bill Clinton enacted a federal law facilitatingthe use of electronic and digital signatures in interstate and foreigncommerce by ensuring the validity and legal effect of contracts.He even approved the eSign Act by digitally signing it [35]. Since2014, organizations delivering public digital services in an EU member state are required to support digitally signed documents, whichare even admissible as evidence in legal proceedings [48]. In Austria, every governmental authority digitally signs any document [17,§19]. In addition, any new law is legally valid after its announcement within a digitally signed PDF. Several countries like Brazil,Canada, the Russian Federation, and Japan also use and accept digitally signed documents [53]. Outside governmental services digitallysigned PDFs are used by the private sector to sign invoices and contracts: e.g., invoices by Amazon, Decathlon, Sixt, and even more areconcluded secretly between companies. Even in the academic world,PDF signatures are used to sign scientific papers (e.g., ESORICSproceedings) as evidence of the paper’s submission state. According to Adobe Sign, the company processed 8 billion electronic anddigital signatures in 2017 alone [1].We thus raise the question: Is it possible to spoof a digitallysigned PDF document in a way such that the spoofed document isindistinguishable from a valid one?.INTRODUCTIONIntroduced in 1993 by Adobe Systems, the Portable Document Format (PDF) was designed as a solution for the consistent presentationof documents, independent of the operating system and hardware.Today, the PDF format has become the standard for electronic documents in our daily workflow. The total number of PDF files inthe world is hard to guess, but according to Adobe System’s VicePresident of Engineering, Phil Ydens, there were about 1.6 billionPDF files on the web in 2015 [3], whereby 80% were created in thePermission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected] ’19, November 11–15, 2019, London, United Kingdom 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM.ACM ISBN 978-1-4503-6747-9/19/11. . . 15.00

CCS ’19, November 11–15, 2019, London, United KingdomVladislav Mladenov, Christian Mainka, Karsten Meyer zu Selhausen, Martin Grothe, and Jörg SchwenkSigned PDFUSFISAHeaderHeaderHeaderBodyBody (Manipulated)BodyBodyXref TableXref TableXref TableXref TableabTrailerTrailerTrailercSignature: [a,b,c,d]Signature: [a,b,c,d]Signature: [a,b,c,d]Xref Table UpdatesXref Table UpdatesXref Table UpdatesTrailerTrailerTrailerdSWAaHeaderbBody (Manipulated)c*Body (Manipulated)Xref TableProtected by the signatureTrailerSignature: [a,b,c*,d*]Xref Table UpdatesXref Table Updatesd*TrailerTrailerContent ManipulationFigure 1: Validly signed PDF document by Amazon with aspoofed content. Adobe Acrobat DC claims that the ‘documenthas not been modified since the signature was applied’.Figure 2: An overview of the attacks introduced in this paper:USF, ISA, and SWA. Each attack relies on a different injectionpoint for malicious content without invalidating the digital signature.Novel Attacks on PDF Signatures. In this paper, we show how tospoof a digitally signed PDF document. The only requirement ofour attacks is access to a signed PDF (e.g., an Amazon invoice).Given such a PDF, our attacks allow an attacker to change the PDF’scontent arbitrarily without invalidating its signature – see Figure 1.Plausible attack scenarios which may abuse the vulnerabilities couldinclude, for example, the manipulation of the billing date on thedigitally signed receipt to extend the warranty period of a productor changing the contract’s information to attain more resources thanagreed upon.We systematically analyze the verification process of PDF signatures in different desktop applications as well as in server implementations, and we introduce three novel attack classes, see Figure 2.Each of them gives a blueprint for an attacker to modify a validlysigned PDF file in such way that for the targeted viewer, the displayed content is altered without being detected by the viewer’ssignature verification code – all elements in the GUI related to signature verification are identical to the original, unaltered document.On a technical level, each attack class abuses a different step inthe signature validation the allocated position. We introduce three different variants ofSWA which we used to bypass the signature validation.Large-Scale Evaluation. We provide the first large-scale evaluationcovering 22 different PDF viewers installed on Windows, Linux, orMacOS. We systematically analyzed the security of the signaturevalidation on each of them and found signature bypasses in 21 of 22of the viewers, including Adobe Reader DC and Foxit. Additionally,we analyzed eight online validation services supporting signatureverification of signed PDF files. We found six of them to be vulnerable against at least one of the attacks, and included, among others,DocuSign – one of the worldwide leading cloud services providingelectronic signatures and ranked #4 on the Forbes Cloud 100 [15].The results are reasoned by the fact that:(1) There is almost no related work regarding the security ofdigitally signed PDF files, even though integrity protection ispart of the PDF specification since 1999.(2) The PDF specification does not provide an implementationguideline or a best-practices document regarding the signature validation. Thus, developers implement a security criticalcomponent without having a thorough understanding regarding the actual risks.(1) The Universal Signature Forgery (USF) manipulates meta information in the signature in such a way that the targeted viewerapplication opens the PDF file, finds the signature, but is unableto find all necessary data for its validation. Instead of treatingthe missing information as an error, it shows that the containedsignature is valid.(2) The Incremental Saving Attack (ISA) abuses a legitimate feature of the PDF specification, which allows updating a PDF fileby appending the changes. The feature is used, for example, tostore PDF annotations, or to add new pages while editing the file.The main idea of the ISA is to use the same technique for changing elements, such as texts, or whole pages included in the signedPDF file to what the attacker desires. The PDF specification doesnot forbid this, but the signature validation should indicate thatthe document has been altered after signing. We introduce fourvariants of ISA masking the modification made without raisingany warnings that the document was manipulated.(3) The Signature Wrapping Attack (SWA) targets the signaturevalidation logic by relocating the originally signed content to adifferent position within the document and inserting new contentContributions. The contributions of this paper are: We developed three novel attack classes on PDF signatures.Each class targets a different step in the signature validationprocess and enables an attacker to bypass a PDF’s integrityprotection completely, shown in section 4. We provide the first in-depth security analysis of PDF applications. The results are alarming: out of 22 popular desktopviewers, we could bypass the signature validation in 21 cases,as seen subsection 5.1. We additionally analyzed eight online validation servicesused within the European Union and worldwide for validatingsigned documents. We could bypass the signature validationin six cases, shown in subsection 5.2. Based on our experiences, we developed a secure signaturevalidation algorithm and communicated it with the applicationvendors during the responsible disclosure process, as seen insection 6. By providing the first in-depth analysis of PDF digital signatures, we pave the road for future research. We reveal new2

1 Trillion Dollar Refund – How To Spoof PDF SignaturesCCS ’19, November 11–15, 2019, London, United KingdomByte Offsetinsights and show novel research aspects regarding PDF security, shown in section 8.0 ByteResponsible Disclosure. In cooperation with the BSI-CERT, wecontacted all vendors, provided proof-of-concept exploits, and helpedthem to fix the issues. As a result, the following three generic CVEsfor each attack class covering all affected vendors were issued [50–52].15 ByteDocument Parts%PDF-1.7Header1 0 obj Catalog/Pages 2 0 R60 Byte2 0 obj Pages/Kids [3 0 R]2PDF BASICS135 ByteThis section deals with the foundations of the Portable DocumentFormat (PDF). We give an overview of the file structure and explainhow the PDF standard for signatures is implemented.2.1245 Byte300 Bytexref050000000000 65535 f0000000015 00000 n0000000060 00000 n0000000135 00000 n0000000245 00000 nBody. The body specifies the content of the PDF and contains textblocks, fonts, images, and metadata regarding the file itself. Themain building blocks within the body are objects, which have thefollowing structure: Each object starts with an object number followed by a generation number. The generation number should beincremented if additional changes are made to the object.XrefTabletrailer/Root 1 0 Rstartxref300%%EOFTrailer1 0 obj2Figure 3: A simplified example of a PDF file’s internal structure.We depict the object names after the obj string for clarification.Constant String “obj”Generation NumberObject Number3464 0 obj streamstreamHello World!endstreamPortable Document Format (PDF)Header. The header is the first line within a PDF and defines theinterpreter version to be used. The provided example uses versionPDF 1.7.5Body/Contents 4 0 RA PDF consists of 4 parts: header, body, xref table, and a trailer, asdepicted in Figure 3.13 0 obj Page.endobjand, thus, describes the in-use object with object number 2and generation number 0 at byte offset 60 (see “2 0 obj” inFigure 3).Listing 1: Example of an object declaration within the body.Trailer. After a PDF file is read into memory, it is processed fromthe end to the beginning. Thus, the Trailer is the first processedcontent of a PDF file. It contains references to the Catalog (1 0 R)and the Xref table.In the example depicted in Figure 3, the body contains four objects: Catalog, Pages, Page, and stream. The Catalog object is theroot object of the PDF file. It defines the document structure andcan additionally declare access permissions. The Catalog refers to aPages object which defines the number of the pages and a referenceto each Page object (e.g., text columns). The Page object containsinformation on how to build a single page. In the given example, itonly contains a single string object “Hello World!”.2.2Creating a PDF SignaturesThis section explains how a digitally signed PDF file is built.Incremental Saving. PDF Signatures rely on a feature of PDF calledincremental saving (also known as incremental updates), allowingthe modification of a PDF file without changing the previous content.In Figure 4, an original document (shown on the left side) is beingmodified via incremental saving by attaching a new body, as wellas a new Xref table, and a new Trailer at the end of the file. Withinthe body, new objects can be defined. A new Pages object can bedefined, referencing two pages, for example, /Kids [3 0 R 3 0 R].For reasons of simplicity, the same content (3 0 R) was used twicehere. The Xref table contains only a description of the newly definedobjects. The new Trailer contains a reference to the Catalog (it couldbe the old Catalog or an updated one), the byte offset of the newXref table, and the byte offset of the previously used Xref table. Thisscheme is applied for each incremental saving.Xref table. The Xref table contains information about all PDF objects.An Xref table can contain one or more sections. Each Xref table section starts with a line consisting of twointeger entries a b (e.g., “0 5” as shown in Figure 3) whichindicates that in the Xref table the following b 5 linesdescribe objects with ID (also known as object numbers)ranging from a {0, . . . , b 1} {0, . . . , 4} Each object entry (a {0, . . . , b 1}) in the Xref table hasthree entries x y z, where x defines the byte offset of theobject from the beginning of the document; y defines itsgeneration number, and z {′ n′ ,′ f ′ } describes whether theobject is in-use (′ n′ ) or not (′ f ′ , say “free”). For example,the line “0000000060 00000 n” is the third line after “0 5”3

CCS ’19, November 11–15, 2019, London, United KingdomVladislav Mladenov, Christian Mainka, Karsten Meyer zu Selhausen, Martin Grothe, and Jörg SchwenkHeaderHeaderHeaderBodyBodyBodyXref TableXref TableXref TableTrailerTrailerTrailerBody UpdatesBody UpdatesXref Table UpdatesXref Table UpdatesUpdate 1defines which bytes of the PDF file are used as the hash input for thesignature calculation and defines two integer tuples:a, b : Beginning at byte offset a, the following b bytes are used asthe first input for the hash calculation. Typically, a 0 is usedto indicate that the beginning of the file is used while a b isthe byte offset where the PKCS#7 blob begins.c, d : Typically, byte offset c is the end of the PKCS#7 blob, whilec d points to the last byte range of the PDF file and is usedas the second input to the hash calculation.TrailerTrailerBody UpdatesUpdate 2Xref Table UpdatesTrailerAccording to the specification, it is recommended to sign thewhole file except for the PKCS#7 blob (located in the range betweena b and c) [21].Figure 4: Multiple incremental savings applied on a PDF file.Structure of a Signed PDF. The creation of a digital signature ona PDF file relies on incremental saving by extending the originaldocument with objects containing the signature information.In Figure 5, an example of a signed PDF file is shown. The2.3If a signed PDF file is opened with a desktop application that supports signatures, it immediately starts to verify it by: (1) extractingthe signature from the PDF and applying the cryptographic operations to verify its correctness and (2) verifying if the used signingkeys are trusted, e.g., an x.509 certificate. One thing that all applications had in common is that by default, they do not trust the operatingsystem’s keystore. Similar to web browsers such as Firefox, theydistribute their own keystore and keep the list of trusted certificatesup to date. Additionally, every viewer allows the utilization of adifferent keystore containing trusted certificates. This feature is interesting for companies using their own Certificate Authority (CA)and disallowing the usage of any other CA. As a result, similarto key pinning, the viewer can be configured to trust only specificcertificates.%PDF-1.71 0 obj Catalog2 0 obj Pages3 0 obj Page4 0 obj streamOriginalDocumentXref TableTrailer%%EOF1 0 obj Catalog3/Pages 2 0 R/Perms 5 0 RSignatureUpdate 15 0 obj SignatureTrailer%%EOFATTACKER MODELIn this section, we describe the attacker model including the attackers’ capabilities and the winning conditions.New SignatureBodyVictim. A victim can be either a human who opens the file usinga certain PDF desktop application or a website offering an onlinevalidation service./Subfilter adbe.pkcs7/Contents sig.value/ByteRange [a b c d]Xref TableVerifying a signed PDF FileNew XrefTableAttacker Capabilities. It is assumed that the attacker is in possession of a signed PDF file. The attacker does not possess the properprivate key that was used to sign it. Also, we assume that the victim only trusts specific certificates (e.g., via the trust store) and theattacker does not possess a single private key that is trusted by thevictim. Thus, malicious PDF files which are digitally signed by theattacker with a self-generated or untrusted certificate will be notverified successfully by the viewer. Apart from this restriction, the attacker can arbitrarily modify the PDF file, for example, by changingthe displayed content.The attacker finally sends the modified PDF file to a victim, wherethe file is then processed.NewTrailerFigure 5: A simplified overview of a signed PDF file.original document is the same document as depicted in Figure 3.By signing the document, an incremental saving is applied and thefollowing content is added: a new Catalog, a Signature object, anew Xref table referencing the new object(s), and a new Trailer. Thenew Catalog extends the old one by adding a new parameter Perms,which defines the restrictions for changes within the document. ThePerms parameter references to the Signature object.The Signature object (5 0 obj) contains information regardingthe applied cryptographic algorithms for hashing and signing thedocument. It additionally includes a Contents parameter containinga hex-encoded PKCS7 blob, which holds the certificates as well asthe signature value created with the private key that corresponds tothe public key stored in the certificate. The ByteRange parameterWinning Conditions. For the successful execution of this attack,we have defined two conditions:Cond. 1) When opening the PDF file, the target application, i.e., theviewer or online service, shows a UI displaying that it isvalidly signed and is identical to the originally unmodifiedsigned PDF file.Cond. 2) The viewer application displays content which is differentfrom the original file.4

1 Trillion Dollar Refund – How To Spoof PDF SignaturesCCS ’19, November 11–15, 2019, London, United KingdomUI-Layer 1: Automatically shown once PDF is opened(1.) Signature is valid and trusted.UI-Layer 2Click to open UI-Layer-2(2.) Untrusted key is used to sign the document.Your Amazon Invoice #345123(3.) Signature value is invalid.(PDF Content)(a) A screenshot of Adobe Acrobat DC is depicted after opening a signed PDF document. A signature validation bar (UI-Layer 1) is automatically shown. A signaturepanel (UI-Layer 2) can be opened by pressing the corresponding button. The panelprovides more details, e.g., the error message or email address of the signer.(b) There are 3 validation states: (1.) A green icon indicates avalid and trusted signature. (2.) If the icon appears in yellow,the key used to sign the PDF is untrusted, e.g., because aself-generated certificate is used. (3.) The red icon indicatesan invalid signature, e.g., if the PDF file is modified.Figure 6: PDF signature validation with two UI-Layers.4For viewer applications, both winning conditions must be met. Forthe online validation services, only the first condition must be fulfilled because online services do not show the content of a PDF file.Instead, they generate a report containing the results of the verification, see Figure 11. Therein, the services show whether the PDF fileis validly signed.Desktop viewer applications differ substantially in displayingthe results of the signature verification. To classify if an attack issuccessful and to determine if the victim could detect the attack, wedefined two different UI-Layer: UI-Layer 1 represents the UI information regarding the signature validation which is immediately displayed to the userafter opening the PDF file. It is shown without any user interaction. Examples for Adobe Acrobat DC UI-Layer 1 arepresented in the top part of the purple box in Figure 6. UI-Layer 2 provides extended information regarding the signature validation. It can be accessed by clicking on the respective menu option. Examples for Adobe Acrobat DC UI-Layer2 are displayed in the bottom-left part of the green box inFigure 6.If the information presented on the UI-Layer 2 states that thesignature is invalid or the document has been modified after theapplication of the signature, the attack can still be classified assuccessful for UI-Layer 1.In Figure 6, an example of a successful signature validation onUI-Layer 1 and UI-Layer 2 is presented. After opening the PDFfile, the information Signed and all signatures are valid is displayed.Further information is revealed by clicking on the Signature Paneland can be seen in the green box of UI-Layer 2.HOW TO BREAK PDF SIGNATURESIn this section, we present three novel attack classes on PDF signatures: Universal Signature Forgery (USF), Incremental SavingAttack (ISA), and Signature Wrapping Attack (SWA). All attackclasses bypass the PDF’s signature integrity protection, allowing themodification of the content arbitrarily without the victim noticing.The attacker’s goal is to place malicious content into the protectedPDF file, such that the previously defined winning conditions forviewer applications and online validation services are satisfied.During the security analysis, we designed many broken PDF filesfor each attack class which are clearly violating the PDF specificationin order to bypass the signature verification process. We also learnedthat nearly every PDF viewer has a high level of error-tolerance sothat these PDF files could be successfully opened even if requiredparameters are missing. We can only assume that this is due to theindividual interpretation of the PDF specification by each vendor.4.1Universal Signature Forgery (USF)The main idea of Universal Signature Forgery (USF) is to disablethe signature verification while the application viewer still shows asuccessful validation on the UI layer. This attack class was inspiredby existing attacks applied to other message formats like XML [42]and JSON [33]. Such attacks either remove all signatures or useinsecure algorithms like none in JSON signatures. For PDFs weestimated two possible approaches – either to remove informationwithin the signature which makes the validation impossible, or toremove references to the signature to avoid the validation. Removingreferences did not lead to any successful attack. Thus, we concentrated on manipulations within the signature. In this case, the attackermanipulates the signature object in the PDF file, trying to create aninvalid entry within this object.Although the signature object is provided, the validation logic isnot able to apply the correct cryptographic operations. This leadsto the situation that a viewer shows some signature informationeven though the verification is being skipped. In the end, we defineSelf-Signed PDFs. We do not consider self-signed PDF as a legitimate attack and neither use nor rely on them because a self-signedPDF can clearly be distinguished from a PDF signed with a trustedcertificate; cf. green and yellow icon in Figure 6.5

CCS ’19, November 11–15, 2019, London, United KingdomVariant: 1Variant: 2Variant: 3Vladislav Mladenov, Christian Mainka, Karsten Meyer zu Selhausen, Martin Grothe, and Jörg SchwenkVariant: 45 0 obj Signature5 0 obj Signature5 0 obj Signature5 0 obj Signature/Subfilter adbe.pkcs7/ByteRange [a b c d]/Subfilter adbe.pkcs7/Contents/ByteRange [a b c d]/Subfilter adbe.pkcs7/Contents null/ByteRange [a b c d]/Subfilter adbe.pkcs7/Contents 0x00/ByteRange [a b c d]5 0 obj Signature5 0 obj Signature5 0 obj Signature5 0 obj Signature/Subfilter adbe.pkcs7/Contents sig.value/Subfilter adbe.pkcs7/Contents sig.value/ByteRange/Subfilter adbe.pkcs7/Contents sig.value/ByteRange null/Subfilter adbe.pkcs7/Contents sig.value/ByteRange [a -b c d]During our research, we elaborated four variants of ISA. Thesevariants are reasoned by the fact that some vendors recognized thatincremental saving is dangerous when concerning PDF signatures.These vendors implemented countermeasures to detect changes afterthe document’s signing. As part of our black-box analysis, we wereable to determine these countermeasures and find generic bypassesthat worked for multiple viewers which we describe below.Variant 1: ISA with Xref table and Trailer. For Variant 1 of theISA class, as depicted in Figure 8, only two of the evaluated signaturevalidators were susceptible to the attack. This is not very surprisingsince this type of modification is exactly what a legitimate PDFapplication would do when editing or updating a PDF file. A digitalsignature in PDF is designed to protect against this behavior; thesignature validator recognizes that the document was updated aftersigning it and shows a warning respectively. To bypass this detection,we found two possibilities. (1) We included an empty Xref table.This can be interpreted as a sign that no objects are changed bythe last incremental saving. Nevertheless, the included updates areprocessed and displayed by the viewer. (2) We used an Xref tablethat contains entries for all manipulated objects. We additionallyadded one entry which has an incorrect reference (i.e., byte offset)pointing to the transform parameters dictionary, which is part of thesignature object. The result of these manipulations is that the viewerapplication does not detect the last incremental saving. No warningis shown that the document has been modified after signing it butthe PDF viewer displays the new objects.Figure 7: Different USF attack variants manipulating the signature object entries to bypass the signature validation.24 different attack vectors, eight of them are depicted in Figure 7.In the given example, the attack vectors target two values: a) theentry Contents contains the key material as well as the signaturevalue and b) the entry ByteRange defines the signed content inthe file. The manipulation of these entries is reasoned by the factthat we either remove the signature value or the information statingwhich content is signed. In Variant 1, as depicted in Figure 7, eitherContents or ByteRange are removed from the signature object.Another possibility is defined in Variant 2 by removing only thecontent of the entries. In Variants 3 and 4, invalid values werespecified and tested. Such values are for instance null, a zero byte(0x00), and invalid ByteRange values like negative or overlappingbyte ranges. Providing such tests is common for penetration testerssince many implementations behave abnormally when processingthese special byte sequences.4.2Variant 2: ISA without Xref table and Trailer. Some of the viewers detected the manipulation by checking if a new Xref table andTrailer were defined within the new incremental saving. By removing the Xref table and the Trailer, a vulnerable validator does notrecognize that incremental saving has been applied and successfullyverifies the signature without showing a warning. The PDF file isstill processed normally by displaying the modif

PDF files allowing an attacker to spoof the content of a signed PDF. We analyzed 22 different PDF viewers and found 21 of them to be vulnerable, including prominent and widely used applications such as Adobe Reader DC and Foxit. We additionally evaluated eight online val