Opened 4 weeks ago
Last modified 4 days ago
#65680 new defect (bug)
Permission Check Mismatch Due to Unnormalized Ability Input
| Reported by: | utsav72640 | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | REST API | Version: | 6.9 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | rest-api |
Description
While reviewing the WP_REST_Abilities_V1_Run_Controller code, I noticed that the request input is handled differently during the permission check and the actual execution.
The check_ability_permissions() method normalizes the input before validating it and checking permissions. However, execute_ability() reads the request input again and passes it directly to execute() without normalizing it first.
Because of this, both methods can end up working with different input values.
For example, if an ability has default values defined in its input schema and the request does not include any input, the permission check uses the normalized default values, while execute() receives null.
I believe both permission checking and execution should use the same normalized input to ensure consistent behavior and avoid unexpected issues during execution.
Attachments (2)
Change History (4)
#1
@
4 days ago
- Milestone Awaiting Review → 6.9
Thanks for the report. As far as I could research, the current behavior should have been occurring since version 6.9 when the Abilities API was introduced.
However, execute_ability() reads the request input again and passes it directly to execute() without normalizing it first.
I don't think this is accurate. While it's true that the REST controller doesn't normalize input values before executing, the WP_Ability class normalizes them here.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
wp-includes\rest-api\endpoints\class-wp-rest-abilities-v1-run-controller.php