# Moodle Security After PHP2Shell: Securing Learning Platforms Properly

> Secure Moodle after PHP2Shell: check PHP under Server > Environment, restart cron, protect moodledata, review plugins and admin accounts.

Source: https://phpsos.de/en/plattformen/moodle/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** After PHP2Shell, Moodle security depends on the server's PHP, not on Moodle. Because learning platforms process data of pupils, students and employees, quick action is important. Patch PHP for web and cron, restart all processes and check `config.php`, `moodledata`, plugins and admin accounts.

## What PHP2Shell means for Moodle operators

Moodle is widespread at schools, universities, in continuing education and for internal training in companies. The platform manages names, email addresses, course enrolments, grades, exam submissions and forum posts, at schools often of minors. According to the PHP team, the PHP flaws CVE-2026-109618 and CVE-2026-109619 allow remote code execution without authentication.

Moodle servers are almost always reachable from the internet, because learners work from home. At warning level 3, the BSI (German Federal Office for Information Security) recommends updating immediately and, if that is not possible, temporarily taking web servers offline. For schools and training providers this is organisationally difficult, but plannable. Sector-specific guidance can be found under [IT security for schools and educational institutions](https://phpsos.de/en/branchen/schulen-bildung/).

## Moodle security: checking the PHP version for web and cron

Under **Site administration > Server > Environment**, Moodle checks the PHP version and other requirements. Under Server > PHP info, administrators additionally see the full PHP details. Both describe the web PHP.

Moodle also needs a cron job that regularly runs `admin/cli/cron.php` via the command-line PHP. This version can differ and must be patched as well. Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; backports often carry older numbers. Which PHP versions your Moodle version supports can be found in the system requirements in the documentation on moodle.org. How to restart all processes cleanly afterwards is described under [Restarting PHP-FPM and all workers](https://phpsos.de/en/php2shell/php-fpm-neustart/).

## Directories and configuration in Moodle

| Location | Content | What to check |
|---|---|---|
| `config.php` | Database credentials, `wwwroot`, path to `moodledata` | Inserted code, change password if you suspect an incident |
| `moodledata/` | File storage, submissions, sessions, caches | Outside the document root, no PHP files |
| `mod/`, `blocks/`, `local/`, `theme/` | Activities, blocks, local extensions, themes | Unknown or modified plugins |
| `admin/cli/` | Command-line scripts | Usable via CLI only |

Moodle offers a setting that prevents program paths from being changed via the web interface. It belongs in `config.php` and makes it harder to call programs on the server through a hijacked admin account:

```php
$CFG->preventexecpath = true;
```

Harmless checks on the command line, as the web server user:

```bash
# Output Moodle's own status and security checks
php admin/cli/checks.php
php admin/cli/checks.php --type=security
# Search for PHP files in the data directory (adjust the path)
find /pfad/zu/moodledata -type f -name "*.php"
```

> **Important:**
> If you suspect a data leak at a school or university, several parties are quickly involved: school management, the school authority, data protection officers and, where applicable, the supervisory authority. Secure logs from 20 October 2026 onward and document every measure with the time.

## Plugins, admin accounts and uploads

A practical note for planning: PHP updates and restarts should not fall into exam periods or running online tests. Moodle has a maintenance mode that informs users beforehand. It does not protect against PHP2Shell, however, because the maintenance page is also delivered by PHP.

Moodle lives on plugins: activities, exam tools, connections to video conferencing and school administration. Every plugin is additional PHP code and must match the Moodle version. Under Site administration, Moodle shows available updates for core and plugins. Remove plugins that nobody uses any more completely.

Check the list of site administrators and global roles with far-reaching rights. Teachers and course creators usually do not need global rights. Enable two-factor authentication at least for administrators. The permitted file types for uploads should be defined as narrowly as possible; guidance is offered by [Implementing file uploads in PHP securely](https://phpsos.de/en/ratgeber/datei-upload-sicher/).

## What a Moodle update can and cannot do

A Moodle update closes flaws in Moodle and often enables newer PHP versions. It does not patch PHP, restarts neither web nor cron processes and removes no foreign files from `moodledata`, no additional administrators and no modified plugins. Nor does an update answer whether data was leaked in the period before the patch.

Moodle also records logins and actions in its own logs, which administrators can view under Site administration > Reports. Search there specifically for conspicuous administrator logins, new accounts with global roles and plugin installations since 17 October 2026. Export these entries before automatic cleanups delete older data. The reports complement the web server logs but do not replace them.

## How does PHP SOS help?

- We clarify the responsibility for PHP and have the patch status and restart of web and cron confirmed.
- We secure logs, database and `moodledata` before any change.
- We check configuration, plugins, administrators, roles and uploads.
- On request, we look after the platform on an ongoing basis in the [security maintenance contract](https://phpsos.de/en/leistungen/security-wartungsvertrag/), aligned with the school year and exam periods.


## Frequently asked questions

**Is Moodle affected by PHP2Shell?**  
Moodle itself has no new flaw but runs on PHP. If the server's PHP is unpatched, an attacker can, according to the PHP team, execute code without authentication. A Moodle update changes nothing about that.

**Where do I see the PHP version in Moodle?**  
Under Site administration > Server > Environment, Moodle checks the PHP version against its requirements. Moodle does not show whether a backport has been applied; the server operator confirms that.

**Why must moodledata be outside the web directory?**  
That is where uploaded files, submissions, sessions and caches are stored. If the directory is reachable via the web, content may be retrievable directly. Moodle therefore requires a location outside the document root.

**Who is responsible for the PHP update at schools?**  
That varies: the school authority, a state agency, a municipal data centre or a service provider. Clarify the responsibility in writing and have the patch status and restart confirmed.

## Sources

- [php.net: Security announcements](https://www.php.net/)
- [Moodle](https://moodle.org/)
- [BSI (German Federal Office for Information Security)](https://www.bsi.bund.de/)
- [GDPR Art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)