Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Woocommerce Business Critical Compromise

Checkout JavaScript Changed Without a WordPress Deployment

Trace unexplained WooCommerce checkout JavaScript through cache, tag manager, CDN, database, injected hooks, vendor scripts and account audits.

Checkout code can change without a Git or WordPress release. Tag Manager, CDN workers, remote vendor scripts, database snippets, page builders and compromised accounts all modify the browser result independently.

Treat unexplained checkout JavaScript as high risk until its owner, source and purpose are verified.

Contain before investigation

Pause checkout/payment or serve trusted maintenance outside WordPress. If a specific external script is confirmed malicious, block it at a trusted layer while preserving evidence.

Do not test with real cards or leave checkout live because code appears only on mobile. Record containment time and affected domains.

Notify the payment/incident owner.

Capture the deployed code safely

Record page URL, timestamp, script URL or inline hash, response headers, initiator and network destination. Preserve tag/CDN versions and browser source without submitting payment data.

Do not publish or execute suspicious code in online tools. Use protected evidence storage.

Compare first-visit, mobile and referrer conditions.

Distinguish static from dynamic code

A theme/plugin asset may have changed on disk, while inline script can come from WordPress options, snippets or remote response. Use browser initiator/source maps and server logs to identify the layer.

Compare origin and CDN responses through authorised testing. Record cache status and age; stale cache can serve an old compromised asset after disk cleanup.

Purge only after preserving evidence.

Audit Tag Manager and analytics

Review container users, publish history, environments, custom HTML tags and API tokens. Confirm every checkout tag has a business owner.

Revoke unknown access and rollback to a verified version through the account owner. Do not assume analytics accounts are lower risk than WordPress.

Keep payment/customer fields out of analytics data layers.

Audit CDN and DNS

Inspect Cloudflare workers, transform/redirect/page rules, Zaraz or similar tooling, cache rules and API tokens. Verify nameservers and origin records.

An attacker can inject at the edge while WordPress files remain unchanged. Secure registrar/CDN accounts with MFA and named users.

Do not expose the origin during comparison.

Inspect WordPress database and hooks

Review code-snippet plugins, widgets/options, page-builder templates, checkout hooks, active/must-use plugins and theme customisations. Search for confirmed domains/hashes.

Back up database rows and use precise changes. Do not globally delete all custom JavaScript; consent, payments and accessibility may depend on reviewed code.

Check scheduled tasks that republish snippets.

Check consent and translation variants

Consent platforms may inject different scripts by region, language or choice. Compare the exact consent state from the report and identify whether a configuration publish occurred.

Multilingual/page-builder templates can carry separate checkout snippets. Audit every active locale and mobile template instead of validating only the default desktop page.

Do not make payment conditional on advertising consent.

Review remote vendor scripts

A vendor can update JavaScript at the same URL without your deployment. Confirm the domain, integrity controls, contract/status and incident notices.

Minimise third parties on checkout and use Content Security Policy/monitoring appropriate to the architecture. Self-host only when licence/security update processes support it.

Document approved version ownership.

Establish a checkout script baseline

Maintain an approved inventory of script domains, tag/container version and owners, with alerts for additions or sensitive-route changes. Hashes can help for self-hosted/static assets but remote vendors may update legitimately.

Review rather than auto-block every difference. Combine baseline monitoring with CSP, account MFA and deployment audits.

Keep customer field values out of monitoring.

Verify the trusted checkout

Rebuild/restore code and external configurations from approved sources, rotate exposed secrets and test in sandbox. Compare network allowlist, rendered hashes and provider-hosted payment domains.

Test mobile/referrer/cache conditions, order creation, webhooks and emails. Monitor future tag/CDN/file/database changes.

Request urgent checkout investigation for any unexplained script. Share hashes, account audit IDs and redacted network evidence—never card data, credentials or script payloads publicly.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident