PHP2Shell and the End of Unmanaged Open Source in Higher Education

Arbisoft Editorial TeamLast Updated on November 2, 2026

20-21 Min Read TimeAdd as preferred on Google

On the afternoon of October 21, 2026, the Austrian student portal studium.at kept a running list of universities that had taken systems offline after the PHP2Shell disclosure. The same entries kept recurring: Moodle, online forms, survey tools and project websites, the sites research projects build and then leave running. The list reads like a map of where PHP lives on a university campus.

PHP2Shell is the name for two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, patched on October 21, 2026. Both allow an attacker to run code on a web server without logging in, and Wiz reports that every PHP version back to 5.4 is affected by at least one of them.

Most guidance published since then treats PHP2Shell as a finding problem: build an inventory, patch what turns up, restart the workers, get vendors to confirm in writing. The advice is correct, and for universities it stops one step short. The systems hardest to find are the ones nobody owns. An inventory records that a system exists. It says nothing about who will maintain it next year.

PHP2Shell affects every sector that runs PHP. Universities stand out because they carry a long tail of PHP systems nobody is funded to maintain: lab tools, departmental sites, digital archives, booking systems built on grants that ended years ago. That long tail of unowned software existed well before PHP2Shell. The vulnerability showed what happens once AI makes neglected code worth attacking.

The underlying problem in higher education is ownership, and AI has removed the obscurity that used to hide it.

How AI made a dormant PHP flaw exploitable

The flaw behind PHP2Shell was first spotted in 2024. According to the PHP Foundation, exploitation was "theorized, but no concrete vectors were found," and issues with clearer impact took priority. That was ordinary triage. Maintainers of large codebases make the same call every week, and a theoretical bug with no known exploit usually loses to a real bug with a known one.

AI changed the price of that bet. Wiz, one of the research teams that found the PHP2Shell flaws, says frontier models let its researchers develop working exploits and adapt them to new applications in hours, and that complexity may no longer be a meaningful barrier. By Wiz's account, one researcher finished in about a week work that would previously have taken a top team months.

For two decades, the effective security model for a research group's PHP server was economics. Nobody capable of writing a memory-corruption exploit would spend three weeks on it to deface a telescope scheduling page. The patching policy, in practice "whenever the one person with the password gets round to it," never had to carry much weight.

Security by obscurity worked like a spare key under the doormat in a town where nobody checked doormats. AI has made checking every doormat cheap.

As of October, 2026, no published source had confirmed that attackers used AI against PHP2Shell. The AI in the PHP2Shell story belongs to the researchers who found and proved the flaws. The structural point holds anyway: once turning a patch into a working exploit gets cheap, obscure campus systems lose the protection that cost used to give them.

PHP2Shell exploitation status

PHP2Shell exploitation is confirmed, and so far it has been narrower than the first headlines predicted. CISA added both CVEs to its Known Exploited Vulnerabilities catalog, the US government's list of flaws confirmed as exploited in real attacks, on October 26. On October 29, Palo Alto Networks' Unit 42 confirmed a campaign that chained PHP2Shell with a Linux kernel flaw to gain root access on firewall management interfaces exposed to the internet. Earlier that week, Unit 42 had withdrawn a separate attribution after it could not tie an intrusion to these CVEs.

The first confirmed PHP2Shell victims fit the ownership pattern this article describes. They were appliances that bundle PHP, patched on a vendor's schedule, with management pages reachable from the public internet. A runtime somebody else maintains, behind an interface nobody restricted, is a combination found all over campus networks.

Taking Moodle offline for a day on October 21 was a sound decision made with incomplete information, which describes most good incident decisions. Moodle HQ did the same with its own sites. The harder question for university leadership is why it took a national alert to establish what was running.

Why universities run PHP systems nobody owns

Universities fund software like research, as a project with an end date, and then run it like infrastructure, indefinitely. When the grant ends or the developer graduates, the server usually stays online.

Consider a composite example built from patterns common across higher education. A postdoc builds a lab-booking tool in 2016 on PHP 7.0. It moves from a spare desktop to a departmental virtual machine, and people come to rely on it. In 2019 the postdoc takes a faculty post elsewhere. The tool keeps working, so nobody touches it. By 2026 it has outlived two department chairs and a building renovation. It runs PHP 7.2, answers requests from the public internet, and lives on a subdomain central IT has never seen.

Every decision in that story was reasonable. The postdoc built something useful, the department kept using it, and central IT could not patch a server it did not know about. The outcome is still a problem, and since nobody did anything wrong, disciplining people will fix nothing. The cause is structural.

