GravityKit products now give you a stronger reason to trust what you install

When you install a plugin, you implicitly trust that the code arriving on your site is the code the vendor intended to ship. WordPress doesn’t verify that—it downloads the package, unpacks it over your existing files, and moves on.

As of April 2026, all GravityKit product installs, updates, and downgrades are now cryptographically verified before WordPress unpacks them. If a package has been changed anywhere along the way, the installation is blocked. The check happens quietly in the background, requires no configuration, and adds another layer of protection between our release process and your website.

Keep reading to learn why we added the new safeguard, how it works, limitations and what’s coming next.

The update path itself has become a target

Keeping software up to date is still one of the best things a site owner can do. But updates only help if the package that reaches your site is the package the vendor actually released. Recent supply-chain incidents have shown that this is no longer a safe assumption. Three from the past few months alone:

• In April 2026, Smart Slider 3 Pro customers received a trojanized build through the vendor’s official update channel after its infrastructure was compromised. Roughly 900,000 paying Pro sites were exposed; the free WordPress.org edition was untouched.
• In March 2026, WowShipping Pro was compromised at the source, with the paid edition shipping malicious code that captured admin logins and exfiltrated 2FA secrets—including from the very 2FA plugins customers had installed to defend themselves.
• Outside of WordPress, in March 2026, a malicious release of Axios—one of the most widely used open-source JavaScript libraries in the world—added a fake dependency that ran during install and downloaded a second-stage remote-access payload.

Each followed the same pattern: malicious code arriving through the vendor’s own update channel, a channel customers had every reason to trust. As Hedgehog Security wrote of the Smart Slider customers, they “did exactly the right thing by keeping their plugins up to date”, and yet were punished for good hygiene because the supply chain was compromised upstream.

What we did about it

Every GravityKit package now leaves our store with a cryptographic signature attached. Think of it like a tamper-evident seal: the signature belongs to that exact package, and only that package. If the file changes after we sign it (even by a single byte), the signature no longer matches, and the install is refused.

This is not a novel idea. For example, WordPress core already uses package signing for its own updates. But that does not apply to products distributed through WordPress.org or other channels. Before starting this work, we reviewed what other vendors were doing, and to the best of our knowledge, none of them currently ship signed releases with install-time verification as part of their normal update flow (if you know of one that does, we’d love to hear about it!). We chose to close that gap by rolling out a solution that’s based on industry best practices and tightly integrated with WordPress’s own update flow.

Somebody had to put a signature on a paid WordPress plugin. We’re surprised it took until 2026 for it to happen

Vlad K., Head of Development, GravityKit

The cryptography behind it is conventional too. We use Ed25519, the same digital-signature standard built into SSH (the protocol every server admin uses to connect to a remote machine), TLS 1.3 (the encryption layer behind modern HTTPS), and most current code-signing systems. It is robust, well-understood, and fast enough that the verification step adds no perceptible delay to an update.

Verification happens before WordPress has finished pulling the file onto disk, and it’s handled by Foundation (the shared library that ships with every GravityKit product to handle licensing, settings, and product infrastructure). Foundation hooks into the update flow at the earliest point it can, downloads the package to a temporary location, recomputes the file’s fingerprint, and compares it to the signature we issued. If anything is off, the temp file is deleted and the install never starts. Nothing unpacks, nothing overwrites your existing plugin. A clean update looks exactly like it always did; a tampered one is refused before it can do any harm.

We started with GravityView 2.57 on April 16, 2026, and the rollout is now reaching the rest of our product line. You don’t have to wait for every product to update individually for the protection to apply, though. When you have several GravityKit products on a site, the newest copy of Foundation becomes the active one—so the moment any single product updates to a build with the new signing layer, Foundation starts verifying every future GravityKit update on that site, not just the one you updated. One update brings the whole installation up to the new protection level.

We also planned for the day a signing key is ever compromised. There is a separate, independently signed revocation list that Foundation checks on a regular basis. If we ever need to invalidate a release, we can do it relatively fast and without shipping a new version of Foundation. A hostile network can’t quietly remove a revocation, because it can’t forge the signature on the list.

Most importantly: there’s nothing to configure on your side. No new setting, no checkbox in your dashboard. You update our products the way you always have, and Foundation handles verification automatically.

What signing doesn’t fix

Signing closes the door between our build server and your filesystem—the door, per the incidents at the top of this post, that attackers have actually been walking through. There are other doors signing doesn’t close, and they need their own defenses: source-code compromises that happen before we sign, post-install tampering on a server that has already been breached, and weaknesses elsewhere in the WordPress ecosystem. For the post-install half of that problem in particular, file-integrity scanners like Wordfence, Sucuri, or Solid Security are the right tools, and worth running on any production WordPress site.

Beyond that, the usual baseline still matters: two-factor authentication (2FA) on your WordPress and GravityKit accounts, backups you trust, strong admin passwords, removing administrators who no longer need access, being selective about any third-party code you run, and patching when updates ship. The Smart Slider story is an argument for more aggressive patching, not less, because the right response to “good hygiene can be punished” is better vendor signing, not worse hygiene.

What’s next

Code signing isn’t the finish line. It is a layer we shipped because the channel between our build pipeline and your site was the one weakness we could harden ourselves, on a timescale we control. Beyond this change, we’re working on other hardening steps (most of them invisible to customers) and watching the broader ecosystem. If WordPress core, the FAIR protocol, or any shared signing model emerges that fits plugin distribution outside WordPress.org, we would rather build on common infrastructure than maintain our own verifier forever.

Until then, this is the part of the supply chain we control, and we’ll keep hardening it. GravityKit customers already trust us every time they update, and this added safeguard just makes that trust a little less implicit and a lot more verifiable. We hope other plugin vendors ship the same.

Want the architecture details—how verification slots into WordPress’s update flow, how we manage and rotate signing keys, and what the model deliberately doesn’t try to solve? Read the technical overview.

Have questions about the new verification flow? Reach out to support.