SeoXan Blog

Inyección NoSQL: Entrar sin password

Alex Rubio — Tue, 27 Oct 2026 21:09:41 +0000

A veces, para entrar en una cuenta no hace falta ni saber la contraseña. Basta con enviar un objeto donde el sistema esperaba un texto.

Todos imaginamos a un atacante probando contraseñas una tras otra hasta acertar. Pero existe una familia de fallos mucho más elegante y silenciosa, en la que el atacante no adivina nada: le pide directamente a la base de datos que le deje pasar. Y la base de datos, obediente, le abre la puerta.

Se llama inyección NoSQL. Es la prima menos conocida de la clásica inyección SQL, y afecta a muchas aplicaciones modernas que han cambiado las tablas de toda la vida por bases de datos como MongoDB. Vamos a ver cómo funciona y, sobre todo, cómo evitarla.

Por qué NoSQL cambia las reglas

Muchas aplicaciones ya no guardan sus datos en tablas SQL, sino en bases de datos documentales como MongoDB, que almacenan la información como objetos JSON. Cada usuario es un documento con sus campos: nombre de usuario, contraseña, rol, correo, y lo que haga falta.

Consultar esa base de datos también se hace con objetos. Para comprobar un login, la aplicación construye algo como "dame el documento cuyo usuario sea X y cuya contraseña sea Y". Y aquí está la clave: en MongoDB, esos criterios de búsqueda admiten operadores especiales, palabras que empiezan por el símbolo del dólar, como $ne (distinto de), $gt (mayor que) o $regex (coincide con esta expresión).

Esos operadores son perfectamente legítimos; forman parte del funcionamiento normal de la base de datos. El problema aparece cuando la entrada del usuario llega sin filtrar hasta la consulta. Si la aplicación espera un texto en el campo de contraseña, pero acepta sin rechistar un objeto, el atacante puede colar sus propios operadores dentro de la búsqueda. Es la misma idea de siempre en seguridad web: mezclar los datos del usuario con las instrucciones del programa.

El truco: entrar con un "distinto de"

Imagina un panel de login de lo más corriente y, por detrás, una base MongoDB con varios usuarios. Uno de ellos, al que llamaremos Luis, es una cuenta normal, con rol de usuario y sin privilegios.

Cuando Luis se identifica, la aplicación lanza una consulta del tipo: "busca el usuario Luis cuya contraseña sea Petito". Si interceptamos esa petición (algo que un auditor hace con un proxy como Burp Suite), vemos un usuario y una contraseña viajando como simples textos.

¿Y si la contraseña deja de ser un texto y se convierte en un operador? En lugar de enviar Petito, el atacante envía un objeto que, en la práctica, significa "cualquier contraseña distinta de un valor imposible". La consulta pasa a pedir: "dame el usuario Luis cuya contraseña sea distinta de un texto que sabemos que nadie usa".

Como la contraseña real de Luis, evidentemente, es distinta de ese valor inventado, la condición se cumple. La base de datos devuelve el usuario, y Luis entra sin saber su propia contraseña. No ha habido adivinación ni fuerza bruta: solo se ha cambiado la pregunta.

Peor aún: reconstruir la contraseña letra a letra

Entrar sin contraseña ya es grave, pero la misma debilidad permite algo más inquietante: averiguar la contraseña real, carácter a carácter, sin verla nunca.

La herramienta es el operador $regex, que comprueba si un texto encaja con un patrón. En lugar de preguntar por la contraseña entera, el atacante hace preguntas de sí o no:

"¿La contraseña empieza por A?". El login responde que no (acceso denegado).
Prueba con la B, la C… hasta que una letra hace que el login responda que sí. Ese es el primer carácter.
Fija esa letra y repite la pregunta para la segunda posición, luego la tercera, y así sucesivamente.

Es un proceso automatizable y rapidísimo: el programa del atacante lanza miles de estas preguntas y va reconstruyendo la contraseña posición a posición, por ejemplo administrador123. Esta técnica se conoce como inyección a ciegas (blind), porque la aplicación nunca muestra la contraseña: solo su sí o su no van filtrando la respuesta.

Con la contraseña completa del administrador en la mano, ya no hace falta ningún truco. El atacante inicia sesión como admin por la puerta principal, y a partir de ahí controla la aplicación.

Conclusiones: el problema no es MongoDB

Es tentador culpar a la base de datos, pero MongoDB hace exactamente lo que se le pide. El fallo está en un error de diseño tan viejo como la web: confiar en lo que envía el usuario.

Tres ideas que conviene grabar a fuego:

Los datos y las instrucciones no deben mezclarse. Es la misma raíz de la inyección SQL, de los ataques de scripts (XSS) y de tantos otros. Cuando la entrada del usuario puede convertirse en parte de la lógica de la consulta, has perdido el control.
Un campo tiene un tipo, y hay que respetarlo. Una contraseña es texto, nunca un objeto. Si tu aplicación acepta un objeto donde esperaba una cadena, está aceptando órdenes disfrazadas de datos.
"No tener SQL" no significa "no tener inyecciones". Cambiar de tecnología no elimina la clase de vulnerabilidad; solo cambia su forma. Cada motor trae sus propios operadores peligrosos.

Y hay un agravante: estos ataques no suelen dejar rastro evidente. No rompen nada, no lanzan errores llamativos. Para la aplicación, todo "funciona correctamente", igual que un cajero que entrega el dinero porque la pregunta estaba bien formulada.

Advertencias: cómo protegerse

La buena noticia es que defenderse de la inyección NoSQL es relativamente sencillo si se aplica desde el diseño. Estas son las medidas que recomendamos, en línea con las guías de INCIBE y OWASP:

