The Bic Pen Moment: What PHP2Shell Means for 70 Percent of the Web

Law Smith

Founder & President, Tocobaga

Law Smith is the Founder and President of Tocobaga, a Tampa-based ROI-focused marketing agency and SMB advisory. He has strategically advised 1,000+ small and medium businesses, executed 600+ integrated marketing campaigns, and written 30+ business plans across industries ranging from professional services to e-commerce to B2B technology. Tocobaga is a Google Partner and Squarespace Gold Partner headquartered in Ybor City.

In December 1950, a Frenchman named Marcel Bich started selling a ballpoint pen with a clear plastic barrel cut into six flat sides, like a pencil, so the writer could see exactly how much ink was left.* It was not glamorous. By 1959 it sold for 29 cents in the United States. In September 2006, Bic sold its 100 billionth Cristal, the best-selling pen in the world, and the Museum of Modern Art eventually added it to its permanent collection as a landmark of industrial design.* It is the most ordinary object in the office supply closet. Its most famous moment had nothing to do with writing.

That moment arrived on a Sunday in September 2004, when a San Francisco computer security specialist named Chris Brennan posted to an online cycling forum called Bikeforums. Brennan shared a short QuickTime video. In it, a Kryptonite U-lock, the heavy steel horseshoe every city cyclist trusted, popped open in seconds. The tool was the empty barrel of a Bic pen, pushed into the round keyway and twisted. The thread ran past 450 posts.† Within days, a bike shop employee demonstrated the trick for a New York Times reporter, and it took about five seconds.‡

Kryptonite was not a bargain-bin brand. The company's founding legend dates to 1972, when a New York bike shop working with co-founder Michael Zane locked a three-speed to a signpost in Greenwich Village and left it there for thirty days and thirty nights. Thieves stripped every part they could carry off. The lock held.§ For three decades, a product named after Superman's famous weakness meant the opposite for bicycles: the thing nobody could beat. Then a pocket-change pen beat it.

Here is the part that matters. The problem was not the bike. It was not the rider, the neighborhood or the signpost. It was the cylinder, a tubular pin design that Kryptonite itself said had been used across the lock industry for more than 30 years.† The same style of cylinder guarded laptop cables and vending machines.‡ And the pen trick was not even new. A British cycling magazine, New Cyclist, had described it in 1992, twelve years before the video.† Nobody acted until a video made it impossible not to.

On Tuesday, October 20, 2026, at about 11 a.m. Eastern, two vulnerability ID numbers started circulating online.‖ They pointed at PHP, the programming language running underneath roughly 70 percent of the websites whose code can be identified.¶ Within 24 hours, the National Security Agency told organizations to patch immediately or take their systems offline,** and government ministries across Europe started pulling the plug on their own websites.†† Researchers named the pair of flaws PHP2Shell. The web had its Bic pen moment.

My name is Law Smith, and I run Tocobaga, an ROI-focused marketing agency and SMB advisory in Ybor City, Tampa. SolvingHow.com is where Tocobaga publishes what it learns. Tocobaga has produced more than 300 websites. Most owners never think about the language under their website, the same way most cyclists never thought about the cylinder inside their lock. So is PHP2Shell one of those news stories that deserves real attention? Yes. Not because the sky is falling today, but because PHP2Shell exposes three things most businesses cannot answer about their own websites: which lock is on the door, who holds the key, and who is supposed to check it.

What is PHP2Shell, in plain English?

PHP2Shell is the nickname for two critical security flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Under the right conditions, either one lets a stranger on the internet run commands on a web server without a password, an account or any prior access.‖

The first flaw involves memory. If a web request pushes PHP to its memory limit at exactly the wrong instant, PHP can leave half-built internal data lying around and later treat it as real. On servers running Apache with the mod_php module, an unauthenticated request can trigger the problem before a single line of the website's own code runs, and researchers demonstrated full remote code execution with default settings.‖ The second flaw involves error handling. A fatal error at the wrong moment can leave PHP pointing at memory that belonged to a previous visitor's request, and the next request handled by that same worker can be steered into using it.‖ Both carry a severity score of 9.2 out of 10 under the current industry scoring system.‖

The National Security Agency boiled the key point down to one line: these are flaws "in PHP itself, not in the hosted application."** That is the Kryptonite cylinder. A business can run the best-built website in its industry, with updated plugins, strong passwords and a clean theme, and still be exposed, because the weakness sits in the engine every page request passes through. The bike is fine. The lock is the problem.

Two more facts frame the scale. The vulnerable code traces back to PHP 5.4, which means it has been sitting inside the web's most common server language since 2012.‡‡ And PHP's maintainers say every installation that serves web requests is in scope, across all the major ways PHP gets wired into a server: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.§§ Those names mean nothing to most owners. That is precisely why an owner needs someone who knows which one the business is running.

