PHP2Shell Website Security Checklist for Local Businesses

PHP2Shell is a reason to verify your website security

PHP2Shell is the name used by Wiz for a set of PHP remote-code-execution vulnerabilities. Remote code execution is serious because it can allow an attacker to run code on an affected server from elsewhere.

Wiz published the underlying PHP2Shell research, and NPR reported increased hacking attempts after the flaws were identified, along with the potentially broad impact on websites that use affected software. That does not mean every local-business website is vulnerable or has been compromised. It does mean website owners should confirm what powers their site and whether their host or developer has applied the appropriate updates.

For a local business, the practical concern is not just whether the homepage stays online. If a website handles contact forms, service requests, appointment bookings, or quote inquiries, a security issue could create operational risk. Businesses should prepare to check whether forms are working, whether submissions are arriving where expected, and whether suspicious activity needs professional review.

Sources: Wiz’s PHP2Shell research and NPR’s report on the flaws and increased hacking attempts.

In this checklist

• Confirm who manages your hosting, CMS, and PHP environment
• Ask whether your website is affected and has been remediated
• Review updates, backups, and administrator access
• Check forms, bookings, and spam activity
• Know when to involve your host or a qualified developer
• Review recent inquiries if you suspect a compromise

First: identify what you actually manage

Many local-business owners do not log into a server or choose their PHP version themselves. That is normal. Your website may be managed through a hosting company, a web developer, a marketing provider, or a website platform.

Before changing anything, write down the answers to these questions:

• Who hosts the website?
• Who has access to the domain registrar?
• What platform or content management system runs the site?
• Is the site built with WordPress, another CMS, custom code, or a hosted website platform?
• Who updates plugins, themes, and server software?
• Where are backups stored, and who can restore one?
• Which email address receives new contact-form or booking notifications?

If you are unsure, start with the person or company that sends your hosting invoice or manages website changes. Avoid guessing at server settings or making technical changes you do not understand.

PHP2Shell website security checklist

Use this as a practical owner-level checklist. You do not need to perform server forensics yourself. The goal is to confirm ownership, request the right verification, and spot visible problems early.

1. Contact your hosting provider or website developer

Send a clear, specific request rather than a vague question about “security.”

You can use this message:

I am reviewing my website after reports about the PHP2Shell vulnerabilities. Please confirm whether my hosting environment or website is affected, whether relevant security updates or mitigations have been applied, and whether you recommend any action from me.

Ask for a response in writing. If your website has a developer and a separate hosting company, contact both. The host may manage server-level PHP updates, while the developer may be responsible for application, theme, or plugin updates.

Do not assume that an updated WordPress plugin alone resolves a server-level issue, and do not assume that a host update resolves outdated website extensions. The responsible party should explain what they checked.

2. Confirm the CMS, PHP version, and update responsibility

Your provider or developer should be able to tell you:

• Whether your website uses PHP
• Which PHP version the hosting environment runs
• Whether the relevant PHP2Shell advisories apply to that environment
• Whether patches, upgrades, or mitigations have been applied
• Whether your CMS core, plugins, and themes need updates
• Whether any incompatible software could delay updates

The PHP2Shell reporting should not be treated as a reason to update random software without a plan. Updates can sometimes conflict with older themes, plugins, or custom functionality. A qualified developer can test and apply changes safely, especially for websites with booking tools, payment features, member logins, or custom forms.

3. Make sure backups exist before changes are made

A recent, restorable backup is a basic safeguard before significant website work.

Ask:

• When was the most recent full website backup completed?
• Does it include website files and the database?
• Is the backup stored separately from the live website?
• Has the restore process been tested recently?
• Can a backup be restored if an update causes a problem?

A backup is not proof that a site is secure, and it does not replace remediation. It can, however, give your technical contact a safer recovery option if the site needs repair after an update or suspected compromise.

For a broader continuity plan, see When a software failure takes down your website: a local business response checklist.

4. Review administrator accounts and access

Old administrator accounts create avoidable exposure. Review every account that can change your website, hosting, domain, or form settings.

Check for:

• Former employees, contractors, or agencies that still have access
• Generic shared logins
• Accounts with administrator permissions that do not need them
• Unrecognized users
• Old email addresses attached to critical accounts
• Passwords shared in email threads, spreadsheets, or documents

Remove access that is no longer needed. For accounts that must remain active, use a verified password-reset process through the provider’s official login page or support channel. Do not reset credentials from links in unexpected emails claiming to be from your host.

If your business has stored website passwords in shared documents, review Local business website security: how to avoid exposing passwords in shared Google Docs.

5. Check that your contact forms and booking paths still work

A website can look normal while an inquiry path is broken. After security maintenance, test the actions that matter most to prospective customers.

Submit one test inquiry through each of these, if applicable:

