Sin impuesto Con impuesto

Un WordPress viejo en el mismo hosting robó las claves de API

En agosto de 2026 Rekire limpió una tienda PrestaShop con un skimmer que había entrado por un WordPress desactualizado del mismo alojamiento. Además de las tarjetas, el atacante se llevó en silencio hashes de contraseñas y claves de API, entre ellas una de OpenAI. Qué aprendes: separar webs y limitar el gasto de cada clave.

Equipo Rekire
Actualizado: 25/08/2026 7
Un WordPress viejo en el mismo hosting robó las claves de API
Compartir:

En agosto de 2026 Rekire limpió otra tienda hackeada, esta vez con una entrada curiosa: el fichero con el skimmer que apareció en PrestaShop venía de un WordPress desactualizado alojado en la misma cuenta de hosting. Y no solo buscaba tarjetas. Respuesta corta: no compartas cuenta de hosting entre la tienda y otras webs, y pon límite de gasto a cada clave de API, sobre todo a las de IA.

Qué se llevaron

Sin hacer ruido, el código recogía hashes de contraseñas y las claves guardadas en la base de datos del WordPress:

  • Las claves de sesión de WordPress (auth_key y compañía).
  • La licencia y las claves de integraciones de un constructor de páginas: reCAPTCHA y varias herramientas de email marketing.
  • Una clave de la API de OpenAI. Como dijo Rekire, esa es la que da sustos: si la usan, el gasto es real y lo pagas tú.
  • Claves de un servicio de resultados de búsqueda, licencias de otros plugins y los datos de PayPal Business.

Por qué una web vecina llega a la tienda

Lo habitual cuando pasa esto: dos webs en la misma cuenta del hosting comparten usuario del sistema. Quien consigue ejecutar código en una puede leer y escribir los ficheros de la otra. Da igual que PrestaShop esté al día: el atacante entra por la puerta más débil de la cuenta y desde ahí llega a la tienda.

En el grupo alguien preguntó si esto pasaba por pegar las claves en una conversación con la IA. En este caso no: estaban guardadas, como es normal, en la base de datos del WordPress, y el atacante las leyó desde ahí. Aunque no está de más recordarlo: una clave pegada en un chat también es una clave fuera de tu control.

Qué hacer

  1. Una cuenta de hosting por web, o al menos usuarios separados. Si una web no se usa, se borra; si se usa, se actualiza.
  2. Cambia todas las claves que estuvieran en cualquiera de las webs de la cuenta, no solo en la que se ha visto el problema. En PrestaShop eso incluye las claves del webservice y las de los módulos de pago, de transporte y de IA.
  3. Límite de gasto en las APIs de IA y, como apuntó un compañero, desactiva la recarga automática. Si alguien usa tu clave, que se pare en una cantidad que puedas asumir.
  4. Una clave por web y por uso. Si te roban una, sabes de dónde ha salido y solo cambias esa.
  5. Revisa los ficheros nuevos o modificados de la tienda: el skimmer era un fichero nuevo, y eso se puede vigilar.

Cómo saber si ya te ha pasado

  • Mira el consumo de cada API en su panel: llamadas a horas raras, modelos que no usas o un gasto que no cuadra con tu actividad.
  • Revisa los usuarios administradores de todas las webs de la cuenta, también de las que «no se usan».
  • Busca ficheros PHP recientes fuera de las carpetas que actualizas tú, en las dos webs.
  • Si has encontrado algo en una web, da por comprometidas todas las de la misma cuenta.

En Rekire buscamos skimmers, puertas traseras y web shells en los ficheros con el módulo de alertas de seguridad por Telegram, y limpiamos tiendas dentro de un bono de horas.

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

Cargando...
Cookies
Volver arriba