# Sicurezza Moodle dopo PHP2Shell: proteggere correttamente le piattaforme di apprendimento

> Proteggere Moodle dopo PHP2Shell: verificare PHP in Server > Ambiente, riavviare il cron, tutelare moodledata, controllare plugin e account admin.

Fonte: https://phpsos.de/it/plattformen/moodle/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** dopo PHP2Shell la sicurezza di Moodle dipende dal PHP del server, non da Moodle. Poiché le piattaforme di apprendimento trattano dati di scolari, studenti e dipendenti, è importante agire in fretta. Aggiorni PHP per web e cron, riavvii tutti i processi e controlli `config.php`, `moodledata`, plugin e account admin.

## Che cosa significa PHP2Shell per i gestori di Moodle

Moodle è diffuso in scuole, università, formazione continua e nella formazione interna delle aziende. La piattaforma gestisce nomi, indirizzi e-mail, appartenenza ai corsi, voti, consegne d'esame e interventi nei forum, nelle scuole spesso di minorenni. Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso da remoto senza autenticazione.

I server Moodle sono quasi sempre raggiungibili da Internet, perché gli studenti lavorano da casa. Il BSI (Ufficio federale tedesco per la sicurezza informatica) raccomanda al livello di allerta 3 l'aggiornamento immediato e, se non è possibile, di scollegare temporaneamente dalla rete i web server. Per scuole ed enti di formazione è difficile dal punto di vista organizzativo, ma pianificabile. Indicazioni specifiche per il settore si trovano in [Sicurezza IT per scuole ed enti di formazione](https://phpsos.de/it/branchen/schulen-bildung/).

## Sicurezza di Moodle: verificare la versione di PHP per web e cron

In **Amministrazione del sito > Server > Ambiente**, Moodle verifica la versione di PHP e altri requisiti. In Server > Info PHP gli amministratori vedono inoltre tutti i dati di PHP. Entrambi descrivono il PHP web.

Moodle richiede inoltre un cronjob che esegua regolarmente `admin/cli/cron.php` tramite il PHP a riga di comando. Questa versione può differire e deve essere altrettanto aggiornata. Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; i backport portano spesso numeri più vecchi. Quali versioni di PHP supporta la Sua versione di Moodle, lo verifichi nei requisiti di sistema nella documentazione su moodle.org. Come riavviare correttamente tutti i processi dopo l'aggiornamento è descritto in [Riavviare PHP-FPM e tutti i worker](https://phpsos.de/it/php2shell/php-fpm-neustart/).

## Directory e configurazione in Moodle

| Posizione | Contenuto | Punto da controllare |
|---|---|---|
| `config.php` | Accesso al database, `wwwroot`, percorso di `moodledata` | codice aggiunto, cambiare la password in caso di sospetto |
| `moodledata/` | Archivio file, consegne, sessioni, cache | fuori dalla document root, nessun file PHP |
| `mod/`, `blocks/`, `local/`, `theme/` | Attività, blocchi, estensioni locali, design | plugin sconosciuti o modificati |
| `admin/cli/` | Script a riga di comando | utilizzabili solo da CLI |

Moodle offre un'impostazione che impedisce di modificare i percorsi dei programmi tramite l'interfaccia web. Va inserita in `config.php` e rende più difficile richiamare programmi sul server attraverso un account admin sottratto:

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

Controlli non invasivi da riga di comando, come utente del web server:

```bash
# Emettere i controlli di stato e di sicurezza propri di Moodle
php admin/cli/checks.php
php admin/cli/checks.php --type=security
# Cercare file PHP nella directory dei dati (adattare il percorso)
find /pfad/zu/moodledata -type f -name "*.php"
```

> **Importante:**
> In caso di sospetta fuga di dati in una scuola o università sono rapidamente coinvolti più soggetti: direzione scolastica, ente gestore, responsabili della protezione dei dati ed eventualmente l'autorità di controllo. Metta al sicuro i log a partire dal 20/10/2026 e documenti ogni misura con l'orario.