How many websites use PHP?

PHP runs on roughly 70.5 percent of all websites whose server-side programming language can be identified, according to W3Techs' August 2026 survey.¶ Even among the one million highest-traffic sites, where large companies build custom technology stacks, PHP still powers 65.7 percent.‖‖ No other server-side language comes close.

That dominance started with a man who wanted to know who was reading his resume. In 1994, a programmer named Rasmus Lerdorf wrote a small set of programs in the C language to track visits to his online resume. He called them Personal Home Page Tools. In June 1995 he released the source code to the public and invited other developers to fix and improve it.¶¶ By May 1998, about 60,000 domains reported running PHP, roughly 1 percent of the internet at the time.¶¶ Twenty-eight years later, a resume visitor counter has become the plumbing of the web. Lerdorf did not set out to build the cylinder inside 70 percent of the world's locks. Nobody ever does.

The single biggest reason for PHP's reach is WordPress. W3Techs counts WordPress on 40.7 percent of all websites, which works out to 58.9 percent of every site using a content management system the survey can identify.*** WordPress is written in PHP. So is WooCommerce, the plugin that turns WordPress into a store. So are Drupal, Joomla and Magento, the commerce platform Adobe now sells as Adobe Commerce. So is MediaWiki, the software behind Wikipedia. Then there is the PHP nobody sees: hosting control panels, appliance dashboards and vendor software that never advertises what is underneath. Palo Alto Networks, a major security vendor, confirmed that all versions of its PAN-OS firewall software and its Panorama management platform are affected by PHP2Shell.§§ Read that sentence twice. Even the lock makers use the lock.

Here is the market in one view. The table below lays out where PHP sits on the web and which platforms put the server in someone else's hands.

Where PHP sits on the web (W3Techs data, 2014 to 2026; host counts from Shodan via CybelAngel)

Platform or measure	Share	Who patches the server
PHP, websites with a known server-side language	70.5% (Aug 2026)	Whoever runs the server
PHP, top 1 million websites	65.7% (Jul 2026)	Whoever runs the server
PHP version 8, share of PHP websites	62.5% (Aug 2026)	Whoever runs the server; the other 37.5% run older generations
WordPress, share of all websites	40.7% (Aug 2026)	The host or the owner
WordPress, CMS market share	59.8% (2014) to 59.2% (Jul 2026)	The host or the owner
Joomla, CMS market share	9.3% (2014) to 1.7% (Jul 2026)	The host or the owner
Drupal, CMS market share	5.5% (2014) to 1.0% (Jul 2026)	The host or the owner
Shopify, CMS market share	0.3% (2014) to 7.6% (Jul 2026)	The platform vendor
Wix, CMS market share	0.2% (2014) to 6.1% (Jul 2026)	The platform vendor
Squarespace, CMS market share	0.3% (2014) to 3.5% (Jul 2026)	The platform vendor
Internet-facing PHP hosts on branches with no official fix	59% of hosts reporting a version (Oct 2026)	The owner must upgrade or find a backport

The numbers carry a story the headlines missed. In January 2014, Joomla and Drupal, both built on PHP, held a combined 14.8 percent of the content management market.††† By July 2026 they held 2.7 percent.‡‡‡ Over the same stretch, hosted platforms where the vendor runs the servers, Shopify, Wix and Squarespace, grew from a combined 0.8 percent to 17.2 percent.†††, ‡‡‡ WordPress barely moved: 59.8 percent in 2014, 59.2 percent in July 2026. The market has been quietly sorting itself into two camps for a decade. One camp owns its servers. The other rents an apartment from a landlord who changes the locks. PHP2Shell is the week the first camp found out exactly what ownership includes.

What happened with PHP2Shell, and when?

PHP2Shell went from a private research finding in August to a global emergency in about a day in October. The patch landed on Wednesday, October 21, 2026, one full day ahead of schedule, after the vulnerability IDs leaked on Tuesday.‖

The story starts earlier than the headlines. In 2024, PHP went through its first external security audit in years, funded by Germany's Sovereign Tech Agency and carried out by the security firm Quarkslab. While fixing one of the audit's findings, a developer contracted by the PHP Foundation spotted the first signs of the memory problem behind CVE-2026-109618.‖ Nobody could prove it was exploitable. The fix stalled.

Then the AI-assisted researchers arrived. Security firm Calif began auditing PHP on July 30, 2026, through an OpenAI security program. On August 11, a Calif researcher reported an unconditional remote code execution with the same root cause, and OpenAI independently reported the same root cause that same day. Wiz followed with more attack paths on August 24, and OpenAI added more on September 18.‖ From August 11 forward, the PHP Foundation says, fixing the problem became the top priority for everyone on its security team.‖

The plan was a coordinated release on Thursday, October 22, at 10 a.m. Eastern. On Tuesday, October 20, at around 11 a.m. Eastern, the two CVE numbers began circulating on forums and social media, attached to the wrong release time and an inflated severity score of 10.0.‖ PHP's security team published an advance notice at 3:30 p.m. Eastern and moved the release up a full day. Later that afternoon, Calif mistakenly published a video showing its proof of concept working against real targets. The video came down, copies spread anyway, and amateur exploit attempts multiplied.‖ That is Chris Brennan's QuickTime file, almost exactly 22 years later, except this time one of the researchers who had reported the flaw hit post.

At 3:41 a.m. Eastern on Wednesday, Chainguard, a software distributor that had received the patch early so its customers could update quickly, published fixed builds before the embargo lifted, which let anyone study the repair.‖ Two minutes later, Cloudflare's chief technology officer reported early attacks, and Cloudflare extended emergency firewall rules to every customer plan, free accounts included.§§§ At about 9:35 a.m. Eastern, roughly 25 minutes ahead of its rescheduled slot, PHP shipped versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.§§§ The NSA issued its advisory that morning.‖‖‖ By the end of the day, governments on two continents had taken websites offline. The full sequence, from a resume counter to a global patch, is in the timeline below.

PHP2Shell timeline (times are U.S. Eastern)

When	What happened	Why it matters
1994 to 1995	Rasmus Lerdorf writes Personal Home Page Tools to track visits to his online resume, then releases the source code.	A resume counter grows into the web's most common server language.
2012	PHP 5.4 ships. Researchers later trace the earliest affected code to this release.	The flaw sits inside the web for about 14 years.
2024	PHP's first external security audit in years. A Foundation developer spots the first signs of the memory problem.	Known but unproven, the fix stalls for months.
Jul 30, 2026	Security firm Calif begins an audit of PHP through an OpenAI security program.	AI-assisted research enters the picture.
Aug 11, 2026	Calif and OpenAI independently report remote code execution from the same root cause.	The risk becomes provable. Fixing it becomes the top priority.
Aug 24 and Sep 18, 2026	Wiz, then OpenAI, report additional attack paths.	The full impact of the memory problem comes into focus.
Oct 17, 2026	Amazon's honeypots record the first known PHP2Shell exploitation attempt.	Attacks begin four days before public disclosure.
Oct 20, about 11:00 a.m.	The two CVE IDs leak online with a wrong release time and an inflated 10.0 score.	The coordinated disclosure breaks two days early.
Oct 20, 3:30 p.m.	PHP posts an advance notice and moves the release up by one day.	Distributors get one night to finish packaging.
Oct 20, late afternoon	Calif mistakenly posts a proof-of-concept video. Copies spread after it is deleted.	Amateur exploit attempts multiply.
Oct 21, 3:41 a.m.	Chainguard publishes fixed builds before the embargo lifts.	Anyone can study the fix early.
Oct 21, 3:43 a.m.	Cloudflare reports early attacks and extends emergency firewall rules to every plan, free included.	A speed bump for sites behind Cloudflare.
Oct 21, about 9:35 a.m.	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.	The only complete fix.
Oct 21, morning	The NSA advises immediate patching, or taking systems offline if patching is not possible.	A rare public warning from the agency.
Oct 21	Germany, France, Belgium, the Netherlands, Finland and the Czech Republic pull government sites. Japan's prime minister posts a warning.	Governments choose a day offline over an exposed server.
Oct 22	Amazon calls PHP2Shell broadly exploited. Sansec says mass exploitation now looks less likely than feared. CISA has not yet listed either CVE.	Probing is widespread; confirmed damage is still being measured.
Oct 22, 10:00 a.m.	The original coordinated release time.	The patch beat its own schedule by a full day.

That timeline is a lesson in how little room any business gets. The original plan gave hosting companies, Linux distributions and agencies a quiet runway to prepare. The leak turned it into a footrace. When the patch window collapses from days to hours, the only businesses that come out clean are the ones that already know where their PHP lives.

Why did the NSA tell organizations to take websites offline?

The NSA told organizations to take systems offline only if they could not patch immediately, because PHP2Shell can let attackers take control of a server with no login at all, and the agency judged that cyber actors were likely to weaponize it.** An offline website loses a day of business. A compromised one can lose far more than that.

Al Jazeera, reporting with Reuters, described the advisory as a rare public warning from the agency.†† The NSA's guidance was specific: inventory every internet-facing service that relies on PHP, apply vendor patches, add enhanced logging, replace end-of-life PHP versions that cannot be patched, and pull a system offline until it can be fully fixed. The agency said the risk was serious enough to require immediate patching across U.S. government departments and agencies.**

Europe took the advice literally. Germany's Federal Ministry for Digital Transformation and Government Modernisation took some websites offline as a precaution. France's Ministry of the Interior deactivated the official websites of local administrative offices. Authorities in Belgium, the Netherlands, Finland and the Czech Republic shut down sites to apply the patch, and Japan's prime minister, Sanae Takaichi, posted a public warning on social media.††

