En pocas palabras: La pantalla blanca (WSOD) tras un hackeo es un error fatal de PHP causado por código inyectado en functions.php, .htaccess o wp-config.php. Se diagnostica activando WP_DEBUG_LOG, revisando esos tres archivos y los logs del servidor, y se resuelve eliminando el código malicioso en menos de 30 minutos.
Una pantalla blanca en WordPress después de un hackeo es un error fatal de PHP que corta la ejecución del sitio antes de mostrar nada, casi siempre porque el atacante modificó functions.php, .htaccess o wp-config.php. Se soluciona activando WP_DEBUG, revisando esos archivos y limpiando el código inyectado.
La pantalla blanca de WordPress (White Screen of Death o WSOD) es un error fatal de PHP que aparece cuando el servidor no puede ejecutar el código del sitio, sin mostrar ningún mensaje visible. Cuando la causa es un hackeo, el error suele originarse en código inyectado dentro de un plugin, un tema o el core de WordPress, y afecta tanto al frontend como, en los casos más graves, al panel de administración.
En este artículo:
- En 30 segundos
- ¿Pantalla blanca por hackeo o por un plugin? Cómo distinguirlos
- ¿Cómo activar WP_DEBUG para ver el error real detrás de la pantalla blanca?
- ¿Qué archivos hay que revisar cuando la pantalla blanca es por un ataque?
- ¿Cómo recuperar el acceso al sitio si el panel de administración también está en blanco?
- ¿Qué herramientas escanean el malware que causó la pantalla blanca?
- ¿Cómo hacer una auditoría de seguridad completa después de recuperar el sitio?
- ¿Cómo evitar que la pantalla blanca por ataque se repita?
- Errores comunes al diagnosticar una pantalla blanca por hackeo
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- La pantalla blanca (WSOD) es un error fatal de PHP, no un bug visual: corta la carga del sitio entero.
- Si /wp-admin también está en blanco, el problema es más profundo: núcleo, wp-config.php o un mu-plugin inyectado.
- WP_DEBUG_LOG activado escribe el error exacto, archivo y línea, en wp-content/debug.log.
- Los puntos de inyección más comunes son functions.php, .htaccess y wp-content/uploads.
- Wordfence y Sucuri SiteCheck son las dos herramientas gratuitas más usadas para confirmar el malware.
¿Pantalla blanca por hackeo o por un plugin? Cómo distinguirlos
La forma más rápida de distinguirlos es mirar si /wp-admin también quedó en blanco. Si solo falla el frontend, casi siempre es un plugin o un tema incompatible con la versión de PHP del hosting. Si el panel de administración también murió, hay más chances de que sea un hackeo con código inyectado en un archivo que se carga siempre, como wp-config.php o un mu-plugin.
Un plugin desactualizado que choca con la versión de PHP es, en la enorme mayoría de los casos, la causa real detrás de una pantalla blanca. El malware es menos frecuente. Eso sí, cuando aparece, deja señales bastante puntuales. Complementá con activar 2FA para evitar que vuelva a pasar.
- Aparece de golpe, sin que hayas actualizado nada. Un plugin roto suele coincidir con una actualización reciente; un hackeo no.
- Hay archivos nuevos con nombres raros en wp-content/uploads. Es una carpeta que no debería tener .php sueltos.
- El hosting avisó de tráfico saliente sospechoso o de un aviso de Google Safe Browsing. Ese tipo de alerta casi nunca la dispara un plugin incompatible.
- Aparecieron usuarios administradores que vos no diste de alta. Es la señal más clara de que alguien entró.
¿Cómo activar WP_DEBUG para ver el error real detrás de la pantalla blanca?
Para ver el error real hay que editar wp-config.php y activar tres constantes: WP_DEBUG en true, WP_DEBUG_LOG en true para que el error quede escrito en un archivo, y WP_DEBUG_DISPLAY en false para no mostrar el error en pantalla a cualquier visitante que entre al sitio mientras lo estás arreglando.
Con eso alcanza casi siempre. El log queda en wp-content/debug.log, y ahí tenés que buscar la línea que dice «Fatal error» o «Parse error», que trae el archivo y el número de línea exactos. Si el hosting no te deja tocar wp-config.php desde el panel, revisá también el error_log del servidor, que suele estar en la raíz del hosting o accesible desde cPanel/Plesk.
¿Y si el log no muestra nada? Ahí el problema puede estar en el propio wp-config.php, que se rompió antes de que WordPress llegue a leer las constantes de debug.
¿Qué archivos hay que revisar cuando la pantalla blanca es por un ataque?
Los cuatro puntos de inyección más comunes son functions.php del tema activo, .htaccess, wp-config.php y la carpeta wp-content/uploads, que no se sobrescribe cuando reinstalás el núcleo de WordPress y por eso es un escondite habitual para backdoors. Más contexto en reforzar las cabeceras de seguridad del sitio.
Subís el sitio, todo funciona bien durante meses, un plugin viejo que nadie actualizó abre la puerta, alguien mete una línea en functions.php, esa línea rompe la sintaxis PHP y ahí aparece la pantalla blanca sin ningún aviso previo.
Dentro de esos archivos, las funciones PHP que casi siempre delatan un backdoor son eval(), base64_decode(), gzinflate() y assert(), sobre todo cuando aparecen encadenadas o con nombres de variables sin sentido. Un caso documentado en la guía de troubleshooting de mdpabel.com describe un malware llamado Zeura que provoca directamente el WSOD al insertarse en archivos del core, un ejemplo concreto de que el hackeo no siempre esconde el ataque, a veces lo hace evidente.
¿Cómo recuperar el acceso al sitio si el panel de administración también está en blanco?
Si ni el frontend ni /wp-admin cargan, hay que entrar por FTP o SSH y desactivar todo a mano. El objetivo es aislar qué archivo rompe la ejecución sin depender del panel, que justamente es lo que está caído.
- Renombrá la carpeta de plugins. Cambiar wp-content/plugins por plugins_old desactiva todos los plugins de una sola vez.
- Descartá el .htaccess. Renombralo a .htaccess_old para sacar de circulación reglas de redirección maliciosas.
- Restaurá desde el último backup limpio si lo tenés. Verificá primero la fecha, no sirve un backup posterior a la infección.
¿Y si no hay backup limpio? Ahí el trabajo se vuelve manual, archivo por archivo, comparando fechas de modificación contra una instalación fresca de WordPress.
¿Qué herramientas escanean el malware que causó la pantalla blanca?
Wordfence y Sucuri SiteCheck son las dos herramientas gratuitas de referencia para confirmar si el WSOD lo causó un malware. Wordfence escanea desde adentro del sitio comparando archivos contra el repositorio oficial; Sucuri SiteCheck escanea desde afuera, sin necesitar acceso al wp-admin, algo clave cuando el panel también está caído. Sobre eso hablamos en aplicar hardening con Patchstack tras el ataque.
| Herramienta | Tipo de escaneo | Necesita acceso al wp-admin | Gratis |
|---|---|---|---|
| Wordfence | Interno (plugin) | Sí, o FTP para instalarlo | Sí, versión free |
| Sucuri SiteCheck | Externo (URL pública) | No | Sí |
| MalCare | Interno (plugin) | Sí, o FTP | Freemium |
| WPScan | Base de datos de vulnerabilidades | No | Sí, con límite de consultas |
Ningún escaneo automático reemplaza mirar a mano los archivos con fecha de modificación reciente. Eso sí, es el primer filtro y ahorra horas.
¿Cómo hacer una auditoría de seguridad completa después de recuperar el sitio?
Una auditoría completa después de un hackeo con pantalla blanca revisa cuatro frentes: usuarios, contraseñas, plugins/temas y la carpeta de archivos subidos. Dejar cualquiera sin chequear suele significar que el atacante vuelve a entrar en semanas.
- Revisá los usuarios administradores. Cualquier cuenta que no reconozcas se borra, sin excepciones.
- Forzá el cambio de todas las contraseñas. WordPress, FTP, base de datos y el panel del hosting, las cuatro.
- Buscá plugins y temas desconocidos. Si no lo instalaste vos, se elimina.
- Revisá wp-content/uploads a mano. Archivos .php sueltos entre imágenes son la bandera roja clásica.
¿Cómo evitar que la pantalla blanca por ataque se repita?
La prevención pasa por cerrar las mismas puertas que se usaron para entrar. Ajustá permisos de archivos, desactivá la edición de archivos desde el panel con la constante DISALLOW_FILE_EDIT y mantené plugins, temas y core siempre actualizados.
Un firewall de aplicación web (WAF) delante del sitio filtra buena parte de los intentos antes de que lleguen a WordPress. Los backups automáticos, guardados fuera del propio hosting, son lo que te salva cuando igual algo pasa. Si estás evaluando dónde alojar el sitio con estas protecciones ya integradas de fábrica, donweb.com es una opción a considerar para hosting en Argentina.
Errores comunes al diagnosticar una pantalla blanca por hackeo
- Reinstalar solo el core y darse por satisfecho. El core no toca wp-content/uploads, que es justamente donde suele quedar el backdoor.
- Restaurar un backup sin cambiar contraseñas. Si el backup es posterior a la infección, la puerta trasera vuelve con él.
- Dejar WP_DEBUG_DISPLAY en true en producción. Expone rutas del servidor y detalles del error a cualquier visitante, no solo a vos.
- Confiar en un solo escaneo y cerrar el caso. Un scanner puede no detectar un backdoor nuevo; la revisión manual de archivos recientes sigue siendo necesaria.
Preguntas Frecuentes
¿Qué es la pantalla blanca de la muerte en WordPress?
Es un error fatal de PHP (conocido como White Screen of Death o WSOD) que detiene la ejecución del sitio antes de renderizar cualquier contenido, dejando una página en blanco sin mensaje visible. Puede originarse en un plugin incompatible, un tema roto o, con menos frecuencia, en código inyectado por un ataque. Esto se conecta con lo que analizamos en sumar passkeys como capa extra de acceso.
¿Cómo sé si mi WordPress fue hackeado?
Las señales más claras son usuarios administradores que no reconocés, archivos .php nuevos en wp-content/uploads y avisos de tráfico saliente sospechoso desde el hosting. Un escaneo con Sucuri SiteCheck desde afuera del sitio confirma rápido si hay malware detectado.
¿Cómo activo el modo debug en WordPress?
Editando wp-config.php y agregando las constantes WP_DEBUG en true y WP_DEBUG_LOG en true, con WP_DEBUG_DISPLAY en false para no exponer el error en pantalla pública. El error queda registrado en wp-content/debug.log con el archivo y la línea exactos.
¿Cuánto cuesta reparar un WordPress hackeado con pantalla blanca?
El costo depende de cuán profunda esté la infección: un plugin incompatible se soluciona en minutos sin gasto, mientras que un backdoor distribuido en varios archivos suele requerir horas de trabajo manual o un servicio de limpieza especializado. No hay una cifra fija, cada caso se cotiza según la cantidad de archivos comprometidos.
¿Cuál es la alternativa gratuita a Wordfence para diagnosticar un ataque?
Sucuri SiteCheck es la alternativa gratuita más usada, porque escanea el sitio desde una URL pública sin necesitar login al wp-admin ni instalar nada. Es la opción indicada justamente cuando el panel de administración también está en blanco.
Conclusión
Una pantalla blanca no es un misterio si la abordás en orden: primero WP_DEBUG para ver el error real, después los archivos típicos de inyección (functions.php, .htaccess, wp-config.php, uploads), y recién ahí un escaneo con Wordfence o Sucuri SiteCheck para confirmar malware. Si el panel también está caído, FTP o SSH son el único camino de entrada. Lo que decide si el sitio vuelve a caer en un mes es la auditoría posterior: usuarios, contraseñas y plugins desconocidos, sin saltarse ninguno.
¿Qué causa la pantalla blanca de WordPress si no fue un hackeo?
Las causas más comunes son un plugin o un tema incompatible con la versión de PHP del hosting, un error de sintaxis en functions.php o que el sitio se quede sin memoria PHP. Para confirmar cuál es, activá WP_DEBUG_LOG y leé el archivo y la línea que figuran en wp-content/debug.log.
¿Cómo solucionar la pantalla blanca de WordPress desactivando el tema?
Entrá por FTP o por el administrador de archivos del hosting y renombrá la carpeta del tema activo dentro de wp-content/themes. WordPress pasa a usar un tema por defecto, y si el sitio vuelve a cargar, el error estaba en ese tema, por ejemplo en su functions.php.
¿Cómo aumentar la memoria de PHP para arreglar la pantalla blanca de WordPress?
Agregá en wp-config.php la constante WP_MEMORY_LIMIT con un valor mayor, por ejemplo 256M, antes de la línea que dice «That’s all, stop editing». Si el debug.log menciona «Allowed memory size exhausted», eso puede resolverlo; si no, el problema es otro y conviene seguir revisando el log.
Fuentes
- Sucuri Blog – Troubleshooting WordPress: cómo solucionar el White Screen of Death
- mdpabel.com – Cómo reparar el WSOD de WordPress causado por el malware Zeura
- AyudaWP – La pantalla blanca de la muerte en WordPress
- BlogVault – WordPress White Screen of Death
- Dev.to – Guía definitiva para eliminar malware de .htaccess en WordPress
Cómo funciona
- Paso 1 – Aislá el sitio y hacé un respaldo: antes de tocar nada, poné el sitio en mantenimiento o bloqueá el acceso público y descargá una copia completa de archivos y base de datos. Así conservás evidencia del ataque y tenés a dónde volver si algo sale mal durante la limpieza.
- Paso 2 – Activá el registro de errores: en
wp-config.phpdefiníWP_DEBUGyWP_DEBUG_LOGentrueyWP_DEBUG_DISPLAYenfalse. Recargá el sitio y abríwp-content/debug.log: ahí vas a ver el archivo y la línea exacta del error fatal. - Paso 3 – Ubicá el código inyectado: abrí el archivo que señala el log y buscá funciones sospechosas como
eval,base64_decode,gzinflateo cadenas largas ilegibles. Contrastá los archivos del core, del tema y de los plugins con copias limpias descargadas de las fuentes oficiales. - Paso 4 – Eliminá la infección y restaurá archivos limpios: reemplazá los archivos comprometidos por versiones originales, borrá los archivos desconocidos, revisá usuarios administradores que no reconozcas y volvé a probar el sitio. Si seguís viendo la pantalla blanca, repetí la lectura del log hasta que no aparezcan errores fatales.
- Paso 5 – Cerrá la puerta de entrada: cambiá todas las contraseñas (WordPress, base de datos, FTP/SSH y hosting), regenerá las claves de seguridad de
wp-config.php, actualizá plugins y temas, y desactivá el modo debug. Un hosting con monitoreo y copias de seguridad automáticas, como los que ofrece Donweb, te facilita detectar y revertir este tipo de incidentes.
Ejemplo práctico
Caso ilustrativo: Marcela, dueña de «Mates del Litoral», una tienda WooCommerce con unos 340 productos y alrededor de 120 visitas diarias, abre su sitio un martes a la mañana y se encuentra con la pantalla blanca. No hay mensaje de error ni acceso a /wp-admin. Dos días antes había instalado un plugin de galería descargado de un sitio no oficial.
Este es el diagnóstico que hace paso a paso:
- Entra por FTP y, en
wp-config.php, agregadefine('WP_DEBUG', true);,define('WP_DEBUG_LOG', true);ydefine('WP_DEBUG_DISPLAY', false);. Así los errores se guardan en un archivo y no se muestran a los visitantes. - Recarga el sitio y abre
/wp-content/debug.log. Encuentra esta línea:PHP Fatal error: Uncaught Error: Call to undefined function wp_cache_hlp() in /wp-content/themes/mi-tema/functions.php:214. - En la línea 214 de
functions.phphay una instrucción coneval(base64_decode('...'))que nadie del equipo escribió. El código estaba pensado para cargar un script externo y falló porque dependía de una función que ya no existía. - Revisa
.htaccessy encuentra 14 reglas de redirección agregadas al final. También detecta 2 usuarios administradores desconocidos en la tablawp_users. - Borra la línea inyectada, restaura el
.htaccessestándar de WordPress y elimina el plugin de origen dudoso. Después elimina los 2 usuarios falsos, cambia todas las contraseñas (hosting, FTP, base de datos y WordPress) y regenera las claves secretas (salts) dewp-config.php. - Vuelve a poner
WP_DEBUGenfalsey compara el resto de los archivos del tema con una copia limpia o con el backup del hosting.
Resultado: el sitio vuelve a cargar en unos 25 minutos desde que Marcela abre el debug.log. La causa estaba en 1 línea inyectada en functions.php, 14 reglas maliciosas en .htaccess y 2 usuarios administradores falsos. Para evitar una reinfección, Marcela deja un backup diario en su hosting y usa solo plugins del repositorio oficial o de desarrolladores confiables. Si todavía no tenés un plan de hosting con backups y soporte que te acompañe en estos casos, es un buen momento para evaluarlo, por ejemplo con Donweb.