Valida y tipa la entrada. Comprueba que cada campo es del tipo esperado. Si la contraseña debe ser texto, rechaza cualquier cosa que llegue como objeto o como array. Esta sola comprobación detiene la mayoría de estos ataques.
Rechaza operadores en los datos del usuario. No permitas que lleguen claves que empiecen por $ (como $ne o $regex) ni puntos en los nombres de campo dentro de la entrada del usuario.
Sanea siempre lo que envía el usuario. Usa las utilidades de limpieza de tu framework o librerías específicas (por ejemplo, un sanitizer para Express/Mongo) antes de construir cualquier consulta.
Usa consultas parametrizadas. Mantén separados los datos del usuario y la lógica de la consulta; no construyas búsquedas concatenando texto ni, mucho menos, evaluando JavaScript con la entrada dentro.
Aplica el mínimo privilegio. La cuenta que usa la aplicación contra la base de datos debe tener solo los permisos imprescindibles. Así, aunque alguien entre, el daño posible se limita.
Pon límites y vigila. Limita los intentos por IP y franja de tiempo para frenar la fuerza bruta a ciegas, y registra y monitoriza patrones anómalos (picos de consultas, muchas peticiones casi idénticas).
Mantén todo actualizado. Base de datos, drivers y dependencias: las versiones antiguas de MongoDB arrastraban fallos graves de inyección ya corregidos.

Y un consejo que vale su peso en oro: haz que alguien lo intente. Una auditoría de seguridad sobre tus formularios de acceso y tus APIs encuentra este tipo de agujeros antes de que lo haga un atacante.

Una última advertencia

Todo lo anterior se explica con un fin defensivo: entender el ataque es el primer paso para blindarse frente a él. Probar estas técnicas solo es legítimo en sistemas propios o con permiso por escrito del responsable. Hacerlo contra servicios ajenos es un delito, por mucho que la intención sea "demostrar que son vulnerables".

En Seoxan Tech auditamos aplicaciones web, APIs y bases de datos buscando exactamente esta clase de fallos: los que no rompen nada, no saltan en ningún antivirus y, sin embargo, abren la puerta de par en par. Si quieres saber si tus formularios de acceso resistirían un "distinto de", hablemos.

Fuentes

El ladrón de los dos céntimos

Alex Rubio — Mon, 26 Oct 2026 20:59:51 +0000

Una historia real sobre cómo una función legítima, multiplicada miles de veces, se convirtió en un agujero de 50.000 dólares.

Imagina un salón cualquiera en Plumas Lake, un pueblo tranquilo del norte de California. Es noviembre de 2007. Un chaval de 22 años mira la pantalla mientras su ordenador trabaja solo, sin descanso, abriendo cuentas en brokers online a una velocidad que ningún humano podría igualar.

Cada cuenta nueva le deja en el bolsillo unos céntimos. Uno, dos, a veces algo más. Calderilla. El tipo de dinero que nadie se agacha a recoger de la acera.

Se llamaba Michael Largent. Y durante unos seis meses, esa calderilla se fue amontonando hasta rozar los 50.000 dólares.

El truco de los céntimos de prueba

Si alguna vez has vinculado tu cuenta bancaria a una plataforma online, conoces el ritual. La plataforma te ingresa una o dos cantidades minúsculas y te pide que le digas cuánto has recibido. Así comprueba que la cuenta existe y que es tuya.

En el sector se llaman microdepósitos. En el caso de Largent oscilaban entre un céntimo y dos dólares. Son un mecanismo honesto, barato y eficaz para verificar datos bancarios. Para la empresa, es un coste de captación de clientes tan pequeño que ni aparece en los informes.

Y ahí estaba la pregunta que Largent se hizo: si cada cuenta nueva regala unos céntimos, ¿qué pasa si abres miles?

58.000 cuentas y un vaquero de dibujos animados

Largent escribió un script que automatizaba el alta de cuentas en dos de los brokers online más conocidos de Estados Unidos: E*Trade y Charles Schwab. Según la Fiscalía, entre noviembre de 2007 y mayo de 2008 abrió o intentó abrir más de 58.000 cuentas.

Cada una necesitaba un titular, y el script se los inventaba: nombres, direcciones, números de carné de conducir y de la Seguridad Social falsos. Para los nombres, Largent tiró de su cultura televisiva. Entre sus "clientes" figuraban Hank Hill y Rusty Shackleford, personajes de la serie de animación King of the Hill, y Johnny Blaze, de los cómics de Marvel. Solo en Schwab, más de 11.000 cuentas se abrieron a nombre de un tal "Speed Apex".

Todas esas cuentas falsas se vinculaban a un puñado de cuentas bancarias y tarjetas prepago que sí controlaba él. Los brokers hacían su ingreso de prueba, él movía el dinero y lo gastaba en gastos personales. Repetido miles de veces, los céntimos sumaron unos 50.000 dólares.

No contento con eso, aplicó el mismo truco a Google Checkout, el antiguo sistema de pagos de Google, del que sacó más de 8.000 dólares. Cuando su banco le preguntó por tantas transferencias diminutas, respondió que había leído las condiciones de Google y que no prohibían tener varias cuentas.

Le delataron los nombres, no el dinero

El dinero nunca levantó sospechas: eran céntimos, y los céntimos no hacen saltar alarmas. Lo que falló fue la identidad. La ley estadounidense obliga a las entidades financieras a verificar quiénes son sus clientes, y en enero de 2008 Schwab detectó más de 5.000 cuentas con datos inventados.

A partir de ahí, el Servicio Secreto y el FBI tiraron del hilo. Las miles de cuentas de "Speed Apex" se habían abierto desde solo cinco direcciones IP, y todas apuntaban a la conexión a Internet de Largent. E*Trade también detectó el fraude por su cuenta y lo denunció.

El desenlace llegó en septiembre de 2009: 15 meses de prisión, una restitución de 200.073,44 dólares y tres años de restricciones estrictas para usar ordenadores e Internet. Al dictar sentencia, el juez reconoció que el plan tenía cierta sofisticación y se preguntó por qué no había usado ese talento de forma legal.

Un detalle importante: a Largent no lo condenaron por "aprovechar" los ingresos de prueba, sino por crear miles de identidades falsas para conseguirlos. Lo que hizo fue un delito, no una travesura ingeniosa.

Conclusiones: el agujero no estaba en el código

Lo más inquietante de esta historia es que no hubo ninguna intrusión. Nadie robó contraseñas ni encontró un bug en los servidores. Largent usó una función pública, documentada y legítima exactamente como estaba diseñada. Solo cambió una variable: la escala.

