The application does not properly validate the lifetime and validity of internal view cache pointers after JavaScript changes the document zoom and page state. When a script modifies the zoom property and then triggers a page change, the original view object may be destroyed while stale pointers are still kept and later dereferenced, which under crafted JavaScript and document structures can lead to a use-after-free condition and potentially allow arbitrary code execution.

The application's list box calculate array logic keeps stale references to page or form objects after they are deleted or re-created, which allows crafted documents to trigger a use-after-free when the calculation runs and can potentially lead to arbitrary code execution.

When the application opens a PDF and JavaScript resets the form fields, the script re-enters the interface. The underlying native object is damaged, but the application does not perform validation. The function call on the damaged object leads to the application crashing.

The application re-enters the document structure via field processing and deletes the current page, and then continues using the field objects obtained before deletion, triggering an illegal read and crashing.

After JavaScript resetting the form, the synchronization process lacks re-entry protection and object lifecycle verification, resulting in the failure of the control pointer during the traversal process. After the pointer fails, it still continues to dereference, causing the application to crash.

The application opened a PDF file containing an abnormal Unity 3D object. During parsing, the application incorrectly resolved a portion of the abnormal object as a pointer and used it as a valid address, ultimately causing the application to crash.

Foxit PDF Editor and Reader before 2025.2.1 allow signature spoofing via OCG. When Optional Content Groups (OCG) are supported, the state property of an OCG is runtime-only and not included in the digital signature computation buffer. An attacker can leverage JavaScript or PDF triggers to dynamically change the visibility of OCG content after signing (Post-Sign), allowing the visual content of a signed PDF to be modified without invalidating the signature. This may result in a mismatch between the signed content and what the signer or verifier sees, undermining the trustworthiness of the digital signature. The fixed versions are 2025.2.1, 14.0.1, and 13.2.1.

The application does not detect or guard against cyclic PDF object references while handling JavaScript in PDF. When pages and annotations are crafted that reference each other in a loop, passing the document to APIs (e.g., SOAP) that perform deep traversal can cause uncontrolled recursion, stack exhaustion, and application crashes.

During the PRC parsing stage, there is a lack of boundary verification for the PRC entity index, which leads to an out-of-bounds read of the entity array. As a result, the application crashes.

The application does not validate the presence of required appearance (AP) data before accessing stamp annotation resources. When a PDF contains a stamp annotation missing its AP entry, the code continues to dereference the associated object without a prior null or validity check, which allows a crafted document to trigger a null pointer dereference and crash the application, resulting in denial of service.

Foxit PDF Editor and Reader before 2025.2.1 allow signature spoofing via triggers. An attacker can embed triggers (e.g., JavaScript) in a PDF document that execute during the signing process. When a signer reviews the document, the content appears normal. However, once the signature is applied, the triggers modify content on other pages or optional content layers without explicit warning. This can cause the signed PDF to differ from what the signer saw, undermining the trustworthiness of the digital signature. The fixed versions are 2025.2.1, 14.0.1, and 13.2.1.