There is a scene in Jaws, the 1975 original, where Mayor Larry Vaughn insists the beaches of Amity stay open for the Fourth of July because closing them would hurt business. Everyone in the theater knows how that decision ages. The NSA played the opposite role. It closed the beach. In 2004, City Bikes in Washington, D.C., made the same call with its own inventory and pulled tubular cylinder locks off its shelves before anyone forced it to.† Closing the beach looks like an overreaction right up until the moment it looks like the only adult decision in the room.

Kevin Beaumont, a widely followed security researcher, put it bluntly, calling PHP2Shell "one of the biggest vulns in years."§§ Security people are not a sentimental bunch. When the people who see a critical vulnerability every week start using superlatives, the rest of the business world should at least look up from the spreadsheet.

Is PHP2Shell being exploited right now?

Attackers are trying, and some started before the patch existed. Whether those attempts are succeeding at scale is still being measured, and the honest answer as of October 22, 2026, is widespread probing, limited confirmed damage and no reason to wait for certainty.

Amazon's threat intelligence team says its honeypot network, a fleet of decoy servers built to attract attackers, caught a first PHP2Shell exploitation attempt on October 17, four days before public disclosure, coming from a commercial anonymization network. Amazon now describes PHP2Shell as "broadly exploited in the wild."¶¶¶ Security firms Hadrian, Patchstack and Cloudflare all reported attempts in the hours before the fix shipped, and watchTowr observed mass exploitation attempts shortly after the patches were released, although none of the proof-of-concept code it saw circulating achieved full remote code execution.¶¶¶

The other side of the ledger matters too. On Wednesday afternoon, PHP Foundation executive director Elizabeth Barron told CNBC there was no evidence of working exploits yet, only "incomplete, misguided, and non-working generated ones."‖‖‖ On October 22, the e-commerce security firm Sansec revised its outlook and said mass exploitation now looks less likely than it expected on release day, because a real attack needs specific knowledge of the target server and the public exploits do not work against a default PHP installation.‡‡ As of October 22, the U.S. Cybersecurity and Infrastructure Security Agency had not added either CVE to its Known Exploited Vulnerabilities catalog.****

So which is it? Both. Not every Kryptonite lock in 2004 got picked. Most were never touched. But once the video existed, every owner had to assume a lock could be opened in five seconds, because thieves only need to be right once. The same logic applies here. Tenable, one of the largest vulnerability management firms, relays Amazon's recommendation that investigations start from at least October 17, not from the disclosure date.†††† A business that patched on Wednesday afternoon is in good shape. A business that patched on Wednesday afternoon and never checked whether someone walked in on Monday night is guessing.

Why did a flaw from 2012 take until 2026 to surface?

The flaw sat in PHP for about 14 years because it lived in the deepest, most-used parts of the engine, memory management and error handling, where bugs are hard to spot and harder to fix without breaking everything built on top. The first warning signs showed up in 2024, and the fix stalled for nearly two years before AI-assisted researchers proved how dangerous it was.‖

The PHP Foundation's own account is unusually candid. Its security team, which made decisions by consensus, developed several competing fixes for the memory problem, and each came with a trade-off: breaking backward compatibility, opening new paths for denial-of-service attacks, or requiring changes to third-party extensions that seemed impossible to coordinate. With no known path to remote code execution, and with only a small group of engineers who understand the engine well enough to touch it, work on a fix stopped and restarted for months. The Foundation called the delay a failure of both its decision process and its resources, and says it has since changed how those decisions get made.‖

That is 1992 all over again. New Cyclist printed the pen trick, and the industry kept shipping tubular cylinders for twelve more years, partly because nobody had shown the problem at scale and partly because changing a cylinder design across an entire product line is expensive and slow. Once Kryptonite finally moved, the company says, it re-engineered nine years' worth of products in a single year.§ Known-but-unproven risks are the most comfortable kind to ignore. They never show up on a quarterly report until the video drops.

There is a funding lesson buried in here, too. PHP runs government services, online stores, banks, media sites and a huge share of business software, yet the Foundation says security work on PHP itself still depends on a small group of foundation-funded developers and a little volunteer help.‖ Billions of dollars of commerce ride on a language maintained by a team that could fit in a conference room. Every business running on PHP is, in effect, a free rider on that team. Most never thought about it until this week.

What does AI have to do with PHP2Shell?

AI did not create PHP2Shell, but AI-assisted research is what finally proved the flaws were exploitable, and the same tools are making new flaws easier to find for attackers and defenders alike. AI is the new Bic pen: cheap, everywhere and indifferent to who is holding it.

