WAF: Skip HTTP rule evaluation when REQUEST_METHOD is absent (fixes CLI cron 403)#49458
WAF: Skip HTTP rule evaluation when REQUEST_METHOD is absent (fixes CLI cron 403)#49458agent-sandbox-automattic[bot] wants to merge 4 commits into
Conversation
Some server-side cron jobs run wp-cron.php via a PHP wrapper (e.g. /usr/bin/php-wrapper) that does not report PHP_SAPI as 'cli'. In those environments there is no HTTP context and REQUEST_METHOD is empty, but the existing PHP_SAPI === 'cli' guard does not fire, so WAF rule 911100 evaluates an empty request method against the allowed-methods list and issues a 403. Extend the early-return guard in Waf_Runner::run() to also bail when $_SERVER['REQUEST_METHOD'] is empty. This covers all non-HTTP execution contexts regardless of the SAPI name. Add a unit test that places a canary rules file in a temp directory and asserts it is never included when REQUEST_METHOD is absent. Co-authored-by: kolja.zuelsdorf <kolja.zuelsdorf@a8c.com> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so: 🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so: Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryCannot generate coverage summary while tests are failing. 🤐 Please fix the tests, or re-run the Code coverage job if it was something being flaky. |
ArSn
left a comment
There was a problem hiding this comment.
Some PHPUnit tests are failing now between PHP 7.4 and 8.1:
[packages/waf] Time: 00:00.989, Memory: 8.00 MB
[packages/waf]
[packages/waf] There was 1 error:
[packages/waf]
[packages/waf] 1) WafRunnerTest::testRunSkipsRulesWhenRequestMethodIsAbsent
[packages/waf] Constant JETPACK_WAF_MODE already defined
[packages/waf]
[packages/waf] /home/runner/work/jetpack/jetpack/projects/packages/waf/tests/php/unit/WafRunnerTest.php:81
[packages/waf]
[packages/waf] ERRORS!
[packages/waf] Tests: 227, Assertions: 857, Errors: 1.
Agent Sandbox PR state — pushedManaged by the Agent Sandbox pipeline — do not edit manually. {
"status": "idle",
"active_run_id": null,
"last_run_outcome": "pushed",
"last_run_at": "2026-06-08T15:12:53Z",
"responded_through_at": "2026-06-08T14:59:43Z",
"revision_count": 3,
"linear_issue_link": null
} |
testDefineModeSetsDefinition defines JETPACK_WAF_MODE in the main PHPUnit process. With preserveGlobalState=true (the default), testRunSkipsRulesWhenRequestMethodIsAbsent's child process inherits that constant, so the explicit define() call in the test body triggers an E_WARNING in PHP 8.1 (was E_NOTICE in 7.4). With failOnWarning=true in phpunit.xml.dist this becomes a test error. Add @preserveGlobalState disabled / #[PreserveGlobalState(false)] so the child process starts with a clean constant slate. Co-authored-by: ArSn Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ArSn
left a comment
There was a problem hiding this comment.
Error: /home/runner/work/jetpack/jetpack/projects/packages/waf/tests/php/unit/WafRunnerTest.php:67:7: error - Expected 1 spaces after opening parenthesis; 0 found (PEAR.Functions.FunctionCallSignature.SpaceAfterOpenBracket)
Error: /home/runner/work/jetpack/jetpack/projects/packages/waf/tests/php/unit/WafRunnerTest.php:67:32: error - Expected 1 spaces before closing parenthesis; 0 found (PEAR.Functions.FunctionCallSignature.SpaceBeforeCloseBracket)
Script phpcs -p -s handling the phpcs:lint event returned with error code 2
Script @phpcs:lint --filter=tools/class-jetpack-phpcs-exclude-filter.php was called via phpcs:lint:required
Error: Process completed with exit code 2.
Co-authored-by: ArSn
ArSn
left a comment
There was a problem hiding this comment.
Now the Protect e2e tests do not work anymore, I am guessing we now need to set the request method in the request if we're using a headless / pseudo browser:
✓ 1 [environment check] › ../../../../../tools/e2e-commons/setup-specs/env-check.setup.ts:33:1 › verify environment readiness @Protect (4.4s)
✓ 2 [global authentication] › ../../../../../tools/e2e-commons/setup-specs/auth.setup.ts:4:1 › authenticate users @Protect (7.9s)
2026-06-08 14:56:00 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:19 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:19 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:28 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:28 error: Page error: "SyntaxError: Unexpected token '<'"
✘ 3 [jetpack protect e2e] › specs/start.test.ts:61:2 › Jetpack Protect Plugin › Jetpack Protect firewall page (39.4s)
2026-06-08 14:56:40 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:53 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:56:53 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:57:00 error: Page error: "SyntaxError: Unexpected token '<'"
2026-06-08 14:57:00 error: Page error: "SyntaxError: Unexpected token '<'"
✘ 4 [jetpack protect e2e] › specs/start.test.ts:61:2 › Jetpack Protect Plugin › Jetpack Protect firewall page (retry #1) (30.9s)
Error: 1) [jetpack protect e2e] › specs/start.test.ts:61:2 › Jetpack Protect Plugin › Jetpack Protect firewall page › Navigate to firewall page
When running in a headless/pseudo-browser context (e.g. server-side cron via a PHP wrapper that does not report PHP_SAPI as 'cli') REQUEST_METHOD may be absent. The previous fix returned early, which skipped WAF rule evaluation entirely and broke the Protect e2e tests. Instead, default REQUEST_METHOD to GET so rule 911100 (which rejects an empty method) does not fire a false-positive 403, while the WAF continues to protect the site. Co-authored-by: ArSn
|
Closing in favor of #49465 |
What
Waf_Runner::run()already skips rule evaluation whenPHP_SAPI === 'cli', but some server-side cron setups runwp-cron.phpvia a PHP wrapper (e.g./usr/bin/php-wrapper) that doesn't report the SAPI as'cli'. In those environments there is still no HTTP context, so$_SERVER['REQUEST_METHOD']is empty — but the existing guard never fires and WAF rule 911100 ("Method is not allowed by policy") evaluates the empty request method against the allowed-methods list and issues a 403.How
Add
|| empty( $_SERVER['REQUEST_METHOD'] )to the existing early-return check inWaf_Runner::run():This is the second form suggested in the issue description. It is more robust than checking
PHP_SAPIalone because it catches all non-HTTP execution contexts regardless of how the PHP binary was invoked.A new unit test (
testRunSkipsRulesWhenRequestMethodIsAbsent) creates a minimal rules file in a temp directory and verifies it is never included whenREQUEST_METHODis absent.Testing
jp test php packages/wafChecklist
projects/packages/waf/changelog/)Linear: PROTECT-174