WordPress.org plugin guideline 8 says plugins may not send executable code via third-party systems. In practice, a directory plugin should not install updates, premium versions or other plugins from servers other than WordPress.org's. The rule keeps the update path reviewable, because code that arrives later from elsewhere skips the directory's checks.
What the guideline says
The WordPress developer handbook lists the examples it treats as not allowed when a plugin is not acting as a service:
- Serving updates or installing plugins, themes or add-ons from servers other than WordPress.org's
- Installing premium versions of the same plugin
- Calling third-party CDNs for reasons other than font inclusion, so non-service JavaScript and CSS must be included locally
- Using third-party services to manage regularly updated lists of data when the service's terms do not explicitly permit it
- Using iframes to connect admin pages, because APIs minimize security risks
There is a carve out. Externally loading code from documented services is permitted, as long as communication is as secure as possible. Management services that push software to a site are permitted, provided the service handles the interaction on its own domain and not inside the WordPress dashboard.
Why this is a supply chain rule
Directory review looks at a version of the plugin at a point in time. If that plugin can fetch and run new code from the vendor's server later, the reviewed code is no longer the code running on your site. The vendor's server, and anyone who controls it, becomes part of your site's supply chain.
This is the same risk pattern behind many package incidents: the thing you approved is not the thing that runs next month. See three kinds of open source risk for how this fits with vulnerable and abandoned code.
How to check a plugin
| Signal | What to look for |
|---|---|
| Settings page | A license key box that unlocks code downloads, or a button that installs add-ons from the vendor |
| Network behavior | The plugin calling the vendor's domain for files that end in code, not just data |
| Source | Calls that download a zip and extract it into the plugins folder |
| Scripts | JavaScript or CSS loaded from an external domain on public pages |
| Admin screens | Pages embedded in an iframe from another site |
A legitimate service integration, such as a form tool or an email service, may call out to its API. The difference is whether the response is data or code you will execute.
What to do on your own site
- List plugins and note which have premium tiers or license keys.
- For each, check where updates come from. The WordPress dashboard update screen is the normal path.
- Test a new plugin on a staging copy with outbound traffic logged.
- For critical plugins, read the source or ask for a review from someone who can.
- Remove plugins you do not use. Deactivated code is still code on disk.
Our WordPress hardening checklist covers wider site controls.
What the rule does not guarantee
Guideline 8 applies to plugins in the directory. Plugins bought and installed from elsewhere are outside it, and a plugin that breaks the rule may exist until someone notices. The rules are enforced as fairly as the team can manage, in the guidelines' own words, not as a guarantee. A review on your side is still the safety net.
Safeguard's dependency scanning and SBOM generation cover the packages your own applications ship. For site plugins you do not build, the controls are inventory, staging and update discipline.
Quick check
Can a WordPress plugin call an external API at all?
Yes. The guideline permits documented services, and Software as a Service plugins are allowed. What it restricts is sending executable code via third-party systems.
Does this rule cover plugins bought outside the directory?
No. The guidelines govern the WordPress.org Plugin Directory. Apply your own review to any plugin from another source.
Sources
Last reviewed: 19 October 2026.