Wiz, the security firm owned by Alphabet, said the findings rank among the most severe ever found in PHP and "arguably in software history," and that proving the flaws were exploitable took a chain of steps at the edge of what human researchers could practically achieve.†† Read that carefully. The flaws had been sitting there since 2012. What changed was not the lock. What changed was the price of testing every lock on the rack.

The PHP Foundation says it has used AI tools from Anthropic and OpenAI to scan PHP and to validate incoming reports. It has published 15 CVEs since July 1, 2026, and worked through more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce.‖ Its summary of the new reality is one sentence long: "Tools now find bugs faster than ever, for defenders and attackers alike."‖

The broader numbers say the same thing. Verizon's 2026 Data Breach Investigations Report, built on more than 22,000 confirmed breaches, found that exploiting vulnerabilities is now the most common way attackers get in, at 31 percent of initial access, ahead of phishing at 16 percent and stolen credentials at 13 percent. It is the first time vulnerabilities have taken the top spot. Meanwhile, organizations fully fixed only 26 percent of the vulnerabilities on CISA's known-exploited list, down from 38 percent the year before.‡‡‡‡ Attackers are getting faster. Defenders are getting slower. That gap is the whole story.

Here is the hot take. For twenty years, small and midsize businesses have been protected less by good security than by obscurity. Nobody was going to spend a week of expert human time picking the lock on a regional firm's website. That moat is draining. When finding a flaw costs a few dollars of computing time instead of a few weeks of a specialist's salary, every website on the rack is worth a try. In 2004, a pen that once sold for 29 cents beat a lock that came with an anti-theft guarantee worth up to $3,500.‡ The price of the pick just dropped again, and this time it does not even need a hand to hold it.

Is a WordPress site affected by PHP2Shell?

A WordPress site is exposed to PHP2Shell if the server it runs on uses an unpatched version of PHP. WordPress itself is not the bug, and updating WordPress core, the theme or the plugins does not fix it, because the repair happens at the server level, inside PHP.§§§

This is where a lot of well-meaning owners will go wrong. The reflex after any security headline is to log into the WordPress dashboard and click every update button in sight. That is good hygiene, and it accomplishes nothing for PHP2Shell. The fix is updating PHP on the server and restarting the services that run it, which is a hosting task, not a website task.§§§ Plenty of owners have never seen the server their site lives on. Some could not name the company that hosts it.

The version picture is uncomfortable. WordPress.org's own statistics, as reported by the newsletter The Repository and summarized by the threat intelligence firm CybelAngel, show 35.1 percent of WordPress sites running a PHP version the PHP project no longer supports, including 16.46 percent on PHP 7.4.§§§ Across the whole PHP web, W3Techs finds version 8 on 62.5 percent of PHP websites,¶ which leaves more than a third of PHP sites on older generations. Those are the cyclists who never mailed in the old lock.

Managed WordPress hosts moved fast this week. Some reportedly switched off a PHP feature called session upload progress as a stopgap,§§§ and Cloudflare's emergency rules now sit in front of sites on its network.§§ Those are speed bumps. PHP's maintainers say there are no complete mitigations and that updating is the only safe choice.§§§ A speed bump is useful while the road gets repaved. Nobody should mistake it for the pavement.

What happens to websites running old versions of PHP?

Websites on PHP 8.1 or older get no official PHP2Shell release. The PHP project shipped fixed versions only for its four supported branches, 8.2 through 8.5, and offered minimal source code patches for 7.4, 8.0 and 8.1 that a normal hosting account cannot apply. Versions 7.3 and older get nothing from the PHP project at all.§§§

That would be a footnote if old PHP were rare. It is not. Internet scan counts from the search engine Shodan, published by the security firm Mallory and summarized by CybelAngel, show about 2.24 million internet-facing hosts advertising PHP. Of the ones that report a version, 59 percent, or 883,717 out of roughly 1.5 million, run a branch with no official fix coming. The United States leads the world with 228,770 of those hosts.§§§ Another 740,000 or so hide their version entirely, and shared hosting stacks many websites behind a single address, so real exposure is likely larger, although some Linux distributions quietly backport fixes into older packages under the old version number.§§§

Kryptonite's exchange program is the cautionary tale here. The company eventually replaced more than 400,000 locks for free in 21 countries.§ But in late October 2004, about six weeks after the video, the parent company, Ingersoll Rand, estimated roughly 500,000 affected locks were still in use and said it had received 38,900 back. It also took a $10 million write-down for the mess.§§§§ That is fewer than 8 locks in 100 returned in the first rush, from owners who had every reason to care and a free replacement waiting at the counter. An exchange program only works when owners show up. A patch only works when someone applies it.

The calendar is not helping. PHP 8.2 receives security fixes only through December 31, 2026.§§§ A business that scrambles onto 8.2 this week has bought itself about ten weeks before it is back on an unsupported branch. The right move is a planned upgrade to a currently supported version, tested against the website's plugins, forms and integrations, not a patch-and-pray.

