Heartbleed, Log4j, PHP2Shell: What the Internet Keeps Teaching Us

The flaws keep landing in the same shared plumbing. What changed with PHP2Shell is speed, and that changes the questions a business owner needs to ask.

Executive Summary

• PHP2Shell is a pair of critical flaws in PHP, the language running a large share of the web. An attacker can take over a vulnerable server with ordinary web requests and no password.
• It repeats two old lessons: the internet runs on shared code few people fund, and you cannot patch what you do not know you run.
• The new lesson is speed. Attackers were testing these flaws before the fix shipped. Plan for exploitation before you finish reading the advisory.
• Machines helped find it. The researchers credited AI models with a real part in uncovering the flaws. Expect more old bugs to surface, faster.
• The secret did not hold. Details leaked early, and attackers were probing servers before patches existed.
• Defenders moved early too. Security providers pushed blocking rules before disclosure, and some governments took websites offline rather than wait.
• The fix was not in your website. Updating plugins or site code did nothing. The patch lived in the PHP engine itself, which for most small businesses belongs to a hosting company or web agency.

The Same Lessons, Learned Again

Heartbleed taught us that software holding up the internet can be maintained by a handful of overworked volunteers. A flaw in OpenSSL, the code that secured much of the web’s encrypted traffic, leaked server memory to anyone who asked.

Log4j taught us that you cannot fix what you cannot find. A logging library was buried so deep inside so many products that companies spent weeks just discovering they ran it.

PHP2Shell rhymes with both. The weakness lives in how PHP cleans up after an error, and it has been there for more than a decade. It sits under WordPress, Drupal, and countless homegrown sites whose owners have never heard the word PHP. That is the Log4j problem all over again.

What Was Different This Time

Verizon’s 2026 Data Breach Investigations Report says AI is helping attackers shrink the window for defense “from months to mere hours.” In the same report, organizations took a median of 43 days to fully fix critical flaws already on the government’s known-exploited list. Hours against weeks is the whole story.

Five Questions to Ask Before the Next One

1. Who patches the plumbing? For every website and web app, name the person or company responsible for the server and runtime underneath, not just the content.

2. How fast, in writing? For critical, internet-facing flaws, the answer is hours or days, not “next maintenance window.”

3. Is there a shield in front? A web application firewall can block known attack patterns before a patch is installed.

4. Who can pull the plug? Decide now who can take a site offline, and what the business does meanwhile.

5. Did anyone get in first? Patching closes the door. It does not tell you who walked through it. Ask for a check for signs of compromise.

The Takeaway

The next internet-wide flaw is already sitting in code you depend on. You will not prevent it. You can decide today who owns the fix, how fast it happens, and how you will know whether someone beat you to it.

A resource for STP clients

STP works with Simulint, which provides cybersecurity services, including human-led penetration testing. For Cybersecurity Awareness Month, Simulint is offering discounts on penetration testing engagements signed by October 31, 2026, along with BlueSphere Pulse, a no-cost seven-day review of selected cyber risk areas. Learn more about Simulint's penetration testing.

STP has a business relationship with Simulint and may receive compensation for referrals. Simulint, not STP, provides penetration testing and BlueSphere Pulse services. Organizations should evaluate the scope and suitability of any service for their own circumstances. This post is for informational purposes and is not legal or regulatory advice.