Un 0x5345… en el log: así se lee un intento de inyección SQL

En noviembre de 2025 Gustavo, de la comunidad, encontró en los registros de Plesk unas peticiones muy raras a un módulo de filtros de productos de terceros: un parámetro de precio que, en vez de un número, traía una cadena enorme que empezaba por 1');SELECT 0x5345…. La respuesta corta: es un intento automatizado de inyección SQL. Si el módulo trata bien ese parámetro, no pasa nada; si no, el atacante se lleva datos. Aquí está cómo leerlo y qué comprobar.

La petición

Era un GET al controlador de listado del módulo, con parámetros normales (categoría, página, fabricante) y uno de precio mínimo con esto detrás. Los 0x… son texto en hexadecimal: así el atacante esquiva filtros simples que buscan palabras como SELECT. Decodificados, los primeros bloques dicen:

SET @table_name = (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
  where TABLE_NAME like "%meta_lang%" LIMIT 1);
SET @prefix = REPLACE(@table_name,"meta_lang","");
SET @id_meta_sql = CONCAT('SELECT id_meta FROM ',@prefix,
  'meta WHERE page = "index" INTO @metaid');
SET @corders_sql = CONCAT('SELECT count(*) FROM ',@prefix,
  'orders WHERE date_add >= "2025-09-01" INTO @corders');

Qué buscaba

1. Averiguar el prefijo de las tablas (ps_ u otro) buscando cuál termina en meta_lang. Cambiar el prefijo al instalar no protege de esto.
2. Localizar la página de inicio en la tabla meta.
3. Contar los pedidos desde septiembre de 2025: saber si la tienda vende y merece la pena.
4. Leer la versión de PrestaShop (PS_VERSION_DB en la tabla de configuración).

El último bloque hace lo que ya apuntaba el análisis que otro compañero hizo con una IA: escribe los datos robados en la meta descripción de la portada, añadiendo al final algo como [i]prefijo[i]versión[i]pedidos. Es una forma ingeniosa de sacarlos: luego basta con visitar tu página de inicio y leer el código fuente.

¿Funcionó?

Otro miembro lo dijo bien: es solo un intento por GET, y si el módulo sanea ese parámetro (por ejemplo, convirtiéndolo a número), no debería pasar nada. Gustavo no encontró ningún aviso oficial de que ese módulo fuera vulnerable; la IA lo relacionaba con avisos genéricos de módulos de terceros de enero de 2025. Para saberlo en tu tienda:

• Mira el código y el tamaño de respuesta de esas peticiones en el registro de accesos. Un 500 o respuestas de tamaños distintos indican que el SQL llegó a ejecutarse en parte.

grep -i "information_schema\|0x5345" access_log | awk '{print $1, $9, $10}' | sort | uniq -c

• Revisa la meta descripción de la página de inicio, en Parámetros de la tienda → Tráfico y SEO, o directamente:

SELECT ml.id_lang, ml.title, ml.description
FROM ps_meta m
JOIN ps_meta_lang ml ON ml.id_meta = m.id_meta
WHERE m.page = 'index';

Si ves [i], números o textos que no escribiste, el ataque funcionó: trata la tienda como comprometida.

Qué hacer en cualquier caso

• Actualiza el módulo o pregunta al desarrollador si esa versión sanea los parámetros. Si no lo usas, desinstálalo y borra su carpeta: un módulo desactivado ya no atiende sus controladores de front, pero cualquier fichero PHP suelto de su carpeta sigue respondiendo si se llama directamente.
• Bloquea la IP, sabiendo que es un ataque automatizado y cambiará.
• Pon un cortafuegos de aplicación (ModSecurity con reglas OWASP, o el de tu CDN) que corte estos patrones antes de llegar a PHP.
• Si desarrollas módulos: nunca concatenes un parámetro en una consulta. Un precio se convierte con (float), un id con (int) y un texto pasa por pSQL().

Un intento de inyección que falla suele dejar errores de SQL en la tienda. Con el módulo Centinela de Rekire te llegan por Telegram en el momento.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación