WordPress Coding Standards versions 0.14.1 through 3.4.0 contain a high-severity command execution issue in `WordPress.WP.EnqueuedResourceParameters`. Scanning attacker-controlled PHP with the affected sniff can run code in the environment where PHPCS executes.
Use this immediately for plugin and theme teams, agencies, CI maintainers, code-review services, marketplaces, and any workflow that scans pull requests, uploads, customer archives, or other untrusted PHP.
Quick answer
Update `wp-coding-standards/wpcs` to 3.4.1 or later, regenerate the Composer lock, and verify the resolved package version in every CI image and developer environment. Until that is complete, do not scan untrusted PHP with the affected sniff. If temporary exclusion is required, confirm the active ruleset with `phpcs -e`, then review CI logs and credential exposure for past untrusted runs.
What to check first
- Search `composer.lock`, global Composer installations, containers, cached vendor directories, CI artifacts, and reusable workflows for WPCS versions from 0.14.1 through 3.4.0.
- Run `phpcs -i` and `phpcs -e` in the exact job environment to confirm installed standards and whether `WordPress.WP.EnqueuedResourceParameters` is active.
- Identify workflows that scan forks, uploaded archives, marketplace submissions, client code, or branches an untrusted contributor can modify.
- Record job permissions, secrets, cloud credentials, package tokens, cache write access, self-hosted runner access, and network reachability for every exposed workflow.
- Update WPCS and required PHPCSUtils and PHPCSExtra constraints, rebuild immutable images, clear stale caches, and rerun safe fixtures.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every WPCS installation | Search `composer.lock`, global Composer installations, containers, cached vendor directories, CI artifacts, and reusable workflows for WPCS versions from 0.14.1 through 3.4.0. | Composer, containers, and CI logs all report WPCS 3.4.1 or later. |
| Stop risky untrusted scans | Run `phpcs -i` and `phpcs -e` in the exact job environment to confirm installed standards and whether `WordPress.WP.EnqueuedResourceParameters` is active. | The intended WordPress ruleset loads with compatible dependency versions. |
| Update and rebuild dependencies | Identify workflows that scan forks, uploaded archives, marketplace submissions, client code, or branches an untrusted contributor can modify. | Untrusted fixtures cannot access secrets, write trusted caches, or modify protected resources. |
| Verify the active sniff list | Record job permissions, secrets, cloud credentials, package tokens, cache write access, self-hosted runner access, and network reachability for every exposed workflow. | Any potentially exposed credential has been reviewed, rotated where needed, and documented. |
Why this usually happens
- The affected sniff used evaluation while analyzing code parameters.
- Development dependencies still execute with the permissions of their runner.
- Composer locks and container layers can keep a vulnerable version after source constraints change.
- Pull request automation often processes code before a human review.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
composer show wp-coding-standards/wpcs --locked
vendor/bin/phpcs -i
vendor/bin/phpcs -e | grep EnqueuedResourceParameters
composer require --dev wp-coding-standards/wpcs:^3.4.1 --with-all-dependencies
composer audit
# Rebuild CI images and clear dependency caches after updating.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory every WPCS installation
- Stop risky untrusted scans
- Update and rebuild dependencies
- Verify the active sniff list
- Audit exposed runs and credentials
Decision rule
Close the update only when every executing environment resolves WPCS 3.4.1 or later, stale artifacts are gone, untrusted scans run with least privilege, and any past exposure has an owned security review.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Composer, containers, and CI logs all report WPCS 3.4.1 or later.
- The intended WordPress ruleset loads with compatible dependency versions.
- Untrusted fixtures cannot access secrets, write trusted caches, or modify protected resources.
- Any potentially exposed credential has been reviewed, rotated where needed, and documented.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Are WordPress-Core and WordPress-Docs rulesets affected?
The advisory says the vulnerable sniff affects the WordPress and WordPress-Extra rulesets, not WordPress-Core or WordPress-Docs. Verify your active sniff list rather than assuming from the ruleset name.
Is excluding the sniff enough?
It is a temporary workaround only when verified with `phpcs -e`. Updating to 3.4.1 or later is the preferred correction.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, secure WordPress code-scanning workflows.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify every scanner and investigate persistent runners
Use the WPCS 3.4.1 Composer lock fleet audit to compare constraints, locks, caches, images, and runtime binaries. If affected WPCS scanned untrusted PHP on persistent infrastructure, follow the self-hosted runner incident triage to preserve evidence, contain access, rotate credentials, and rebuild.
Remove stale WPCS runtimes beyond the lock file
Use the WPCS 3.4.1 dependency proxy purge for mirrors, caches, containers, and offline archives. Then run the IDE binary path shadow audit so editors and remote workspaces invoke the corrected project runtime.
Helpful references