Research on shadow IT in higher education supports the pattern. A UMBC study published in Cryptologia combined a case study with a survey of IT professionals at universities, colleges and community colleges, and found that shadow-IT security incidents correlated with decentralized IT and with legacy systems, among other factors. The authors note that independent research grants give faculty the money to build systems outside central review. Their case study, a grants-management system built around 2010 inside a chemistry department, carried cross-site scripting and SQL injection flaws typical of software nobody had reviewed in years. A smaller 2023 interview study of eleven Dutch higher-education security professionals named outdated software and visibility gaps as the recurring risks.

Web-wide data points the same way. In August 2026, W3Techs found about 37% of the PHP websites it could identify running PHP 7 or PHP 5, both long out of support. That figure undercounts, because W3Techs groups the unsupported 8.0 and 8.1 releases under "8." Separate scans reported by Mallory and Recorded Future found most version-disclosing PHP hosts on end-of-life branches: about 884,000 of 1.5 million in one count, about 758,000 of 1.1 million in the other. Version banners are imperfect, since Linux distributions sometimes backport fixes under an old version number, but two independent counts in the same range are hard to dismiss.

No dataset shows that universities are more exposed than banks or hospitals, and this article makes no such claim. The conditions the UMBC study linked to incidents (decentralized IT, legacy systems, grant-funded builds) simply describe most research universities.

Well-run learning platforms show a related pattern. In a mature Open edX or Moodle deployment, the core platform rarely causes trouble, because thousands of students notice the moment it breaks. Risk collects in the satellites: the WordPress marketing site, the reporting plugin one department commissioned, the integration built for a single course in 2018.Open edX runs on Python and Django, so its core was never in PHP2Shell's path, yet an Open edX institution can still carry PHP exposure through the systems around it. The best-maintained system on campus tends to be the one with the most users. The worst-maintained tends to have about six, because six people complaining is just a Tuesday.

The three-clock model of campus software maintenance

Every campus software system depends on three support timelines that run independently. An ownership gap opens when one timeline runs out and nobody notices, and most PHP exposure on campus sits inside such a gap.

1. Ownership clock. How long someone is funded and responsible for the system: a grant, a contract, a graduate student's remaining time on campus. The ownership clock usually runs out first.
2. Application clock. How long the software itself is supported: a Moodle LTS release, a Drupal major version, a plugin whose maintainer still answers issues.
3. Runtime clock. How long the layer underneath is supported: PHP, the operating system, the database.
    

In the lab-booking example, the ownership clock stopped in 2019. The application and runtime clocks kept running with nobody watching. The runtime expired, then the application, and nothing happened for years because nobody attacked it. Silence passed for safety.

The three clocks drift apart even when everyone does their job. Moodle's documentation lists Moodle 4.5 LTS as requiring PHP 8.1 to 8.3, and Moodle 4.5 is supported into 2027. PHP 8.1 stopped receiving fixes from the PHP project at the end of 2025. A university running a supported Moodle on an allowed PHP version could therefore have met PHP2Shell on an unpatched runtime. Moodle 4.1 LTS requires PHP 7.4 to 8.1, all of which are already end of life upstream.

Different projects set the application and runtime clocks on different calendars, and neither answers for the other's schedule. The gap lands on whoever runs the server. Where nobody clearly does, it lands on whoever is on call the night an advisory drops.

Ownership, in the three-clock model, belongs to the person who gets the call when a system breaks. For a surprising number of campus systems, that call goes to a help desk that has never heard of the system.

Obscurity covered these gaps for years. It was luck with a long track record.

PHP 8.2 security support ends December 31, 2026

PHP 8.2.35 contains the PHP2Shell fix, and PHP 8.2 stops receiving security fixes on December 31, 2026. End of life means the PHP project publishes no further security fixes for that branch, so any flaw found after December 31 leaves PHP 8.2 where PHP 8.1 sits today. An institution that ended its emergency weekend on 8.2 has renewed a passport that expires in nine weeks.
 

A third, configuration-dependent PHP flaw in the session upload progress feature was acknowledged on October 23. It will be fixed in the next regular PHP release, with no emergency patch planned, and PHP's interim advice is to switch the feature off.

Emergency patching is the most expensive form of maintenance there is. The whole bill arrives at once, at the worst moment, and is paid by people who had planned other work. Scheduled upgrades cost the same in installments.

When legacy Moodle or Drupal code cannot run on supported PHP

When an application cannot run on a supported PHP version, the PHP2Shell patch becomes a migration, and it needs a plan.

Patch guides treat this as an edge case. In higher education it is common. A legacy Moodle fork, a custom Drupal module untouched since its developer left, or a database front end written against PHP 5 behavior can all break on a supported PHP version. Upgrading the runtime means fixing the application, which needs someone who understands the application, which leads back to the ownership clock. Most roads in this article end there.

