WPCS 3.4.1 fixes a command-execution vulnerability when affected rulesets scan untrusted PHP. Updating composer.json or composer.lock is not enough if a Composer proxy, artifact repository, dependency cache, offline bundle, base image, or developer cache still serves an older package.
Use this for agencies, plugin vendors, CI platform owners, marketplaces, and developer fleets that install WordPress Coding Standards through Composer mirrors, package proxies, cached containers, or offline build artifacts.
Quick answer
Inventory every package source and cache, resolve wp-coding-standards/wpcs through each path, record version and archive checksum, purge stale metadata and objects, rebuild without cache, and print the runtime WPCS version from the exact binary that scans code. Quarantine any worker that can still execute 3.4.0 or earlier against untrusted PHP.
What to check first
- List Packagist, Private Packagist, Satis, Artifactory, Nexus, GitHub cache, CI cache, Docker layers, dependency proxy, offline archive, workstation cache, and monorepo vendor directories.
- Record package name, resolved version, dist URL, reference, checksum, mirror response age, composer.lock content hash, PHPCSUtils, PHPCSExtra, and the active ruleset.
- Purge stale provider metadata, package archives, lock caches, vendor caches, build layers, and offline bundles according to each registry's supported invalidation procedure.
- Run a no-cache build through every network boundary and compare the downloaded archive hash plus the runtime package version to a trusted 3.4.1 reference.
- Search fleet images and workspaces for remaining WPCS copies, identify which can execute, and block untrusted scans until stale runtimes are removed or isolated.
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 |
|---|
| Map every package source | List Packagist, Private Packagist, Satis, Artifactory, Nexus, GitHub cache, CI cache, Docker layers, dependency proxy, offline archive, workstation cache, and monorepo vendor directories. | Each proxy and offline source resolves the expected 3.4.1 package metadata and archive. |
| Record versions and checksums | Record package name, resolved version, dist URL, reference, checksum, mirror response age, composer.lock content hash, PHPCSUtils, PHPCSExtra, and the active ruleset. | A clean no-cache build prints WPCS 3.4.1 from the binary used by CI. |
| Purge proxy and build caches | Purge stale provider metadata, package archives, lock caches, vendor caches, build layers, and offline bundles according to each registry's supported invalidation procedure. | Fleet search finds no executable older copy in images, workspaces, shared volumes, or global Composer paths. |
| Rebuild through each boundary | Run a no-cache build through every network boundary and compare the downloaded archive hash plus the runtime package version to a trusted 3.4.1 reference. | Security controls prevent untrusted scans from reaching credentials, writeable host paths, or privileged networks. |
Why this usually happens
- A dependency proxy can retain immutable-looking package metadata and archives beyond a normal client update.
- Docker and CI caches can restore vendor directories after the lock file changes.
- Offline builds may use a manually curated archive that has no automatic security refresh.
- The runtime binary can load a different installed standards path than the package inspected in composer.lock.
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
composer show wp-coding-standards/wpcs
composer clear-cache
composer install --no-interaction --no-cache --prefer-dist
vendor/bin/phpcs -i
composer why wp-coding-standards/wpcs
# Record the archive checksum supplied by each proxy before trusting it.
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.
- Map every package source
- Record versions and checksums
- Purge proxy and build caches
- Rebuild through each boundary
- Quarantine stale scanners
Decision rule
Close the purge only when every active build and scanner resolves WPCS 3.4.1 or later from an approved source, archive checksums are known, stale copies cannot execute, and untrusted code is isolated from secrets and persistent infrastructure.
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
- Each proxy and offline source resolves the expected 3.4.1 package metadata and archive.
- A clean no-cache build prints WPCS 3.4.1 from the binary used by CI.
- Fleet search finds no executable older copy in images, workspaces, shared volumes, or global Composer paths.
- Security controls prevent untrusted scans from reaching credentials, writeable host paths, or privileged networks.
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
Is composer update enough?
Not when a proxy or restored vendor cache serves an older archive. Verify the runtime binary and package hash.
Should old packages be deleted from evidence storage?
Preserve forensic evidence in an isolated location, but remove or block executable stale copies from normal build paths.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, 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 infrastructure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Find global Composer and PHPCS path shadows
After clearing package mirrors and caches, use the WPCS 3.4.1 global Composer installed paths audit to prove which PHPCS executable, ruleset, plugin runtime, IDE process, hook, container, and CI job actually runs.
Helpful references