Hoy, a tres meses del deadline del EU Cyber Resilience Act, menos del 50% de los plugins WordPress activos en el mercado tiene una política de divulgación de vulnerabilidades documentada y funcional. El 11 de septiembre de 2026 entra en vigencia la obligación de reporting activo: sin una VDP en regla, los desarrolladores que distribuyan en mercados europeos enfrentan multas de hasta EUR 15 millones.
Una Vulnerability Disclosure Policy (VDP) es el proceso formal mediante el cual los investigadores de seguridad pueden reportar vulnerabilidades en privado antes de hacerlas públicas, dando al desarrollador tiempo para parchear. Sin este proceso, el reporte va directo a Twitter o a bases de datos públicas, y los bots automáticos explotan la falla en menos de 24 horas.
En 30 segundos
- El 11 de septiembre de 2026 vence el plazo CRA para que los plugins con distribución en la UE tengan reporting obligatorio de vulnerabilidades activamente explotadas (72 horas a ENISA).
- Según datos del sector, el 52% de los desarrolladores no coordina parches con la divulgación, y el 71% de las vulnerabilidades se hacen públicas sin fix disponible.
- En el primer trimestre de 2026 se registraron 2.738 vulnerabilidades en plugins WordPress, según reportes del sector.
- Los plugins sin VDP documentada después del deadline quedan expuestos a prohibición de distribución en el mercado europeo y multas del 2,5% de ingresos globales.
- Existen opciones desde gratuitas (SECURITY.md + email dedicado) hasta plataformas como HackerOne o CVD Portal para cumplir en tiempo.
¿Qué porcentaje de plugins WordPress realmente tiene una política de divulgación de vulnerabilidades funcional?
Ponele que instalás un plugin con 200.000 activaciones activas en tu WordPress. ¿Sabés si ese plugin tiene un canal documentado para reportar fallas de seguridad antes de que alguien las publique? En la mayoría de los casos, la respuesta es no.
Los números son bastante claros: según el reporte de Patchstack sobre seguridad WordPress 2026, el 52% de los desarrolladores no coordina los parches con la divulgación pública de vulnerabilidades. El 46% no tiene fix disponible cuando la vulnerabilidad sale a la luz. Y el 71% de las vulnerabilidades se divulgan sin parche previo.
¿Alguien midió cuántos plugins activos en WordPress.org tienen un archivo SECURITY.md o una dirección security@ publicada? Números exactos no están disponibles de forma centralizada, pero la estimación del sector es que menos de la mitad del ecosistema activo tiene algo documentado y funcional.
El Q1 2026 confirmó el ritmo: 2.738 vulnerabilidades registradas en plugins, según datos compilados por la industria de seguridad WordPress. Un 13% apareció en plugins que ya no tienen mantenimiento activo, lo que hace la VDP imposible de implementar a posteriori.
¿Qué es una VDP y qué diferencia hace respecto a la divulgación directa?
La diferencia entre una VDP y la divulgación directa es simple: con VDP, el investigador te avisa a vos primero. Sin ella, te avisa a todos al mismo tiempo. Esto se conecta con lo que analizamos en reportar vulnerabilidades de plugins.
El flujo con VDP funcional se ve así: el investigador detecta una vulnerabilidad, escribe a security@tu-plugin.com, espera un acuse de recibo en menos de 72 horas, y acuerdan un timeline para publicar la falla una vez que el parche esté disponible. Habitualmente entre 45 y 90 días. El flujo sin VDP: el investigador publica directamente en su blog, en Twitter, o lo vende a un broker de exploits. Los bots rastrean esas publicaciones en tiempo real y empiezan a explotar activamente en cuestión de horas.
La diferencia en la ventana de exposición es enorme. Con un proceso de divulgación coordinada (CVD), los usuarios tienen tiempo de actualizar. Sin él, corren contra el reloj desde el momento en que el investigador decide publicar.
¿Cuál es el deadline del EU CRA y qué pasa exactamente el 11 de septiembre de 2026?
El Cyber Resilience Act de la Unión Europea tiene un calendario específico, y septiembre de 2026 es la fecha que más duele para el ecosistema WordPress.
A partir del 11 de septiembre de 2026, cualquier software con elementos digitales distribuido en la UE debe cumplir con la obligación de notificar a ENISA (la agencia de ciberseguridad europea) dentro de las 72 horas si detecta una vulnerabilidad que está siendo activamente explotada. Eso implica tener procesos internos ya establecidos para detectar, evaluar y reportar, lo que a su vez requiere que el canal de entrada (la VDP) funcione correctamente.
El timeline práctico para quienes arrancan en junio 2026 es ajustado: junio para redactar la política, julio para implementar el canal y los procesos internos, agosto para el audit interno y pruebas. No hay margen para improvisar.
Las sanciones no son simbólicas. Según el texto del CRA, las multas llegan a EUR 15 millones o el 2,5% de los ingresos globales anuales, lo que sea mayor. Para un plugin commercial con volumen razonable, ese 2,5% puede ser más que la multa fija.
Ojo con esto: la exención parcial para software open-source no comercial existe, pero tiene condiciones. Un plugin gratuito que alimenta un negocio de servicios o soporte técnico difícilmente califica como «no comercial» ante una auditoría regulatoria. Cubrimos ese tema en detalle en complementar con un firewall adicional.
¿Cómo verificás si tus plugins activos tienen una política de divulgación documentada?
La verificación manual toma unos minutos por plugin. Los puntos de chequeo son concretos:
- Archivo SECURITY.md en el repositorio. Si el plugin tiene repo público en GitHub o GitLab, buscá ese archivo en la raíz. Es el estándar de facto para declarar el proceso de reporte.
- Política de seguridad en WordPress.org. Desde 2024, WordPress.org permite a los desarrolladores publicar una página de seguridad asociada al plugin. Si no está, ya hay una señal de alerta.
- Email dedicado (security@dominio o similar). No vale info@ ni contacto@ general. Tiene que ser un canal monitoreado exclusivamente por seguridad.
- Historial de CVEs publicados. Revisá la base de Patchstack o WPScan. Si el plugin tiene instalaciones activas y nunca apareció en ningún CVE, puede ser buena señal o puede ser que nadie haya mirado. Ambas posibilidades merecen atención.
- Fecha de último update. Un plugin sin actualización en más de 6 meses con vulnerabilidades conocidas en su categoría es riesgo real. Ahí la VDP no alcanza si el desarrollador no responde.
Para auditar de forma más sistemática, Patchstack tiene un checklist CRA descargable que cubre estos puntos y algunos más relacionados con el Software Bill of Materials (SBOM).
¿Por qué el 71% de vulnerabilidades se divulgan sin parche disponible?
Subís el reporte de seguridad, ves la vulnerabilidad listada, buscás el fix y… todavía no existe. Eso pasa más de lo que deería.
Las causas son bastante predecibles. Primero: el 52% de los desarrolladores directamente no monitorea los canales donde llegan los reportes de seguridad. No tienen un proceso, no tienen una persona asignada, y si llega un email a info@, puede perderse durante días. Segundo: los investigadores de seguridad tienen sus propios timelines. Si no reciben respuesta en un plazo razonable, muchos optan por publicar igual, porque retener la información indefinidamente tampoco es justo para los usuarios afectados.
El problema específico del ecosistema WordPress es la escala. Hay decenas de miles de plugins activos, la mayoría desarrollados por equipos pequeños o personas individuales sin recursos para mantener un proceso de seguridad formal. Un desarrollador solo, con trabajo de día, que recibe un reporte complejo un viernes a la noche, difícilmente lo resuelve en 72 horas.
El 13% de vulnerabilidades que aparecen en plugins abandonados es el caso extremo: no hay nadie que atienda. Los usuarios siguen con el plugin instalado, la falla queda expuesta indefinidamente y no hay VDP que lo solucione.
¿Qué elementos necesita una VDP para ser compliant con el CRA?
Según el análisis de Oliver Sild sobre CRA aplicado a WordPress, una VDP compliant no es solo un email de contacto. Los requisitos mínimos cubren varios aspectos:
- Canal único de contacto monitoreado. Un email security@ o un formulario dedicado con SLA documentado. El tiempo de respuesta inicial no puede superar las 72 horas.
- Software Bill of Materials (SBOM). Inventario de todas las dependencias que usa el plugin. Si usás una librería externa con vulnerabilidad conocida, el SBOM permite detectarlo antes de que alguien te lo reporte.
- Changelog de seguridad. Cada release debe documentar si corrige vulnerabilidades, con referencias CVE si corresponde. No alcanza con «bugfixes menores».
- Plan de soporte mínimo 5 años. Para software comercial, el CRA exige un compromiso explícito de soporte. Plugins que se venden «una sola vez sin soporte» tienen un problema estructural con esta exigencia.
- Proceso de remediación documentado. No solo recibir el reporte, sino qué pasa después: ¿en cuánto tiempo evaluás? ¿cuándo informás al investigador? ¿cuándo publicás el fix?
La diferencia entre plugins comerciales y open-source no comercial es real pero más estrecha de lo que parece. Un plugin gratuito con donaciones, servicios asociados o versión premium rara vez califica para la exención completa. En protección integral del sitio profundizamos sobre esto.
¿Qué consecuencias concretas tienen los plugins sin VDP después del 11 de septiembre?
Las multas ya las mencioné: EUR 15 millones o 2,5% de ingresos globales. Pero el impacto operativo puede ser más inmediato que la multa.
| Consecuencia | Aplica a | Timeline |
|---|---|---|
| Obligación de notificar a ENISA en 72h | Todos los plugins con distribución UE | Desde 11/09/2026 |
| Multa por incumplimiento | Software comercial principalmente | Desde 11/09/2026 |
| Prohibición de distribución en mercado UE | Reincidentes o faltas graves | Por resolución regulatoria |
| Responsabilidad civil por data breach | Plugins sin VDP con vulnerabilidad explotada | Ya aplica bajo GDPR |
| Desindexación de marketplaces | Plugins en tiendas que adopten CRA como criterio | A definir por marketplaces |
Los plugins con más de 100.000 instalaciones activas están en el radar regulatorio con más exposición. Más usuarios afectados implica impacto mayor si hay una falla explotada sin divulgación responsable previa.
Plan de acción para cumplir con CRA antes de septiembre de 2026
Tres meses es tiempo suficiente si arrancás ahora. El roadmap mínimo funcional:
- Junio 2026 — Redactar la política. Documentá el proceso: cómo reportar, a qué dirección, en cuánto tiempo respondés, qué información pedís al investigador, cómo coordinás la publicación. No tiene que ser largo, tiene que ser claro y estar publicado.
- Julio 2026 — Implementar el canal y los procesos. Crear security@tudominio.com, configurar alertas para que no se pierda ningún mensaje, definir quién en el equipo es responsable de la evaluación inicial. Si usás una plataforma como CVD Portal o HackerOne, este mes es para la configuración.
- Agosto 2026 — Audit interno y testing. Revisá el SBOM de tus dependencias, actualizá el changelog histórico con CVEs pasados si los tenés, y hacé una prueba del proceso completo: mandá un reporte ficticio y seguí el flujo hasta el final.
El costo varía bastante. Una implementación DIY con SECURITY.md en el repo y un email dedicado cuesta prácticamente nada. Las plataformas de gestión de vulnerabilidades tipo HackerOne o servicios especializados CRA arrancan desde unos cientos de dólares anuales hasta USD 5.000 o más para versiones con soporte completo. Para plugins con volumen comercial serio, el costo de la plataforma es marginal frente a la exposición regulatoria.
Si el plugin está alojado en un servidor o necesita infraestructura para el proceso de divulgación, un hosting confiable como donweb.com puede manejar sin problema los requerimientos técnicos básicos de un sistema de contacto seguro.
Errores comunes al implementar una VDP
Error 1: Confundir «política publicada» con «proceso funcional». Podés tener un archivo SECURITY.md impecable y un email de seguridad que nadie revisa hace tres meses. Los auditores regulatorios van a preguntar por el proceso real, no por el documento. La política sin implementación operativa no protege nada.
Error 2: Establecer tiempos de respuesta que no podés cumplir. Si el archivo dice «respondemos en 48 horas» y en la práctica tardás una semana, ese documento juega en tu contra. Mejor poner «respondemos en 5 días hábiles» y cumplirlo siempre, que prometer 48 horas e incumplir.
Error 3: Ignorar las dependencias de terceros. Tu plugin puede tener el código impecable, pero si usás una librería externa con vulnerabilidad conocida, la exposición es tuya. El SBOM no es burocracia: es la única forma de saber qué estás distribuyendo realmente (sí, en serio). Relacionado: plugins confiables con VDP.
Error 4: Pensar que la exención open-source aplica automáticamente. El CRA tiene exenciones para software libre sin actividad comercial, pero «libre» no significa «sin VDP». Si distribuís un plugin con licencia GPL pero tenés servicios de soporte pagos o versión premium, la exención no aplica completamente.
Preguntas Frecuentes
¿Cuántos plugins WordPress actualmente tienen una política de divulgación de vulnerabilidades?
No hay un número oficial consolidado, pero los datos del sector indican que menos del 50% del ecosistema activo tiene un proceso documentado y funcional. El 52% de los desarrolladores no coordina parches con la divulgación, lo que sugiere que una parte importante del ecosistema opera sin VDP operativa. WordPress.org no hace pública una estadística centralizada de este indicador.
¿Qué sucede si mi plugin WordPress no tiene VDP después del 11 de septiembre de 2026?
A partir de esa fecha, los plugins que distribuyan en la UE sin cumplir los requisitos CRA quedan expuestos a multas de hasta EUR 15 millones o el 2,5% de los ingresos globales anuales. En casos graves, las autoridades pueden prohibir la distribución en el mercado europeo. La responsabilidad civil por brechas de datos atribuibles a vulnerabilidades no reportadas ya existía bajo GDPR; el CRA la refuerza con la capa regulatoria específica de seguridad de producto.
¿Cuál es la diferencia entre divulgación responsable y divulgación pública?
Divulgación responsable (o coordinada, CVD) significa que el investigador reporta la vulnerabilidad al desarrollador en privado primero, espera que se desarrolle un parche, y publica los detalles técnicos recién cuando los usuarios tienen la opción de actualizar. Divulgación pública directa significa que los detalles de la falla aparecen en un blog, en Twitter o en una base de datos antes de que exista fix. La segunda opción puede ser legítima si el desarrollador no responde en un plazo razonable, pero expone a los usuarios al riesgo inmediato de explotación.
¿Cómo implementar una política de divulgación de vulnerabilidades en mi plugin desde cero?
El camino mínimo viable tiene tres pasos: crear un archivo SECURITY.md en el repositorio con las instrucciones de reporte, configurar un email security@ con alertas activas y SLA documentado (72 horas para la respuesta inicial), y publicar la política en la página del plugin en WordPress.org. Para una implementación más robusta compatible con CRA, agregá el SBOM de dependencias y un changelog de seguridad. Si necesitás una plataforma gestionada, CVD Portal y HackerOne tienen planes que se adaptan a equipos pequeños.
¿El CRA aplica a plugins gratuitos de WordPress.org?
Depende del modelo. Plugins completamente gratuitos, sin servicios asociados y sin actividad comercial tienen exención parcial bajo el CRA. Pero si el plugin gratuito alimenta un negocio de soporte, tiene versión premium o genera ingresos indirectos, la exención no aplica. El texto del CRA usa el criterio de «actividad comercial» de forma amplia, y una interpretación conservadora indica que cualquier plugin vinculado a un negocio debería cumplir con los requisitos mínimos de VDP.
Conclusión
El deadline del 11 de septiembre de 2026 no es una fecha abstracta. Es el punto en que la falta de una política de divulgación de vulnerabilidades en plugins WordPress pasa de ser una mala práctica a una exposición regulatoria concreta con multas definidas. El ecosistema WordPress llega a este momento con menos del 50% del inventario activo en condiciones de cumplir, 2.738 vulnerabilidades registradas solo en el primer trimestre del año, y la mayoría de ellas divulgadas sin parche previo.
Tres meses son suficientes para implementar lo básico. El problema no es técnico, es de priorización. Un SECURITY.md, un email monitoreado y un proceso de respuesta documentado no requieren inversión grande. Lo que sí requieren es decisión de hacerlo ahora, no en agosto.
Si sos desarrollador de un plugin con distribución activa en Europa, la pregunta no es «¿debo cumplir?» sino «¿por qué no empecé hace tres meses?» (que, admitámoslo, es la pregunta que siempre hacemos tarde).