Problem
The recovery-code generation REST endpoint does not reject a nonexistent user_id before passing false into provider logic. An authenticated administrator can trigger code generation and warnings for user ID 0; enabling the provider reaches a database failure and returns HTTP 500 instead of a bounded 4xx error.
Minimized reproductions
POST /wp-json/two-factor/1.0/generate-backup-codes
Observed result: HTTP 200 with ten plaintext generated codes plus PHP warnings from providers/class-two-factor-backup-codes.php around lines 332 and 400.
{"user_id":0,"enable_provider":true}Observed result: HTTP 500 db_error.
Expected
The route should resolve and validate the target user before provider logic or mutations. Missing users should return a stable 404/400 REST error, produce no codes, emit no warnings, and leave all provider state unchanged.
Fuzz evidence
Found during an isolated deterministic multisite REST campaign against #935:
- Seed:
935202607
- 10,000 malformed/schema cases
- 2,000 provider transition sequences
- 14,044 REST operations
- WordPress 6.9, PHP 8.4.21, Two Factor 0.16.0
user_id=0 cases reproduced deterministically; 14 occurrences generated 28 warnings.
The campaign found no provider-settings/TOTP permission bypass, secret leakage, invariant failure, replay acceptance, or invalid-state mutation.
Problem
The recovery-code generation REST endpoint does not reject a nonexistent
user_idbefore passingfalseinto provider logic. An authenticated administrator can trigger code generation and warnings for user ID0; enabling the provider reaches a database failure and returns HTTP 500 instead of a bounded 4xx error.Minimized reproductions
POST /wp-json/two-factor/1.0/generate-backup-codes{"user_id":0}Observed result: HTTP 200 with ten plaintext generated codes plus PHP warnings from
providers/class-two-factor-backup-codes.phparound lines 332 and 400.{"user_id":0,"enable_provider":true}Observed result: HTTP 500
db_error.Expected
The route should resolve and validate the target user before provider logic or mutations. Missing users should return a stable 404/400 REST error, produce no codes, emit no warnings, and leave all provider state unchanged.
Fuzz evidence
Found during an isolated deterministic multisite REST campaign against #935:
935202607user_id=0cases reproduced deterministically; 14 occurrences generated 28 warnings.The campaign found no provider-settings/TOTP permission bypass, secret leakage, invariant failure, replay acceptance, or invalid-state mutation.