Pulsa ESC para cerrar

Curso WordpressCurso Wordpress

PHP2Shell: cuando el agujero está en PHP y no en WordPress (qué revisar hoy)

El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para dos fallas críticas, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). En el peor caso permiten que alguien ejecute código en tu servidor sin iniciar sesión.

Lo que hace distinta a esta alerta es que el problema no está en WordPress, ni en tu tema, ni en tus plugins: está en PHP, el lenguaje que hace funcionar a WordPress. Es como si la falla no fuera de tu auto sino de la bencina que le echas. Por eso se arregla de otra manera, y en esta entrada te mostramos cómo, tanto si estás en un hosting compartido como si administras tu propio VPS.

Paso 1: mira qué versión de PHP usa tu sitio

  1. En el escritorio entra a Herramientas → Salud del sitio.
  2. Abre la pestaña Información y despliega la sección Servidor.
  3. Anota la línea Versión de PHP.

Estas son las versiones que ya traen la corrección, según el aviso oficial de PHP:

  • PHP 8.5: 8.5.12 o superior.
  • PHP 8.4: 8.4.27 o superior.
  • PHP 8.3: 8.3.36 o superior.
  • PHP 8.2: 8.2.35 o superior. Ojo: esta rama deja de recibir soporte el 31 de diciembre de 2026, así que conviene ir planificando el salto.

Si tu número es menor, no te asustes todavía. Muchos hostings y distribuciones de Linux aplican el parche «por dentro» sin cambiar el número de versión. El número sirve de pista, pero la confirmación real solo te la puede dar quien administra el servidor.

Si usas PHP 8.1 o anterior, la cosa es más seria: esas ramas ya no tienen versiones oficiales con la corrección. Dependes de que tu hosting haya aplicado un parche por su cuenta, y lo más sano es cambiarte a una versión con soporte.

Paso 2: si estás en un hosting compartido, pregunta

En un hosting compartido tú no puedes actualizar PHP por dentro, eso lo hace el proveedor. Lo que sí puedes hacer es preguntar con precisión. Copia y adapta este mensaje para el soporte:

Hola. Quisiera confirmar si mi cuenta (tudominio.cl) ya usa una versión
de PHP corregida contra PHP2Shell (CVE-2026-109618 y CVE-2026-109619):
8.2.35, 8.3.36, 8.4.27, 8.5.12 o un parche equivalente aplicado por ustedes.
¿Me pueden indicar qué versión o paquete usa mi sitio y si los procesos
de PHP se reiniciaron después de la actualización? Gracias.

La pregunta del reinicio no es un detalle: si se actualiza el paquete pero los procesos de PHP siguen corriendo con el código viejo, el servidor sigue expuesto hasta que se reinician.

Si tu panel te deja elegir la versión de PHP (en cPanel suele llamarse Seleccionar versión de PHP o MultiPHP Manager), cambiarte a una rama más nueva es algo que sí está en tus manos. Hazlo con un respaldo reciente y revisa el sitio después.

Paso 3: si el servidor es tuyo (VPS con cPanel)

Aquí el trabajo es tuyo, pero también el control. En cPanel las versiones de PHP vienen en paquetes llamados ea-phpXX. Conéctate por SSH como root y revisa qué tienes:

# Versión real de cada PHP instalado
for php in /opt/cpanel/ea-php*/root/usr/bin/php; do
  echo "$php → $($php -r 'echo PHP_VERSION;')"
done

# Qué versión usa cada dominio
whmapi1 php_get_vhost_versions | grep -E 'vhost:|version:'

Para actualizar todos los PHP de EasyApache y reiniciar los procesos:

dnf -y update 'ea-php*'        # en CentOS 7 / CloudLinux 7 usa: yum -y update 'ea-php*'
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

Vuelve a ejecutar el primer bloque para confirmar que las versiones subieron. No te quedes con «seguro que se actualizó solo de noche»: las actualizaciones automáticas de cPanel dependen de cómo estén configuradas en WHM → Preferencias de actualización, y es mejor verlo con tus propios ojos.

