En resumen: la seguridad en MediaWiki tras PHP2Shell empieza en el PHP del servidor, porque la vulnerabilidad está allí y no en la wiki. Las wikis internas suelen no tocarse durante años y funcionan con versiones antiguas de PHP. Compruebe el estado en Spezial:Version, parchee y reinicie, y controle después LocalSettings.php, images y los administradores de interfaz.
Por qué las wikis internas son un objetivo atractivo
En muchas empresas, administraciones y centros de investigación, MediaWiki sirve de manual interno. Allí hay procesos, personas de contacto, planos de red, instrucciones para servidores y, a veces, incluso credenciales que no deberían estar ahí. Para un atacante, una wiki así es un mapa de la empresa.
Según el equipo de PHP, las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso de forma remota y sin autenticación. Una wiki pensada «solo para uso interno», pero accesible desde internet, es por tanto directamente vulnerable. Y como las wikis rara vez están en el foco del departamento de TI, suelen funcionar en servidores antiguos, a menudo todavía con PHP como módulo de Apache, el modo de funcionamiento de mayor riesgo según el equipo de PHP.
Seguridad en MediaWiki: comprobar la versión de PHP y el nivel de parcheo
La página Especial:Versión muestra la versión de MediaWiki, de PHP y de la base de datos, así como todas las extensiones y skins instaladas. Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Muchos servidores de wikis funcionan sobre distribuciones de Linux con backports; entonces el número mostrado no cambia, aunque esté parcheado.
Si la wiki funciona con PHP 8.1 o anterior, el proyecto PHP ya no ofrece actualizaciones oficiales, solo backports mínimos del código fuente para 7.4, 8.0 y 8.1. Lo que rige entonces se resume en PHP 8.1 y anteriores. Qué versiones de PHP admite su versión de MediaWiki puede consultarlo, según los requisitos del sistema, en mediawiki.org. Un cambio de PHP puede requerir una actualización de MediaWiki.
Los scripts de mantenimiento y los job runners se ejecutan con el PHP de línea de comandos. Esa versión también debe estar parcheada. Si la cola de trabajos funciona como servicio permanente, este debe reiniciarse tras la actualización igual que el servidor web o PHP-FPM. Con mod_php esto significa reiniciar Apache en sí, porque allí PHP está dentro del proceso del servidor web.
Aclare además a quién pertenece la wiki. Las wikis internas las suele montar un departamento especializado y funcionan al margen del mantenimiento normal de servidores. Sin una responsabilidad clara, la actualización de PHP es allí lo que más tarda.
Directorios y archivos en MediaWiki
| Lugar | Contenido | Punto de control |
|---|---|---|
LocalSettings.php |
Acceso a la base de datos, $wgSecretKey, $wgUpgradeKey, permisos, ajustes de subida |
Código añadido; renovar las claves ante una sospecha |
images/ |
Archivos subidos y miniaturas | Sin archivos PHP, sin ejecución de PHP |
extensions/, skins/ |
Extensiones y diseños | Archivos desconocidos o modificados |
cache/ |
Caché | Vaciar tras la limpieza |
maintenance/ |
Scripts de mantenimiento para la línea de comandos | No usar a través de la web |
El directorio de subidas no debería ejecutar scripts a nivel del servidor web. Con Apache, esto funciona así, independientemente del modo de funcionamiento de PHP:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Una primera comprobación inofensiva:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Revise en el historial de versiones las páginas MediaWiki:Common.js y MediaWiki:Common.css. Los cambios allí afectan a todos los visitantes de la wiki y son un lugar típico para código introducido.
Permisos, grupos y extensiones
En MediaWiki, la seguridad la deciden los grupos de usuarios. Revise en Spezial:Benutzer y Spezial:Benutzerrechte quién pertenece a los grupos de administradores, burócratas y administradores de interfaz. Los administradores de interfaz pueden modificar el JavaScript de toda la wiki; este grupo debería ser muy reducido.
En una wiki interna, la lectura sin iniciar sesión debería estar desactivada y el registro de cuentas nuevas bloqueado. Permita las subidas solo para los tipos de archivo que realmente se necesiten. Las extensiones aportan código PHP propio; además, las extensiones sin mantenimiento frenan cualquier actualización. Para los permisos de archivos en el servidor, la guía Permisos de archivos en el servidor web ofrece una orientación.
Lo que puede y no puede hacer una actualización de MediaWiki
Una actualización de MediaWiki sustituye el núcleo y cierra errores conocidos en él. No parchea PHP, no reinicia procesos de PHP, no cambia nada en LocalSettings.php y no elimina ni archivos de images/, ni cambios en MediaWiki:Common.js, ni miembros adicionales de grupos. Tampoco demuestra que nadie haya estado leyendo antes del parche.
Los registros de Spezial:Logbuch ofrecen además una visión rápida. Las cuentas de usuario nuevas, los cambios en los permisos de grupo y las ediciones de páginas de interfaz desde el 17/10/2026 figuran allí con su fecha y hora.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos la versión de PHP, el modo de funcionamiento y el estado de los backports de su servidor de wiki y hacemos que se confirme el reinicio.
- Guardamos los registros a partir del 20/10/2026, la base de datos y los archivos.
- Revisamos
LocalSettings.php, las subidas, las extensiones, los permisos de grupo y el historial de versiones de las páginas de interfaz. - En el marco de la ayuda inmediata ante PHP2Shell valoramos con usted si la wiki debe seguir siendo accesible públicamente.
Preguntas frecuentes
¿Está MediaWiki afectado por PHP2Shell?
MediaWiki en sí no tiene ninguna vulnerabilidad nueva, pero se ejecuta sobre PHP. Si el PHP del servidor no está parcheado, según el equipo de PHP un atacante puede ejecutar código sin autenticarse. Una actualización de MediaWiki no cierra la vulnerabilidad.
¿Dónde veo la versión de PHP de mi wiki?
En la página Especial:Versión, MediaWiki enumera el software instalado, incluida la versión de PHP. El número no permite saber si se ha aplicado un backport; eso lo confirma el operador del servidor.
¿Por qué es un riesgo MediaWiki:Common.js?
El contenido de esta página se entrega como JavaScript a todos los visitantes de la wiki. Quien pueda modificarla puede ejecutar código en el navegador de cualquier usuario. Por eso el grupo de administradores de interfaz debería ser muy reducido.
¿Basta con hacer la wiki accesible solo internamente?
Una wiki accesible solo en la red de la empresa o por VPN reduce claramente el riesgo, porque los atacantes desde internet no pueden alcanzarla directamente. Aun así debe parchearla, porque un ataque también puede venir de la red interna.