After the discovery and subsequent fix of a reflected cross-site scripting vulnerability, the focus has been on auditing the codebase to improve the overall security. Thanks to the help of the WordPress.org Plugins Team, we were able to identify a vulnerability in the Core Font Installer, and refactor a number of areas in the codebase that had a bad smell. To put it in simple terms, we rewrote a bunch of legacy code to follow the latest best practices, included additional checks and balances, updated third-party software, and fixed a few bugs, too. Gravity PDF 6.4 is the culmination of this work.
tl;dr A vulnerability in the Core Font installer has the potential for a remote code execution attack (RCE) under very specific conditions. Other security-related changes were made to reduce the potential of any unknown vulnerabilities that could be exploited. For developers, there are changes in functionality you should be aware of.
Core Font Installer
Let’s start with the elephant in the room: the Core Font installer vulnerability. Without going into too many specifics, for the vulnerability to be exploited on a typical WordPress installation an attacker would need direct access to a compromised user with the administrator role and a non-standard directory structure needs to exist on the server. The likelihood of this occurring is low, but if it did, a bad actor could successfully execute an RCE attack, and that puts this vulnerability in the medium severity category. This vulnerability is present in Gravity PDF 5.0 – 6.3.1.
Allowed Core Template HTML
In this release, all HTML generated in Core and Universal PDF templates are sanitized with the help of a modified version of wp_kses_post(), which includes support for PDF-specific tags and styles. This change doesn’t affect the standard Gravity Forms field output in your PDFs, but if you are doing any weird and wonderful things with Custom Content you may need to tweak your HTML mark-up.
To bring Gravity PDF in line with Gravity Forms capabilities, a user will need the
gravityforms_edit_forms capability to manage PDFs on a form, which includes adding, editing, and deleting PDFs. Previously the
gravityforms_edit_settings capability was used. The Font Manager capability was also adjusted to
This change will only affect websites that use custom roles to restrict user access to specific Gravity Forms features.
PDF Engine Update
This release saw most Gravity PDF dependencies get updated to the latest version, including the mPDF library which is responsible for turning HTML into PDFs. The mPDF update includes a change in how images are processed which caused some display problems for the Tritan and Aryal templates. This was on our radar early in the development process and we release an update for both templates at the start of this month.
Functionality Changes for Developers
In the past, we had no hard restrictions on the filename that could be used for a PDF template, and developers were free to use any valid string supported by the filesystem. However, if taking advantage of the template configuration file, the config class name needed to be valid PHP and follow our naming conversion which meant no special characters.
To prevent any confusion and increase reliability, we have added restrictions on the template filename. It must now only contain the following: A-Z, a-z, 0-9, underscore (_) or dash (-), followed by the .php extension. Existing templates created for v4 or higher that don’t follow this naming convention will remain functional (with the exception of deleting templates via the PDF Template Manager), but aren’t guaranteed to in future versions.
To prevent any problems moving forward, we recommend developers update template names to follow the new convention.
The template name helper parameter is a quick and easy way for administrators to swap between PDF templates. From 6.4, this input must only contain: A-Z, a-z, 0-9, underscore (_) or dash (-). This change also affects legacy templates (v3) which haven’t been officially supported since 2017.
Data and HTML
- Move from early escaping to late escaping variables on output
- Add additional validation checks to the Core Font installer
- Escape text returned from WordPress l10n functions
- Escape any and all strings from the Gravity Forms form object, in any context (including PDFs)
- Move to earlier sanitizing of user input
- Custom PDF template filenames are now limited to the following characters:
?data=1developer helper parameters now only work in non-production environments (
WP_ENVIRONMENT_TYPE !== 'production'), or when Gravity PDF Debug Mode is explicitly enabled
- Prevent directory traversal when loading the various Gravity PDF UI components
- Change PDF Form Settings capability check from
- Change Font Manager CRUD capability check from
- Switch to
sodium_crypto_secretbox_keygen()function with modified fallback to
wp_generate_password()when generating new PDF URL signing secret key
- Switch from a Text to Password field for the Gravity PDF License Keys
- Added “Get more info” link in the Core Font Installer instructions, and disclaimer to plugin’s README.txt installation section
\GFPDF\Statics\Kses::parse($html)methods for use with escaping/sanitizing HTML in PDFs (as an alternative to
- Fix issue passing PDF URL to Gravity Forms Mailchimp add-on
- Allow hyphen in custom font key when updating or deleting to remain backwards compatible
- Fix PHP8.1 type conversion warning in the template cache when transient’s are flushed
- Remove empty repeater sections from Core PDFs when not filled in by the user