Gecko [ www.prositehelp.com ]

Name	Size	Permission	Date
app	[ DIR ]	drwxr-xr-x	2026-06-29 17:13
vendor	[ DIR ]	drwxr-xr-x	2026-06-29 17:13
LICENSE	1.04 KB	-rw-r--r--	2026-06-29 17:13
bootstrap.php	913 B	-rw-r--r--	2026-06-29 17:13
changelog.md	2.78 KB	-rw-r--r--	2026-06-29 17:13
composer.json	584 B	-rw-r--r--	2026-06-29 17:13
composer.lock	11.05 KB	-rw-r--r--	2026-06-29 17:13
readme.md	6.22 KB	-rw-r--r--	2026-06-29 17:13

Rename

# WP Registry — Host Version

A WP-CLI command that checks WordPress sites against [WP Registry](https://wpregistry.io), a public database of hashed WordPress plugins, themes, and files.

This version is built for **hosts and shared servers**: install it once on a server and run it against any WordPress site via `wp --path=/var/www/site registry ...`. No plugin is added to customer sites.

## How it works

1. Hashes installed plugins, themes, and loose PHP files locally.
2. Looks up only those hashes against the registry and reports each one: `clean`, `low`, `medium`, `high`, `critical`, `malware`, `update`, `in queue`, or `unaudited`.
3. If a copy has been modified, the hash will not match a known build and the component is reported as `unaudited` rather than falsely marked clean.
4. Anything still `unaudited` can be uploaded for review with `wp registry upload`.

Only content hashes leave the server for a check — sent as short, shared prefixes. No file contents, site URL, or user data. Uploading a build sends that one build's code for review.

## Install

Build or copy the artifact to the server. The artifact is a plain directory; no GitHub, Packagist, or WordPress.org is required.

```bash
# On your build machine
./build.sh

# Copy to each managed server
rsync -av build/wp-registry-cli/ host:/opt/wp-registry-cli/
```

Then make WP-CLI load it. The recommended way is a global `require:` in `/etc/wp-cli.yml`:

```yaml
require: /opt/wp-registry-cli/bootstrap.php
```

Or use it per-command:

```bash
wp --require=/opt/wp-registry-cli/bootstrap.php --path=/var/www/site registry check
```

## Usage

All commands support `--path=/var/www/site` to target a specific WordPress installation.

### Survey a site

```bash
wp --path=/var/www/site registry check
```

```
Plugins (12)
  Name                Hash          Audit
⚠ flavor-jenga       a1b2c3d4e5f6  critical
⚠ jenga-toolkit      f6e5d4c3b2a1  high
✓ akismet            1234567890ab  clean
✓ contact-form-7     ba0987654321  clean
↑ jenga-pro          9a8b7c6d5e4f  update
… jenga-blocks       1f2e3d4c5b6a  in queue
? jenga-starter      0f0e0d0c0b0a  unaudited

Scanned 12 components in 3s: 2 vulnerable, 7 clean, 1 update, 1 in queue, 1 unaudited
WP Registry: 75% coverage (9/12 audited)
```

### Filter by type

```bash
wp --path=/var/www/site registry check --type=plugins
wp --path=/var/www/site registry check --type=themes
wp --path=/var/www/site registry check --type=files
```

### Append each component's key issue

```bash
wp --path=/var/www/site registry check --details
```

### Machine-readable output

```bash
wp --path=/var/www/site registry check --format=json
```

### Inspect one component

```bash
wp --path=/var/www/site registry show elementor-pro
wp --path=/var/www/site registry show twentytwentyfive --type=theme
wp --path=/var/www/site registry show elementor-pro --format=json
```

### Apply security patches

```bash
wp --path=/var/www/site registry update           # apply available patches
wp --path=/var/www/site registry update --dry-run # preview without changes
```

### Upload unaudited components for review

```bash
wp --path=/var/www/site registry upload                       # upload all eligible
wp --path=/var/www/site registry upload plugin/jenga-starter  # upload one component
wp --path=/var/www/site registry upload --dry-run             # preview
```

## Statuses

| Status      | Meaning                                              |
|-------------|------------------------------------------------------|
| `clean`     | Audited, no issues found                             |
| `low`       | Minor issues, informational                          |
| `medium`    | Meaningful issues (e.g. abandoned, weak practices)   |
| `high`      | Significant vulnerability                            |
| `critical`  | Immediately exploitable or actively dangerous        |
| `malware`   | Confirmed malicious code                             |
| `update`    | Not audited at this build, and a newer version is available — update rather than upload |
| `in queue`  | Uploaded and awaiting audit                          |
| `unaudited` | Not in the registry, on the latest version — upload it for review |

## Why hash-based?

The tool computes a SHA-256 of the actual files on disk. The version string in a plugin header can be forged or out-of-date; the hash cannot.

- **Modified code is flagged.** If malware was injected into a plugin on the server, the hash will not match any known-clean build. The component is reported `unaudited` rather than falsely marked clean.
- **Identical code is deduplicated.** A plugin audited on one site automatically covers every other site running the same build.
- **Premium plugins work too.** Plugins not on WordPress.org can still be checked, as long as the same build has been audited somewhere.

## Public API

Everything the tool talks to is public at `https://wpregistry.io`.

| Endpoint | Used by | Description |
|---|---|---|
| `/hashes/<prefix>.json` | `check` | Audited and queued hashes for a short prefix. |
| `/upload?slug=&version=&type=&hash=` | `upload` | POST a plugin/theme zip to the audit queue. |
| `/manifest.json` | `update` | Available patches for vulnerable components. |

## Privacy

A `check` sends only short **prefixes** of content hashes. The registry returns every audited hash sharing each prefix and the match happens locally, so the registry never learns exact hashes — and never sees the site URL, file contents, or user data.

`upload` is the deliberate exception: it sends the build's zip along with slug, version, and hash. `update` only downloads the public patch manifest.

Hashes are one-way; code cannot be reconstructed from them.

## Notes for hosts

- **No customer-site plugin files are added.** The command is loaded from `/opt/wp-registry-cli/` (or wherever you place it) via WP-CLI.
- **WordPress update transients may be refreshed.** `check` and `upload` call WordPress's own `wp_update_plugins()` / `wp_update_themes()`, which refreshes the standard `update_plugins` and `update_themes` transients. This is the same behavior as running `wp plugin list`.
- **Outbound HTTPS required.** The server must reach `https://wpregistry.io`.
- **Updates are deployed by replacing the directory.** There is no in-site auto-updater.

## License

MIT