De ahí salen tres lecciones que siguen vigentes casi veinte años después:

Lo pequeño multiplicado deja de ser pequeño. Un coste de dos céntimos por alta es irrelevante. Multiplicado por 58.000 altas automáticas, es una hemorragia. Cualquier proceso que entregue algo de valor de forma automática, sea dinero, saldo, créditos o descuentos, es un objetivo.
Diseñamos pensando en usuarios humanos. Los procesos de alta se piensan para personas que se registran una vez. Un script no se cansa, no duerme y no se aburre. Si tu sistema no distingue entre ambos, el script gana.
Las alarmas miran donde esperamos el problema. Nadie vigilaba los céntimos porque nadie imaginaba que fueran un botín. Lo que finalmente lo destapó fue un control de identidad pensado para otra cosa.

Hoy esta idea tiene nombre en ciberseguridad: abuso de lógica de negocio. No ataca la tecnología, ataca las reglas del juego. Y es especialmente peligroso porque los antivirus, cortafuegos y escáneres de vulnerabilidades no lo ven: para ellos, todo funciona correctamente.

Advertencias para tu negocio

Puede que tu empresa no regale céntimos, pero seguramente tiene su propia versión del microdepósito. Un cupón de bienvenida, una prueba gratuita, puntos por registro, un formulario que envía SMS o correos, un regalo por recomendar a un amigo. Revisa estos puntos:

Haz inventario de lo que regalas. Lista cada acción de tu web o app que entregue algo de valor sin pago previo. Ese es tu mapa de riesgos.
Pon límites de velocidad. Restringe cuántos registros, envíos o solicitudes se aceptan por IP, dispositivo o franja de tiempo. 11.000 altas desde cinco IP no deberían pasar nunca desapercibidas.
Frena a los bots. Usa verificaciones anti-bot, confirmación por correo o teléfono y huella de dispositivo en los procesos de alta.
Vigila patrones, no solo importes. Una alerta por importe no detecta mil operaciones de dos céntimos. Monitoriza volúmenes, repeticiones, nombres similares y picos de actividad.
Valida los datos que te dan. Nombres de personajes de ficción, direcciones inexistentes o datos repetidos son señales claras de altas falsas.
Calcula el peor caso. Pregúntate cuánto costaría tu promoción si alguien la explotara 50.000 veces en una noche. Si la respuesta asusta, ponle tope.
Revisa los registros con regularidad. Los logs del servidor y de tu tienda online cuentan historias. Alguien tiene que leerlas.

Y como usuario, una advertencia más: si te llega un microdepósito que no has solicitado, no lo ignores. Puede ser señal de que alguien está usando tus datos bancarios para abrir cuentas a tu nombre.

¿Y tú? ¿Lo habrías visto venir?

La historia de Michael Largent no es la de un genio del hacking. Es la de alguien que miró un proceso cotidiano desde un ángulo que nadie había considerado. Esa es la mirada que conviene aplicar a tu propio negocio antes de que lo haga otro.

En Seoxan Tech revisamos webs, tiendas online y servidores buscando no solo fallos técnicos, sino también esos procesos legítimos que, a gran escala, pueden volverse en tu contra. Si quieres saber cuál es tu "microdepósito", hablemos.

Fuentes

El peligro del copy paste

Alex Rubio — Mon, 26 Oct 2026 18:24:42 +0000

Lo que copias no siempre es lo que pegas: el fraude que puede desviar tus transferencias

Copias el número de cuenta de una tienda, lo pegas en tu banco y confirmas la transferencia. Una operación habitual que parece no tener ningún misterio. Sin embargo, el dinero puede acabar en la cuenta de un delincuente aunque en la web hayas visto el IBAN correcto.

¿Cómo es posible? Porque lo que aparece en pantalla y lo que se guarda al copiar pueden ser dos cosas distintas.

Una trampa en el momento de copiar

Imagina que un atacante consigue introducir código malicioso en una tienda online. La página continúa funcionando y sus datos bancarios parecen los de siempre.

Pero, cuando seleccionas el IBAN y pulsas «Copiar», ese código sustituye el contenido que se guarda en el portapapeles por otra cuenta bancaria: la del atacante.

Después entras en tu banco, pegas el número y continúas con el pago. Si no revisas los datos, puedes autorizar tú mismo una transferencia al destinatario equivocado.

No hace falta que el atacante entre en tu banca online: le basta con engañarte sobre la cuenta a la que estás enviando el dinero.

¿Puede una web cambiar lo que copio?

Sí. Los navegadores permiten que una página gestione la acción de copiar mediante JavaScript y modifique el texto que se guarda en el portapapeles. Es una función legítima que también puede utilizarse con fines maliciosos si alguien compromete la web. Esto no significa que cualquier página pueda leer o controlar todo lo que copias en tu ordenador.

El peligro está en que copiar y pegar es un gesto automático. Precisamente porque lo hacemos continuamente, rara vez comprobamos el resultado.

Cómo protegerte antes de hacer una transferencia

No necesitas dejar de copiar y pegar. Necesitas incorporar una comprobación antes de pagar:

Revisa el IBAN completo que has pegado, comparándolo con una fuente fiable. Comprobar únicamente los últimos dígitos no equivale a verificar toda la cuenta.
Presta atención a la verificación del beneficiario de tu banco. Comprueba el resultado, no solo el nombre que tú has escrito.
Si hay discrepancias o no se puede verificar el destinatario, detén la operación y confirma los datos por un canal de confianza.
Verifica cualquier cambio de cuenta de un proveedor, especialmente si viene acompañado de prisas. Llama a un teléfono que ya conocías, no únicamente al que aparece en el mensaje que anuncia el cambio.

La verificación bancaria permite comprobar si el nombre del beneficiario coincide con el titular del IBAN. Puede indicar coincidencia, coincidencia aproximada, falta de coincidencia o imposibilidad de verificarlo. Si decides continuar pese a una discrepancia, el dinero se enviará al IBAN indicado. El aviso merece una comprobación, no un clic por costumbre.

