Seguridad Drupal, Joomla, Magento: las vulnerabilidades que nadie verifica
WordPress acapara toda la atención de seguridad — pero Drupal, Joomla y Magento tienen sus propias vulnerabilidades críticas. Una brecha en Magento = tarjetas bancarias expuestas. Los riesgos son enormes.
- Cada CMS tiene archivos y endpoints expuestos por defecto: CHANGELOG.txt (Drupal), configuration.php.bak (Joomla), /app/etc/local.xml (Magento) — visibles sin ningún acceso admin
- Las auditorías externas (sin acceso al back-office) pueden detectar la mayoría de estas vulnerabilidades — exactamente como lo haría un atacante durante el reconocimiento inicial
- Los Lotes 1 y 2 de Orilyt añadirán pruebas de seguridad específicas de cada CMS — Joomla, Magento, PrestaShop, Drupal, OpenCart, todas externas, todas automáticas
WordPress absorbe toda la atención en seguridad web. Plugins vulnerables, versiones obsoletas, ataques de fuerza bruta en wp-admin — se habla de ello constantemente. Mientras tanto, Drupal, Joomla y Magento siguen funcionando en sitios gubernamentales, portales universitarios y tiendas e-commerce sin que nadie audite seriamente su seguridad.
Los riesgos son considerables. Una vulnerabilidad en Magento puede significar números de tarjeta bancaria expuestos. En Drupal, datos gubernamentales en peligro. En Joomla, bases de datos de clientes accesibles. Drupalgeddon en 2018 afectó a cientos de miles de sitios — y patrones similares siguen existiendo hoy.
Lo que hace la situación aún más preocupante: la mayoría de estas vulnerabilidades son detectables sin ningún acceso de administrador, simplemente mirando lo que el servidor expone públicamente. Eso es exactamente lo que hace un atacante durante la fase de reconocimiento. Y es lo que Orilyt va a automatizar para tu próxima auditoría.
Drupal — los puntos débiles del gigante empresarial
Drupal alimenta ministerios, universidades y empresas del Fortune 500. Su reputación de robustez es merecida — pero crea una falsa impresión de seguridad automática. En realidad, varios vectores de ataque son accesibles desde el primer reconocimiento externo.
Drupal mantiene un archivo CHANGELOG.txt en la raíz que revela la versión exacta instalada. Un atacante solo necesita esta información para apuntar a CVEs específicos. Este archivo debería eliminarse o restringirse en producción.
El script /update.php permite actualizar la base de datos después de una actualización de Drupal. Si se deja accesible sin protección, cualquiera puede activarlo — un vector clásico para la manipulación del esquema de base de datos.
La ruta de administración por defecto /user/login es fácilmente identificable. Combinada con la detección de versión mediante la etiqueta meta generator (a menudo presente en instalaciones por defecto), proporciona toda la información necesaria para un ataque dirigido.
El caso Drupalgeddon (SA-CORE-2018-002) sigue siendo emblemático: ejecución de código remota sin autenticación, explotada masivamente en pocas horas. La vulnerabilidad inicial era un fallo de inyección SQL — pero fue la exposición de la versión lo que permitió a los atacantes apuntar a los sitios no parcheados con precisión quirúrgica.
Joomla — el hijo olvidado de la web
Joomla ocupa una posición incómoda en el ecosistema CMS: lo suficientemente popular para ser un objetivo atractivo, lo suficientemente ignorado para que sus vulnerabilidades pasen desapercibidas. Millones de sitios siguen funcionando con Joomla 3.x — una rama que llegó al fin de su vida en diciembre de 2023.
Durante actualizaciones o migraciones, a veces se dejan accesibles archivos de respaldo de la configuración principal. configuration.php.bak — o configuration.php.old, configuration.bak.php — puede contener credenciales de base de datos en texto plano.
La interfaz de administración de Joomla es accesible en /administrator/ por defecto. No se sugiere ningún cambio de ruta durante la instalación. Esta ruta es escaneada con prioridad por los bots de ataque automatizados.
Joomla a menudo expone su versión exacta mediante la etiqueta meta generator. Peor aún: dejar el modo debug activado en producción (configuration.php: $debug = 1) provoca que se muestren informaciones sensibles en las páginas de error — rutas del servidor, consultas SQL, variables de sesión.
Las extensiones de Joomla son un vector de ataque importante a menudo subestimado. A diferencia de WordPress, que tiene un repositorio centralizado con sistemas de notificación, el ecosistema Joomla cuenta con miles de extensiones de terceros, muchas de las cuales ya no reciben mantenimiento.
Magento — donde el dinero se encuentra con el riesgo
Magento (Adobe Commerce) es el CMS de e-commerce de referencia para tiendas de alto volumen. También es uno de los objetivos más lucrativos para los atacantes. Los ataques Magecart — inyección de JavaScript malicioso en el checkout para capturar datos de tarjeta — han afectado a miles de tiendas Magento.
Magento 1.x exponía un downloader en /downloader/ que permitía instalar extensiones. Magento 2.x tiene su asistente de instalación en /setup/. Estos endpoints, dejados accesibles tras la instalación, son puntos de entrada directos para los atacantes.
El archivo /app/etc/local.xml (Magento 1) o /app/etc/env.php (Magento 2) contiene las credenciales de la base de datos, las claves de cifrado y otros secretos. Un servidor mal configurado que sirve este archivo directamente expone todos los datos de la tienda.
Magento permite personalizar la ruta de administración durante la instalación, pero muchos despliegues conservan /admin/ o /index.php/admin/. La gestión de parches de seguridad también es un problema: los comerciantes a menudo retrasan las actualizaciones por miedo a romper personalizaciones, dejando CVEs críticos sin corregir durante meses.
Los ataques Magecart ilustran perfectamente la realidad del riesgo: un atacante no necesita acceso de administrador para causar daños catastróficos. Una simple inyección de JavaScript en el formulario de checkout — posibilitada por una versión sin parche o una extensión vulnerable — es suficiente para exfiltrar todos los datos de pago.
PrestaShop y OpenCart — los perdedores del e-commerce
PrestaShop y OpenCart no reciben la misma cobertura mediática que Magento, pero alimentan cientos de miles de tiendas online. Sus vulnerabilidades son tanto más peligrosas cuanto que rara vez se auditan.
PrestaShop normalmente renombra la carpeta admin durante la instalación, pero /admin-dev/ a veces se deja en su lugar en entornos de desarrollo desplegados en producción. Los archivos /app/config/parameters.php y /config/settings.inc.php contienen credenciales de base de datos.
OpenCart mantiene /admin/ como ruta por defecto en la mayoría de instalaciones. Más crítico aún: los archivos config.php y admin/config.php contienen la ruta absoluta del servidor, credenciales de base de datos y claves secretas — y a veces son legibles directamente desde el navegador en servidores mal configurados.
Un patrón de inyección SQL conocido afecta a varias versiones de OpenCart, especialmente en los módulos de filtrado de productos. Estas vulnerabilidades están documentadas y existen PoC públicos — haciendo la explotación trivial para cualquier script kiddie con acceso a un motor de búsqueda.
Por qué las auditorías externas detectan lo que las herramientas internas no ven
La gran mayoría de las herramientas de seguridad para CMS requieren acceso de administrador o la instalación de un plugin de monitorización. Este enfoque tiene un punto ciego fundamental: presupone que el atacante no puede ver lo que la herramienta no mira.
Una auditoría externa prueba lo que un atacante ve desde el exterior. Sin instalación, sin acceso, sin dependencias. El servidor responde o no — y esa respuesta lo revela todo.
Las mismas solicitudes HTTP que un escáner de seguridad ofensivo: buscando CHANGELOG.txt, probando /administrator/, solicitando /app/etc/env.php. Si un atacante puede hacerlo, la herramienta debe hacerlo.
La versión del CMS a menudo se expone en meta tags, cabeceras HTTP, archivos README o assets versionados. Conocer la versión sin acceso admin es el primer paso de cualquier ataque dirigido.
La auditoría externa no reemplaza un pentest exhaustivo — pero detecta los frutos bajos que los atacantes buscan primero. En el 80% de las intrusiones reales, el punto de entrada era información accesible públicamente que nadie había pensado en verificar.
La hoja de ruta de seguridad multi-CMS de Orilyt
Orilyt audita hoy principalmente sitios WordPress. El siguiente paso — ya en desarrollo — es extender estas capacidades a los CMS más utilizados en la web. El enfoque sigue siendo el mismo: todo externo, todo automático, todo accionable.
Joomla (configuration.php.bak, /administrator/ desprotegido, versión en meta generator), Magento (/downloader/, /setup/, /app/etc/local.xml), PrestaShop (/admin-dev/, parameters.php). Estas pruebas verifican la exposición de los archivos y endpoints más peligrosos.
Drupal (CHANGELOG.txt, update.php, detección de versión), OpenCart (config.php expuesto, /admin/ sin protección adicional), Ghost (versión en assets, endpoints de API expuestos). Pruebas que combinan detección de CMS + verificación de archivos sensibles + análisis de cabeceras.
Todas estas pruebas estarán disponibles en el mismo informe Orilyt que ya conoces — con recomendaciones FIA (Hecho, Impacto, Acción) listas para presentar a tus clientes. Sin configuración adicional, sin acceso requerido.
El punto ciego que puedes cerrar hoy
La seguridad de los CMS no-WordPress es un punto ciego masivo en la industria web. Los propietarios de sitios Joomla, Magento o Drupal a menudo tienen una falsa sensación de seguridad porque su CMS es "menos atacado" que WordPress. Este es un razonamiento peligroso: los atacantes se adaptan al objetivo, no al revés.
Para los freelancers y las agencias, este punto ciego es una oportunidad. Proponer una auditoría de seguridad a un cliente con Magento que nunca ha verificado si /app/etc/env.php es accesible — eso es aportar un valor inmediato, demostrable y tangible. También es potencialmente salvarlos de una catástrofe.
Orilyt hará estas verificaciones automáticas. Mientras se esperan los Lotes 1 y 2, las pruebas WordPress existentes ya cubren patrones comunes a todos los CMS: cabeceras de seguridad, SSL, redirecciones, reputación IP. Una auditoría completa sigue siendo un excelente punto de partida.