Disembark WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+ #8 in Updates & Deployment

High-severity findings.

Audited release

2.8.0

Findings

3

Worst severity

high

Content hash

7cdc817b879857dfbb64dc8d… Copy

Findings

• high Unauthenticated download of database dumps and restore tokens from uploads/disembark/

  information_disclosure

  Backup::construct writes session dirs at wp_upload_dir()/disembark/{token} with mkdir(..., 0777, true) and exposes them via baseurl. database_export/database_export_batch write full table dumps as .sql.txt specifically to bypass host blocks on .sql downloads, then return the public URL; zip_file_list/zip_files do the same for archives; finalize_manifest publishes files-*.json listing every site path. No index.php or .htaccess is created in the parent or session directories, so directory listing (common on Apache without Options -Indexes) reveals 12-hex session ids and _import_* folders. Those dumps include wp_options.disembark_token. Pull::connect additionally writes source_url and the source site's live token to uploads/disembark/_import_{id}/pull.json; Pull::cleanup_pull_state() exists but is never called, and Import::finalize() only deletes staging/, intentionally retaining rollback/*.sql.txt (another full DB dump) under the same web-accessible tree. An unauthenticated client who lists the directory or obtains a leaked session URL can recover the token and call /file/save or /import/sql for RCE on this site, and the source token for a second site after a pull restore.

  app/Backup.php:13-30

  Recommendation

  Serve backup/restore artifacts only through the authenticated REST stream (stream_file already exists). Add an empty index.php and an Apache/Nginx deny rule for wp-content/uploads/disembark/. Do not use world-writable 0777. Hash session ids at 128+ bits. Stop using .sql.txt to evade host download blocks. Call Pull::cleanup_pull_state() from finalize() (and on failure) so source tokens are not left on disk; store pull.json outside the web root. Encrypt or auth-gate rollback dumps.

• medium Authenticated path traversal in zip_file_list archives files outside the web root

  file_access

  POST /disembark/v1/zip-sync-files (after User::allowed) forwards the caller-supplied files[].name list to Backup::zip_file_list. Each name is concatenated onto dirname(WP_CONTENT_DIR) or ABSPATH and passed to ZipArchive::addFile / PclZip with only file_exists+is_readable — no realpath() and no path_within() check. stream_file, save_file, and rename_file in the same class of handlers already resolve realpath and reject paths outside the web/core roots, so this is an inconsistent hole. A manage_options user or token holder can zip ../../../../etc/passwd, sibling-site wp-config.php on shared hosting, or other files outside the WordPress tree; the resulting zip is then written to the public uploads/disembark/{session}/ URL and downloaded without further auth. zip_files() (manifest-based) has the same concatenation pattern if a poisoned manifest chunk is used.

  app/Backup.php:653-665

  Recommendation

  Reuse the realpath + path_within() logic from stream_file/save_file before addFile. Reject names containing .., leading slashes, or NUL. Resolve the path and require it to stay under the web root or core root. Do not return a public URL for the zip; stream it through the authenticated endpoint.

• medium Full-access site token sent in GET query strings on REST and pull probes

  information_disclosure

  disembark_token is a 42-character secret that User::allowed() and allow_token_auth treat as equivalent to manage_options (file write, arbitrary SQL import, full DB read). The dashboard still sends it as axios GET params on /database, /backup-size, /manifest, and /cleanup (template.php), and allow_token_auth reads $_REQUEST['token'] so query-string auth works. Pull::connect probes the source with /wp-json/disembark/v1/database?token= plus the rest_route form, putting the source site's live token in that site's access logs, reverse-proxy logs, and any Referer. v2.1.0 already moved /stream-file from GET to POST specifically to keep the token out of URLs; the remaining GET routes were not converted. Anyone who can read those logs (shared hosting, log aggregators, a later XSS) can replay the token against POST /file/save or /import/sql. /cleanup is also a state-changing GET.

  app/Run.php:52-64

  Recommendation

  Accept the token only from POST JSON bodies or an Authorization header, never $_GET/$_REQUEST. Convert remaining GET routes (database, backup-size, manifest, cleanup, database/rows, database/schema) to POST. Change Pull::connect probes to POST. Prefer cookie+nonce / application passwords on the dashboard (already the primary path) and stop attaching token as a query param in template.php.

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.