Si tienes una web, también afecta a tu empresa

Una tienda comprometida puede convertirse en el instrumento para engañar a sus propios clientes. El perjuicio no termina en el pago perdido: también afecta a la confianza en el negocio.

Por eso, mantener una web no consiste únicamente en comprobar que carga y que el formulario funciona. Implica actualizar sus componentes, proteger los accesos y revisar posibles modificaciones no autorizadas.

Las copias de seguridad ayudan a recuperar una web, pero deben acompañarse de medidas de prevención y detección.

En SeoXan insistimos en que la seguridad de tu web forma parte de la seguridad de tu negocio y de tus clientes.

Antes de confirmar tu próxima transferencia, dedica unos segundos a revisar el destino. Copiar y pegar ahorra tiempo. Comprobar lo que has pegado puede ahorrarte un problema mucho mayor.

Avisos por Telegram cuando tu web cae (y cuando vuelve)

Alex Rubio — Mon, 19 Oct 2026 10:33:03 +0000

Tu web se cae… y todavía no lo sabes

Una caída no avisa. Lo habitual es enterarte cuando un cliente escribe, cuando dejan de llegar pedidos o cuando alguien del equipo abre la web y ve el error. Para entonces el daño ya está hecho: minutos (o horas) sin vender, sin captar contactos y con una imagen poco profesional. El problema no es solo la caída: es el tiempo que pasa hasta que alguien se da cuenta.

Aviso al caer y al recuperarse

Por eso en SeoXan hemos creado Uptime. Comprueba tus webs cada pocos minutos y te envía un aviso por Telegram cuando dejan de responder. Cuando vuelven a estar online, recibes un segundo aviso. Así sabes en el momento que hay un problema… y también cuando ya está resuelto, sin tener que refrescar la web a ciegas.

El objetivo no es inundarte de notificaciones: es que llegues tú primero, no tu cliente. Los avisos están pensados para ser claros —web caída / web recuperada— y útiles de verdad, con el dominio afectado en el propio mensaje.

Sin falsas alarmas

Un monitor que grita cada vez que hay un microcorte o un pico puntual acaba ignorándose. Uptime está pensado para avisarte cuando importa: al caer y al recuperarse, sin falsas alarmas. Comprueba cada pocos minutos, con historial de uptime, tiempo de respuesta y fallos, para que puedas actuar con contexto y no a ciegas.

En el resto de la serie veremos también SSL, PageSpeed y Core Web Vitals reales, vigilancia SEO de indexabilidad, informes y la página de estado para tus clientes. Este segundo vídeo se centra solo en Telegram.

Empieza sin coste

Uptime es gratis para monitorizar 2 webs, y puedes conseguir más mediante referidos o insignias. Solo tienes que dar de alta tu web y vincular tu Telegram.

Pruébalo gratis en uptime.seoxan.es y deja de enterarte de las caídas por tus clientes.

Lo que cuesta una web caída y cómo enterarte antes que tus clientes

Alex Rubio — Sat, 17 Oct 2026 19:32:58 +0000

Cada minuto que tu web está caída cuesta dinero

Una web que no responde no vende, no capta contactos y transmite una imagen poco profesional. Lo peor no suele ser la caída en sí, sino el tiempo que pasa hasta que alguien se da cuenta. Si dependes de que un cliente te avise, el problema ya lleva tiempo afectando a tu negocio.

Los problemas que no ves a simple vista

Una web no solo falla cuando se cae por completo. Hay problemas silenciosos que afectan igual o más:

Lentitud: si la web tarda en cargar, los usuarios se van y Google lo tiene en cuenta.
Certificado SSL caducado: el navegador muestra un aviso de seguridad y la mayoría de visitantes no pasa de ahí.
Dominio caducado: un descuido en la renovación puede dejar la web y el correo fuera de servicio.
Pérdida de indexabilidad: un cambio mal hecho puede hacer que tu web deje de aparecer en Google sin que nadie lo note.
Empeoramiento del rendimiento: las Core Web Vitals reales empeoran poco a poco tras una actualización o un nuevo plugin.

Enterarte tú primero

Por eso en SeoXan hemos creado Uptime. Comprueba tus webs cada pocos minutos y te avisa por Telegram cuando se caen y cuando se recuperan, sin falsas alarmas. Además vigila el certificado SSL y el dominio, mide PageSpeed y Core Web Vitals reales y te alerta si tu web deja de ser indexable. Guarda un historial de 30 días de uptime, tiempo de respuesta y fallos.

Transparencia con tus clientes

Si gestionas webs de terceros, puedes ofrecer a cada cliente una insignia de uptime y una página de estado. Es una forma sencilla de demostrar que su web está vigilada y de aportar valor a tu servicio de mantenimiento.

Empieza sin coste

Uptime es gratis para monitorizar 2 webs, y puedes conseguir más mediante referidos o insignias. Solo tienes que dar de alta tu web y vincular tu Telegram.

Pruébalo gratis en uptime.seoxan.es y deja de enterarte de las caídas por tus clientes.

Uptime: monitoriza tu web gratis y recibe avisos por Telegram

Alex Rubio — Sat, 17 Oct 2026 19:32:55 +0000

¿Tu web se cae y te enteras por un cliente?

Es una de las situaciones más incómodas para cualquier negocio online: la web deja de funcionar, nadie se da cuenta y, horas después, es un cliente quien te avisa. Mientras tanto se pierden ventas, contactos y confianza. Para evitarlo hemos creado Uptime, la herramienta de monitorización web de SeoXan.

Qué hace Uptime

Uptime comprueba tus webs cada pocos minutos y te avisa por Telegram en cuanto detecta un problema: si la web se cae, si va lenta, si caduca el certificado SSL o el dominio, si deja de aparecer en Google o si empeora su rendimiento. Así eres tú quien se entera primero y puede actuar antes de que el problema afecte a tus clientes.

