Site compromise & injected content — high-level pointers (local fallback)

growlithe tells you that injected content exists on a page. The detailed, current incident- response runbook — rotating credentials, auditing plugins/themes for the entry point, verifying a cleanup actually holds — lives in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• A match is a compromise, not a copy edit — removing the visible text alone does nothing; the injector re-adds it until the entry point is closed.
• Find the entry point first — a compromised plugin, a stale/shared admin credential, or a writable upload directory are the usual routes; look there before cleaning content.
• Rotate credentials — every admin/FTP/hosting password with access to the site, not just the one that looks suspicious.
• Audit installed plugins and themes — for anything unrecognised, unlicensed, or recently added without a corresponding change request.
• Phishing / bank-impersonation content is a liability event, not a support ticket — escalate immediately rather than queuing it as routine work.
• Verify the cleanup holds — re-scan after a fix; if the same pattern reappears within days, the entry point is still open.
• URL-cluster injections (a sitemap suddenly claiming thousands of pages) usually mean a compromised endpoint is auto-generating content — treat it the same as a visible-page injection.

Full playbook → the team wiki’s site compromise & injected-content incident-response standards.