While the migration is planned, three options remain: a vendor backport if the Linux distribution offers one, the PHP security team's source backport for PHP 7.4 through 8.1 for anyone who builds PHP from source, or removing the system from the public internet. Below PHP 7.4 there is no backport.

Version numbers mislead in both directions. A distribution package can carry the fix under an old version string, and a self-built PHP with the source backport still reports its old version. The package changelog, checked for CVE-2026-109618 and CVE-2026-109619, is the reliable test.

Why a SaaS-only response to PHP2Shell fixes the wrong systems

For commodity systems, SaaS is often the right move. As a campus-wide response to PHP2Shell, a SaaS-everything plan fixes the systems that were least at risk. SaaS removes runtime patching from the institution's workload, but no vendor sells the long tail of research tools and departmental software, and every migration trades some control for licensing cost and lock-in.

A university on a hosted commercial LMS did not spend October 21 patching that LMS's runtime. The vendor did it. That benefit is real and deserves plain acknowledgment.

A SaaS-everything plan moves the LMS, the student information system and perhaps the main website. Those were usually the best-maintained systems on campus already. The telescope scheduler stays put, because nobody sells a telescope scheduling platform with an enterprise tier. The plan relocates problems that were under control and leaves the real exposure where it was.

SaaS fits best when a function is a commodity with mature vendors (email, payroll, ticketing), customization adds nothing, and no internal team can own it. Arbisoft applies the same test in its own open-source engineering: open-source choices are made deliberately, and where a proprietary tool is the better fit, the right move is to say so.

What a proprietary contract buys is accountability. Someone else is responsible for patching. Institutions can build that accountability for themselves.

How to triage PHP systems after PHP2Shell

For each PHP system found, decide who will answer for its three clocks, then choose one of four outcomes: own it, contain it, consolidate it onto a managed platform, or retire it.

The triage table leaves four judgment calls open.

Public-by-design systems. A digital humanities archive or a public dataset portal exists so outsiders can reach it, and containment defeats that purpose. Once active work ends, freezing the project as a static HTML export keeps the scholarship online and removes the runtime clock entirely. Infrastructure rarely offers a cleaner trade.

Systems nobody will switch off. Expect at least one system that nobody can explain and everybody fears turning off. Taking it offline behind a notice with a contact address settles the matter. If a month passes without a call, it can go.

Firewalls in front of contained systems. A web application firewall (WAF) helps while a system waits, but it only inspects traffic routed through it, and Cloudflare reported attackers adjusting PHP2Shell payloads to slip past its rules. WAF rules buy time and little else.

Credentials on exposed systems. One PHP2Shell path reads server memory, which can include passwords, tokens and API keys, according to Wiz. Any system that sat unpatched on the public internet needs its credentials rotated, whatever the logs show.

How universities can prevent the next ownership gap

Each change below makes the secure option the easier one and keeps one of the three clocks from expiring unnoticed.

Paved-path platforms that rebuild apps automatically

A paved path is a standard, centrally maintained way to deploy applications. The platform team keeps the runtime current, and every application on it is rebuilt and redeployed whenever the base changes. The paved path keeps the runtime clock current for every department at once.

Containers alone do not provide this. A container built from a base image pinned two years ago ships two-year-old PHP, only more portably. The protection comes from automated rebuilds and a team that owns the base image.

Presentation matters as much as architecture. A department head will resist "central IT now controls your server" and welcome "nobody in your department will have to think about PHP again." The 2023 Dutch interview study made a related recommendation: support researchers and educators with IT they actually want to use. If the paved path is slower than spinning up a virtual machine, people will spin up virtual machines, and the institution will run this inventory again in five years.

Some research software needs dependencies no standard platform supports. An escape hatch with conditions handles this better than a ban. A team can leave the paved path if it names an owner and accepts responsibility for all three clocks in writing. Few teams take the offer once they read the conditions.

Public internet access by exception

Most departmental systems serve people who already hold campus credentials, so they have no need to accept traffic from the whole internet. An identity-aware proxy, which checks a user's campus login before passing any request to the application, keeps those systems available to their users and out of reach of internet-wide scanning. Restricting public access contains the damage when any of the three clocks runs out.

TU Wien did something similar on October 21, closing its websites to outside traffic while keeping them usable on the campus network and over VPN. Unit 42's advice for the PHP2Shell firewall campaign follows the same logic: restrict management access to trusted internal addresses.

Public access by exception is the cheapest change on the list. An unmaintained system stays unmaintained, but it stops being public, which turns a potential incident into a maintenance ticket.

Repositories and dependency scanning for every codebase

