fix: validate Content ID charset to block API path/query injection

[galbus]

Summary

Fixes an authenticated API path/query injection via an unvalidated Content ID. A WordPress user with edit_post (author, or contributor on their own draft) could store a crafted beyondwords_content_id and steer authenticated, organization-API-key-scoped requests to arbitrary BeyondWords API endpoints.

The vulnerability

beyondwords_content_id was persisted with only sanitize_text_field(), which permits /, ., ?, # and &. That value was later read back verbatim and interpolated unencoded into API URL paths:

sprintf( '%s/projects/%d/content/%s', $api_url, $project_id, $content_id )

in Client::get_content(), update_audio() and delete_audio(). Because Client::filter_http_request_args() attaches the org X-Api-Key header to any outbound URL that starts with the API base — and path-suffix manipulation preserves that prefix — a value such as:

x/../../projects/999/content/abc?force=1

resolves (after cURL dot-segment normalization) to an attacker-chosen endpoint under the API host, with the org key attached, letting an author-level user read/update/delete content in other projects of the organization. Both write paths were affected: the classic-editor metabox (ContentId::save()) and the block-editor/REST meta write (Sync::register_meta(), sanitize_callback => sanitize_text_field). The plugin's own inspect REST route already documented the intended charset as [a-zA-Z0-9\-]+.

What changed

Defense at three layers (per the advisory):

1. New shared validator — Meta::sanitize_content_id(): sanitize_text_field() + a strict ^[a-zA-Z0-9-]*$ gate (the same charset the inspect REST route enforces), blanking anything else.
2. Both write paths routed through it — ContentId::save() (classic editor) and the beyondwords_content_id sanitize_callback in Sync::register_meta() (block editor / REST). Only that one meta key gets the strict callback; others keep sanitize_text_field.
3. Defense-in-depth at the sink — rawurlencode( (string) $content_id ) at the three Client URL builders. Transparent for legitimate IDs (numeric / UUID), so no behavior change for valid callers. (batch_delete already sends IDs in a JSON body, not a URL path — unchanged.)

Follows WordPress-VIP standards — input is unslashed + sanitized, and no phpcs:ignore was added.

Reviewer notes

• The register_meta sanitize_callback applies globally, so the strict gate takes effect on every beyondwords_content_id write (including update_post_meta), not just REST. API-issued IDs (UUIDs/numeric) pass through unchanged.
• Three pre-existing tests needed small adjustments for the now-stricter meta contract, documented inline:
  • The stored-XSS renderer test now raw-writes its payload to the DB (bypassing the sanitizer) so it still exercises the renderer's output-escaping — that second line of defense is preserved.
  • Two placeholder Content IDs containing underscores ('beyondwords_content_id', 'test_value') were changed to charset-valid values.

Testing

• phpcs (full WordPress-VIP-Go scope): clean (exit 0).
• Full PHPUnit suite: OK — 662 tests, 2079 assertions, 0 failures. Ran the whole suite (not just changed files) because the register_meta callback registers globally.
• New tests: sanitize_content_id unit provider; ContentId::save injection cases; a Sync test proving update_post_meta blanks a crafted ID end-to-end; a Client test asserting the URL is %2F/%3F-encoded.
• Per project guidance, the full Cypress suite was not run.

🤖 Generated with Claude Code

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check