In the twenty years since interGen opened its doors, we have answered thousands of phone calls and support tickets. Our team has answered questions about website redesigns, custom software features, content updates, and search engine visibility. But until this past week, we had never received a single direct inquiry from a client asking about our server security protocols.
That changed this week. Clients from all across the country, in a wide range of industries and nonprofit organizations, reached out to ask us a single question: Are we protected against the new PHP vulnerability announced earlier this week?
I want to be completely clear: we treat this milestone as a very good thing. Security questions belong at the center of every healthy partnership, and we welcome them wholeheartedly. When you trust us to build, host, and maintain your digital front door, you deserve to know how we keep the keyhole secure.
Here is what happened this week, why the vulnerability mattered, and exactly how we kept your websites safe.
What Made "PHP2Shell" Uniquely Important
The security issue in question was nicknamed "PHP2Shell". It involved two specific software flaws (CVE-2026-109618 and CVE-2026-109619) that received a severity rating of 9.2 out of 10 from cybersecurity analysts.
To understand why this issue felt different from typical security notices, you do not need a degree in computer science. You just need to understand what PHP is and how security disclosures are supposed to work.
PHP is the core programming language that powers most of the web, including major content management platforms like WordPress and Joomla. It operates behind the scenes on the web server to assemble web pages whenever a visitor requests them. Because PHP operates at this foundational level, a flaw inside PHP affects almost every website running on it, regardless of how well built or carefully maintained the individual website might be. Left unpatched, the PHP2Shell flaws could allow an attacker to take full administrative control of a website's server.
What made PHP2Shell uniquely urgent, however, was a total breakdown in standard security protocol. Normally, security researchers follow a process called "responsible disclosure," where software flaws are reported privately so developers have time to create a fix before announcing the bug to the public.
With PHP2Shell, that secret window was shattered. Details of the vulnerability leaked publicly onto social media and developer forums before the official patch release, and Amazon reported seeing exploitation attempts four days before the scheduled fix. Because attackers were given a head start, site administrators were thrust into a real-time race against automated attack bots before official updates were even out.
The PHP development team released the official fix on Wednesday, October 21, 2026, at 9:00 a.m. Central Time.
How We Handled It Behind the Scenes
We did not wait for Wednesday morning to start working.
As soon as the leak was confirmed early in the week, our team began working overnight and through the early morning hours before the official release. We took several immediate, proactive steps:
- Full Inventory: We took a complete inventory of every server we manage and identified every version of PHP running across our infrastructure.
- Prepared Response Plans: We wrote a step-by-step update plan and staged the update on every server in advance, ensuring that applying the fix would take minutes rather than hours.
- Shrank the Attack Surface: We retired older, unneeded PHP versions, reducing the overall number of elements that could potentially be targeted.
- Pre-emptively Upgraded Sites: We migrated several older client websites onto modern, supported versions of PHP after thoroughly testing each site to ensure nothing would break.
When the official patch became available at 9:00 a.m. Central on Wednesday, our preparation paid off. We had every server we manage completely patched by 9:21 a.m. Central.
For a small handful of older websites that cannot yet run on modern PHP versions, we applied a specialized fix created for those environments and added an extra layer of protection that specifically blocks the type of web request the attack relies on.
Once patching was complete, we checked every server for any activity linked to this specific bug over the previous 30 days. We found no sign that this vulnerability had been used against any server we manage.
Finally, for clients on an interGen support or maintenance plan whose websites are hosted with other providers, we evaluated their exposure and helped them request the update from their host. Every client who wrote in received a direct, specific update about their own site, not a generic form letter.
The Bigger Point: Good Security Is Quiet
When web hosting works the way it should, most of this labor is completely invisible. You do not see the overnight system audits, the staged server updates, or the 20-minute patch window on a Wednesday morning. That is exactly how it should be.
Being ready is a matter of habits, not luck: knowing exactly what runs on every server, keeping software current, preparing before the fix arrives, and verifying the environment afterward.
No web firm can promise that software bugs will never happen. But we can promise that when they do, your site is backed by a team that pays attention, acts quickly, and treats your security as our personal responsibility.
Where We Go From Here
We are deeply grateful for the trust you place in interGen. Security questions are an essential part of choosing and keeping a web partner, and we are happy to answer them any time.
If you are a current client with questions about your specific website, reach out to us at
If you are not currently an interGen client, but this week's events left you wondering whether your own website was covered when the clock was ticking, you are welcome to reach out as well.
Thank you for your partnership over these last twenty years. We look forward to keeping your digital home secure for the next twenty.
Warmly,
Brian Mitchell
President, interGen