Who is responsible for patching PHP on a business website?

Whoever controls the server is responsible for patching PHP. On hosted platforms such as Shopify, Squarespace and Wix, that is the platform vendor. On managed WordPress hosting, it is usually the host, sometimes with the owner choosing the version. On a self-managed server or cloud account, it is whoever holds administrator access, which is often an agency, a former developer, or nobody at all.

That last answer is the one that keeps me up at night. In Tocobaga's website rebuilds, the question that stalls the most kickoff meetings is the simplest one: who has the hosting login? Too often the answer is the agency that built the site six years ago, a freelancer who moved to Denver, or an IT contractor nobody has called since the pandemic. The business believes it owns its website. In practice it is renting one from a landlord it cannot reach, and the landlord holds the only key to the lock that just got picked.

Concentration adds a twist. CybelAngel's analysis puts Amazon at about 293,480 PHP hosts, Hostinger at about 142,401 and Alibaba Cloud at about 81,078, which makes provider-side patching decisive for huge numbers of sites at once.§§§ A single hosting company's Wednesday afternoon can decide the security of thousands of businesses that have never heard its name. That works fine when the host is responsible for PHP. It becomes a problem when the business sits on a bare cloud server and assumes the cloud company handles everything. Cloud companies rent out the building. They do not lock the apartment doors.

In Tocobaga's advisory work, this blind spot grows with complexity. The platform company that bought six competitors now owns six websites on six hosts with six different PHP versions. The firm with a client portal runs it on a server nobody has logged into since launch. The online store's checkout plugin depends on a PHP version the host retired last year. The manufacturer's quote request form lives on a microsite a trade show vendor built in 2019. None of those businesses did anything reckless. They just never wrote down who checks the locks.

What should a business do about PHP2Shell this week?

A business should inventory every website and web tool it runs, confirm who controls each server, verify the PHP version each one actually serves, patch or upgrade, and then check for signs of intrusion back to at least October 17. The order matters, because nobody can patch a server nobody can find.

Here is the checklist Tocobaga uses, in order:

• Inventory every web property, not just the main site: landing pages, microsites, the careers page, the old site still live on a forgotten subdomain, the client portal, the online store, and any vendor appliance with a web login.

• Find out who holds the keys for each one: hosting, domain registrar, DNS, content delivery network and administrator accounts. Move every login into a business-owned password manager.

• Ask the host, in writing, which PHP version each site serves and whether it is now on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor-backported equivalent.§§ The version that matters is the one serving live web requests, which can differ from what a command-line check reports.§§§

• Patch, then restart. Updating PHP without restarting the services that run it can leave the old, vulnerable code loaded in memory.§§§

• If a site runs PHP 8.1 or older, schedule an upgrade now, or get a backported fix from the Linux distribution or a long-term support vendor. Until then, restrict access or take the site offline, exactly as the NSA advised.**

• Put a web application firewall in front of anything public. It is a speed bump, not a fix, but speed bumps matter while the real fix gets scheduled.

• Look for compromise going back to at least October 17: unfamiliar files in the web folders, new administrator accounts, unexpected scheduled tasks and odd outbound connections.††††

• After any change, test the money paths: contact forms, booking tools, checkout, CRM connections and analytics tags. A patched site that silently stops sending leads is just a different kind of outage.

• Write down who calls whom next time. The next leak will not wait for a meeting to get scheduled.

That list takes an organized business an afternoon. It takes a disorganized one a week, most of it spent hunting for passwords. The difference between those two businesses has nothing to do with PHP. It has everything to do with ownership.

What does a website outage or breach actually cost a small business?

A short planned outage usually costs a small business a few days of leads, while a breach can cost months of disruption, cleanup and lost trust. IBM's 2026 Cost of a Data Breach Report puts the average U.S. breach at $11.5 million and the global average at a record $4.99 million, with breaches taking an average of 247 days to identify and contain.‖‖‖‖

Those averages are skewed by large companies, so here is the math at a smaller scale. Take a professional services firm whose website produces 44 qualified leads a month, about two per business day. The firm closes 1 in 8, so 5.5 new clients a month, at an average first-year value of $8,000. The website is feeding $44,000 a month in new business. Now take it offline for five business days to upgrade an old PHP version that turned out to be harder than expected. Five of roughly 22 business days is about 23 percent of the month: roughly 10 leads, 1.25 clients and $10,000 of first-year revenue that never shows up. That is the price of doing it the slow, safe way.

Now the bad way. IBM found that breaches lasting more than 200 days cost an average of $5.65 million, compared with $4.32 million for breaches contained faster.‖‖‖‖ A small firm will not hit those totals, but the shape holds: the longer an intruder sits inside, the more it costs. A compromised website can be used to serve malware to visitors, inject spam pages that wreck search rankings, or skim payment data, and Google can flag a hacked site with a warning in its search results. Rebuilding a reputation takes longer than rebuilding a server, and nobody has ever gotten a referral from a security warning.