• Main contact form
• Quote-request form
• Appointment or booking form
• Service-page contact form
• Newsletter sign-up
• Online chat or callback request
• E-commerce order or payment flow

For each test, verify that:

1. The confirmation message appears on the website.
2. The submission reaches the intended inbox, CRM, booking system, or dashboard.
3. The notification email does not land in spam.
4. Your team knows who is responsible for responding.

Use clearly labeled test information, such as “TEST — please ignore,” so no one mistakes it for a real customer request.

This is also a good time to review whether your forms collect only necessary details. Local business lead form fields: what to ask and what to leave out can help you simplify forms without requesting more customer information than you need.

6. Watch for suspicious form and email activity

The research does not show that local businesses experienced a documented increase in missed leads from PHP2Shell. Still, it is sensible to monitor form activity after a security concern, particularly if you notice unusual website behavior.

Look for:

• A sudden spike in spam submissions
• Messages containing unfamiliar links, scripts, or odd attachments
• New form notifications sent to an unfamiliar email address
• Customer reports that they submitted a form but received no response
• Changes to form confirmation messages or redirect pages
• A booking tool that no longer sends notifications
• Unrecognized autoresponder emails sent from your business address

Do not click suspicious links or open unexpected attachments. Preserve the message and share it with your hosting provider or developer if it appears connected to website activity.

7. Review visible signs that need escalation

Contact your host or qualified developer promptly if you see any of the following:

• The website redirects visitors to an unrelated page
• The homepage or service pages show unfamiliar content
• You cannot log in with known credentials
• Unknown administrator accounts appear
• Your host sends a malware, abuse, or security notice
• Search results show strange page titles or unfamiliar pages for your domain
• Customers report browser security warnings
• Website files, forms, or settings change without authorization

If compromise is suspected, avoid making broad changes on your own. Preserve relevant evidence, such as screenshots, timestamps, notification emails, suspicious URLs, and unfamiliar account names. Your technical contact may need that information to investigate and remediate the issue.

If you suspect your website was compromised, check recent inquiries

A security event does not automatically mean customer requests were lost. But if forms, email notifications, redirects, or administrator settings may have been altered, it is worth reviewing the recent inquiry path.

Start with the period when you first noticed a problem, then check a little earlier as well.

Compare submissions across systems

If available, compare:

• Form entries in the website dashboard
• Notifications in the business inbox
• Leads in your CRM
• Booking-system appointments
• Call logs or voicemail
• Customer messages from social channels or Google Business Profile

You are looking for gaps. For example, if the form dashboard shows a submission but no email notification arrived, that points to an email-delivery or notification issue. If a customer says they reached out but there is no record in any system, ask your developer to check the form configuration and relevant logs.

Follow up carefully when you have a real reason

If you identify a verified inquiry that did not receive a response, follow up using the contact information the person submitted. Keep the message simple:

Hi [Name], we are following up on your recent request. We want to make sure you received a response from us. How can we help?

Do not tell customers their data was exposed unless you have verified information and appropriate professional guidance. A technical issue, missed notification, or spam-filter problem is not the same thing as a confirmed data breach.

What not to do

Security news can create pressure to act fast. Fast action is useful only when it is controlled.

Avoid these mistakes:

• Do not ignore host or developer notices. Ask whether your environment was reviewed and remediated.
• Do not install unfamiliar “security fixes” from email links. Go directly to your provider’s verified website or support channel.
• Do not delete suspicious files or accounts without guidance. That can remove evidence needed for investigation.
• Do not assume a visible homepage means everything is fine. Test forms, bookings, emails, and customer-facing workflows.
• Do not claim your business was hacked without confirmation. Escalate the issue and communicate based on verified facts.
• Do not treat one checklist as a guarantee. Security requires ongoing updates, access review, monitoring, and reliable technical support.

Keep this as a recurring website maintenance task

PHP2Shell is a useful reminder that a local-business website is not a set-it-and-forget-it asset. The most practical long-term habits are straightforward:

• Keep a current record of your host, domain registrar, website platform, and support contacts.
• Assign a clear owner for software updates and security notices.
• Maintain current backups.
• Review administrator access when staff or vendors change.
• Test forms and bookings after significant website updates.
• Keep customer inquiry notifications routed to a monitored inbox.
• Escalate suspicious behavior to your host or developer rather than attempting advanced investigation alone.

A short website-security bridge for busy owners

If managing hosting contacts, updates, form tests, and page changes is not something you want on your weekly to-do list, it may be time to reconsider who maintains your website. StoopCraft builds websites for local businesses and includes on-page SEO as part of its $99/month service.

Visit StoopCraft to learn more.

Related reading

• Cybersecurity Awareness Month checklist for local business websites
• ConnectWise cloud backup attack: website and lead-handling checks for local businesses
• Local business website lead form privacy checklist: what to review before publishing
• When a software failure takes down your website: a local business response checklist