Why plugin update security matters
Two recent incidents show how WordPress supply chain security can fail. In June 2026, BleepingComputer reported on 18 June that tampered Pro builds of three ShapedPlugin plugins had reached paying customers through the vendor's own update channel (CVE-2026-10735). In July 2025, BleepingComputer reported on 11 July that manual downloads of Gravity Forms had been backdoored; the vendor said its auto-update service was not compromised.
Both show that an update is only as trustworthy as every step between the vendor's build and your server. Most sites install whatever arrives, without asking where it came from. WP SecureGate assumes its own update channel will be attacked, so it checks every update to itself before installing it.
Secure WordPress plugin updates: seven checks before install
WP SecureGate refuses an update unless every one of these passes:
- TLS certificate verification on the connection to the update server;
- an Ed25519 public key compiled into the plugin, which no filter or setting can replace;
- an Ed25519 signature over the exact bytes of the update manifest, checked before the manifest is even parsed (if the server lacks libsodium, updates are refused rather than installed unchecked);
- manifest freshness: at most 30 days old and no more than 1 day in the future, so an old signed manifest can't be replayed;
- a host allowlist, exact host plus https, checked on the manifest and again at download;
- a SHA-384 digest of the package, compared in constant time, with the downloaded file deleted if it doesn't match;
- anti-downgrade: the version must be newer than the one installed, so nobody can push you back to an older release.
Always on. These checks can't be switched off.
Smaller checks around the edges
The manifest must carry its required fields and a valid version number, and it is capped at 64 KB. A fresh manifest is fetched again at download time rather than trusting a cached copy. The new version also has to meet its own PHP and WordPress requirements before it is offered.
What signing protects against, and what it doesn't
Signing is how you verify WordPress plugin updates without trusting the network or the download server. If someone swaps the package on a server, or alters it in transit, the digest no longer matches the signed manifest and the update is refused. A manifest past its 30-day window is refused, and an old release can't be passed off as a new one.
Signing does not protect against a vendor whose own build was compromised before signing. In that case the tampered package gets a valid signature like any other release. That is why we don't claim signing would have stopped the ShapedPlugin incident. It proves a package is the one the vendor signed; it can't prove the vendor's build was clean.
Auto-updates are a one-click opt-in
WP SecureGate does not turn on automatic updates for itself. Until you do, the plugin shows a banner with a one-click button to switch them on. An update you start yourself from the Plugins or Updates screen goes through the same checks.
Off by default. The banner offers a one-click turn-on.
Releases that arrive at once
WordPress checks for plugin updates on its own schedule, which can leave a fix waiting for hours. So when a release ships, wpsecuregate.com sends sites a signed notice, and a site with auto-updates on fetches the fix straight away. This is a vendor-side push, not a button you press.
The notice carries no code and no download link. It only tells the site that a new version exists; the site then fetches it the ordinary way, through the signed manifest and the digest check. A forged notice could at worst make a site check for an update early.
Part of WP SecureGate: the all-in-one WordPress security plugin →