A flaw in a shared piece of technology can become a problem for thousands of organizations at once. SEVN-X founder Matt Barnett joined NBC10 Philadelphia to explain the critical PHP security story, why some websites were being taken offline, and what businesses and everyday users can do next.
Watch the full interview below. Matt breaks down the issue without the panic—and explains where responsibility for the fix actually sits.
Video: NBC10 Philadelphia interview with Matt Barnett, founder of SEVN-X. Runtime: approximately 3 minutes, 20 seconds.
When the foundation has a flaw
Matt compares PHP to the concrete beneath a house. Developers can build very different applications on top of the same underlying material. When that shared foundation has a weakness, the impact can reach far beyond a single website.
That does not mean every site has been compromised. Exposure, exploitation, and a confirmed breach are different things. The immediate task for an organization is to find out what it runs, who maintains it, and whether the relevant fixes have actually been deployed.
What website owners should do
PHP published security updates on October 21, 2026 for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Its advisory warns that affected systems can allow unauthenticated remote code execution. For current fixes and configuration guidance, consult the official PHP security advisory and your software or hosting provider.
- Identify the systems and the owner. Include public websites, applications, hosting arrangements, and vendor-managed services. Make one person accountable for confirming the response.
- Verify the update. Ask your provider which fix is installed and confirm it is running. A ticket marked complete is less useful than evidence that the affected service has been updated.
- Reduce exposure while you coordinate. If a fix cannot be applied promptly, work with your technical team on restricting public access and maintaining essential operations.
- Investigate suspicious activity. Applying an update closes a vulnerability; it does not establish whether someone already used it.
Why some websites go offline
In the interview, Matt explains that temporarily removing a website from public access can reduce the opportunity for exploitation. The decision becomes more complicated when the service supports a critical business process.
The Canadian Centre for Cyber Security recommends isolating affected internet-facing applications when immediate patching is not feasible. This is a coordinated availability decision—not a blanket instruction to power down suspected compromised machines or discard evidence.
What everyday users can control
As Matt points out, the application or hosting team must apply the server-side fix. Customers cannot patch someone else's website. They can limit the damage that a compromised account might cause elsewhere.
Use a different password for every account and enable multifactor authentication wherever it is available. Follow legitimate instructions from affected providers, and approach unexpected “security update” emails carefully. A widely reported vulnerability can also become a convincing phishing pretext.
Clear ownership. A measured response.
A widespread vulnerability creates urgency, but a useful response starts with specific questions: Are we affected? Who is applying the fix? How will we verify it? Do we see evidence of compromise?
If your team needs help answering those questions, talk with a SEVN-X practitioner. If you suspect an active incident, use our incident support dashboard or call +1 (484) 989-0911.
Technical context checked October 23, 2026. Follow current vendor advisories as guidance evolves.