Put the two numbers side by side. Ten thousand dollars of delayed revenue for a planned fix, versus an open-ended bill for an unplanned one. That is not a technology decision. It is a capital allocation decision, the same kind owners make every week about insurance, equipment and payroll. The website is a revenue asset. It deserves the maintenance budget of one.

Should a business leave WordPress or PHP after PHP2Shell?

Not automatically. PHP2Shell is a reason to know exactly who maintains a website's server and to keep it on a supported version, not a reason to panic-migrate. The right platform depends on who will own patching, how custom the site needs to be and what the business can realistically maintain.

The market has been making this decision on its own for years. Since 2014, hosted platforms such as Shopify, Wix and Squarespace have grown from under 1 percent of the content management market to more than 17 percent combined, while the self-hosted PHP alternatives Joomla and Drupal shrank from nearly 15 percent to under 3.†††, ‡‡‡ Owners who did not want to be responsible for servers voted with their feet. Full disclosure: Tocobaga is a Squarespace Gold Partner, so weigh this paragraph accordingly. Hosted platforms trade some control for having someone else handle the server. Self-hosted WordPress trades more responsibility for more flexibility. Neither choice is wrong. Not knowing which trade a business has made is wrong.

Kryptonite did not stop making locks in 2004. It moved its lineup to disc cylinders that a pen cannot turn,† re-engineered its products and introduced a color-coded security rating so buyers could see what they were getting.§ The company's first statement to the press ended with a line that sounded like a movie trailer: "The world just got tougher and so did our locks."† Bold talk from a company that had just been beaten by stationery, but the instinct was right. The answer to a picked lock is not giving up on locks. It is a better cylinder, a clear rating and a schedule for checking it.

Tocobaga's approach to website ownership follows the same logic. The client owns every account, login and asset from day one, so there is never a mystery about who holds the key. Work is billed at a flat fee, contracts never auto-renew, and when Tocobaga is not the right fit for a business, Tocobaga says so and points it somewhere better. If the answers to who holds the logins and which PHP version is serving are fuzzy, an intro call at (813) 534-1261 or through SolvingHow.com is a reasonable place to start.

Marcel Bich never meant to build a lock pick. Rasmus Lerdorf never meant to build the engine under 70 percent of the web. The Bic Cristal is still on sale, still cheap and still everywhere, and somewhere in the world a person is holding one right now. The tools that found PHP2Shell are not going back in the box either. The businesses that come out of this week fine will not be the ones that got lucky. They will be the ones that knew which lock was on the door, who held the key, and who was coming by to check it.

What are CVE-2026-109618 and CVE-2026-109619?

CVE-2026-109618 and CVE-2026-109619 are the two critical PHP vulnerabilities known together as PHP2Shell. The first corrupts memory when a request hits PHP's memory limit at the wrong moment; the second reuses memory left over from an earlier request after a fatal error. Either can allow an unauthenticated attacker to run code on a web server. Both were rated 9.2 under CVSS v4.0 and were fixed on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Does updating WordPress plugins fix PHP2Shell?

No. PHP2Shell is a flaw in PHP, the language WordPress runs on, not in WordPress core, themes or plugins. Updating plugins is good practice, but it does not change the PHP version on the server. The fix is upgrading PHP on the server to a patched release and restarting the services that run it, a job usually handled by the hosting company or whoever administers the server.

Which PHP versions are patched for PHP2Shell?

The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published on October 21, 2026. PHP 7.4, 8.0 and 8.1 received only minimal source code patches meant for people who compile PHP themselves, and PHP 7.3 and older received nothing from the PHP project. Some Linux distributions and long-term support vendors ship their own backported fixes for older versions, often without changing the version number.

How can a business tell which PHP version its website runs?

The most reliable method is asking the hosting provider, in writing, which PHP version serves the live site, because the version handling web requests can differ from the one a command-line check reports. Many hosting dashboards also show the PHP version for each site. Businesses on hosted platforms such as Shopify, Squarespace or Wix do not manage server software directly, because the platform vendor handles server patching.

Can a web application firewall stop PHP2Shell?

A web application firewall can block known attack patterns and buy time, and Cloudflare deployed emergency rules for PHP2Shell to every plan, including free accounts. It is not a complete fix. PHP's maintainers said there are no complete mitigations and that updating PHP is the only safe choice. A firewall belongs in front of a patched server, not in place of one.

How far back should a business check for a PHP2Shell compromise?

Security researchers recommend looking back to at least October 17, 2026, the date Amazon's threat intelligence team recorded the first known PHP2Shell exploitation attempt, four days before public disclosure. Warning signs include unfamiliar PHP files in web folders, new administrator accounts, unexpected scheduled tasks, unusual outbound network connections and web server processes that launch command shells or download tools.

