Was this forwarded to you by a friend? Sign up, and get your own copy of the news that matters sent to your inbox every week. Sign up for the On EdTech newsletter. Interested in additional analysis? Upgrade to the On EdTech+ newsletter.
In June I wrapped up my coverage of the Canvas data breach with a post about AI, cybersecurity, and the new world we had entered. My argument was that increasingly capable agentic AI represented a paradigm shift in the economics of attacking software.
Reading a large codebase closely enough to find detailed weaknesses was never impossible. For a target like EdTech, however, it was usually not worth the time, because the data was only moderately valuable and the labor was real and better spent elsewhere. What changed last year is not that the work became possible but that it became cheap, and cheap enough to move attacking a mid-value sector out of what was often in the “not worth it” column and into the “worth it” one. The capability had been visible earlier, in autonomous systems that were already finding real vulnerabilities and outscoring human researchers through 2025, but the broad, low-cost, reliable version is recent. It is the cost, and not the novelty, that moves the calculation.
I concluded that post with a warning.
The new game is already being played. EdTech is in it whether or not the community has fully registered the change.
Last week’s disclosure of two critical vulnerabilities in PHP, the software underlying much of higher education’s web infrastructure, provides clarity on this argument. Researchers involved in the discovery of the vulnerabilities describe using AI to turn longstanding weaknesses into working exploits and adapt them across applications in hours. The connection to AI is explicit, and so is the change in what becomes practical.
The immediate response involved emergency patches, disrupted services, and universities and hosting providers taking systems offline. My view is that we should read this as a significant marker of a broader change in EdTech. The assumptions that made it reasonable for a college, department, or individual faculty member to operate a public-facing application are breaking down.
Higher education has a particularly large exposure because so much of its technology grew through local initiative: someone built a useful tool, installed an open-source application, or kept a departmental website running. That approach delivered considerable value and fit the education ethos, but it also distributed responsibility for maintaining and defending software across multiple teams and individuals with very different capabilities.
I believe we are entering a period that will significantly accelerate the move toward managed services, shared infrastructure, and restrictions on locally operated applications exposed to the public internet, particularly for under-resourced institutions. This reaches into budgets, institutional autonomy, and the ways educational technology gets built and delivered—well beyond the immediate work of a CIO responding to a security alert.
AI also seems to anthropomorphize EdTech as Marky Mark for some reason
Where PHP Lives in EdTech
Wiz Research, one of the groups that reported the PHP vulnerabilities, estimates that PHP powers about 70% of websites. W3Techs finds PHP on 79.1% of .edu websites whose server-side programming language it can identify. That is a large footprint, though neither figure tells us who maintains those installations.
PHP sits underneath the application itself, creating a dependency that is easy to overlook. Addressing PHP2Shell means installing a fixed PHP build, including a vendor backport where available, and checking that the application still works. For older applications, that may require an application upgrade first.
PHP runs much of the campus web and one of the major LMS families. Moodle and related platforms such as Totara and Open LMS use it, as do other open-source learning systems including ILIAS, Stud.IP, and Open eClass. Beyond the LMS, WordPress and Drupal power campus and departmental websites, while tools such as REDCap, Open Journal Systems, and Omeka support research and scholarship. The applications have different owners and maintenance arrangements, even when they share the same underlying language.
According to Moodle’s registered-site statistics, about a quarter of registered Moodle sites run Moodle 4.1 LTS or older. Those branches cannot run any of PHP’s officially patched 8.2-or-newer releases. Operators on older versions need a distribution or long-term-support vendor backport, or they need to upgrade Moodle before moving to a supported PHP release. That is why “run the update” can become an unplanned project.
Percentage of registered Moodle sites worldwide using specific versions
Moodle HQ (which runs the Moodle ecosystem) put out this message in a forum post.
As a precautionary measure in response to the PHP2SHELL vulnerability, which was made public on October 21, 2026, Moodle HQ made the decision to take our sites offline. You may notice that our public facing sites were inaccessible for a period of time, but are back online or coming back online now.
Patches to address this vulnerability have been released. We have patched this site and brought it back online. We are continuing to deploy and validate the patches on our other public facing and client sites and will continue to bring sites back online as quickly as possible.
We strongly encourage self-hosted site holders to notify the individual(s) responsible for updating PHP for their sites and to create a plan to update your PHP with the released security patches, immediately.
Unpatched sites remain vulnerable to potential exploits related to PHP2SHELL.
The managed-hosting response shows both the capacity and the disruption involved. eLeDia took its managed learning platforms offline on October 21 and reported 99% restored that evening. Open LMS took customer sites offline and reported the last sites patched and restored late on October 22. In each case, an identifiable operator could act across its customers, even though that meant interrupting access.
Other major EdTech systems, including Canvas, Blackboard Learn, and Brightspace, do not run on PHP. That distinction matters for this particular vulnerability. For the larger argument, the question is who can identify and maintain each layer of an application when the next vulnerability appears.
The Departmental Tail
Learning management systems and central campus websites usually have identifiable operators. Departments, labs, libraries, and research centers also run smaller applications built to solve local problems. Those tools can persist long after the project team changes, and the person responsible for the application may have little control over the software underneath it.
When a critical vulnerability appears, someone still has to find each tool, identify the version actually serving it, determine a patch path, and decide whether it can remain on the public internet while that work happens.
In spot checks of public room-booking systems, I found a Stanford CCRMA installation reporting PHP 5.3.3 on an operating-system generation that has been out of support for years, while UT Austin Astronomy reported PHP 7.2.24, a branch whose upstream support ended in 2020. These are small, useful applications—the kind someone set up to solve a local problem and that may have kept working long after the people or assumptions behind the original installation changed. Public version information cannot establish whether a particular server was compromised, and some vendors backport security fixes without changing the reported PHP version, but the examples expose the operating question colleges now face. Who knows each of these applications exists, who owns the full stack beneath it, and who can act quickly when a critical flaw appears? A departmental tool can be inexpensive to create and valuable for years, while the continuing work of keeping it safe on the public internet remains easy to overlook.
The comparison is McGill’s neuroscience center, which runs an old version of the same room-booking software on a centrally maintained host that reported PHP 8.4.27, a release patched for PHP2Shell. The application did not have to be new for the underlying software to be current. What mattered was having someone responsible for that software.
Universities described the same divide in their emergency response. Leiden restricted affected faculty and institute websites while its central sites remained available, and advised people running their own research or conference sites to take them offline. Marburg restricted numerous web services to campus or VPN access and asked their operators to check whether the servers used PHP, update it if necessary, and report back before public access was restored. That is the departmental tail in practice: an institution trying to coordinate a response across services it does not operate as a unified action.
The End of the Internet
Ben Thompson at Stratechery described a similar shift through his own experience. He installed WordPress and configured PHP himself in 2003; today, his site runs on managed WordPress, and he says his provider had patched it before the vulnerability was publicly disclosed. Thompson argues that the old internet promise that anyone could put a server online and keep it there has become much harder to sustain in the age of AI. Higher education’s departmental applications are part of that same history, with institutional responsibilities attached.
Thompson also sees a future with more software created for individuals and small groups. For EdTech, that could mean more tools built close to the faculty, staff, and students who need them, while institutions take a more deliberate role in where those tools run and who maintains them. Managed platforms and restricted networks can support local invention, provided the institution still accounts for the risks of the applications and data it holds.
Where We Stand
It is instructive to understand how AI has changed the economics of cybersecurity and that we are not dealing with new cases of poor software development. The PHP vulnerability has existed at least since version 5.4, released in 2012, with the original bug entering code in 2004. What AI has done is make it cost-effective to find this long-hidden vulnerability.
My take is that PHP2Shell and this new reality mark an acceleration in the restructuring of EdTech. Colleges and universities will still make local choices, use open-source software, and build tools for their own needs. But the ability to put an application on the public internet carries an operating obligation that is becoming much harder to sustain through spare capacity, occasional upgrades, and the knowledge of one helpful colleague. I expect that pressure to drive a substantial shift toward managed services and shared infrastructure, with the strongest pressure on the institutions and departments least able to fund continuous attention. The budget comparison increasingly has to include the full cost of keeping a service safely available.
The developments to watch will be the decisions made after this week’s patches are installed: which applications return under new management, which remain behind restricted access, and which disappear. At the same time, AI may enable a proliferation of small, useful tools built close to the people who need them. Those trends can happen together. AI is making software easier to create while changing what it takes to operate it responsibly. I think that combination will reshape EdTech far more than another round of cybersecurity guidance suggests.
The main On EdTech newsletter is free to share in part or in whole. All we ask is attribution.
Thanks for being a subscriber.
