En resumen: en la seguridad de OXID eShop, tras PHP2Shell se trata primero del servidor: la vulnerabilidad está en PHP, no en OXID. Haga que le confirmen el estado de PHP y que se reinicien todos los procesos. Después, revise config.inc.php, los módulos, los archivos del tema, las cuentas de administrador y los accesos al ERP y a los servicios de pago.
Por qué las tiendas OXID deberían mirar con atención
OXID eShop está muy extendido en el ámbito de habla alemana, sobre todo en el comercio B2B, entre fabricantes con venta directa y en el comercio mayorista. Estas tiendas rara vez son soluciones aisladas: intercambian pedidos, precios, existencias y datos de clientes con el ERP, el PIM y los servicios de pago. Por eso, un atacante en el servidor de la tienda suele ver más que solo la tienda.
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. Que OXID esté actualizado no influye en ello. Datos típicos en las tiendas OXID son:
- Clientes empresariales con personas de contacto, direcciones, números de cliente y precios individuales
- Historial de pedidos y solicitudes de oferta
- Credenciales del ERP y de los servicios de pago y de envío en la configuración y en los ajustes de módulos
- Cuentas de empleados en el área de administración
Seguridad en OXID eShop: comprobar correctamente el estado de PHP
En el área de administración, Servicio > Información del sistema muestra los datos de PHP de la tienda en ejecución. Es la versión web con la que se atiende a los clientes. En cambio, la consola de OXID, las importaciones y los cron jobs suelen ejecutarse con un PHP de línea de comandos que puede ser otra versión. Ambos deben estar parcheados.
Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones y los proveedores de hosting entregan a veces las correcciones como backport, y entonces el número no cambia; lo decisivo es el estado de los paquetes confirmado. Qué versiones de PHP admite su versión de OXID puede consultarlo, según los requisitos del sistema, en la documentación del fabricante en oxid-esales.com.
Las tiendas OXID más antiguas de la generación 4 o las primeras versiones de la generación 6 suelen funcionar todavía con versiones antiguas de PHP sin actualizaciones oficiales. Entonces, hasta la actualización hacen falta una protección transitoria y un calendario firme.
Directorios y archivos en OXID
Desde OXID 6, la tienda se instala mediante Composer; la raíz de documentos suele ser el directorio source/.
| Lugar | Contenido | Punto de control |
|---|---|---|
source/config.inc.php |
Acceso a la base de datos, ajustes básicos | Código añadido; cambiar la contraseña ante una sospecha |
source/modules/ (hasta OXID 6), desde OXID 7 vendor/ |
Módulos, en parte de paquetes de Composer | Módulos desconocidos, archivos modificados |
var/configuration/ |
Configuración de módulos y de la tienda como archivos | Cambios inesperados |
source/out/ |
Temas, imágenes, JavaScript | Scripts ajenos, archivos PHP en carpetas de imágenes |
source/tmp/ |
Plantillas compiladas y caché | Vaciar tras la limpieza |
source/log/ |
Registro de la tienda | Guardar antes de hacer cambios |
Las plantillas compiladas del directorio tmp suelen pasarse por alto. Constan de código PHP y se regeneran tras una limpieza; por eso la carpeta debería vaciarse después de cada hallazgo.
Primeras comprobaciones inofensivas:
# Archivos PHP en las carpetas de imágenes y medios
find source/out -type f -name "*.php"
# Archivos de módulos modificados desde el 17/10/2026 (OXID 6; desde OXID 7 los módulos están en vendor/)
find source/modules -type f -newermt "2026-10-17"
# Vulnerabilidades conocidas en las dependencias
composer audit
Un servidor de tienda limpiado no vuelve a hacer secretos los accesos de interfaz que se hayan filtrado. Ante una sospecha, renueve las credenciales del ERP y de los servicios de pago y de envío, de acuerdo con sus operadores.
Área de administración y módulos
El área de administración está por defecto en /admin/. Revise la gestión de usuarios en busca de cuentas con derechos de administrador que nadie sepa asignar y de accesos de antiguos proveedores de servicios. Si es posible, restrinja el acceso de administración a la red de la empresa o a una VPN; en el entorno B2B suele ser perfectamente viable.
Los módulos para métodos de pago, conexión con el ERP y funciones B2B como precios escalonados o procesos de aprobación suelen estar adaptados a medida en las tiendas OXID. Cada módulo es código PHP propio, y los módulos adaptados frenan con frecuencia las actualizaciones de PHP. Deje constancia de qué módulos están activos, quién los mantiene y si existe una versión para la versión de PHP prevista.
Lo que puede y no puede hacer una actualización de OXID
Una actualización de OXID o de un módulo cierra errores conocidos en ese código y puede permitir versiones más recientes de PHP. No parchea PHP y no reinicia ni PHP-FPM ni los procesos en segundo plano. Los archivos ajenos en source/out, los módulos manipulados, las plantillas compiladas y las nuevas cuentas de administrador permanecen. Si hay indicios de un ataque, compruébelo con ¿Estoy ya comprometido?. Sobre la situación en las pymes encaja Seguridad informática para pymes e industria.
Muchas tiendas OXID tienen, además del sistema en producción, un entorno de staging en el mismo servidor o en uno segundo. Revíselo y parchéelo también, porque a menudo contiene una copia de los datos de clientes y es igual de útil para los atacantes.
¿Cómo ayuda PHP SOS en concreto?
- Determinamos el PHP web y el PHP de CLI de su servidor OXID y hacemos que se confirmen el parche y el reinicio.
- Guardamos los registros a partir del 20/10/2026, los archivos y la base de datos.
- Revisamos
config.inc.php, módulos, temas, plantillas compiladas y cuentas de administrador. - Ante una sospecha, coordinamos, mediante nuestra respuesta a incidentes, la limpieza y la renovación de los accesos de interfaz con su agencia y sus proveedores de ERP.
Preguntas frecuentes
¿Está OXID eShop afectado por PHP2Shell?
PHP2Shell no es una vulnerabilidad de OXID, sino de PHP. Por eso, cualquier tienda OXID en un servidor con PHP sin parchear es potencialmente vulnerable. Una actualización de OXID no cierra la vulnerabilidad.
¿Dónde veo la versión de PHP en OXID?
En el área de administración, en Servicio > Información del sistema, donde se muestran los datos de PHP de la tienda en ejecución. El número no permite saber si se ha aplicado un backport; lo confirma su proveedor de hosting o su operador.
¿Qué archivo de OXID contiene las credenciales?
El archivo config.inc.php del directorio source. Contiene el acceso a la base de datos. Ante una sospecha, debería cambiar la contraseña de la base de datos y revisar el archivo en busca de código añadido.
¿Debemos revisar nuestra interfaz con el ERP?
Sí. Si un atacante ha ejecutado código en el servidor de la tienda, puede haber leído credenciales del ERP, del PIM o de servicios de pago. Esos accesos deberían renovarse ante una sospecha.