Sources

*

Wikipedia. "Bic Cristal." Accessed October 22, 2026. Launched December 1950; 29 cents in the U.S. market in 1959; 100 billionth pen sold September 2006; held in the Museum of Modern Art's permanent collection. https://en.wikipedia.org/wiki/Bic_Cristal

†

BikeBiz. "The Pen Is Mightier Than the U-Lock." September 16, 2004. Chris Brennan's Bikeforums post and video; the 1992 New Cyclist article; Kryptonite's statement on tubular cylinders; City Bikes pulls stock. https://bikebiz.com/the-pen-is-mightier-than-the-u-lock/

‡

Felten, Edward W. "Bike Lock Fiasco." Center for Information Technology Policy, Princeton University, September 17, 2004. https://blog.citp.princeton.edu/2004/09/17/bike-lock-fiasco

§

Kryptonite. "Company History." Accessed October 22, 2026. The 1972 Greenwich Village signpost test; the 2004 exchange of more than 400,000 locks in 21 countries. https://www.kryptonitelock.com/en/company-history.html

‖

The PHP Foundation. "Today's PHP Security Release, and How We're Strengthening PHP Security." October 21, 2026. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

¶

W3Techs. "Usage Statistics of PHP for Websites." Survey of August 4, 2026. https://w3techs.com/technologies/details/pl-php

**

National Security Agency. "NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities." Press release, October 21, 2026. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4630238/nsa-advisory-critical-patches-recommended-for-php-vulnerabilities/

††

Farooq, Umar, and Reuters. "World Leaders Warn of Security Flaws Found in PHP Programming Language." Al Jazeera, October 22, 2026. https://www.aljazeera.com/news/2026/10/22/world-leaders-warn-against-security-flaw-found-in-php-computer-programming

‡‡

Sansec. "PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619)." Updated October 22, 2026. https://sansec.io/research/php2shell

§§

Help Net Security. "PHP2Shell: Critical PHP Vulnerabilities Patched, Update Now!" October 21, 2026, updated October 22, 2026. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/

‖‖

W3Techs. "Comparison of the Usage Statistics of PHP for Websites." Survey of July 15, 2026. https://w3techs.com/technologies/comparison/pl-php

¶¶

The PHP Group. "History of PHP." PHP Manual. Accessed October 22, 2026. https://www.php.net/manual/en/history.php.php

***

W3Techs. "Usage Statistics and Market Shares of Content Management Systems." Survey of August 24, 2026. https://w3techs.com/technologies/overview/content_management

†††

W3Techs. "Market Share Yearly Trends for Content Management Systems." January 2014 through May 2025. https://w3techs.com/technologies/history_overview/content_management/ms/y

‡‡‡

W3Techs. "Market Share Trends for Content Management Systems." Monthly data through July 25, 2026. https://w3techs.com/technologies/history_overview/content_management

§§§

Koonthamattam, Leah. "2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming: What We Know About php2shell." CybelAngel, October 21, 2026. Cites Shodan counts published by Mallory and WordPress.org statistics reported by The Repository. https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/

‖‖‖

CNBC. "Why Governments Pulled Websites Offline over the Decades-Old PHP Programming Language." October 22, 2026. https://www.cnbc.com/2026/10/22/php2shell-vulnerability-what-is-it-and-is-your-data-at-risk.html

¶¶¶

Arghire, Ionut. "PHP2Shell Exploitation Started Days Before Patches." SecurityWeek, October 22, 2026. https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/

****

watchTowr. "Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 and CVE-2026-109619)." Updated October 22, 2026. https://watchtowr.com/intelligence/php-cve-2026-109618-faq/

††††

Tenable. "php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions About Critical PHP Remote Code Execution Vulnerabilities." Updated October 22, 2026. https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

‡‡‡‡

SC Media. "Verizon DBIR 2026: Vulnerability Exploits Top Initial Access as Patching Coverage Falls." May 2026. Summary of Verizon's 2026 Data Breach Investigations Report, more than 22,000 confirmed breaches analyzed. https://www.scworld.com/news/verizon-dbir-2026-vulnerability-exploits-top-initial-access-as-patching-coverage-falls

§§§§

SGB Media. "Kryptonite Parent Company Takes $10 Million Hit from Lock Snafu." October 25, 2004. https://sgbonline.com/kryptonite-parent-company-takes-10-million-hit-from-lock-snafu/

‖‖‖‖

Baker Donelson. "Ten Takeaways from IBM's 2026 Cost of a Data Breach Report." 2026. Summary of IBM's 2026 Cost of a Data Breach Report. https://www.bakerdonelson.com/ten-takeaways-from-ibms-2026-cost-of-a-data-breach-report