Una vulnerabilidad zero-day es la pesadilla de cualquier admin: nadie la conoce, no hay parche, y ya están explotándola. Cómo funcionan, por qué no podés prevenirlas todas, y cómo construir defensa resiliente contra lo desconocido.
Imaginá este escenario. Lunes a las 8am, abrís las noticias. Un investigador de seguridad acaba de publicar una vulnerabilidad crítica en un plugin que vos tenés instalado en tu sitio. CVSS 9.8. Exploit público en GitHub. El vendor del plugin responde: "parche oficial en 48-72 horas". Durante esas 72 horas, tu sitio es target legítimo de cualquier bot que escanee internet. ¿Qué hacés?
La atribución no es solo curiosidad técnica. Es evidencia legal, inteligencia de amenazas, y — a veces — lo que determina si recuperás tu dinero. Cómo funciona la atribución moderna y sus límites honestos.
La inteligencia de amenazas dejó de ser capacidad exclusiva de Fortune 500. Cómo consumirla si sos empresa mediana, qué feeds valen, cómo diferenciarla de ruido, y cómo integrarla a tu operación sin SOC propio.
Eso es un zero-day. Más precisamente, una vulnerabilidad que era zero-day hasta esta mañana — cuando fue descubierta antes del parche oficial. El reloj empezó a correr y todos los administradores de sistemas con ese plugin instalado entraron en el mismo loop mental: "¿cuándo lo van a patchear? ¿cómo me protejo mientras tanto?".
Este artículo explica qué son los zero-days, cómo funciona su ciclo de vida, por qué no podés prevenirlos todos, y — críticamente — cómo construir defensa resiliente que te proteja aun contra lo desconocido. Pensado para admins de WordPress y directores técnicos de empresas medianas LATAM.
Tres términos que suenan similares pero son distintos:
Vulnerabilidad que existe en software pero NO es públicamente conocida. Cero días han pasado desde su descubrimiento público. El vendor no sabe que existe. No hay parche. Si un atacante la conoce, la puede explotar sin resistencia.
Los zero-days más valiosos (en dark markets, brokers, nation-states) son los que nadie más conoce. Zerodium históricamente ofrecía $2.5M por zero-day de iOS. Google Project Zero invierte fuerte en encontrarlos antes que atacantes.
Vulnerabilidad ya conocida públicamente PERO no parcheada en sistemas específicos. "N-day" porque N días han pasado desde el anuncio público. Si una CVE se publicó hace 30 días y tu sitio no la parcheó, para vos es n-day con n=30.
La mayoría de hackeos exitosos son n-days, no zero-days. Los sistemas no se parchean; los atacantes aprovechan.
Vulnerabilidad descubierta por investigadores, reportada al vendor, en proceso de fix, pero NO pública aún. Durante este período (semanas a meses), la vulnerabilidad existe pero el riesgo es bajo — solo el vendor y el investigador la conocen.
Este período se llama "responsible disclosure window" — típicamente 90 días entre reporte y publicación pública.
El paseo típico de una vulnerabilidad desde secreto hasta ampliamente explotada:
Alguien — investigador, empleado del vendor, o atacante — encuentra la vulnerabilidad. Puede quedarse oculto durante meses o años antes de ser reportado o explotado.
El investigador reporta al vendor. El vendor confirma, desarrolla fix, prueba, prepara release. El investigador coordina el timing del anuncio público con el release del parche.
Durante esta fase, si la vulnerabilidad es secreta, el riesgo es bajo. Si el atacante es el que la encontró (no un investigador ético), la explota silenciosamente.
El vendor publica la CVE y el parche. Idealmente al mismo momento. "Zero-day" deja de ser zero-day en este momento — ahora todos saben que existe.
Alguien — investigador, atacante, curioso — publica una prueba de concepto en GitHub. Proof of concept: código que demuestra la explotación. A veces los investigadores publican su PoC junto con el report; a veces atacantes reverse-engineer del parche y publican en GitHub/pastebin.
Los atacantes de masa incorporan el exploit en sus scanners. Los bots empiezan a escanear millones de sitios buscando la versión vulnerable. Si tu sitio tiene esa versión y no parcheó, te están escaneando ahora mismo.
Las campañas a escala empiezan. Newsworthy incidents. Vendors de seguridad publican reportes. Empresas afectadas aparecen en prensa.
WAFs agregan reglas. Threat intel marca IPs de atacantes activos. La mayoría de sitios aplican el parche. El incendio se apaga para la mayoría, queda humeando para sitios sin parchear.
Una cola larga de sitios nunca parcheados sigue siendo vulnerable. Atacantes de menor capacidad aprovechan. Reporte post-mortem: "X% de sitios tenía la versión vulnerable un año después".
Históricamente, las campañas de zero-day targeteaban Fortune 500 (más valor por cliente comprometido). Patrón cambió:
Resultado: los zero-days que aparecen en plugins WordPress, WooCommerce, frameworks populares — afectan a miles de empresas medianas LATAM en cuestión de días.
No podés prevenir zero-days. Lo que sí podés es construir defensa que reduzca el impacto aun contra amenazas desconocidas.
La mejor protección contra zero-days es no tenerlos. Cada plugin, theme, service que agregás a tu stack es superficie adicional. Principio: mínimo viable.
Auditoría periódica:
Cada componente removido = una fuente menos de zero-days potenciales.
La mayoría de zero-days que realmente afectan a tu sitio: o están en plugins/themes no actualizados (son n-days, no zero-days puros), o en componentes reales donde el parche llega rápido y lo aplicás rápido.
Disciplina de patcheo: automático para parches menores de seguridad, semanal para mayores con testing previo, mensual para upgrades compatibles-breaking.
Aun si un zero-day es explotado contra tu sitio, el atacante típicamente deja artefactos: archivos nuevos, archivos modificados, usuarios creados, tareas cron. Monitoreo de integridad detecta el artefacto aun sin conocer el vector original.
Con Drako (hardening + monitoreo SHA-256 + análisis IA del código modificado), un exploit de zero-day que modifica archivos dispara alerta incluso aunque no conozcas la CVE original.
Cuando la CVE se publica públicamente (fase 3-4 del ciclo de vida), vos querés proteger ANTES de que el parche oficial llegue. Virtual patching con IA (Conan) genera reglas en minutos, protege durante las 24-72 horas de ventana de vulnerabilidad.
No previene el zero-day cuando aún es secreto. Pero reduce dramáticamente la ventana de exposición post-anuncio público.
Si un zero-day te golpea antes de que defensas preventivas actúen, lo que te salva es velocidad de respuesta:
Estas capas son las que separan "un susto recuperable" de "crisis existencial" cuando un zero-day pega.
Anticipá qué amenazas probablemente te afectarán antes de que lleguen. Telemetría LATAM + IA + contexto regional.
Disponible hoy: Mientras tanto, protegé tu sitio hoy con Drako — $9/mes.
Empezar con DrakoUn malentendido común: "¿Oráculo puede predecir zero-days antes de que existan?". No, y nadie puede — si pudieras predecir código no escrito, serías rico en otros campos.
Lo que Oráculo hace es predecir riesgo, no vulnerabilidad específica:
"Basado en telemetría anónima de clientes Drokio, las tiendas WooCommerce LATAM tienen alta probabilidad (estimada >30%) de ser target de campaña de skimmer en próximas 2-4 semanas."
Esto no te dice qué exploit específico usarán. Te dice que la probabilidad de ser target para tu tipo de sitio es alta ahora mismo. Acción: reforzá defensas de checkout específicamente, aumentá monitoreo de ese vector.
"Sitios con combinación de Plugin A + Plugin B + PHP 7.x tienen 3x más probabilidad de ser comprometidos en próximos 90 días que sitios con stack moderno."
Basado en histórico de incidentes entre clientes Drokio con configuraciones similares. Acción: actualizar stack, específicamente las combinaciones que históricamente correlacionan con compromiso.
"Plugin X tiene tasa histórica de 3-5 CVEs críticos por año, con promedio de 45 días entre CVE y siguiente. Última CVE hace 38 días. Alta probabilidad de próxima CVE en próximas 2-4 semanas."
Predice ritmo de publicación de vulnerabilidades, no contenido específico. Acción: preparate para aplicar parche rápido cuando aparezca, tener virtual patching listo.
Cuando un zero-day aparece que afecta a tu stack, escalá respuesta según severidad:
El error frecuente: tratar toda CVE con el mismo nivel de pánico. Genera fatigue del equipo, las críticas reales se atienden como si fueran rutina.
Las pólizas de seguro cibernético modernas sí cubren zero-days, con caveats:
Para empresa mediana LATAM 2026: primas típicas 1-5% del revenue anual. Cobertura típica: $500K-$5M. Para empresas con revenue significativo y exposición digital alta, vale la pena.
Zero-days son inevitables. Lo que controlás es tu posición cuando aparecen: superficie de ataque, disciplina de patcheo, capacidad de detección, virtual patching, capacidad de respuesta. Ninguna capa individual alcanza; la combinación de todas reduce el impacto dramáticamente.
Oráculo no predice el futuro — reduce incertidumbre al darte estimaciones basadas en data. Eso no es magia, es estadística aplicada con IA. Pero operacionalmente, tener estimación de riesgo para las próximas 4 semanas vale más que operar a ciegas.
La pregunta que importa no es "¿cómo prevenir todo zero-day?" (imposible) sino "¿cómo minimizar el daño cuando alguno te golpea?" (alcanzable).
Rango típico: 80-150 zero-days catalogados públicamente por año en toda la industria (Project Zero de Google, Zerodium, vendors). Los que afectan a WordPress/ecommerce típicamente son 20-30 por año. La mayoría son patcheados antes de amplio abuso; solo 10-20% resultan en campañas masivas. Los zero-days que afectan producto específico tuyo en un año dado: probablemente 0-2.
Tres vías: 1) Investigadores independientes o de empresas de seguridad los encuentran y reportan responsablemente al vendor. 2) Bug bounty programs (HackerOne, Bugcrowd) donde el vendor paga por reportes. 3) Atacantes los encuentran y los usan en ataques (el 'zero-day en uso' que detectan vendors de seguridad). Los primeros dos son el camino responsable; el tercero es el preocupante.
No puede predecir vulnerabilidades específicas en código que no vio. Lo que sí puede predecir: qué industrias/regiones serán target próximo basado en patrones de campañas, qué tipos de vulnerabilidades son más probables en qué frameworks (telemetría histórica), y qué sitios tienen combinaciones de software que históricamente correlacionan con exposición a zero-days. Es predicción de riesgo, no de vulnerabilidad específica.
Rango típico: horas a semanas. Pattern observado 2023-2025: anuncio público de CVE → primer exploit en GitHub dentro de 6-24 horas → bots automatizados escaneando dentro de 12-48 horas → amplio abuso en 72 horas. Zero-days CRÍTICOS (CVSS 9+) tienen la ventana más corta; CVEs medianos pueden tardar semanas en ser weaponizados a escala.
Parcial. Virtual patching funciona contra zero-days con patrones de explotación claros (SQL injection, XSS, path traversal) — la IA puede generar reglas de mitigación. Para zero-days con lógica de negocio compleja o requisitos específicos de entorno, virtual patching es menos efectivo. Conan + Oráculo combinan: Oráculo predice categorías de riesgo, Conan aplica virtual patching cuando hay patrón claro.
Sí. Las pólizas de seguro cibernético modernas cubren incidentes resultantes de zero-days, aunque típicamente requieren evidencia de diligencia razonable (parcheo regular, logs, respuesta a incidentes). El costo es significativo (1-5% del revenue anual para póliza decente en empresa mediana) pero provee cobertura financiera real. En LATAM todavía es mercado en desarrollo; evaluá vendors locales.
Producto mencionado
Anticipación de ataques con scoring heurístico
Scoring heurístico transparente y auditable sobre telemetría anónima: anticipa campañas antes de que te golpeen, sin caja negra.
Disponible hoy
Mientras tanto, protegé tu sitio hoy con Drako — $9/mes.
Los ataques exitosos a WooCommerce siguen un patrón conocido: recon, acceso inicial, escalada, persistencia, exfiltración. Cada etapa tiene defensas específicas que la cortan. Si entendés las 5 etapas, sabés exactamente dónde está fallando tu protección.