## Plugin, account admin e upload

Un'indicazione pratica per la pianificazione: aggiornamenti di PHP e riavvii non dovrebbero cadere in periodi d'esame o durante test online in corso. Moodle ha una modalità di manutenzione che informa gli utenti in anticipo. Contro PHP2Shell non protegge, però, perché anche la pagina di manutenzione è consegnata da PHP.

Moodle vive di plugin: attività, strumenti d'esame, collegamenti a videoconferenze e gestione scolastica. Ogni plugin è codice PHP aggiuntivo e deve essere compatibile con la versione di Moodle. In Amministrazione del sito, Moodle mostra gli aggiornamenti disponibili per core e plugin. Rimuova completamente i plugin che nessuno usa più.

Controlli l'elenco degli amministratori del sito e i ruoli globali con diritti estesi. Docenti e creatori di corsi di solito non hanno bisogno di diritti globali. Attivi l'autenticazione a due fattori almeno per gli amministratori. I tipi di file consentiti per gli upload dovrebbero essere il più ristretti possibile; indicazioni in merito offre [Implementare in modo sicuro i caricamenti di file in PHP](https://phpsos.de/it/ratgeber/datei-upload-sicher/).

## Che cosa può fare un aggiornamento di Moodle e che cosa no

Un aggiornamento di Moodle chiude errori in Moodle e rende spesso possibili versioni di PHP più recenti. Non applica patch a PHP, non riavvia né processi web né cron e non rimuove file estranei da `moodledata`, amministratori aggiuntivi o plugin modificati. Un aggiornamento non risponde nemmeno alla domanda se nel periodo precedente la patch siano usciti dati.

Moodle registra accessi e azioni anche nei propri log, che gli amministratori consultano in Amministrazione del sito > Report. Cerchi lì in modo mirato accessi anomali di amministratori, nuovi account con ruoli globali e installazioni di plugin dal 17/10/2026. Esporti queste voci prima che pulizie automatiche cancellino i dati più vecchi. I report integrano i log del web server, ma non li sostituiscono.

## In che modo PHP SOS aiuta concretamente?

- Chiariamo la competenza per PHP e ci facciamo confermare stato delle patch e riavvio di web e cron.
- Mettiamo al sicuro log, database e `moodledata` prima di ogni modifica.
- Controlliamo configurazione, plugin, amministratori, ruoli e upload.
- Su richiesta seguiamo la piattaforma in modo continuativo nel [contratto di manutenzione della sicurezza](https://phpsos.de/it/leistungen/security-wartungsvertrag/), in accordo con anno scolastico e periodi d'esame.


## Domande frequenti

**Moodle è interessato da PHP2Shell?**  
Moodle stesso non ha una nuova vulnerabilità, ma gira su PHP. Se il PHP del server non è aggiornato, secondo il team PHP un aggressore può eseguire codice senza autenticazione. Un aggiornamento di Moodle non cambia nulla al riguardo.

**Dove vedo la versione di PHP in Moodle?**  
In Amministrazione del sito > Server > Ambiente, Moodle verifica la versione di PHP rispetto ai propri requisiti. Moodle non mostra se sia stato applicato un backport; lo conferma il gestore del server.

**Perché moodledata deve trovarsi fuori dalla directory web?**  
Lì si trovano file caricati, consegne, sessioni e cache. Se la directory è raggiungibile dal web, i contenuti potrebbero essere richiamabili direttamente. Moodle richiede quindi una posizione fuori dalla document root.

**Chi è responsabile dell'aggiornamento di PHP nelle scuole?**  
Varia: ente gestore della scuola, azienda regionale, centro di calcolo comunale o un fornitore di servizi. Chiarisca la competenza per iscritto e si faccia confermare stato delle patch e riavvio.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [Moodle](https://moodle.org/)
- [BSI (Ufficio federale tedesco per la sicurezza informatica)](https://www.bsi.bund.de/)
- [GDPR art. 33 (in tedesco)](https://dsgvo-gesetz.de/art-33-dsgvo/)