# Sicurezza MediaWiki dopo PHP2Shell: proteggere i wiki interni

> Sicurezza MediaWiki dopo PHP2Shell: verificare PHP su Speciale:Version, proteggere LocalSettings.php e images, controllare interface admin e Common.js.

Fonte: https://phpsos.de/it/plattformen/mediawiki/  
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:** la sicurezza di MediaWiki dopo PHP2Shell parte dal PHP del server, perché la vulnerabilità si trova lì e non nel wiki. I wiki interni spesso non vengono toccati per anni e girano su vecchie versioni di PHP. Verifichi lo stato su `Speciale:Version`, aggiorni e riavvii, poi controlli `LocalSettings.php`, `images` e gli interface admin.

## Perché i wiki interni sono un bersaglio interessante

In molte aziende, autorità e istituti di ricerca MediaWiki funge da manuale interno. Vi si trovano procedure, referenti, schemi di rete, istruzioni per i server e talvolta perfino credenziali che non dovrebbero starci. Per un aggressore un wiki così è una mappa dell'azienda.

Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso da remoto senza autenticazione. Un wiki pensato «solo per uso interno» ma raggiungibile via Internet è quindi direttamente attaccabile. E poiché i wiki raramente sono al centro dell'attenzione dell'IT, girano spesso su vecchi server, frequentemente ancora con PHP come modulo Apache, la modalità di esecuzione con il rischio più alto secondo il team PHP.

## Sicurezza di MediaWiki: verificare versione di PHP e stato delle patch

La pagina **Speciale:Version** mostra la versione di MediaWiki, PHP e del database, nonché tutte le estensioni e gli skin installati. Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Molti server wiki girano su distribuzioni Linux con backport; il numero visualizzato resta allora lo stesso, anche se la patch c'è.

Se il wiki gira su PHP 8.1 o precedente, il progetto PHP non rilascia più aggiornamenti ufficiali, ma solo backport minimi del sorgente per 7.4, 8.0 e 8.1. Che cosa vale in tal caso è riassunto in [PHP 8.1 e precedenti](https://phpsos.de/it/php2shell/php-8-1-und-aelter/). Quali versioni di PHP supporta la Sua versione di MediaWiki, lo verifichi nei requisiti di sistema su mediawiki.org. Un cambio di PHP può presupporre un upgrade di MediaWiki.

Script di manutenzione e job runner girano con il PHP a riga di comando. Anche questa versione deve essere aggiornata. Se la coda dei job gira come servizio permanente, dopo l'aggiornamento questo deve essere riavviato come il web server o PHP-FPM. Con mod_php significa riavviare Apache stesso, perché PHP si trova lì nel processo del web server.

Chiarisca inoltre a chi appartenga il wiki. I wiki interni sono stati spesso allestiti da un reparto specialistico e girano al di fuori della normale manutenzione dei server. Senza una competenza chiara, l'aggiornamento di PHP lì resta in sospeso più a lungo.

## Directory e file in MediaWiki

| Posizione | Contenuto | Punto da controllare |
|---|---|---|
| `LocalSettings.php` | Accesso al database, `$wgSecretKey`, `$wgUpgradeKey`, diritti, impostazioni di upload | codice aggiunto, rinnovare le chiavi in caso di sospetto |
| `images/` | file caricati e anteprime | nessun file PHP, nessuna esecuzione di PHP |
| `extensions/`, `skins/` | Estensioni e design | file sconosciuti o modificati |
| `cache/` | Memoria temporanea | svuotare dopo la bonifica |
| `maintenance/` | Script di manutenzione per la riga di comando | non usare tramite il web |

La directory di upload non dovrebbe eseguire script a livello di web server. Con Apache, indipendentemente dalla modalità di esecuzione di PHP, si fa così:

```apache
<Directory "/var/www/wiki/images">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>
```

Un primo controllo non invasivo:

```bash
find images -type f -name "*.php*"
ls -l LocalSettings.php
```

> **Consiglio:**
> Controlli nella cronologia delle versioni le pagine `MediaWiki:Common.js` e `MediaWiki:Common.css`. Le modifiche lì agiscono su ogni visitatore del wiki e sono un luogo tipico per codice introdotto.

## Diritti, gruppi ed estensioni

In MediaWiki sulla sicurezza decidono i gruppi di utenti. Verifichi in `Speciale:ElencoUtenti` chi appartenga ai gruppi amministratori, burocrati e interface admin. Gli interface admin possono modificare il JavaScript dell'intero wiki; questo gruppo dovrebbe essere molto piccolo.

Per un wiki interno la lettura senza autenticazione dovrebbe essere disattivata e la registrazione di nuovi account bloccata. Consenta gli upload solo per i tipi di file di cui c'è davvero bisogno. Le estensioni portano codice PHP proprio; le estensioni non manutenute rallentano inoltre ogni upgrade. Per i diritti dei file sul server, la guida [Diritti dei file sul web server](https://phpsos.de/it/ratgeber/dateirechte-webserver/) offre un orientamento.

## Che cosa può fare un aggiornamento di MediaWiki e che cosa no

Un aggiornamento di MediaWiki sostituisce il core e chiude errori noti in esso. Non applica patch a PHP, non riavvia processi PHP, non cambia nulla in `LocalSettings.php` e non rimuove né file in `images/` né modifiche a `MediaWiki:Common.js` o membri aggiuntivi dei gruppi. Non dimostra nemmeno che prima della patch nessuno abbia letto di nascosto.

Una rapida panoramica la danno inoltre i registri in `Speciale:Registri`. Nuovi account utente, modifiche ai diritti dei gruppi e modifiche alle pagine dell'interfaccia dal 17/10/2026 vi sono annotati con data e ora.

## In che modo PHP SOS aiuta concretamente?

- Verifichiamo versione di PHP, modalità di esecuzione e stato dei backport del Suo server wiki e ci facciamo confermare il riavvio.
- Mettiamo al sicuro i log a partire dal 20/10/2026, il database e i file.
- Controlliamo `LocalSettings.php`, upload, estensioni, diritti dei gruppi e la cronologia delle versioni delle pagine dell'interfaccia.
- Nell'ambito dell'[assistenza immediata PHP2Shell](https://phpsos.de/it/leistungen/php2shell-soforthilfe/) valutiamo con Lei se il wiki debba restare raggiungibile pubblicamente.


## Domande frequenti

**MediaWiki è interessato da PHP2Shell?**  
MediaWiki 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 MediaWiki non chiude la vulnerabilità.

**Dove vedo la versione di PHP del mio wiki?**  
Nella pagina Speciale:Version MediaWiki elenca il software installato, tra cui la versione di PHP. Da essa non si capisce se sia stato applicato un backport; lo conferma il gestore del server.

**Perché MediaWiki:Common.js è un rischio?**  
Il contenuto di questa pagina viene consegnato come JavaScript a tutti i visitatori del wiki. Chi può modificarla può eseguire codice nel browser di ogni utente. Il gruppo degli interface admin dovrebbe quindi essere molto piccolo.

**Basta rendere il wiki raggiungibile solo internamente?**  
Un wiki raggiungibile solo nella rete aziendale o tramite VPN riduce nettamente il rischio, perché gli aggressori da Internet non lo raggiungono direttamente. L'aggiornamento resta comunque necessario, perché un attacco può arrivare anche dalla rete interna.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [MediaWiki](https://www.mediawiki.org/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