Uptime, tiempo de respuesta y fallos con un historial de 30 días para ver la evolución de cada web.
Avisos al caer y al recuperarse, sin falsas alarmas, para que solo recibas las notificaciones que importan.
Certificado SSL, PageSpeed y Core Web Vitals reales, para controlar la seguridad y la velocidad que perciben tus usuarios.
Vigilancia SEO: te avisamos si tu web deja de ser indexable y corre el riesgo de desaparecer de los buscadores.
Insignia de uptime y página de estado para compartir con tus clientes y demostrar la fiabilidad de su web.

Pensado para agencias, freelance y empresas

Si gestionas webs de clientes, Uptime te ayuda a ofrecer un servicio más profesional: detectas incidencias antes que nadie, tienes datos para justificar tu trabajo y puedes mostrar a cada cliente una página de estado transparente. Si tienes tu propio negocio, te da la tranquilidad de saber que tu web está vigilada las 24 horas.

Gratis para 2 webs

Uptime es gratis para monitorizar 2 webs, y puedes desbloquear más con referidos o insignias. Sin complicaciones: das de alta tu web, vinculas tu Telegram y empiezas a recibir avisos.

Este es el primer vídeo de una serie en la que iremos mostrando cada función en detalle. Empieza gratis en uptime.seoxan.es y síguenos en redes como @seoxan.mkt para no perderte los próximos.

Aviso de seguridad importante para webs WordPress

Alex Rubio — Sun, 30 Aug 2026 08:49:14 +0000

Estimado/a cliente/a,

Durante las últimas semanas se han detectado varias vulnerabilidades graves de seguridad en WordPress, algunas de ellas especialmente preocupantes por permitir ataques contra páginas web sin necesidad de conocer previamente las credenciales de administrador.

No estamos hablando únicamente de vulnerabilidades teóricas. Se han registrado campañas automatizadas de explotación a gran escala, buscando instalaciones WordPress vulnerables en Internet.

La sucesión de actualizaciones de seguridad durante las últimas semanas ha sido especialmente rápida:

WordPress 7.0.2 corrigió vulnerabilidades críticas, entre ellas problemas relacionados con SQL Injection y ejecución remota de código.
Pocas semanas después se publicó WordPress 7.0.3, corrigiendo 12 vulnerabilidades adicionales.
Apenas unos días después fue necesario publicar WordPress 7.0.4, nuevamente con correcciones de seguridad.

Esto pone de manifiesto un problema que desde SeoXan Tech consideramos importante trasladar a todos nuestros clientes:

Tener una página WordPress funcionando correctamente no significa necesariamente que esté segura.

WordPress es una plataforma que requiere mantenimiento continuo. Además del propio WordPress, una instalación está formada por plugins, temas, librerías y diferentes componentes que pueden presentar nuevas vulnerabilidades en cualquier momento.

Cuando aparece una vulnerabilidad crítica, los ataques automatizados pueden comenzar en cuestión de horas. Por este motivo, dejar una instalación sin actualizar durante semanas o meses supone actualmente un riesgo considerable.

También queremos destacar algo especialmente importante: actualizar WordPress después de que una página haya sido comprometida no garantiza que el problema quede solucionado. Un atacante puede haber instalado puertas traseras o archivos maliciosos que continúen funcionando incluso después de actualizar el sistema.

Por ello recomendamos que cualquier página WordPress disponga, como mínimo, de:

Actualizaciones periódicas y controladas de WordPress, plugins y temas.
Copias de seguridad externas y recurrentes.
Monitorización de archivos y cambios sospechosos.
Sistemas de protección y firewall.
Revisión periódica de malware y vulnerabilidades.
Un procedimiento de recuperación ante posibles compromisos.

Desde SeoXan Tech estamos revisando y reforzando las instalaciones WordPress que tenemos bajo mantenimiento, aplicando las actualizaciones y medidas de seguridad necesarias.

Para aquellos clientes que actualmente disponen únicamente de alojamiento web pero no tienen contratado un servicio de mantenimiento WordPress, recomendamos especialmente revisar su situación.

Si desea que revisemos el estado de seguridad de su página web o que le informemos sobre las opciones de mantenimiento y protección disponibles, puede ponerse en contacto con nosotros.

El objetivo de este aviso no es generar alarma, sino informar de una situación que durante las últimas semanas ha demostrado que mantener WordPress actualizado, monitorizado y con copias de seguridad ya no debería considerarse opcional.

WordPress en 2026: mantener una web se está convirtiendo en un sufrimiento

Alex Rubio — Wed, 26 Aug 2026 07:59:31 +0000

Estamos en agosto de 2026 y voy a decir algo que hace unos años probablemente habría defendido justo al revés: cada vez me cuesta más recomendar WordPress para un proyecto web serio.

No porque WordPress haya dejado de funcionar. Funciona. Tampoco porque haya desaparecido. Todo lo contrario.

WordPress continúa siendo gigantesco. Según los datos de W3Techs del 25 de agosto de 2026, WordPress está presente en aproximadamente el 40,7 % de todas las webs y conserva cerca del 58,9 % del mercado de CMS conocidos.

Y precisamente ahí empieza parte del problema.

Cuando prácticamente todo el mundo utiliza una tecnología, esa tecnología se convierte en un objetivo extraordinariamente interesante.

Y si además construimos nuestra web añadiendo plugins desarrollados por decenas de proveedores diferentes, algunos mantenidos impecablemente y otros prácticamente abandonados, tenemos una combinación que en 2026 empieza a resultar bastante difícil de defender.

El problema no es exactamente WordPress

Esto hay que dejarlo claro.

El núcleo de WordPress no es necesariamente el desastre de seguridad que algunas personas imaginan.

De hecho, los datos apuntan precisamente en otra dirección.

El informe State of WordPress Security in 2026 de Patchstack contabilizó 11.334 nuevas vulnerabilidades descubiertas en el ecosistema WordPress durante 2025, un incremento del 42 % respecto al año anterior. Sin embargo, el 91 % estaba relacionado con plugins y el 9 % con temas, mientras que solamente se registraron seis vulnerabilidades en el núcleo de WordPress y fueron consideradas de baja prioridad.

El problema, por tanto, no es instalar WordPress.

El problema es lo que viene después.

Quieres un formulario.

