Pulsa ESC para cerrar

Curso WordpressCurso Wordpress

«Tu web tiene una vulnerabilidad grave»: cómo reconocer a los cazarrecompensas falsos

Abres tu correo y encuentras algo así: «Estimado, soy investigador de seguridad y encontré una vulnerabilidad crítica en tudominio.cl. Puedo darle los detalles. Espero una recompensa adecuada por mi trabajo.»

Da miedo, y está hecho para eso. Pero en la gran mayoría de los casos no es un aviso real: es lo que en el mundo de la seguridad se llama beg bounty, algo así como «pedir recompensa a ciegas».

Cómo funciona

Alguien pasa un escáner automático por miles de sitios, toma cualquier detalle que el escáner marque como «riesgo» y envía el mismo correo a todos. No revisó tu sitio en particular, no hay un ataque real y no hay una falla seria. Solo hay una esperanza: que te asustes y pagues.

Las señales típicas

  • El remitente usa un correo gratuito (Gmail, Outlook, Proton) y no tiene un perfil público verificable.
  • Habla de «vulnerabilidad crítica» pero no dice cuál, o la explica con frases genéricas.
  • Pide dinero, o pregunta si tienes un «programa de recompensas», antes de darte los detalles.
  • Te presiona con plazos («si no responde en 48 horas…»).
  • Cuando da detalles, son siempre los mismos de la lista de abajo.

Un aviso real se ve distinto. Un investigador serio explica la falla con precisión, te da tiempo para corregirla y no condiciona la información a un pago. Y si la falla es de un plugin, normalmente avisa al autor del plugin o a empresas como Wordfence o Patchstack, no a cada sitio que lo usa.

Lo que suelen «reportar»

Casi todos los beg bounty se basan en estos hallazgos. Ninguno es una vulnerabilidad grave por sí solo:

  1. «Faltan cabeceras de seguridad» (X-Frame-Options, Content-Security-Policy, HSTS). Es una buena práctica, no un agujero.
  2. «Su sitio es vulnerable a clickjacking». Es lo mismo que el punto anterior, contado de otra forma.
  3. «Falta el registro SPF o DMARC». Afecta la entrega de tus correos, no la seguridad de tu web.
  4. «XML-RPC está activo». Puede usarse para ataques de fuerza bruta, pero se corrige en un minuto.
  5. «Se pueden ver los nombres de usuario». Es cierto en casi todo WordPress, y una contraseña fuerte con doble factor lo vuelve irrelevante.
  6. «Se ve la versión de WordPress». Si estás actualizado, no importa.

Revisa en 10 minutos (y corrige lo fácil)

Aunque el correo sea un intento de cobro, a veces apunta a algo que vale la pena ajustar. Para las cabeceras, agrega esto al .htaccess (Apache o LiteSpeed), fuera del bloque de WordPress:

<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Y si no usas la app móvil ni servicios que publican por XML-RPC, desactívalo con un mu-plugin de una línea, wp-content/mu-plugins/cwp-sin-xmlrpc.php:

<?php
/**
 * Plugin Name: Sin XML-RPC (Curso WordPress)
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Comprueba las cabeceras con curl -I https://tudominio.cl o con un servicio como securityheaders.com.

Qué hacer con el correo

  • No pagues nada por adelantado, nunca.
  • No abras adjuntos ni enlaces del correo. Algunos de estos mensajes son también intentos de phishing.
  • No respondas con datos de acceso, aunque te pidan «verificar».
  • Si quieres responder, basta con algo como: «Gracias. Si encontraste una vulnerabilidad concreta, envíame los detalles técnicos para revisarla. No ofrecemos recompensas.» Si es un investigador real, te enviará los detalles. Si no, desaparecerá.
  • Si te queda la duda, pide los detalles y revísalos con tu proveedor de hosting o en un foro de confianza.

Excepción importante: si el correo menciona un plugin concreto con una versión concreta, revisa de todas formas que tengas ese plugin actualizado. Los estafadores a veces copian alertas reales para sonar creíbles, y actualizar no cuesta nada.

Nivel pro: publica un security.txt

El archivo security.txt es un estándar para decir dónde reportar fallos y cuál es tu política. Crea .well-known/security.txt en la raíz de tu sitio:

Contact: mailto:[email protected]
Expires: 2027-10-31T23:59:59.000Z
Preferred-Languages: es, en
Policy: https://tudominio.cl/politica-de-seguridad/

En la página de política puedes dejar claro que agradeces los reportes responsables y que no pagas recompensas. Los investigadores serios lo leen; los que piden dinero a ciegas tendrán una respuesta antes de escribirte.

¿Te llegó uno de estos correos y no sabes si es real? Compártelo en el foro, borrando tus datos, y lo revisamos juntos.