El ticket de WordPress n.° 30465 se abrió hace 10 años: ¿será 2025 el año en que finalmente se resuelva?

En noviembre de 2014, un desarrollador de WordPress llamado Sergej Mueller planteó lo que parecía una preocupación razonable: los usuarios no tenían forma de saber si un complemento que estaban usando había sido eliminado del repositorio oficial, incluso si se eliminó por razones de seguridad. Su ticket (oficialmente #30465) se cerró relativamente poco después, pero sin resolución. Sergej no sabía que sería reabierto casi diez años después .

Y aquí estamos, a principios de 2025, escribiendo una actualización al respecto.

¿Por qué?

Por algunas razones.

Primero, es muy relevante para algunos eventos de seguridad de complementos que ocurrieron recientemente (octubre del año pasado para ser exactos). Hablaré de ellos en breve. Y, en segundo lugar, la voluntad y el impulso para resolver el problema han ido cobrando fuerza: la última actividad en el billete fue hace menos de un mes:

Así que parece que la paciencia de Sergej finalmente dará sus frutos pronto...

Empecemos por seguir el desarrollo del billete. Luego, podemos pasar a lo que ha estado sucediendo en las últimas semanas:

De “no se arreglará” a subir al escenario en WCEU 2023 🙅‍♂️

Cuando se abrió el ticket por primera vez, recibió algunas respuestas, pero el desarrollador principal de WordPress, Andrew Nacin, lo cerró con bastante rapidez. Lo cerró y lo marcó como "no se soluciona", explicando que las eliminaciones de complementos ocurrieron por varias razones, no solo por problemas de seguridad:

Después de eso hubo una avalancha de comentarios, pero luego se calmó y se convirtió en un comentario que se realiza una vez al año (a veces incluso menos que eso) de alguien que intentaba revivir el tema.

Luego, en marzo de 2023 , sucedió algo interesante. Joost de Valk, una figura muy conocida en la comunidad de WordPress, reabrió oficialmente el ticket . Su argumento fue que WordPress tiene la responsabilidad de informar a los usuarios si un complemento se mantiene o no.

También señaló que WordPress.org ya mostraba esta información en la propia plataforma, pero sólo después de un período de espera de 60 días. Su sugerencia fue llevar esa misma transparencia al backend de WordPress donde los usuarios realmente administran sus complementos.

Eso desató una nueva ola de entusiasmo en todo el hilo. El boleto se hizo tan popular que Oliver Sild, director ejecutivo y cofundador de Patchstack, incluso lo mencionó en su discurso en la WCEU 2023 :

No sólo lo mencionó, sino que animó a los asistentes a WCEU a dejar comentarios en el hilo utilizando el código QR personalizado que añadió a su presentación. También usó este complemento como un alley-oop retrasado para un concurso que Patchstack organizaría el año siguiente.

Evento de Patchstack de octubre de 2024 🪲

En octubre de 2024, Patchstack lanzó un evento Bug Bounty como parte del Mes de la Seguridad Cibernética. Si la mención de Oliver del boleto #30465 en su discurso en la WCEU fue un alley-oop, entonces los resultados de este evento serían definitivos.

Los investigadores de seguridad que participaron en el evento terminaron descubriendo la asombrosa cifra de 1.571 informes de vulnerabilidades de seguridad válidos en un solo mes. Estos tampoco fueron solo problemas menores: estamos hablando de:

• 73 casos en los que los atacantes pudieron subir archivos maliciosos.
• 67 vulnerabilidades de inyección SQL que podrían comprometer bases de datos enteras.
• 58 formas en que los atacantes pueden aumentar sus privilegios.
• 17 vulnerabilidades de ejecución remota de código (¡ay!)

Las consecuencias provocaron el cierre temporal de cerca de 1.000 complementos. Y cuando Patchstack intentó contactar a los desarrolladores de complementos sobre estos problemas, casi el 74% fueron completamente inalcanzables. O sus formularios de contacto estaban rotos, sus correos electrónicos rebotaron o sus dominios habían caducado.

Lo bueno es que muchos de estos complementos vulnerables habían estado en el repositorio durante 6 a 11 años. ¡Algunos datan de hace 17 años! Y sí, todavía hay sitios web activos que dependen de estos complementos.

No hace falta decir que todos estos datos le dieron a Oliver influencia en el hilo para impulsar el ticket n.° 30465 hasta su finalización. Felizmente lo aprovechó y publicó algunos de los detalles dos semanas antes de la publicación de la publicación oficial del blog de Patchstack sobre el evento:

De la discusión a la acción 🛠️

La actividad en el hilo ya estaba aumentando cuando Oliver agregó su comentario, por lo que evaluar su impacto individual es difícil. Sin embargo, no es descabellado suponer que añadió más leña a una llama creciente. Especialmente con otros usuarios (de los cuales al menos uno es empleado de Patchstack) apoyando abiertamente su comentario.

En respuesta, el desarrollador principal de WordPress, Dion Hulse (@dd32), rechazó varios puntos, pero también dio un paso adelante enorme al crear un complemento experimental que implementa la característica tan esperada:

La implementación es maravillosamente simple: cuando se cierra un complemento en el repositorio de WordPress.org, los usuarios ven una notificación clara pero mesurada. No hay alertas rojas que provoquen pánico, solo información directa sobre el estado del complemento.

Que alguien encuentre a Sergej y le diga: "¡Mamá, lo logramos!"

Bueno… casi.

¡No es parte del núcleo de WordPress todavía, pero siento que estamos cerca de la meta!

Ahora que se ha demostrado que es posible, el siguiente paso es decidir una implementación final. Luego se puede integrar en el núcleo de WordPress.

¿Qué sigue? 🎯

Al momento de escribir este artículo, se está considerando la inclusión de la función en WordPress 6.8 (según Dion Hulse), aunque todavía quedan algunos obstáculos por superar. Estos incluyen:

• Finalizando el plazo de notificación (se está discutiendo la posibilidad de extender la ventana de 60 días).
• Estandarizar la documentación del motivo del cierre.
• Equilibrar la conciencia del usuario con la carga de soporte del desarrollador.
• Decidir la ubicación exacta (la pantalla de estado del sitio versus directamente en el complemento como se muestra en la captura de pantalla de ejemplo del complemento).

El panorama general 🌐

La evolución del ticket #30465 de WordPress nos dice algo fascinante sobre cómo ha cambiado la seguridad de WordPress durante la última década. Lo que alguna vez se descartó como un caso límite se ha vuelto cada vez más crítico a medida que el ecosistema ha crecido y los desafíos de seguridad se han multiplicado.

Si bien nos tomó diez años llegar hasta aquí, el complemento experimental sugiere que finalmente nos estamos acercando a una solución que equilibra la conciencia de seguridad con la experiencia del usuario. Con millones de instalaciones de WordPress potencialmente afectadas por complementos vulnerables, esta característica no llegará lo suficientemente pronto.

Si desea seguir el desarrollo, consulte el complemento experimental en GitHub o esté atento al ticket n.° 30465. Este podría ser uno de esos raros momentos en los que somos testigos de cómo una conversación de una década se transforma en un resultado tangible. 💡

¿Qué opinas de esta característica? ¿Crees que sería útil para ti, como usuario de WordPress, ser informado de que se cerró un complemento? Déjamelo saber en los comentarios. Te veré allí.