What happened, in plain English

Roughly 7 out of 10 websites run on the same piece of behind-the-scenes software. On October 21, that software got an emergency security fix, and attackers were already trying to break in before the fix was even out.

If your company has a website, a customer portal, or an online form that sends leads to your sales team, there’s a good chance you’re running it. Most owners and executives have never heard its name. That’s exactly why this one is easy to miss.

The software is called PHP. Think of it as the engine under the hood: you never see it, but it powers most WordPress sites, plenty of customer portals, and many of the forms that quietly feed your CRM. Security researchers have nicknamed this week’s flaws “PHP2Shell,” which is the name your IT team or vendor will recognize.

Here’s what the two bugs do, in business terms:

• Bug one is a master key. A stranger on the internet, with no login, can make your web server run their commands. Your app’s own code can be perfect and it still happens, because the flaw is in PHP itself.

• Bug two is a peek at the front desk. An attacker can read scraps of the server’s short-term memory. That memory holds whatever was passing through: passwords, login sessions, API keys, even security certificates.

The second one is the sneakier of the two. Nothing crashes. Nothing looks hacked. Someone just walks away with a bag full of perfectly copied keys.

Why patching isn’t the finish line

Patching fixes the broken window. It does nothing about the keys someone copied while the window was open.

Security researchers are blunt about this: any password or API key that leaked before you patched stays valid until you change it. And because exploitation started before the fix shipped, “we patched the same day” doesn’t mean “we were never exposed.”

This is where business owners get blindsided. That WordPress site feeding leads into Salesforce? The PHP server behind it is often holding the credentials your CRM integration uses. The same goes for your payment processor key, your email service key, and increasingly, your AI provider key. A leak on a “marketing website” can become a leak into your customer data.

A quick translation guide for the conversation with your tech team:

That last row matters. Researchers found most PHP servers that reveal their version are running old, unsupported releases. If you’re on one, there may be no patch coming at all; the fix is an upgrade.

Rotate your keys, and practice doing it

Most companies can’t rotate their keys quickly because they’ve never done it. That’s the real risk.

Here’s the pattern we see over and over. A key was created years ago by someone who’s since left. Nobody knows every place it’s used. Everyone is afraid that changing it will break checkout, the lead form, or the nightly sync to Salesforce. So it never gets changed, and a leaked key works forever.

A healthy rotation looks like this:

1. Know what you have. Keep a simple inventory: every key, what system it unlocks, where it’s stored, who owns it.

2. Create the new key first. Most providers let two keys work at the same time, so there’s no downtime.

3. Swap it in and confirm. Deploy the new key, then verify the integration actually works with it.

4. Kill the old key. Only now do you revoke it. A rotation where the old key still works isn’t a rotation.

5. Store keys properly. Keys belong in a secrets manager or environment settings, never pasted into code or a shared doc.

Then test it like a fire drill. Pick a non-critical key once a quarter and rotate it on purpose. Time it. Note what broke. The first drill is always messy; that’s the point. You want to find the surprises on a calm Tuesday, not during an incident.

Put a credit limit on every key, especially AI keys

A stolen AI API key is basically a stolen company credit card with no limit.

AI keys are a hot commodity right now. They’re valuable to bad actors because AI compute is expensive, and a stolen key lets someone run (or resell) that compute on your dime. Attackers scan for exposed keys constantly and can start using them within minutes. The first sign is often a bill you weren’t expecting.

What good looks like:

• Hard spending caps. Set a monthly limit at the provider so the worst case is a known number, not an open checkbook.

• Usage alerts. Get notified at 50% and 80% of normal spend, not after the invoice lands.

• One key per app. If the chatbot’s key leaks, you rotate one key, not everything.

• Least privilege. Give each key only the permissions it needs. A key that only reads shouldn’t be able to write or delete.

• Expiration dates. Keys that never expire are keys that get forgotten.

The same logic applies to your payment, email, SMS, and cloud accounts. Every service that bills by usage should have a ceiling and someone watching it.

Who actually owns the deed to your building?

We’ve walked into companies where the master account for a critical system was tied to a former employee’s personal Gmail.

Not a shared company inbox. Not even their old work email. A personal account belonging to someone who no longer worked there, or a founder who built from the ground up. In tech terms, that’s the root or owner account: the one login that can change every other login, reset every password, and delete everything. If that person is unreachable, uncooperative, or gets their own Gmail hacked, the company has effectively lost control of its own system.

This shows up more often than you’d think: cloud hosting, domain registrars, DNS, website hosting, AI and API provider accounts, and CRM admin users. It almost always starts innocently. Someone set it up quickly years ago and “meant to move it later.”

The fix is simple and boring, which is why it gets skipped:

• Company-owned email for every owner account, ideally a shared role address (like it@yourcompany.com) rather than one person.

• Multi-factor authentication on every admin and owner login, with backup codes stored somewhere the company controls.

• At least two admins on critical systems, so one departure never locks you out.

• An offboarding checklist that covers keys and accounts, not just laptops and badges. When someone leaves, the keys they created or knew get rotated.

• A yearly ownership audit. List your critical systems and confirm who holds the master key for each one.

Your PHP2Shell checklist, and how we can help

If you run anything on PHP, here’s the short list for this week:

• [ ] Find every place PHP runs, including the old site nobody touches anymore

• [ ] Patch or upgrade to a supported PHP version

• [ ] Rotate every key and password that server could see: CRM integrations, payments, email, cloud, AI

• [ ] Log everyone out so stolen sessions stop working

• [ ] Look back for signs of trouble starting before you patched, not from the patch date forward

• [ ] Add spending caps and alerts on usage-billed services

• [ ] Confirm every owner/root account is on a company email with MFA

At HelloMavens, we spend our days inside the systems that hold your most valuable data: your CRM, the integrations that feed it, and the operations around it. We help companies untangle exactly this kind of mess. We map which keys connect to what, rotate them safely without breaking your lead flow, set up limits and alerts, and make sure the company (not a former employee) holds the master keys.

If PHP2Shell has you wondering what’s exposed, let’s talk. A short conversation now is a lot cheaper than finding out from a surprise bill or a breach notice.

Book a security review today with Calendly

Sources

• W3Techs: PHP usage statistics (about 70% of websites with a known server-side language)

• ReliaQuest: PHP2Shell, responding to critical PHP vulnerabilities

• Recorded Future: PHP2Shell exploitation explained

• CodeAnt: PHP2Shell remediation playbook

• Paubox: What healthcare IT teams should know about PHP2Shell

• IBM Cloud: Understanding API keys

• 20 years of professional experience