In short: Moodle security in schools is about the data of children and teenagers, about grades and about ongoing lessons. First clarify who runs your Moodle: the state, the school authority, a service provider or a dedicated teacher. That determines who patches PHP, restarts it and provides the proof.
Which PHP systems run in schools and educational institutions
The focus is often on the learning platform Moodle. Added to this are the school website, frequently on WordPress or Joomla, tools for substitution plans, parent letter and registration forms, booking systems for rooms and devices, and file storage such as Nextcloud. Almost all of this runs on PHP.
At private education providers, adult education centres and continuing education providers, course booking, participant management and online exams come in. Here the learning platform is often directly linked to invoicing and participant data.
Which data sits in Moodle and the like
A learning platform contains more than worksheets: names and classes of students, submissions, grades and feedback, forum posts, messages between teachers and learners and, at education providers, also attendance certificates and exam results. Occasionally there are notes on special educational needs or health limitations, which can belong to the special categories under Art. 9 GDPR.
Those affected are mostly minors. That increases the risk in a data leak, because children can hardly fend off consequences such as targeted approaches or public embarrassment themselves. For reporting duties, the 72-hour deadline under the GDPR applies, and the responsible data protection officer makes the assessment.
School, Moodle and security: the question of responsibility
| Operating model | Who patches PHP | What the school should check |
|---|---|---|
| Centrally by the state or a state institute | The state's operator | The school's own additional systems |
| Via the school authority or a media centre | The authority's IT | Request a written confirmation |
| External service provider | Provider as per contract | Whether PHP is explicitly in the contract |
| Own server, looked after by a teacher | The school itself | Time, knowledge and deputising |
The last model is more common than many think. A dedicated teacher set up Moodle years ago and looks after it on the side. With a critical vulnerability, time, deputising and often also the rights to act quickly are lacking.
A Moodle update does not close PHP2Shell. The vulnerability is only fixed with PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a confirmed backport, and only after all PHP processes have been restarted.
What an outage means for lessons and exams
If Moodle goes down, material and submission options are missing. In exam periods or shortly before report cards this is especially delicate. Nevertheless: better to shut a platform down in an orderly way for a few hours than to let it keep running unpatched. A compromised system can falsify submissions or take over teachers' accounts.
Therefore plan a simple fallback route, for example submission via another, unaffected system, and briefly inform teachers, learners and parents of the reason.
After a cleanup, a look at the accounts is worthwhile. Schools have many users with extended rights: teachers, trainee teachers, subject heads, former colleagues whose access was never deleted. Orphaned accounts with teacher rights are a convenient way back into the platform. A comparison with the school's current staff list closes this door, and accounts with administrator rights should be limited to a few people.
Particularities of education providers and continuing education
Private education providers, adult education centres and continuing education providers often work with adult participants, but with more commercial data: course bookings with payment details, invoices to corporate customers, documents on funded programmes, exam results and certificates. Here the learning platform is frequently connected to the booking system and accounting.
An attack can therefore also affect certificates and exam results. Anyone who can change data in the platform can forge pass marks or issue certificates that were never earned. After an incident, have it checked whether grades and certificates were changed afterwards, and compare them with your exam records.
First steps for school management and the authority
- Clarify who operates Moodle, the website and the cloud, and have patch level and restart confirmed in writing for each.
- Put unconfirmed systems into maintenance mode or take them offline.
- Have logs preserved from 20 October 2026 onward.
- Check admin accounts: are there new or unknown administrators?
- Inform the data protection officer and the school authority.
How does PHP SOS help?
- We coordinate with the school management, the authority and the supervising teacher and clarify who is responsible for which system.
- Through the PHP2Shell emergency help we patch PHP, restart all workers and document the result.
- We check the Moodle data directory, database and admin accounts for traces of an attack.
- Afterwards we take over server hardening, so that the platform no longer depends on a single person.
Frequently asked questions
Our Moodle is run by the state. Do we have to do anything?
If Moodle is operated centrally by the state or a state institute, the patch lies with the operator. The school should still check whether it has systems of its own alongside, such as the school website or a self-hosted cloud. These are usually the responsibility of the school or the school authority.
Is a Moodle update enough against PHP2Shell?
No. PHP2Shell affects PHP itself, on which Moodle runs. What is needed is a patched PHP and a restart of all PHP processes. Which PHP version your Moodle version supports, you can check in the system requirements on moodle.org.
Who is responsible for a data leak at the school?
Depending on the federal state, responsibility is divided between the school, the head teacher and the school authority. For assessing reporting duties, the responsible data protection officer is the first point of contact. Responsibilities should be settled in writing before an incident.