Plugin.

Quieres SEO.

Plugin.

Quieres caché.

Plugin.

Quieres gestionar cookies.

Otro plugin.

Quieres hacer copias de seguridad.

Plugin.

Quieres conectar un CRM.

Plugin.

Quieres añadir funcionalidades a WooCommerce.

Tres plugins más.

Y cuando terminas, aquella instalación de WordPress que parecía sencilla depende de 15, 20 o 30 componentes desarrollados por empresas y programadores diferentes.

Enhorabuena: acabas de convertir tu página corporativa en una pequeña convención internacional de PHP.

El plugin gratuito que alguien programó con toda su buena voluntad

Aquí existe además un problema que no considero justo cargar exclusivamente sobre los desarrolladores.

Durante años nos hemos acostumbrado a disponer de plugins gratuitos extraordinarios.

Un programador dedica cientos de horas a desarrollar una herramienta, la publica gratuitamente, corrige errores, responde preguntas y mantiene compatibilidad con nuevas versiones de WordPress.

Todo fantástico.

Hasta que pasan los años.

Porque el desarrollador tiene que trabajar, mantener otros proyectos, pagar facturas y posiblemente descubrir esa curiosa característica del ser humano llamada querer cobrar por su trabajo.

Entonces el plugin empieza a actualizarse menos.

Después deja de actualizarse.

Pero sigue instalado en miles de páginas web.

Y ahí tenemos el problema.

Un plugin abandonado no deja automáticamente de funcionar. Puede continuar funcionando durante años.

Lo que deja de tener es alguien detrás revisando qué ocurre cuando aparecen nuevas técnicas de ataque o se descubren errores en su código.

En la base de datos de Patchstack correspondiente a 2026, alrededor del 27 % de las vulnerabilidades publicadas que recoge actualmente aparecen como no parcheadas. Además, aproximadamente el 87 % corresponden a plugins.

Todavía resulta más preocupante otro dato: Patchstack señala que el 46 % de las vulnerabilidades analizadas en 2025 no habían recibido una corrección del desarrollador cuando llegó el momento de su divulgación pública.

Eso significa que actualizar WordPress y pulsar alegremente el botón de "Actualizar plugins" ya no resuelve necesariamente el problema.

Porque no puedes instalar una actualización que no existe.

"Pues utilizo plugins de pago"

Perfecto.

Pero pagar tampoco produce mágicamente código seguro.

Es más, el informe de Patchstack de 2026 introduce un dato especialmente incómodo: encontró 1.983 informes válidos de vulnerabilidades relacionados con componentes premium o freemium, y el 76 % de las vulnerabilidades detectadas en componentes premium eran explotables en ataques reales según su clasificación.

Por tanto, el debate gratuito contra premium es demasiado simplista.

Un plugin de pago puede proporcionar mejor mantenimiento, soporte profesional, auditorías y capacidad económica para solucionar vulnerabilidades rápidamente.

Eso es importante.

Pero premium no significa invulnerable.

La cuestión realmente importante es quién mantiene ese software, con qué frecuencia se actualiza, qué política de seguridad tiene, cómo responde ante una vulnerabilidad y cuánto tiempo tarda en publicar un parche.

Y entonces llegó la inteligencia artificial

Aquí es donde creo que el escenario ha cambiado considerablemente.

Durante años existió una especie de barrera técnica natural.

Encontrar vulnerabilidades requería conocimientos.

Había que entender PHP, JavaScript, SQL, autenticación, permisos, peticiones HTTP, APIs, WordPress, hooks, nonces y bastantes conceptos adicionales.

Ahora podemos entregar grandes cantidades de código a modelos de inteligencia artificial y utilizarlos para analizar patrones, explicar código, detectar errores potenciales y acelerar auditorías de seguridad.

Esto es fantástico para los desarrolladores y para los investigadores legítimos.

Pero exactamente la misma capacidad reduce el coste de analizar software para todo el mundo.

El código abierto siempre ha podido ser auditado, y eso también constituye una de sus grandes ventajas: más ojos pueden encontrar y corregir problemas.

El problema de 2026 es la velocidad.

Ya no hablamos exclusivamente de un investigador sentado durante tres días leyendo PHP.

Podemos automatizar parte del análisis.

Podemos comparar versiones.

Podemos localizar funciones sensibles.

Podemos estudiar cambios publicados después de un parche.

Y podemos hacerlo a una escala que hace unos años requería muchísimo más trabajo.

El propio informe de Patchstack advierte de que los atacantes pueden convertir nuevas vulnerabilidades en ataques en cuestión de horas, lo que reduce enormemente la ventana disponible para reaccionar.

La IA no ha inventado las vulnerabilidades de WordPress.

Lo que está haciendo es reducir la fricción necesaria para encontrarlas, comprenderlas y automatizar procesos alrededor de ellas.

Y eso cambia bastante las reglas del juego.

¿Un niño de 12 años puede hackear WordPress preguntándole a una IA?

Aquí conviene separar la provocación de la realidad técnica.

Decir literalmente que cualquier niño de 12 años puede comprometer cualquier WordPress con cuatro instrucciones a una IA sería exagerado.

Una instalación correctamente mantenida, protegida y configurada no cae mágicamente porque alguien escriba cuatro prompts.

Pero la idea de fondo sí debería preocuparnos.

La barrera de entrada para realizar determinadas tareas técnicas está bajando radicalmente.

Una persona ya no necesita comprender cada línea de código para empezar a entender qué está haciendo un script, interpretar un error, identificar una tecnología o automatizar determinadas comprobaciones.

La IA puede actuar como profesor técnico permanente.

Eso democratiza la programación.

También democratiza parcialmente el conocimiento sobre seguridad.

Y WordPress tiene una característica irresistible para quien busca objetivos: hay millones de instalaciones extraordinariamente parecidas entre sí.

Encuentras una vulnerabilidad seria en un componente popular y el problema deja de ser "¿cómo entro en esta web?".

La pregunta pasa a ser:

¿Cuántas webs utilizan esta misma versión vulnerable?

Ese cambio de escala es fundamental.

