A considered approach to websites, stores and content platforms.
Explore ServicesPractical craft for people building for the web.
Explore DevelopmentLearn something. Find a tool. Meet your next collaborator.
Practical ideas for your next build.
Find useful software and free utilities.
Meet makers and find expert help.
Finding your next read
Respond to a suspected PHP website compromise with evidence preservation, containment, verified patching, trustworthy recovery and credential revocation.
AI-assisted, source-based editorial guide. Illustrative PHP snippets syntax-checked only; not a live hosting audit or application integration test. Sources checked 22 October 2026.
Respond to a suspected PHP website compromise with evidence preservation, containment, verified patching, trustworthy recovery and credential revocation.
One good read leads to another
Record the filters, sort order, selected fields and representative data size. A query that is fast for a tiny development table can behave differently on…
Remove untrusted PHP object deserialization, define a bounded JSON contract and plan legacy migration without preserving an unsafe parser fallback.
Continue with another published guide. Stories connected to this topic, platform and format come first.
Validate PHP uploads, bound file size, generate server-owned names and plan private storage and authorized downloads. Includes a focused validation helper.
Read the story
Use PDO value parameters, fixed sorting and tenant authorization together. Review an original query example and a practical SQL security test matrix.
Read the storyAn unpatched PHP version is an exposure. An unexpected administrator account, an unauthorized file change or a malicious redirect is an observation that needs investigation. Those statements are related, but they are not interchangeable: a version check cannot prove a site was compromised, and a completed update cannot prove a previously compromised site is clean.
For a small website, the most useful first response is a controlled sequence with a named owner. Preserve what happened, reduce ongoing harm, establish the affected systems, repair the entry point and recover from a trustworthy state. Avoid making irreversible cleanup changes before the evidence needed to understand the incident has been preserved.
Record the first observed symptom, the time and timezone, the affected URL or service, who reported it and what has already changed. Distinguish an observation from a hypothesis. “Unexpected redirect seen at 09:15” is more useful than declaring a particular vulnerability responsible without evidence.
WordPress's compromised-site guidance emphasizes documenting symptoms and obtaining appropriate help. Contact the hosting provider through its authenticated support channel. Share exact observations and request relevant logs and account-level checks; do not post credentials, private backups or visitor data in a public support thread.
Assign one person to coordinate changes. If multiple people independently restore backups, change passwords and delete files, the resulting timeline can become harder to understand than the original problem.
If visitors are being redirected, malware is being served or unauthorized activity is continuing, work with the host to restrict the affected service. Depending on the environment, containment may involve restricting origin access, isolating an instance or serving a maintenance page outside the affected application.
A CDN rule or a WordPress maintenance plugin may not isolate a compromised origin or runtime. Identify who controls the web server, scheduled jobs and credentials. Do not assume a frontend message stops background execution.
The ENISA joint PHP statement recommends inventory, prompt updates and isolation where affected systems cannot be patched. That is a response to exposure; determining whether an actual intrusion occurred still requires evidence from the environment.
Ask the provider or responder to preserve relevant application/server logs, configuration, deployment records and snapshots before destructive remediation. Store collected material privately with restricted access. Record the collection time, source and custodian. A backup of a compromised system is investigation material, not automatically a safe recovery image.
OWASP's logging guidance addresses protecting logs and excluding secrets such as passwords and access tokens. Keep the incident worksheet similarly restrained. Do not paste complete session cookies or database credentials into a support ticket to demonstrate an issue.
A missing log entry does not establish that an event never occurred. Retention limits, timezone differences and incomplete application logging may leave gaps. Record those limits honestly.
Check the PHP security update overview for the current incident's runtime issue, then verify the actual web-serving handler and the provider's package revision. Also review application dependencies, extensions and account access. Avoid attributing every unauthorized change to the newest advisory.
Updating PHP closes the addressed runtime vulnerabilities. It does not remove an unauthorized account, restore a changed database record or revoke a credential already copied by an attacker. Likewise, deleting a suspicious PHP file does not repair the interpreter or explain how the file arrived.
For WordPress, inventory core, themes, plugins, must-use plugins, uploads, scheduled jobs and administrator accounts. File integrity checks can support the investigation, but a comparison against available official checksums does not cover every custom file, database change or hosting-level persistence path. A clean checksum result is one piece of evidence, not a universal all-clear.
Choose a recovery approach with the provider or responder. A fresh deployment from trusted source and carefully reviewed data may be preferable to editing an unknown collection of files in place. A backup must be evaluated for both age and integrity: it could predate the visible symptom while already containing an earlier unauthorized change.
Apply the relevant security fixes before reopening the recovered service. Keep investigation snapshots separate from the restored production environment. Verify that the restored application can perform essential business functions with a limited, trusted set of credentials.
The WordPress hardening guide is useful for reviewing update practices, file permissions and administrative access. Adapt it to the host's responsibility model rather than applying server commands intended for a different platform.
Plan credential replacement after containment so new secrets are not immediately exposed through the same compromised system. Consider hosting accounts, deployment keys, database users, application administrators, API integrations and email delivery credentials according to the evidence and access scope.
Revoke old sessions and tokens through supported mechanisms, and update the legitimate services that depend on changed credentials. Keep a recovery channel available so a rushed password change does not lock the actual owner out while leaving another access path open.
If personal information or customer accounts may be involved, involve the appropriate business/privacy advisers to establish applicable communication obligations. Do not promise visitors that no data was accessed when the available evidence cannot establish that.
Before public restoration, verify the patched web runtime, trusted deployment provenance, expected administrators, working login/logout, forms, uploads, scheduled tasks and outbound email. Check both cached public pages and direct origin behavior through an authorized test path. Monitor for recurrence after reopening.
Close the incident record with what was confirmed, what remains unknown, the recovery source and the changes that reduce recurrence. Store follow-up tasks with owners and dates. “The homepage looks normal” is insufficient as the only closure criterion.
Use Composer and runtime checks as ongoing maintenance evidence. This article provides a defensive response framework, not a claim that FinderPress inspected or remediated the reader's server. Sources were reviewed on 22 October 2026.
Choose one step from this article, try it on a representative project, and record what you learn before changing the wider workflow.
This is general editorial guidance rather than a hands-on product test; verify platform-specific details in current primary documentation.
Take it with you
Review PHP session ownership, cookie policy, identifier rotation, expiry and CSRF validation with an original token helper and practical integration checks.
Understand what Composer audit, platform checks and PHP runtime updates each prove, then connect dependency evidence to the artifact actually deployed.
Read the storyTake a useful starting point into your next project. These free, editable Markdown templates open in any text editor.
A practical checklist for scope, testing, rollback and follow-up.
Website change checklistEvaluate editing, performance, accessibility and ongoing support.
Theme evaluation scorecardCapture the steps, expected result and evidence in one place.
Bug report templateExplore the wider collection or tell us which question we should tackle next.
The conversation
Be the first to share a thoughtful response.
From the community
Join the conversation.