A codebase outside a repository with automated dependency scanning will reach the end of its application clock without anyone noticing. Dependabot, Snyk and similar tools flag outdated or vulnerable dependencies well before an emergency. Arbisoft treats this as a baseline for production work, with every open-source dependency tracked, versioned and kept current against CVEs and security advisories. This is routine work, and routine work is what keeps software alive.

Deployment by FTP, or by editing files directly on a server, also has to go. When code exists only on the server, nobody can say what it contains.

Maintenance funded as an operating cost

Maintenance needs a budget line. The simplest rule is that no new public-facing system is approved unless someone is funded to own it for its expected life. That rule keeps the ownership clock running and records the real cost of a system at the moment of approval. Arbisoft makes a similar argument in its brief on why legacy modernization is a business decision.

Where internal teams lack capacity for flagship platforms such as Moodle, Open edX or Drupal, specialist partners can carry upgrade, backport and dependency work while the institution keeps ownership of its code and data. That arrangement preserves the independence that drew the institution to open source, which a blanket move to SaaS gives up.

PHP itself shows the same pattern at a larger scale. The PHP Foundation called its delay in fixing the 2024 finding "a structural failure," citing its decision process and lack of resources. On disclosure day, a widely used volunteer-maintained package repository told users it would have no updates that day. Universities rely on that volunteer layer, then run one of their own (the postdoc, the graduate student, the staff member who "knows the server") and expect it to hold.

Open edX offers a useful contrast. Arbisoft has worked with edX engineers since 2013 and has contributed more than 3,000 pull requests to Open edX over more than a decade, a history described in Arbisoft's edX case study. The lesson from that work is plain. Platforms stay healthy when upgrades are scheduled, dependencies are tracked against advisories, and watching all three clocks is somebody's job. Arbisoft's open-source practice places the risk in the operating team's ability to patch, upgrade and extend the software responsibly.

Five steps universities can start with current staff

1. Inventory internet-facing PHP first, including vendor products and appliances that bundle it, as the FBI's PHP2Shell guidance recommends.
2. Give every system a named owner or a retirement date. "We'll look into it" counts as a retirement date with extra steps.
3. Contain every system on end-of-life PHP until it has a plan.
4. Schedule each PHP 8.2 system's move to PHP 8.3 or later before December 31, 2026.
5. Adopt one rule for the future: no new public system without a named owner and a place on the paved path.

Steps one to four clean up the past. Step five decides whether this inventory has to be repeated.

AI coding tools and the next wave of unowned campus software

Faculty and staff now build campus software with AI coding assistants. A department administrator can produce in an afternoon what once took a postdoc a semester. That is good news for academic work, and it also opens a fresh ownership gap, written faster and often by someone who has never had reason to think about a runtime.

The technology that made old code cheap to exploit is making new code cheap to create. With a paved path in place, AI-built tools land on it and inherit its maintenance from the first day. Without one, every university is building its next PHP2Shell inventory in real time.

Ownership as a security control

Innovation without ownership is deferred risk. Universities have always been good at the first half of that sentence. PHP2Shell and the AI economics behind it remove the option of skipping the second.

Open source remains how universities keep control of their tools and their data, and that independence is worth defending. What has to change is the habit of treating maintenance as somebody else's job. Institutional autonomy and real security reinforce each other once someone owns the clocks.

If you run an open-source LMS, reach out to Arbisoft for a security audit and information security implementation to reduce your risk.
 

PHP2Shell FAQ for universities

Does updating Moodle fix PHP2Shell? Moodle updates leave PHP2Shell in place, because the flaw lives in PHP itself. Whoever controls the server's PHP must install a patched release such as PHP 8.3.36.

Is Open edX vulnerable to PHP2Shell? The Open edX core runs on Python and Django, so PHP2Shell never touched it. PHP sites and plugins deployed around an Open edX platform still need checking.

Is PHP2Shell being exploited in the wild? CISA confirmed active exploitation on October 26, 2026, adding both CVEs to its Known Exploited Vulnerabilities catalog. Three days later, Unit 42 verified attackers rooting exposed firewall management interfaces with PHP2Shell.

Is a web application firewall enough to stop PHP2Shell? A WAF buys time and nothing more. Attackers have already altered payloads to slip past PHP2Shell rules, and directly reachable servers bypass the firewall entirely.

What should universities do with servers still on PHP 7? Pull them off the public internet until they are upgraded, frozen as static sites, or retired. PHP 7.4 has a source backport, and anything older has no fix at all.

When does PHP 8.2 lose security support? PHP 8.2 loses security support on December 31, 2026. Servers patched to 8.2.35 for PHP2Shell should reach PHP 8.3 or later before then.

Is open source less secure than proprietary software? Security depends on maintenance far more than on licensing. Unmaintained software fails the same way under either model, as PHP2Shell's unpatched servers show.