La popularidad de WordPress empieza a jugar en su contra

Que WordPress esté instalado en aproximadamente cuatro de cada diez webs es una demostración espectacular de éxito.

Pero desde la perspectiva de un atacante también significa otra cosa:

economía de escala.

Si dedicas recursos a investigar una tecnología utilizada por el 0,01 % de Internet, tu superficie potencial es pequeña.

Si investigas vulnerabilidades de un ecosistema presente en aproximadamente el 40 % de las webs, cualquier descubrimiento potencialmente reutilizable resulta muchísimo más interesante.

No significa que WordPress sea vulnerable simplemente por ser popular.

Significa que es rentable investigar cómo atacarlo.

Es exactamente el mismo fenómeno que históricamente hemos visto con sistemas operativos, navegadores, dispositivos y aplicaciones enormemente populares.

Donde están los usuarios, aparecen los atacantes.

El verdadero sufrimiento: mantener WordPress

Para mí, aquí está actualmente el mayor problema.

Crear una web WordPress sigue siendo relativamente sencillo.

Mantenerla durante cinco o diez años ya es otra historia.

Un proyecto profesional requiere vigilar constantemente:

WordPress Core.
La versión de PHP.
El servidor.
El tema.
Los plugins.
Las dependencias.
Las vulnerabilidades publicadas.
Las copias de seguridad.
Los usuarios administradores.
Los intentos de acceso.
El firewall.
El malware.
Los plugins abandonados.
Las incompatibilidades después de actualizar.

Y encima existe una maravillosa paradoja.

Si no actualizas, puedes quedar vulnerable.

Si actualizas, puedes romper la web.

Así que pulsas "Actualizar" mirando la pantalla como quien corta el cable rojo de una bomba.

Una web seria no debería depender de veinte desconocidos

Este es probablemente mi principal problema conceptual con WordPress en 2026.

Imaginemos una empresa cuya página web es crítica para captar clientes.

Tiene WordPress.

Un tema comprado a una empresa.

Un constructor visual de otra.

Un plugin SEO de otra.

Un sistema de formularios de otra.

Un plugin de caché de otra.

Un plugin de cookies de otra.

Cinco extensiones adicionales.

WooCommerce.

Extensiones para WooCommerce.

Y alguna pequeña maravilla instalada en 2019 porque "hacía exactamente lo que necesitábamos".

La seguridad del proyecto ya no depende únicamente de tu empresa.

Depende de toda esa cadena de proveedores.

Y basta con que falle uno.

Ese es el problema arquitectónico que considero cada vez más difícil de justificar en proyectos importantes.

No es que WordPress sea imposible de securizar.

Por supuesto que puede protegerse.

Hay instalaciones extraordinariamente bien administradas.

Existen empresas especializadas, WAF, sistemas de virtual patching, monitorización, backups externos, control de integridad, staging y políticas de actualización excelentes.

Pero fíjate en la ironía.

Necesitamos incorporar cada vez más infraestructura y servicios para proteger el CMS que elegimos originalmente porque era sencillo.

WordPress barato puede terminar siendo WordPress caro

Este es otro clásico.

"WordPress es gratis."

Sí.

También Linux.

También una enorme cantidad de tecnologías empresariales.

Que el software tenga coste de licencia cero no significa que el coste de operación sea cero.

Una instalación profesional de WordPress puede necesitar:

hosting administrado + mantenimiento + plugins premium + copias externas + seguridad + monitorización + staging + actualizaciones + intervención técnica.

Y entonces descubrimos que lo gratuito era solamente el archivo ZIP.

Para un blog personal esto puede ser perfectamente asumible.

Para una pequeña web también.

Pero cuando hablamos de una empresa cuya facturación depende de formularios, reservas, ecommerce, leads o servicios online, el cálculo debería hacerse utilizando coste total y riesgo, no preguntando únicamente cuánto cuesta instalar WordPress.

¿Significa esto que nadie debería utilizar WordPress?

No.

Y sería intelectualmente bastante pobre afirmar algo así.

WordPress sigue teniendo ventajas enormes: ecosistema gigantesco, facilidad para publicar contenido, profesionales disponibles, integraciones prácticamente para cualquier necesidad y una comunidad extraordinaria.

Hay proyectos donde continúa teniendo muchísimo sentido.

Una web editorial.

Un blog.

Una página corporativa sencilla.

Un proyecto donde exista mantenimiento profesional permanente.

Una instalación extremadamente controlada y con pocos componentes.

El problema aparece cuando confundimos:

"WordPress permite hacer prácticamente cualquier cosa"

con:

"WordPress es la arquitectura adecuada para hacer cualquier cosa".

Son afirmaciones completamente diferentes.

Para proyectos críticos, cada vez me cuesta más verlo

Si hoy tuviera que plantear una aplicación donde seguridad, estabilidad y disponibilidad fueran realmente críticas, intentaría reducir al máximo la superficie de ataque y, especialmente, el número de dependencias que pueden introducir código ejecutable en el servidor.

No quiero 35 plugins.

No quiero descubrir que una funcionalidad esencial depende de un desarrollador que dejó el proyecto hace tres años.

No quiero comprobar cada mañana si alguna extensión utilizada por mis clientes acaba de aparecer en una base de datos de vulnerabilidades.

Y tampoco quiero solucionar el problema instalando otro plugin de seguridad encima de los plugins que ya tengo.

Porque llega un momento en que parece que estamos sujetando WordPress con cinta americana mientras instalamos un plugin para comprobar si la cinta americana tiene alguna vulnerabilidad.

El gran cambio de 2026 es la velocidad

Esta es posiblemente la cuestión que más debería preocupar a administradores y empresas.

En el primer semestre de 2025 ya se habían identificado 6.700 nuevas vulnerabilidades en el ecosistema WordPress, y Patchstack estimaba que el 41 % podían explotarse en ataques reales.

El informe completo publicado en 2026 elevó la cifra de 2025 a 11.334 vulnerabilidades, con un crecimiento anual del 42 %.

No todas son críticas.

No todas afectan a nuestra web.

No todas serán explotadas.

