{"id":3718,"date":"2026-07-24T00:45:43","date_gmt":"2026-07-23T22:45:43","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-detectar-y-eliminar-inyecciones-de-codigo-o-hackeos-en-prestashop\/"},"modified":"2026-07-24T00:45:45","modified_gmt":"2026-07-23T22:45:45","slug":"como-detectar-y-eliminar-inyecciones-de-codigo-o-hackeos-en-prestashop","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-detectar-y-eliminar-inyecciones-de-codigo-o-hackeos-en-prestashop\/","title":{"rendered":"\u00bfC\u00f3mo detectar y eliminar inyecciones de c\u00f3digo o hackeos en PrestaShop?"},"content":{"rendered":"<article>\n<section>\n    \u00bfC\u00f3mo detectar y eliminar inyecciones de c\u00f3digo o hackeos en PrestaShop? \ud83d\udee1\ufe0f<\/p>\n<p>Una tienda PrestaShop hackeada rara vez entra gritando. Suele hacerlo en puntillas: una l\u00ednea de JavaScript donde no deber\u00eda, un archivo PHP con nombre inocente, un pedido que nunca llega, una redirecci\u00f3n que aparece solo desde Google. El atacante, con admirable modestia, no suele dejar una tarjeta de visita. Deja algo peor: s\u00edntomas ambiguos.<\/p>\n<p>Y ah\u00ed empieza el oficio. No el de pulsar un bot\u00f3n m\u00e1gico \u2014ese animal mitol\u00f3gico tan querido por algunos paneles de hosting\u2014, sino el de investigar con m\u00e9todo, limpiar sin romper y cerrar las puertas que alguien, o algo, abri\u00f3 con paciencia de hormiga.<\/p>\n<\/section>\n<nav>\n    <strong>Contenido de la gu\u00eda<\/strong><\/p>\n<ul>\n<li><a href=\"#senales\">Se\u00f1ales de que PrestaShop ha sido comprometido<\/a><\/li>\n<li><a href=\"#tipos\">Tipos habituales de inyecci\u00f3n y malware<\/a><\/li>\n<li><a href=\"#primeros-pasos\">Qu\u00e9 hacer en los primeros minutos<\/a><\/li>\n<li><a href=\"#investigacion\">C\u00f3mo investigar archivos, base de datos y logs<\/a><\/li>\n<li><a href=\"#limpieza\">C\u00f3mo eliminar c\u00f3digo malicioso sin destruir la tienda<\/a><\/li>\n<li><a href=\"#prestashop\">Zonas cr\u00edticas espec\u00edficas de PrestaShop<\/a><\/li>\n<li><a href=\"#herramientas\">Herramientas \u00fatiles para el an\u00e1lisis<\/a><\/li>\n<li><a href=\"#prevencion\">C\u00f3mo prevenir nuevos hackeos<\/a><\/li>\n<li><a href=\"#faq\">Preguntas frecuentes<\/a><\/li>\n<\/ul>\n<\/nav>\n<section id=\"senales\">\n<h2>Se\u00f1ales de que tu PrestaShop puede estar hackeado \ud83d\udd0d<\/h2>\n<p>Una inyecci\u00f3n de c\u00f3digo en PrestaShop no siempre se manifiesta como una pantalla negra con letras verdes, pese a lo que el cine nos haya ense\u00f1ado con tanto entusiasmo. A menudo se parece m\u00e1s a una humedad en la pared: peque\u00f1a, casi decorativa, hasta que descubres que detr\u00e1s hay una tuber\u00eda rota.<\/p>\n<p>Estas son las se\u00f1ales m\u00e1s comunes de compromiso:<\/p>\n<ul>\n<li><strong>Redirecciones extra\u00f1as<\/strong> hacia dominios de apuestas, farmacias falsas, descargas, p\u00e1ginas adultas o tiendas clonadas.<\/li>\n<li><strong>Alertas de Google Safe Browsing<\/strong>, navegadores o antivirus indicando sitio peligroso, phishing o malware.<\/li>\n<li><strong>Scripts desconocidos<\/strong> insertados en el encabezado, pie de p\u00e1gina, plantillas del tema o m\u00f3dulos.<\/li>\n<li><strong>Archivos PHP sospechosos<\/strong> dentro de carpetas donde no deber\u00edan existir, como <code>\/img\/<\/code>, <code>\/upload\/<\/code>, <code>\/download\/<\/code> o subdirectorios de cach\u00e9.<\/li>\n<li><strong>Usuarios administradores nuevos<\/strong> o cuentas con permisos alterados.<\/li>\n<li><strong>Pedidos, pagos o carritos con comportamiento an\u00f3malo<\/strong>, especialmente si se sospecha robo de datos de tarjeta mediante skimmers.<\/li>\n<li><strong>Ca\u00eddas de rendimiento<\/strong>, alto consumo de CPU, procesos PHP persistentes o env\u00edo masivo de correos.<\/li>\n<li><strong>URLs indexadas en Google<\/strong> que no pertenecen a tu cat\u00e1logo: p\u00e1ginas en japon\u00e9s, chino, casinos, cupones falsos, spam SEO.<\/li>\n<li><strong>Modificaciones recientes<\/strong> en archivos centrales de PrestaShop, m\u00f3dulos o temas sin intervenci\u00f3n del equipo.<\/li>\n<li><strong>Errores 500 intermitentes<\/strong>, especialmente tras visitar ciertas p\u00e1ginas o al acceder al panel de administraci\u00f3n.<\/li>\n<\/ul>\n<p><strong>Una pista importante:<\/strong> si el problema solo aparece desde m\u00f3vil, desde resultados de b\u00fasqueda o para usuarios no autenticados, no significa que sea \u201cun fallo raro\u201d. Puede ser una t\u00e9cnica deliberada para ocultar el ataque al propietario de la tienda y mostrarlo \u00fanicamente a v\u00edctimas concretas.<\/p>\n<\/section>\n<section id=\"tipos\">\n<h2>Qu\u00e9 tipos de hackeos afectan con m\u00e1s frecuencia a PrestaShop \ud83e\uddec<\/h2>\n<p>PrestaShop, como cualquier CMS de comercio electr\u00f3nico, vive en una contradicci\u00f3n inc\u00f3moda: debe ser flexible para vender y r\u00edgido para resistir. Extensible como una navaja suiza, pero seguro como una caja fuerte. Esa ant\u00edtesis explica buena parte de sus riesgos: m\u00f3dulos, temas, overrides y personalizaciones son poder; tambi\u00e9n superficie de ataque.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tipo de ataque<\/th>\n<th>Qu\u00e9 hace<\/th>\n<th>D\u00f3nde suele esconderse<\/th>\n<th>Riesgo principal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Inyecci\u00f3n JavaScript<\/strong><\/td>\n<td>Inserta scripts externos, pop-ups, redirecciones o capturadores de datos.<\/td>\n<td>Plantillas <code>.tpl<\/code>, m\u00f3dulos, footer\/header, base de datos, hooks.<\/td>\n<td>Robo de credenciales, phishing, malware, p\u00e9rdida de confianza.<\/td>\n<\/tr>\n<tr>\n<td><strong>Webshell PHP<\/strong><\/td>\n<td>Permite ejecutar comandos, subir archivos o modificar el sitio desde el navegador.<\/td>\n<td><code>\/modules\/<\/code>, <code>\/img\/<\/code>, <code>\/upload\/<\/code>, <code>\/cache\/<\/code>, <code>\/var\/<\/code>.<\/td>\n<td>Control remoto de la tienda y reinfecciones.<\/td>\n<\/tr>\n<tr>\n<td><strong>Skimmer de pago<\/strong><\/td>\n<td>Captura datos introducidos por clientes en checkout o formularios.<\/td>\n<td>JavaScript del tema, m\u00f3dulos de pago, plantillas de checkout.<\/td>\n<td>Compromiso de datos financieros y posibles obligaciones legales.<\/td>\n<\/tr>\n<tr>\n<td><strong>Spam SEO<\/strong><\/td>\n<td>Crea p\u00e1ginas ocultas o enlaces para manipular buscadores.<\/td>\n<td>Base de datos, controladores, <code>.htaccess<\/code>, archivos generados.<\/td>\n<td>P\u00e9rdida de posicionamiento, penalizaciones y reputaci\u00f3n da\u00f1ada.<\/td>\n<\/tr>\n<tr>\n<td><strong>Backdoor persistente<\/strong><\/td>\n<td>Deja una puerta trasera para volver a entrar despu\u00e9s de la limpieza.<\/td>\n<td>Archivos con nombres leg\u00edtimos, overrides, cron jobs, m\u00f3dulos falsos.<\/td>\n<td>Reinfecci\u00f3n silenciosa.<\/td>\n<\/tr>\n<tr>\n<td><strong>Manipulaci\u00f3n de configuraci\u00f3n<\/strong><\/td>\n<td>Cambia variables de la tienda, URLs, SMTP, permisos o par\u00e1metros.<\/td>\n<td>Base de datos, archivos de configuraci\u00f3n, panel de administraci\u00f3n.<\/td>\n<td>Secuestro operativo o desv\u00edo de tr\u00e1fico.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>El malware moderno rara vez es tosco. Puede estar ofuscado con <code>base64_decode<\/code>, <code>eval<\/code>, <code>gzinflate<\/code>, <code>str_rot13<\/code> o cadenas rotas como cristales en una alfombra. Y s\u00ed, a veces un m\u00f3dulo leg\u00edtimo usa funciones delicadas por razones v\u00e1lidas. Por eso conviene investigar, no cazar sombras con una escoba.<\/p>\n<\/section>\n<section id=\"primeros-pasos\">\n<h2>Qu\u00e9 hacer en los primeros minutos: calma, copia y contenci\u00f3n \ud83d\udea8<\/h2>\n<p>Cuando una tienda empieza a redirigir clientes a un casino de dudosa poes\u00eda, la tentaci\u00f3n es borrar cosas al azar. Se comprende. Pero limpiar sin preservar evidencias es como barrer una escena antes de saber por d\u00f3nde entr\u00f3 el ladr\u00f3n.<\/p>\n<h3>1. Pon la tienda en modo mantenimiento si hay riesgo para clientes<\/h3>\n<p>Si sospechas de robo de datos, redirecciones maliciosas o scripts en el checkout, activa el modo mantenimiento desde el back office o restringe el acceso temporalmente a nivel de servidor. Es preferible perder unas horas de ventas que ofrecer a tus clientes una ruleta rusa con carrito.<\/p>\n<h3>2. Haz una copia completa antes de tocar nada<\/h3>\n<p>Guarda:<\/p>\n<ul>\n<li>Todos los archivos del sitio.<\/li>\n<li>La base de datos completa.<\/li>\n<li>Logs de acceso y errores del servidor.<\/li>\n<li>Logs de PHP-FPM, Apache, Nginx, ModSecurity o WAF si existen.<\/li>\n<li>Lista de procesos, tareas cron y usuarios del sistema si tienes acceso SSH.<\/li>\n<\/ul>\n<p><strong>No restaures una copia antigua sin analizarla.<\/strong> Muchas infecciones duermen durante semanas. Restaurar un backup infectado es como cambiar las s\u00e1banas sin sacar al escorpi\u00f3n.<\/p>\n<h3>3. Cambia credenciales, pero en el momento correcto<\/h3>\n<p>Cambia contrase\u00f1as de FTP\/SFTP, panel de hosting, base de datos, back office, cuentas de empleados, correo SMTP y claves API. Pero si a\u00fan hay una webshell activa, el atacante podr\u00eda capturar las nuevas claves. Primero cont\u00e9n, identifica accesos persistentes y despu\u00e9s rota credenciales de forma ordenada.<\/p>\n<h3>4. Desactiva accesos inseguros<\/h3>\n<ul>\n<li>Deshabilita FTP cl\u00e1sico y usa SFTP\/SSH.<\/li>\n<li>Revoca usuarios antiguos del hosting.<\/li>\n<li>Comprueba claves SSH autorizadas.<\/li>\n<li>Bloquea temporalmente el back office por IP si es viable.<\/li>\n<li>Revisa integraciones externas: ERP, marketplaces, conectores de transporte, m\u00f3dulos de pago.<\/li>\n<\/ul>\n<\/section>\n<section id=\"investigacion\">\n<h2>C\u00f3mo investigar una inyecci\u00f3n de c\u00f3digo en PrestaShop \ud83e\uddea<\/h2>\n<p>La investigaci\u00f3n tiene tres territorios: archivos, base de datos y logs. Separarlos ayuda. Mezclarlos demasiado pronto produce esa niebla mental tan propia de las madrugadas t\u00e9cnicas, cuando uno ya no sabe si <code>index.php<\/code> es un archivo o una advertencia existencial.<\/p>\n<h3>Revisar archivos modificados recientemente<\/h3>\n<p>Si tienes acceso SSH, localiza cambios recientes. Ajusta la ruta a tu instalaci\u00f3n:<\/p>\n<pre><code>find \/ruta\/a\/tu\/prestashop -type f -mtime -15 -printf \"%TY-%Tm-%Td %TT %p\\n\" | sort<\/code><\/pre>\n<p>Este comando muestra archivos modificados en los \u00faltimos 15 d\u00edas. Si el ataque ocurri\u00f3 hace m\u00e1s tiempo, ampl\u00eda el rango. Presta especial atenci\u00f3n a archivos PHP creados o alterados en carpetas de im\u00e1genes, descargas o cach\u00e9.<\/p>\n<h3>Buscar funciones PHP sospechosas<\/h3>\n<p>Muchas puertas traseras usan funciones de ejecuci\u00f3n, decodificaci\u00f3n u ofuscaci\u00f3n. No todas son maliciosas por s\u00ed mismas, pero merecen revisi\u00f3n:<\/p>\n<pre><code>grep -RIn --include=\"*.php\" \"eval\\|base64_decode\\|gzinflate\\|shell_exec\\|passthru\\|system\\|assert\\|preg_replace.*\\\/e\\|str_rot13\" \/ruta\/a\/tu\/prestashop<\/code><\/pre>\n<p>Tambi\u00e9n busca patrones de inyecci\u00f3n habituales:<\/p>\n<pre><code>grep -RIn \"document.write\\|atob\\|fromCharCode\\|unescape\\|iframe\\|crypto\\|skimmer\\|checkout\" \/ruta\/a\/tu\/prestashop\/themes \/ruta\/a\/tu\/prestashop\/modules<\/code><\/pre>\n<p><strong>Consejo pr\u00e1ctico:<\/strong> compara cualquier hallazgo con una copia limpia de la misma versi\u00f3n de PrestaShop y del mismo m\u00f3dulo. La diferencia entre una personalizaci\u00f3n leg\u00edtima y una infecci\u00f3n puede ser una sola l\u00ednea, tan discreta como una astilla bajo la u\u00f1a.<\/p>\n<h3>Comprobar integridad contra una versi\u00f3n limpia<\/h3>\n<p>Descarga desde el sitio oficial de PrestaShop la misma rama que usa tu tienda \u2014por ejemplo, PrestaShop 1.7.8.x, 8.x o la versi\u00f3n correspondiente\u2014 y compara los archivos del n\u00facleo. Los directorios personalizados, m\u00f3dulos comerciales y temas no estar\u00e1n en el paquete oficial, as\u00ed que interpreta los resultados con criterio.<\/p>\n<p>En servidores Linux puedes usar <code>diff<\/code> o generar hashes:<\/p>\n<pre><code>diff -rq \/ruta\/prestashop-limpio \/ruta\/prestashop-produccion<\/code><\/pre>\n<p>Los archivos del core no deber\u00edan estar modificados salvo que se haya hecho una personalizaci\u00f3n directa \u2014pr\u00e1ctica poco recomendable, aunque todav\u00eda frecuente\u2014. En PrestaShop, lo sensato es extender mediante m\u00f3dulos, overrides controlados o temas, no editar el n\u00facleo como quien escribe notas en el margen de un contrato.<\/p>\n<h3>Buscar archivos PHP en carpetas sospechosas<\/h3>\n<p>Algunas ubicaciones rara vez deber\u00edan contener PHP ejecutable:<\/p>\n<pre><code>find \/ruta\/a\/tu\/prestashop\/img \/ruta\/a\/tu\/prestashop\/upload \/ruta\/a\/tu\/prestashop\/download -type f -name \"*.php\" -print<\/code><\/pre>\n<p>En muchas instalaciones, un archivo PHP dentro de <code>\/img\/<\/code> o <code>\/upload\/<\/code> es mala se\u00f1al. No lo borres sin verlo antes. \u00c1brelo en un entorno seguro, no desde el navegador.<\/p>\n<h3>Revisar permisos peligrosos<\/h3>\n<p>Permisos demasiado abiertos facilitan escrituras indebidas. Busca archivos y carpetas con permisos 777:<\/p>\n<pre><code>find \/ruta\/a\/tu\/prestashop -perm -0777 -print<\/code><\/pre>\n<p>Como referencia general, los directorios suelen usar <code>755<\/code> y los archivos <code>644<\/code>, aunque puede variar seg\u00fan el usuario del servidor web, PHP-FPM y la configuraci\u00f3n del hosting. El objetivo no es recitar n\u00fameros sagrados, sino evitar que cualquiera pueda escribir donde no debe.<\/p>\n<h3>Analizar la base de datos<\/h3>\n<p>El malware no vive solo en archivos. Puede esconderse en tablas de configuraci\u00f3n, contenido CMS, descripciones de productos, bloques HTML o m\u00f3dulos. Seg\u00fan el prefijo de tu tienda \u2014habitualmente <code>ps_<\/code>, aunque puede ser otro\u2014 revisa especialmente:<\/p>\n<ul>\n<li><code>ps_configuration<\/code><\/li>\n<li><code>ps_cms<\/code> y <code>ps_cms_lang<\/code><\/li>\n<li><code>ps_product_lang<\/code><\/li>\n<li><code>ps_category_lang<\/code><\/li>\n<li><code>ps_hook_module<\/code><\/li>\n<li><code>ps_module<\/code><\/li>\n<li><code>ps_employee<\/code><\/li>\n<li>Tablas creadas por m\u00f3dulos de banners, HTML libre, sliders, chat, p\u00edxeles o marketing.<\/li>\n<\/ul>\n<p>B\u00fasquedas \u00fatiles en SQL, adaptando el prefijo:<\/p>\n<pre><code>SELECT name, value\nFROM ps_configuration\nWHERE value LIKE '%&lt;script%'\n   OR value LIKE '%iframe%'\n   OR value LIKE '%base64%'\n   OR value LIKE '%eval(%'\n   OR value LIKE '%document.write%';<\/code><\/pre>\n<pre><code>SELECT id_cms, content\nFROM ps_cms_lang\nWHERE content LIKE '%&lt;script%'\n   OR content LIKE '%iframe%'\n   OR content LIKE '%onerror=%'\n   OR content LIKE '%javascript:%';<\/code><\/pre>\n<p>Ten especial cuidado con scripts externos en campos aparentemente normales. Un dominio desconocido cargado en todas las p\u00e1ginas puede ser un simple p\u00edxel de marketing mal documentado&#8230; o una aguja envenenada.<\/p>\n<h3>Leer logs: el diario \u00edntimo del ataque<\/h3>\n<p>Los logs no siempre lo cuentan todo, pero cuando hablan, conviene escuchar. Revisa:<\/p>\n<ul>\n<li><strong>Access logs:<\/strong> peticiones POST a archivos raros, llamadas a m\u00f3dulos vulnerables, subidas de archivos.<\/li>\n<li><strong>Error logs:<\/strong> errores PHP repetidos, rutas inexistentes, warnings en m\u00f3dulos concretos.<\/li>\n<li><strong>Logs del back office:<\/strong> accesos de empleados, IPs inusuales, cambios de configuraci\u00f3n.<\/li>\n<li><strong>Logs de WAF o ModSecurity:<\/strong> intentos bloqueados y patrones de explotaci\u00f3n.<\/li>\n<\/ul>\n<p>Busca peticiones a archivos PHP en carpetas no habituales:<\/p>\n<pre><code>grep -Ei \"POST .*\\.php|\/upload\/.*\\.php|\/img\/.*\\.php|\/modules\/.*\\.php\" access.log<\/code><\/pre>\n<p>Tambi\u00e9n conviene revisar URLs con par\u00e1metros largos, cadenas codificadas, intentos de subida y accesos desde IPs repetitivas. El atacante automatizado es incansable: no duerme, no negocia, no se aburre. Un empleado s\u00ed.<\/p>\n<\/section>\n<section id=\"prestashop\">\n<h2>Zonas cr\u00edticas de PrestaShop que debes revisar \ud83e\udded<\/h2>\n<p>PrestaShop tiene su propia geograf\u00eda. Conocerla permite distinguir una plaza p\u00fablica de un callej\u00f3n sin luz.<\/p>\n<h3>1. Carpeta de m\u00f3dulos: <code>\/modules\/<\/code><\/h3>\n<p>Es una de las zonas m\u00e1s sensibles. Un m\u00f3dulo vulnerable, abandonado o pirateado puede abrir la puerta al servidor. Revisa:<\/p>\n<ul>\n<li>M\u00f3dulos instalados que ya no se usan.<\/li>\n<li>M\u00f3dulos descargados de fuentes no oficiales.<\/li>\n<li>Archivos modificados recientemente dentro de m\u00f3dulos de pago, banners, chat, importaci\u00f3n\/exportaci\u00f3n, blog o formularios.<\/li>\n<li>Controladores frontales accesibles sin validaci\u00f3n.<\/li>\n<li>Endpoints AJAX sin token o sin comprobaci\u00f3n de permisos.<\/li>\n<\/ul>\n<p>Muchos ataques a PrestaShop han aprovechado vulnerabilidades en m\u00f3dulos de terceros. No basta con actualizar el n\u00facleo si el eslab\u00f3n d\u00e9bil es un m\u00f3dulo que nadie recuerda haber instalado.<\/p>\n<h3>2. Tema activo: <code>\/themes\/tu-tema\/<\/code><\/h3>\n<p>Las plantillas <code>.tpl<\/code>, archivos JavaScript y hooks del tema son lugares ideales para inyectar scripts visibles al cliente. Revisa especialmente:<\/p>\n<ul>\n<li><code>header.tpl<\/code><\/li>\n<li><code>footer.tpl<\/code><\/li>\n<li>Plantillas de checkout.<\/li>\n<li>Archivos JS cargados globalmente.<\/li>\n<li>Bloques personalizados insertados por el maquetador o page builder.<\/li>\n<\/ul>\n<h3>3. Overrides: <code>\/override\/<\/code><\/h3>\n<p>Los overrides permiten modificar clases y controladores. Son \u00fatiles, s\u00ed. Tambi\u00e9n pueden ocultar comportamiento malicioso con una elegancia casi ofensiva. Si hay c\u00f3digo que altera procesos de pedido, cliente, pago o autenticaci\u00f3n, rev\u00edsalo con lupa.<\/p>\n<h3>4. Archivos de configuraci\u00f3n<\/h3>\n<p>Seg\u00fan la versi\u00f3n, revisa archivos como:<\/p>\n<ul>\n<li><code>\/app\/config\/parameters.php<\/code><\/li>\n<li><code>\/config\/settings.inc.php<\/code><\/li>\n<li><code>.env<\/code>, si existe en instalaciones modernas o adaptadas.<\/li>\n<li><code>.htaccess<\/code><\/li>\n<li><code>.user.ini<\/code> o configuraciones locales de PHP.<\/li>\n<\/ul>\n<p>El archivo <code>.htaccess<\/code> merece atenci\u00f3n especial. Unas pocas reglas de reescritura pueden convertir una tienda honesta en una estaci\u00f3n de transbordo hacia sitios fraudulentos.<\/p>\n<h3>5. Carpetas de cach\u00e9 y compilaci\u00f3n<\/h3>\n<p>PrestaShop puede usar rutas como <code>\/var\/cache\/<\/code>, <code>\/app\/cache\/<\/code> o <code>\/cache\/<\/code> seg\u00fan versi\u00f3n. En general, la cach\u00e9 puede regenerarse, pero no asumas que todo lo que hay dentro es descartable sin verificar. Algunos atacantes depositan archivos all\u00ed porque saben que muchos administradores no miran debajo de la alfombra.<\/p>\n<h3>6. Back office renombrado<\/h3>\n<p>PrestaShop suele renombrar la carpeta de administraci\u00f3n, por ejemplo <code>\/admin123abc\/<\/code>. Que est\u00e9 renombrada no la convierte en invisible. Revisa accesos, empleados, permisos y cualquier archivo extra\u00f1o dentro de esa ruta.<\/p>\n<\/section>\n<section id=\"limpieza\">\n<h2>C\u00f3mo eliminar malware de PrestaShop paso a paso \ud83e\uddf9<\/h2>\n<p>Limpiar no es borrar lo sospechoso y brindar. Limpiar es comprender el alcance, retirar el c\u00f3digo malicioso, cerrar el vector de entrada y verificar que no queda una puerta trasera. Lo dem\u00e1s es maquillaje sobre una herida.<\/p>\n<h3>1. Trabaja en una copia o entorno de staging<\/h3>\n<p>Si es posible, clona la tienda en un entorno aislado. As\u00ed podr\u00e1s analizar sin exponer a clientes ni romper producci\u00f3n. Si no tienes staging, trabaja con copias descargadas y mant\u00e9n la tienda restringida mientras intervienes.<\/p>\n<h3>2. Sustituye el n\u00facleo por archivos limpios<\/h3>\n<p>Para archivos del core modificados, lo m\u00e1s seguro suele ser reemplazarlos por copias oficiales de la misma versi\u00f3n. Evita sobrescribir:<\/p>\n<ul>\n<li><code>\/modules\/<\/code> completos sin revisar m\u00f3dulos comerciales.<\/li>\n<li><code>\/themes\/<\/code> si hay un tema personalizado.<\/li>\n<li><code>\/img\/<\/code> con im\u00e1genes de cat\u00e1logo.<\/li>\n<li>Archivos de configuraci\u00f3n con credenciales.<\/li>\n<\/ul>\n<p>Despu\u00e9s de limpiar, valora actualizar a una versi\u00f3n soportada de PrestaShop. Mantener una tienda antigua conectada a Internet es una forma muy elaborada de confiar en la bondad del mundo.<\/p>\n<h3>3. Elimina webshells y backdoors<\/h3>\n<p>Un archivo malicioso puede llamarse <code>class.php<\/code>, <code>image.php<\/code>, <code>cache.php<\/code>, <code>autoload.php<\/code> o incluso imitar nombres leg\u00edtimos. Revisa contenido, fecha, propietario y ubicaci\u00f3n. Se\u00f1ales frecuentes:<\/p>\n<ul>\n<li>C\u00f3digo ilegible u ofuscado.<\/li>\n<li>Uso combinado de <code>eval<\/code>, <code>base64_decode<\/code>, <code>gzinflate<\/code>, <code>assert<\/code> o ejecuci\u00f3n de comandos.<\/li>\n<li>Formularios ocultos para subir archivos.<\/li>\n<li>Comprobaciones de contrase\u00f1a internas.<\/li>\n<li>C\u00f3digo que lee o escribe en rutas arbitrarias.<\/li>\n<li>Archivos PHP dentro de carpetas de im\u00e1genes o subida.<\/li>\n<\/ul>\n<p><strong>Atenci\u00f3n:<\/strong> si eliminas solo la inyecci\u00f3n visible pero dejas la webshell, el sitio se reinfectar\u00e1. Es como cambiar la cerradura de la puerta principal mientras la ventana del s\u00f3tano sigue abierta con una cinta que dice \u201cbienvenido\u201d.<\/p>\n<h3>4. Limpia la base de datos<\/h3>\n<p>Retira scripts, iframes y enlaces no autorizados de tablas de contenido y configuraci\u00f3n. Hazlo con copia previa y evita reemplazos masivos sin revisar, porque podr\u00edas romper contenido leg\u00edtimo.<\/p>\n<p>Despu\u00e9s comprueba:<\/p>\n<ul>\n<li>Variables de dominio y SSL en <code>ps_configuration<\/code>.<\/li>\n<li>Contenido CMS y bloques HTML.<\/li>\n<li>Descripciones de productos y categor\u00edas.<\/li>\n<li>Empleados del back office.<\/li>\n<li>Hooks con m\u00f3dulos inesperados.<\/li>\n<li>Tablas desconocidas creadas recientemente.<\/li>\n<\/ul>\n<h3>5. Reinstala o actualiza m\u00f3dulos sospechosos<\/h3>\n<p>Si un m\u00f3dulo est\u00e1 comprometido, reempl\u00e1zalo desde una fuente oficial. No reutilices archivos de una carpeta infectada por comodidad. La comodidad, en seguridad, tiene a veces la textura de una trampa bien acolchada.<\/p>\n<p>Elimina m\u00f3dulos que:<\/p>\n<ul>\n<li>No est\u00e9n mantenidos.<\/li>\n<li>No sean compatibles con tu versi\u00f3n actual.<\/li>\n<li>Procedan de sitios no confiables.<\/li>\n<li>No se usen desde hace meses.<\/li>\n<li>Tengan historial de vulnerabilidades sin parche.<\/li>\n<\/ul>\n<h3>6. Regenera cach\u00e9 y recompila<\/h3>\n<p>Despu\u00e9s de limpiar archivos y base de datos:<\/p>\n<ul>\n<li>Vac\u00eda la cach\u00e9 desde el back office si es posible.<\/li>\n<li>Borra manualmente cach\u00e9 de PrestaShop seg\u00fan versi\u00f3n, sin eliminar configuraciones cr\u00edticas.<\/li>\n<li>Purga cach\u00e9 de CDN, proxy inverso o sistemas como Varnish, LiteSpeed Cache o Cloudflare.<\/li>\n<li>Revisa que el HTML final generado ya no contenga scripts maliciosos.<\/li>\n<\/ul>\n<h3>7. Cambia todas las credenciales<\/h3>\n<p>Una vez retiradas puertas traseras evidentes:<\/p>\n<ul>\n<li>Cambia contrase\u00f1as de empleados PrestaShop.<\/li>\n<li>Rota contrase\u00f1a de base de datos y actualiza el archivo de configuraci\u00f3n correspondiente.<\/li>\n<li>Cambia accesos al hosting, SSH\/SFTP, panel de control y proveedor DNS.<\/li>\n<li>Renueva claves API de m\u00f3dulos de pago, transportistas, marketplaces y ERPs.<\/li>\n<li>Revisa cuentas de correo usadas para recuperaci\u00f3n de contrase\u00f1as.<\/li>\n<\/ul>\n<h3>8. Verifica desde fuera<\/h3>\n<p>Comprueba la tienda como la ver\u00eda un cliente real:<\/p>\n<ul>\n<li>Navegaci\u00f3n desde inc\u00f3gnito.<\/li>\n<li>Acceso desde m\u00f3vil.<\/li>\n<li>Visitas procedentes de Google.<\/li>\n<li>Checkout completo en modo prueba.<\/li>\n<li>Escaneo con herramientas externas de seguridad.<\/li>\n<li>Revisi\u00f3n de c\u00f3digo fuente renderizado en navegador.<\/li>\n<\/ul>\n<p>Algunos malware usan cloaking: muestran contenido limpio al administrador y malicioso al visitante. La tienda parece una cosa para ti y otra para el mundo. Es teatro, pero con p\u00e9rdidas.<\/p>\n<\/section>\n<section id=\"herramientas\">\n<h2>Herramientas \u00fatiles para detectar hackeos en PrestaShop \ud83e\uddf0<\/h2>\n<p>No existe una herramienta \u00fanica que lo encuentre todo. La seguridad web se parece m\u00e1s a una mesa de trabajo que a una varita m\u00e1gica: varias piezas, cada una con su modesta utilidad.<\/p>\n<table>\n<thead>\n<tr>\n<th>Herramienta o recurso<\/th>\n<th>Uso recomendado<\/th>\n<th>Observaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Comparaci\u00f3n con paquete oficial<\/strong><\/td>\n<td>Detectar cambios en archivos del n\u00facleo.<\/td>\n<td>Muy \u00fatil para core, menos para m\u00f3dulos y temas personalizados.<\/td>\n<\/tr>\n<tr>\n<td><strong>grep, find, diff<\/strong><\/td>\n<td>B\u00fasqueda t\u00e9cnica de patrones, fechas y diferencias.<\/td>\n<td>Potente si tienes SSH y criterio para interpretar resultados.<\/td>\n<\/tr>\n<tr>\n<td><strong>ClamAV \/ Maldet<\/strong><\/td>\n<td>Escaneo de malware conocido en servidor.<\/td>\n<td>Puede dar falsos positivos y no detecta todo.<\/td>\n<\/tr>\n<tr>\n<td><strong>VirusTotal<\/strong><\/td>\n<td>Analizar archivos o URLs sospechosas.<\/td>\n<td>No subas archivos con secretos, claves o datos privados.<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Search Console<\/strong><\/td>\n<td>Revisar problemas de seguridad, spam indexado y solicitudes de revisi\u00f3n.<\/td>\n<td>Imprescindible si Google ha marcado el sitio.<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Safe Browsing<\/strong><\/td>\n<td>Comprobar si el dominio aparece como peligroso.<\/td>\n<td>\u00datil para reputaci\u00f3n, no sustituye an\u00e1lisis interno.<\/td>\n<\/tr>\n<tr>\n<td><strong>WAF\/CDN<\/strong><\/td>\n<td>Bloquear patrones de ataque, bots y explotaci\u00f3n masiva.<\/td>\n<td>Ayuda a prevenir, pero no limpia una infecci\u00f3n ya existente.<\/td>\n<\/tr>\n<tr>\n<td><strong>Esc\u00e1neres especializados<\/strong><\/td>\n<td>Auditor\u00eda de vulnerabilidades, malware y cabeceras.<\/td>\n<td>Conviene combinarlos con revisi\u00f3n manual.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Sobre los plugins o m\u00f3dulos \u201climpiadores\u201d:<\/strong> pueden ayudar, pero no delegues toda la respuesta en ellos. Si la tienda procesa pagos, datos personales y pedidos, necesitas una limpieza verificable, no una promesa con bot\u00f3n azul.<\/p>\n<\/section>\n<section id=\"prevencion\">\n<h2>C\u00f3mo prevenir nuevas inyecciones de c\u00f3digo en PrestaShop \ud83d\udd10<\/h2>\n<p>La prevenci\u00f3n no consiste en construir una muralla medieval y dormir tranquilo. Internet trae catapultas nuevas cada semana. Se trata de reducir superficie de ataque, detectar antes y responder mejor.<\/p>\n<h3>Mant\u00e9n PrestaShop, m\u00f3dulos y tema actualizados<\/h3>\n<p>Las actualizaciones corrigen fallos funcionales y vulnerabilidades. En tiendas con alto volumen, prueba antes en staging. Pero no confundas prudencia con abandono: posponer parches durante meses es una invitaci\u00f3n escrita en varios idiomas.<\/p>\n<h3>Elimina lo que no uses<\/h3>\n<p>Cada m\u00f3dulo instalado es c\u00f3digo que puede fallar. Si no se usa, fuera. Si no se mantiene, fuera. Si nadie sabe para qu\u00e9 sirve, probablemente merece una conversaci\u00f3n inc\u00f3moda y luego fuera.<\/p>\n<h3>Usa permisos adecuados<\/h3>\n<ul>\n<li>Evita permisos 777.<\/li>\n<li>Limita escritura a carpetas necesarias.<\/li>\n<li>Configura correctamente usuario y grupo del servidor web.<\/li>\n<li>Bloquea ejecuci\u00f3n PHP en carpetas de subida cuando sea posible.<\/li>\n<\/ul>\n<p>Ejemplo de regla para Apache en una carpeta de subidas, adapt\u00e1ndola con cuidado al entorno:<\/p>\n<pre><code>&lt;FilesMatch \"\\.php$\"&gt;\n  Require all denied\n&lt;\/FilesMatch&gt;<\/code><\/pre>\n<p>En Nginx, la restricci\u00f3n debe hacerse en la configuraci\u00f3n del servidor, no mediante <code>.htaccess<\/code>.<\/p>\n<h3>Protege el back office<\/h3>\n<ul>\n<li>Usa contrase\u00f1as \u00fanicas y largas.<\/li>\n<li>Activa doble factor si tu versi\u00f3n, m\u00f3dulo o infraestructura lo permite.<\/li>\n<li>Limita acceso por IP cuando sea viable.<\/li>\n<li>Reduce permisos de empleados seg\u00fan funci\u00f3n real.<\/li>\n<li>Elimina cuentas antiguas de agencias, freelancers o personal que ya no participa.<\/li>\n<\/ul>\n<h3>Implementa cabeceras de seguridad<\/h3>\n<p>Cabeceras como <code>Content-Security-Policy<\/code>, <code>X-Frame-Options<\/code>, <code>Referrer-Policy<\/code> y <code>Permissions-Policy<\/code> ayudan a reducir riesgos. La m\u00e1s delicada es CSP, porque puede bloquear scripts leg\u00edtimos si se configura sin inventario previo.<\/p>\n<p>Una CSP bien dise\u00f1ada puede dificultar skimmers e inyecciones JavaScript. Una CSP improvisada puede romper el checkout. Entre la fortaleza y el incendio hay, a veces, una comilla.<\/p>\n<h3>Vigila integridad de archivos<\/h3>\n<p>Configura alertas para cambios en archivos cr\u00edticos. Puedes usar herramientas de monitorizaci\u00f3n, Git para despliegues controlados o scripts que comparen hashes. Lo importante es saber cu\u00e1ndo cambi\u00f3 algo y qui\u00e9n lo hizo.<\/p>\n<h3>Backups: frecuentes, externos y probados<\/h3>\n<p>Un backup que nunca se ha restaurado es una superstici\u00f3n comprimida. Mant\u00e9n copias:<\/p>\n<ul>\n<li>Autom\u00e1ticas y peri\u00f3dicas.<\/li>\n<li>Fuera del servidor principal.<\/li>\n<li>Con retenci\u00f3n suficiente para detectar infecciones antiguas.<\/li>\n<li>Cifradas si contienen datos sensibles.<\/li>\n<li>Probadas en restauraci\u00f3n real.<\/li>\n<\/ul>\n<h3>Usa WAF y reglas contra bots<\/h3>\n<p>Un firewall de aplicaciones web puede bloquear intentos comunes de explotaci\u00f3n, fuerza bruta, payloads conocidos y tr\u00e1fico automatizado. No sustituye las actualizaciones, pero a\u00f1ade una capa valiosa. Seguridad por capas: aburrida de explicar, preciosa cuando funciona.<\/p>\n<h3>Audita m\u00f3dulos antes de instalarlos<\/h3>\n<p>Antes de a\u00f1adir un m\u00f3dulo:<\/p>\n<ul>\n<li>Comprueba reputaci\u00f3n del desarrollador.<\/li>\n<li>Revisa fecha de \u00faltima actualizaci\u00f3n.<\/li>\n<li>Verifica compatibilidad con tu versi\u00f3n.<\/li>\n<li>Evita m\u00f3dulos nulled o pirateados.<\/li>\n<li>Lee permisos y funcionalidades reales.<\/li>\n<\/ul>\n<p><strong>Regla sencilla:<\/strong> si un m\u00f3dulo \u201cpremium gratis\u201d promete ahorrarte 79 euros, preg\u00fantate qu\u00e9 cobra a cambio. A veces el precio llega despu\u00e9s, vestido de incidente de seguridad.<\/p>\n<\/section>\n<section>\n<h2>Qu\u00e9 hacer si hubo robo de datos o afectaci\u00f3n al checkout \ud83d\udcb3<\/h2>\n<p>Si sospechas que el ataque pudo capturar datos personales, credenciales o informaci\u00f3n de pago, la respuesta deja de ser solo t\u00e9cnica. Entra en terreno legal, reputacional y contractual.<\/p>\n<ul>\n<li>Documenta fechas, alcance y evidencias.<\/li>\n<li>Identifica si se comprometieron datos personales de clientes.<\/li>\n<li>Consulta obligaciones bajo RGPD u otra normativa aplicable.<\/li>\n<li>Contacta con tu proveedor de pagos si el checkout estuvo afectado.<\/li>\n<li>Revisa requisitos PCI DSS si tu tienda procesa, transmite o afecta datos de tarjeta.<\/li>\n<li>Prepara comunicaci\u00f3n clara para clientes si procede.<\/li>\n<\/ul>\n<p>Muchas tiendas usan pasarelas redirigidas o tokenizadas, lo cual reduce exposici\u00f3n, pero no elimina todos los riesgos. Un skimmer JavaScript puede capturar datos antes de que salgan hacia la pasarela si se inserta en el momento adecuado. La frontera entre \u201cno almacenamos tarjetas\u201d y \u201cno hubo riesgo\u201d es m\u00e1s delgada de lo que parece.<\/p>\n<\/section>\n<section>\n<h2>Checklist profesional de limpieza y endurecimiento \u2705<\/h2>\n<ul>\n<li>Activar mantenimiento o contenci\u00f3n temporal si hay riesgo para usuarios.<\/li>\n<li>Realizar copia completa de archivos, base de datos y logs.<\/li>\n<li>Analizar archivos modificados recientemente.<\/li>\n<li>Comparar core con una versi\u00f3n limpia de PrestaShop.<\/li>\n<li>Buscar webshells, backdoors y funciones PHP sospechosas.<\/li>\n<li>Revisar m\u00f3dulos instalados, especialmente terceros y no mantenidos.<\/li>\n<li>Auditar tema activo, plantillas de checkout, header y footer.<\/li>\n<li>Examinar base de datos en busca de scripts, iframes y contenido an\u00f3malo.<\/li>\n<li>Revisar empleados del back office y permisos.<\/li>\n<li>Eliminar c\u00f3digo malicioso y reemplazar archivos comprometidos por copias limpias.<\/li>\n<li>Actualizar PrestaShop, m\u00f3dulos y tema.<\/li>\n<li>Regenerar cach\u00e9 y purgar CDN.<\/li>\n<li>Rotar todas las credenciales.<\/li>\n<li>Configurar permisos adecuados y bloquear ejecuci\u00f3n PHP donde no corresponda.<\/li>\n<li>Implementar WAF, monitorizaci\u00f3n e integridad de archivos.<\/li>\n<li>Verificar el sitio desde navegador, m\u00f3vil, buscadores y herramientas externas.<\/li>\n<li>Solicitar revisi\u00f3n en Google Search Console si hubo advertencias.<\/li>\n<li>Documentar el incidente y medidas aplicadas.<\/li>\n<\/ul>\n<\/section>\n<section id=\"faq\">\n<h2>Preguntas frecuentes sobre PrestaShop hackeado \u2753<\/h2>\n<h3>\u00bfPuedo limpiar una tienda PrestaShop solo restaurando un backup?<\/h3>\n<p>A veces s\u00ed, pero solo si sabes que el backup es anterior al compromiso y si corriges el vector de entrada. Si restauras y mantienes el m\u00f3dulo vulnerable, la contrase\u00f1a filtrada o la webshell en otra ruta, volver\u00e1s al punto de partida con puntualidad casi administrativa.<\/p>\n<h3>\u00bfActualizar PrestaShop elimina el malware?<\/h3>\n<p>No necesariamente. Actualizar puede reemplazar parte del n\u00facleo y corregir vulnerabilidades, pero no limpia por completo m\u00f3dulos infectados, base de datos manipulada, archivos subidos ni puertas traseras fuera del core. Primero analiza; despu\u00e9s actualiza con control.<\/p>\n<h3>\u00bfLos antivirus del hosting son suficientes?<\/h3>\n<p>Son \u00fatiles, pero no infalibles. Detectan firmas conocidas, no siempre variantes nuevas u ofuscadas. Adem\u00e1s, pueden pasar por alto inyecciones en base de datos o scripts cargados desde configuraciones leg\u00edtimas.<\/p>\n<h3>\u00bfPor qu\u00e9 mi PrestaShop se reinfecta?<\/h3>\n<p>Las causas t\u00edpicas son: backdoor no eliminada, m\u00f3dulo vulnerable sin actualizar, credenciales comprometidas, permisos inseguros, tareas cron maliciosas o varias tiendas en el mismo hosting compartiendo infecci\u00f3n. La reinfecci\u00f3n no es mala suerte; suele ser una pista.<\/p>\n<h3>\u00bfDebo cambiar la carpeta de administraci\u00f3n?<\/h3>\n<p>Ayuda contra bots b\u00e1sicos, pero no es una defensa suficiente. Debe acompa\u00f1arse de contrase\u00f1as fuertes, doble factor cuando sea posible, restricci\u00f3n por IP, actualizaci\u00f3n y control de empleados.<\/p>\n<h3>\u00bfC\u00f3mo s\u00e9 si Google ya detect\u00f3 el hackeo?<\/h3>\n<p>Revisa Google Search Console, el informe de problemas de seguridad y el estado del dominio en Safe Browsing. Tambi\u00e9n busca en Google con operadores como <code>site:tudominio.com casino<\/code>, <code>site:tudominio.com viagra<\/code> o t\u00e9rminos sospechosos. No es elegante, pero funciona.<\/p>\n<h3>\u00bfQu\u00e9 diferencia hay entre malware, inyecci\u00f3n de c\u00f3digo y hackeo?<\/h3>\n<p>\u201cHackeo\u201d es el t\u00e9rmino general. \u201cInyecci\u00f3n de c\u00f3digo\u201d describe la inserci\u00f3n de c\u00f3digo no autorizado, por ejemplo JavaScript o PHP. \u201cMalware\u201d es software malicioso con un objetivo: robar, redirigir, persistir, enviar spam, manipular SEO o controlar el servidor. En una tienda comprometida suelen convivir, como invitados indeseables que encima ensucian la cocina.<\/p>\n<\/section>\n<section>\n<h2>La seguridad de una tienda no se improvisa<\/h2>\n<p>Detectar y eliminar inyecciones de c\u00f3digo en PrestaShop exige una mezcla de t\u00e9cnica, paciencia y desconfianza saludable. Hay que mirar archivos, base de datos, m\u00f3dulos, logs y comportamiento real del navegador. Hay que distinguir el polvo del veneno. Y hay que aceptar una verdad poco c\u00f3moda: una tienda online no es un folleto digital, es una m\u00e1quina econ\u00f3mica conectada al mundo.<\/p>\n<p>Por eso un PrestaShop seguro no es el que nunca recibe ataques. Ese sitio no existe. Es el que reduce sus puntos d\u00e9biles, detecta cambios extra\u00f1os, actualiza a tiempo, guarda backups \u00fatiles y responde con m\u00e9todo cuando algo se tuerce. Entre la tienda abandonada y la tienda vigilada hay la misma diferencia que entre una puerta pintada y una puerta cerrada.<\/p>\n<p>El c\u00f3digo malicioso se esconde en silencio, s\u00ed. Pero el silencio tambi\u00e9n deja huellas. Solo hay que saber escucharlas. \ud83d\udee1\ufe0f<\/p>\n<\/section>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfC\u00f3mo detectar y eliminar inyecciones de c\u00f3digo o hackeos en PrestaShop? \ud83d\udee1\ufe0f Una tienda PrestaShop<\/p>\n","protected":false},"author":1,"featured_media":3717,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3718","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento"],"_links":{"self":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3718","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/comments?post=3718"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3718\/revisions"}],"predecessor-version":[{"id":3719,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3718\/revisions\/3719"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3717"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3718"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3718"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3718"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}