Si todavía no puedes actualizar, el aviso de PHP propone una medida temporal contra la segunda falla: desactivar session.upload_progress.enabled y reiniciar PHP. En WHM está en MultiPHP INI Editor. Reduce el riesgo, pero no reemplaza la actualización. Y no sirve ponerlo en un .user.ini ni con ini_set(): llega demasiado tarde.

Lo que NO conviene hacer

  • Correr «escáneres» de GitHub contra tu sitio. En cuanto sale una falla famosa aparecen decenas de scripts recién publicados, sin revisión. Algunos intentan provocar el error en el servidor y otros escriben datos en él. Ejecutar código ajeno recién salido del horno, en plena alerta, es justo lo que un atacante querría que hicieras.
  • Instalar un plugin de seguridad «para protegerte». Un plugin es código PHP que corre dentro de PHP: no puede arreglar el motor en el que él mismo funciona. En algunas configuraciones el ataque ocurre antes de que WordPress cargue una sola línea.
  • Dejarlo para la próxima semana. Las fallas de ejecución remota sin inicio de sesión son de las que se automatizan rápido.

Extra: que WordPress te avise solo

Si administras varios sitios, puedes agregar una prueba propia a Salud del sitio que compare la versión de PHP con las corregidas. Guarda este archivo como wp-content/mu-plugins/cwp-php2shell.php (si la carpeta mu-plugins no existe, créala):

<?php
/**
 * Plugin Name: Aviso PHP2Shell (Curso WordPress)
 * Description: Agrega una prueba a Salud del sitio que revisa la versión de PHP.
 */

add_filter( 'site_status_tests', function ( $tests ) {
	$tests['direct']['cwp_php2shell'] = array(
		'label' => 'Versión de PHP y PHP2Shell',
		'test'  => 'cwp_test_php2shell',
	);
	return $tests;
} );

function cwp_test_php2shell() {
	$corregidas = array(
		'8.5' => '8.5.12',
		'8.4' => '8.4.27',
		'8.3' => '8.3.36',
		'8.2' => '8.2.35',
	);
	$rama = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
	$ok   = isset( $corregidas[ $rama ] ) && version_compare( PHP_VERSION, $corregidas[ $rama ], '>=' );

	return array(
		'label'       => $ok
			? 'PHP ' . PHP_VERSION . ' ya incluye la corrección de PHP2Shell'
			: 'Confirma con tu hosting si PHP ' . PHP_VERSION . ' está parchado',
		'status'      => $ok ? 'good' : 'recommended',
		'badge'       => array(
			'label' => 'Seguridad',
			'color' => $ok ? 'green' : 'orange',
		),
		'description' => $ok
			? '<p>Tu versión es igual o superior a la corregida.</p>'
			: '<p>El número no basta: algunos hostings aplican el parche sin cambiarlo. Pregúntales y, si usas PHP 8.1 o anterior, planifica el cambio a una versión con soporte.</p>',
		'test'        => 'cwp_php2shell',
	);
}

Fíjate en que, igual que en el paso 1, la prueba nunca dice «estás en peligro»: dice «confírmalo». Desde dentro de WordPress no se puede saber si el hosting aplicó el parche sin cambiar el número, y es mejor que la herramienta no prometa lo que no puede comprobar.

Resumen

  • La falla está en PHP: se arregla actualizando PHP, no con plugins.
  • Hosting compartido: revisa tu versión y pregunta con el mensaje de arriba.
  • VPS con cPanel: **actualiza ea-php*, reinicia PHP-FPM y Apache, y verifica**.
  • Si sigues en PHP 8.1 o anterior, este es el empujón para cambiarte.

¿No sabes qué contestó tu hosting o qué versión elegir? Pega su respuesta (sin datos privados) en el foro y te ayudamos a interpretarla. Si tienes VPS, comparte la salida de los comandos del paso 3.

logo

Aprende WordPress paso a paso, en español y sin vueltas: tutoriales claros, plugins explicados y soluciones probadas en servidores reales. ¿Tienes una duda? Pregúntala en el foro.