Pero la dirección resulta difícil de ignorar.

Tenemos más investigadores, mejores herramientas, programas de recompensas, automatización, inteligencia artificial y atacantes capaces de reaccionar cada vez más rápido.

Mientras tanto, seguimos teniendo instalaciones de WordPress donde alguien pregunta:

"¿Podemos actualizar ese plugin? Es que no sabemos si se romperá la plantilla."

Ese desfase entre la velocidad del atacante y la velocidad de mantenimiento de una web tradicional es lo que realmente me preocupa.

El futuro de WordPress necesita menos dependencia, no más plugins

WordPress probablemente seguirá existiendo durante muchos años.

Con una cuota cercana al 59 % entre los CMS conocidos en agosto de 2026, hablar de su desaparición inmediata sería absurdo.

Pero supervivencia y conveniencia tecnológica no son lo mismo.

Mi duda no es si WordPress seguirá existiendo.

Mi duda es qué tipo de proyectos deberían seguir construyéndose sobre WordPress durante la próxima década.

Porque en un Internet donde descubrir y explotar errores puede automatizarse cada vez más, una arquitectura basada en combinar decenas de componentes PHP de procedencias distintas necesita replantearse seriamente.

Quizá el futuro pase por instalaciones mucho más minimalistas.

Quizá por WordPress desacoplado.

Quizá por arquitecturas donde el CMS no esté directamente expuesto.

Quizá por sistemas estáticos para determinados proyectos.

O quizá WordPress consiga transformar radicalmente la seguridad y gobernanza de su ecosistema de plugins.

Pero continuar instalando WordPress, añadir 27 plugins, configurar actualizaciones automáticas y pensar que alguien se ocupará de todo parece, en agosto de 2026, una estrategia cada vez más difícil de defender.

Sobre todo porque ahora ese "alguien" que está revisando tu plugin abandonado de 2018 podría no ser su desarrollador.

Podría ser una IA.

Y puede que no esté trabajando para ti.

SeoXan y el deporte: cuando los valores también se llevan puestos

Alex Rubio — Sat, 25 Jul 2026 21:11:40 +0000

En SeoXan siempre hemos creído que la tecnología y el deporte comparten mucho más de lo que parece. Detrás de un buen proyecto, igual que detrás de un buen partido, hay constancia, estrategia, trabajo en equipo y ganas de superarse cada día.

Por eso hemos querido dar un paso más en nuestro compromiso con el deporte lanzando una camiseta exclusiva de pádel, desarrollada junto a Por4.es, que entregaremos a clientes seleccionados como agradecimiento por la confianza que depositan en nosotros.

No se trata simplemente de una camiseta. Representa una forma de entender las relaciones con nuestros clientes: cercanas, duraderas y basadas en valores compartidos.

El pádel es un deporte que refleja perfectamente nuestra filosofía empresarial. Cada punto requiere comunicación, adaptación, esfuerzo y confianza en el compañero. Son los mismos principios que aplicamos cada día cuando desarrollamos soluciones tecnológicas, protegemos infraestructuras o acompañamos a nuestros clientes en el crecimiento de sus negocios.

Esta edición exclusiva nace también de la colaboración con Por4.es, una empresa que comparte nuestra pasión por el deporte y la calidad. Juntos hemos creado una prenda pensada para utilizar dentro y fuera de la pista, con un diseño moderno que representa la unión entre innovación, rendimiento y espíritu deportivo.

En SeoXan queremos seguir apoyando iniciativas que fomenten un estilo de vida activo y saludable. Creemos que las empresas también tienen un papel importante en impulsar valores como el esfuerzo, el respeto, la superación y el compañerismo, tanto dentro como fuera del ámbito profesional.

A todos los clientes que recibáis esta camiseta, esperamos que la disfrutéis tanto como nosotros hemos disfrutado preparándola. Nos encantará verla en las pistas de pádel, compartiendo momentos de deporte, amistad y competición sana.

Porque al final, tanto en la empresa como en el deporte, los mejores resultados siempre llegan cuando se trabaja con pasión.

SeoXan. Tecnología que impulsa personas.

Projecte televisiu IA al Dia i implementació de la IA

Alex Rubio — Fri, 15 May 2026 16:45:11 +0000

Avui he assistit a la presentació del projecte “IA al Dia”, liderat per Carles Argemí, una proposta que busca apropar la intel·ligència artificial a l’empresa des d’un enfocament pràctic i aplicable.

El plantejament és clar: càpsules quinzenals d’uns 30 minuts basades en casos reals. Res de teoria buida. Problema, solució i aplicació directa. Un format que, ben executat, pot aportar molt més valor que molts continguts formatius que es queden en el PowerPoint i no arriben mai a l’operativa del dia a dia.

Més enllà del projecte en si, la sessió ens ha servit per posar sobre la taula una realitat que moltes empreses encara estan evitant: la IA ja no és opcional. Estem en un punt molt similar al que es va viure amb internet. Qui no s’hi adapta, simplement queda fora.

També s ha comentat una tendència que ja és evident: el model gratuït s’està acabant. Plataformes com Anthropic amb Claude o ChatGPT estan limitant funcionalitats i orientant-se cap a models de pagament. I és lògic. La IA que realment aporta valor tindrà cost, i les empreses que ho entenguin abans tindran avantatge competitiu.

Un dels punts més encertats de la sessió ha estat la diferència entre “provar la IA” i treballar-hi de veritat. Fer quatre prompts no transforma cap negoci. El canvi real ve quan es construeixen solucions pròpies: GPTs personalitzats, sistemes amb RAG, integracions amb dades internes… aquí és on es guanya productivitat de veritat.

Pel que fa a “IA al Dia”, l’estratègia de començar per televisions locals com TV Sabadell Vallès pot semblar conservadora, però té sentit com a fase de validació. El repte no és arrencar, és escalar. I aquí és on veurem si el projecte pot créixer o es queda en una bona iniciativa.

En resum, una sessió interessant, amb una idea força clara: la IA no substituirà empreses, però sí substituirà les empreses que no la sàpiguen utilitzar. I això ja està passant.