Cualquier equipo de ingeniería reconoce ese frío en el estómago cuando se publica un boletín de ejecución remota de código con puntuación CVSS 9.2 para el lenguaje que sustenta su backend. El 21 de octubre de 2026, el equipo de PHP lanzó una actualización de emergencia para corregir dos fallos críticos. El backend de encrypted1on1 está desarrollado en PHP. Nuestra plataforma se actualizó prácticamente de inmediato tras la publicación del parche. Pero este incidente fue además una prueba de fuego práctica de nuestra arquitectura: por qué ni siquiera un exploit a nivel de servidor pudo comprometer las notas confidenciales de tus 1 a 1, y la honestidad radical sobre lo que el cifrado client-side protege —y lo que no.
Qué ocurrió (y por qué exigía actuar de inmediato)
El 21 de octubre de 2026 se publicaron las versiones de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para mitigar dos fallos de seguridad críticos: CVE-2026-109618 y CVE-2026-109619. Ambos cuentan con una calificación CVSS de 9.2 y permiten a un atacante remoto no autenticado ejecutar código arbitrario en el servidor.
Los avisos emitidos por el CERT-EU e investigadores de ciberseguridad confirmaron que los detalles técnicos ya se debatían abiertamente y que circulaban pruebas de concepto operativas en cuestión de horas. En términos de operaciones, no era una actualización para diferir a la próxima ventana mensual de mantenimiento: exigía intervención inmediata.
encrypted1on1 opera sobre PHP 8.5 en el contenedor oficial de FrankenPHP. Las imágenes base corregidas se publicaron en Docker Hub esa misma noche.
Qué hicimos en nuestra infraestructura
Desplegamos los contenedores actualizados en toda nuestra infraestructura prácticamente de inmediato tras la publicación del parche:
- Nuestra plataforma se reconstruyó sobre la imagen corregida con PHP 8.5.12 y se reinició sin interrupción de servicio.
- Cero modificaciones de código: Dado que nuestros Dockerfiles de producción referencian la etiqueta
php8.5, una simple reconstrucción incorporó de inmediato la versión subsanada del entorno de ejecución. - Auditoría y telemetría: Realizamos una revisión exhaustiva de registros y anomalías en los balanceadores perimetrales y los procesos de la aplicación. No se detectó rastro alguno de escaneos, intentos de ataque o comportamientos anómalos antes ni durante la actualización.
Por qué las notas de 1 a 1 jamás fueron legibles en el servidor
Es en estos escenarios concretos donde una arquitectura Zero-Knowledge demuestra todo su valor real.
En una herramienta habitual de gestión o wiki corporativa (Notion, Google Docs, Slack o un HRIS tradicional), una vulnerabilidad RCE en el servidor es una catástrofe total. El atacante abre una shell, lee las credenciales de la base de datos y ejecuta un volcado completo. Al instante quedan expuestos años de conversaciones íntimas: dudas sobre desempeño, discrepancias salariales, indicios de agotamiento y retroalimentación sin filtros.
En encrypted1on1, el servidor es ciego por diseño frente al contenido. Todas las notas de reunión, temas de agenda, reflexiones privadas y borradores de respuesta se cifran directamente en el navegador del usuario mediante AES-GCM-256 antes de que ningún dato salga hacia la red.
Nuestra base de datos solo almacena texto cifrado opaco:
- Respuestas y reflexiones privadas de ambos participantes (tanto borradores como notas publicadas);
- Comentarios, acuerdos, temas de debate y tareas pendientes;
- Anotaciones privadas retrospectivas de cada participante;
- Seguimiento periódico y avance en los objetivos de desarrollo.
Las claves criptográficas para descifrar esta información se derivan localmente en los dispositivos a partir de las contraseñas de los usuarios mediante Argon2id. Estas claves jamás viajan al servidor en texto claro: el servidor solo custodia sobres sellados que es matemáticamente incapaz de abrir.
Incluso si un atacante hubiese sustraído un volcado íntegro de nuestra base de datos de producción y los volúmenes en disco, únicamente habría obtenido datos ininteligibles sin las contraseñas de cada participante. Esa es la premisa angular de nuestro diseño: no te pedimos que confíes ciegamente en que nuestros servidores jamás sufrirán una vulnerabilidad de día cero. Un defecto en PHP, en una librería de C o en nuestro propio código no desemboca en la filtración de lo conversado en un 1 a 1.
El límite transparente: qué protege el cifrado de extremo a extremo (y qué no)
La confianza técnica se sustenta en la honestidad rigurosa y no en la retórica comercial. Este es el límite exacto de nuestro modelo de amenazas ante un servidor comprometido:
1. Los metadatos son visibles en el servidor. El cifrado protege el contenido de las conversaciones, pero el servidor necesita coordinar la operativa: qué cuentas existen, quién mantiene reuniones con quién, su periodicidad y las marcas temporales. Asimismo, por diseño del producto, ciertos elementos organizativos se gestionan en texto plano: títulos de objetivos, fechas límite, estado y plantillas de preguntas de la empresa. El detalle íntegro está documentado abiertamente en nuestro modelo de amenazas.
2. El cifrado protege los datos almacenados, no la entrega futura de código. encrypted1on1 es una aplicación web: el navegador descarga los archivos JavaScript desde el servidor. Si un atacante consiguiera ejecución persistente de código en el host, en teoría podría intentar alterar esos archivos para capturar contraseñas en futuros inicios de sesión. Mitigamos este riesgo mediante políticas estrictas de CSP (Content-Security-Policy), imágenes de contenedor inmutables y control de integridad de recursos. No obstante, ningún cifrado en el cliente puede evitar que un servidor totalmente comprometido intente servir código manipulado a visitantes posteriores.
La conclusión clave: El cifrado de extremo a extremo transforma lo que habría sido una brecha devastadora e irreversible de todo el histórico en un incidente de mantenimiento ágil y controlado. Todo lo registrado en el pasado permanece matemáticamente seguro; parchear el servidor de inmediato preserva la integridad de las sesiones venideras. Ambas defensas son imprescindibles.
Cómo actualizar tu servidor autohospedado (Paso a paso)
Si autohospedas encrypted1on1 con nuestra configuración oficial de Docker, el proceso toma menos de dos minutos y no requiere migraciones de datos ni ajustes de configuración.
Paso 1: Descargar la imagen base corregida.
El script de despliegue construye el contenedor de la aplicación, pero Docker puede reutilizar la capa base almacenada en caché local. Hacer un pull explícito garantiza descargar la versión limpia de PHP 8.5.12:
docker pull dunglas/frankenphp:php8.5Paso 2: Reconstruir y desplegar.
Ejecuta el script de despliegue estándar desde la raíz de tu proyecto:
PROD_COMPOSE_FILE=docker-compose.prod.yml ./docker/prod/deploy.sh(O simplemente ./docker/prod/deploy.sh si tu entorno ya define el archivo compose).
El script compila automáticamente la imagen con tu código actual, recrea el contenedor, ejecuta migraciones, actualiza la caché del contenedor y realiza una comprobación interna de salud.
Nota: No es necesario hacer git pull del código de la aplicación si únicamente deseas aplicar el parche de seguridad. Reconstruir sobre la nueva imagen base es suficiente.
Paso 3: Verificar la versión de PHP en el contenedor.
Comprueba la versión activa dentro del contenedor:
docker compose -f docker-compose.prod.yml --env-file .env.prod exec app php -vDebe indicar PHP 8.5.12 (o superior).
Si ejecutas encrypted1on1 directamente sin Docker, actualiza los paquetes de PHP mediante el gestor de tu sistema operativo y reinicia el proceso de ejecución (worker de FrankenPHP o PHP-FPM) para desalojar el binario antiguo de memoria.
Reflexión final: Confía en las matemáticas, no en promesas
Las vulnerabilidades de seguridad continuarán presentándose en el futuro: en PHP, en el kernel de Linux, en OpenSSL o en los motores de navegación. Ningún creador de software puede prometer con seriedad que sus servidores nunca correrán código vulnerable durante una ventana temporal.
Lo que sí podemos garantizar —y lo que nuestro código abierto te permite verificar de primera mano— es que el diálogo confidencial entre las personas de tu equipo no depende de la supuesta infalibilidad de un servidor. Cuando la infraestructura flaquea, las matemáticas mantienen la línea.
Si tienes preguntas sobre este parche o sobre la arquitectura de cifrado, te invitamos a participar en GitHub.