Manager (by ROBOTSTXT) WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+ git.robotstxt.es

High-severity findings.

Audited release

1.9.1

Findings

3

Worst severity

high

Content hash

5f2b3659bf59dd709a561aa1… Copy

Findings

• high Catalog slug collision is injected as a native plugin update

  rce

  After activation the store URL defaults to https://www.robotstxt.software, so inject_updates() runs for every read of the update_plugins transient with no extra settings. It maps every installed plugin by directory slug onto the remote catalog and, when the catalog version is higher, writes a store package into update_plugins->response. The only refusal is when that response slot is already occupied by a package whose host is not the store; an up-to-date WordPress.org plugin has an empty response slot and is therefore claimed. Update URI is never consulted, even though this plugin sets one itself. WordPress then offers the store ZIP on the Plugins and Updates screens, to WP-CLI, and to auto-updates. Plugin_Upgrader downloads {store}/wp-json/robotstxt-core/v1/plugins/{slug}/download and, for an active plugin, reactivates whatever PHP the store returns. A catalog entry whose slug collides with an unrelated plugin (benign naming clash or a compromised store) replaces that plugin without anyone using Manager's Install button. Free entries do not need an API key. A subscriber cannot trigger this; the actor is the configured store.

  includes/class-robotstxt-manager-updater.php:92-137

  Recommendation

  Inject an update only for plugins this Manager install actually installed, or whose Update URI host equals the configured store host. Do not claim a response slot that WordPress.org left empty just because the directory slug matches a catalog row. Ignore catalog rows that fail that provenance check before version_compare.

• medium Long-lived API key is placed in the update package URL and persisted in the transient

  information_disclosure

  Premium package URLs prefer a short-lived download token, but if POST /me/download-token fails the decrypted account API key is appended as the api_key query argument. That object is returned from the site_transient_update_plugins filter. Core wp_update_plugins() reads the filtered transient and immediately set_site_transient()s it, then returns without restoring a clean copy when api.wordpress.org errors — the host class this plugin documents as common. The long-lived key, which the settings screen otherwise encrypts with AES-256-CBC, then sits in plaintext in the update_plugins site transient (options or sitemeta) and is sent on the download query string, so it is copied into store access logs, backup dumps, and any redirect target. A subscriber cannot call this path; anyone who can read the transient or those logs gets the store bearer credential. The same URL shape also stores the shorter-lived download token on the happy path.

  includes/class-robotstxt-manager-updater.php:447-462

  Recommendation

  Never put the account API key in a package URL or in the update transient. If the token exchange fails, omit the premium package so WordPress does not advertise an update, and keep retrying the token endpoint from the upgrader download filter instead of persisting a credential. Prefer an Authorization header on a custom upgrader HTTP filter over a query argument.

• medium Free-plugin install fetches catalog download_url with no host allowlist

  ssrf

  handle_install() is limited to manage_options / manage_network_options plus a nonce, so a subscriber cannot open it. When an administrator does click Install, a catalog row whose type is not premium and whose download_url is non-empty is passed straight to wp_remote_get and, if the file starts with PK, to Plugin_Upgrader::install. There is no allowlist against the configured store host, no wp_http_validate_url / reject_unsafe_urls call, and no checksum. A catalog download_url of an internal or link-local HTTP URL is a blind server-side request; a URL that returns a ZIP is unpacked into wp-content/plugins. The same path runs for requires_plugins dependencies that resolve to a catalog row, without a second confirmation. The store download endpoint is skipped whenever that public URL is present, including cleartext http URLs that a network attacker can swap. The new plugin is left inactive, but its PHP is on disk under the plugins directory.

  admin/class-robotstxt-manager-installer.php:535-565

  Recommendation

  Download free plugins only from the configured store host over HTTPS, or from an explicit allowlist. Reject download_url values that fail wp_http_validate_url, and pass reject_unsafe_urls. Require a catalog checksum and refuse the ZIP when the installed directory slug does not match the requested slug.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.