Tras una filtración de variables de entorno, por qué la clave nueva no debe volver al chat

A finales de agosto de 2026, la plataforma de despliegue Zeabur publicó un incidente titulado «Unauthorized Access to Project Environment Variable Data». La página oficial de estado indica que el atacante usó una credencial administrativa interna de AWS filtrada, llegó a la base de datos principal y lanzó consultas y exportaciones dirigidas contra las Variables de los proyectos. El objetivo declarado eran claves API de servicios de IA y otras credenciales que se pueden usar en el acto.

La misma página enumera nombres de clave expuestos, entre ellos OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, DATABASE_URL, AWS_ACCESS_KEY_ID, además de formas habituales de JWT, Stripe y GitHub. Los nombres personalizados también contaron como expuestos cuando el valor coincidía con esos formatos. Zeabur pidió a los afectados que revocaran y sustituyeran las credenciales listadas y que revisaran el uso y los cargos de terceros. Una captura que circuló sobre un «dataset completo a la venta» se trata como no verificada: la página de estado dice que las pruebas que tienen no respaldan esa afirmación, y este artículo no la da por hecha.

En incidentes así, el botiquín es siempre el mismo: revocar la clave vieja, mirar el consumo, rotar a una nueva. La primera filtración ya ocurrió en el host. No puedes sacar una cadena de las manos de otra persona. El paso que los equipos se saltan es el segundo: cuando la consola del proveedor imprime una clave nueva, alguien tiene que dársela a un compañero, pegarla en otra máquina o dejarla en un ticket temporal. Si ese salto es una ventana de chat, el «texto en claro recién rotado» queda escrito en un registro que se busca, se sincroniza y que un administrador puede exportar.

El nombre de la plataforma solo ancla una fecha y un registro público. La conclusión vale para cualquier entrega «primero rota, luego pasa»: contraseñas de base de datos, tokens de CI, una contraseña SSH temporal. El peligro no es que el compañero vea el secreto. El peligro es que cada salto puede quedarse con una copia completa en claro. Este artículo no reconstruye el plan de endurecimiento de un host, ni vende UsePwd como una caja fuerte que habría evitado la lectura en el lado del proveedor.

Pega en un canal una cadena que empiece por sk- y aparecen varias copias a la vez. El cuerpo del mensaje entra en el historial del espacio de trabajo. El cliente de escritorio y el del móvil guardan cada uno su caché. Muchos productos además mandan el texto a un índice de búsqueda en el servidor, para que dentro de tres meses alguien escriba «openai» y lo recupere. Las exportaciones de administrador, las retenciones legales y el «empaqueta el archivo del chat» al dar de baja a alguien se llevan ese texto en claro. Borrar una burbuja casi nunca borra la notificación que el otro ya leyó, una biblioteca de cliente descargada, ni el fotograma que una herramienta de captura ya guardó.

Eso no es lo mismo que «confío en mi compañero». El compañero necesita la clave nueva para que el servicio vuelva a arrancar. El canal, por defecto, guarda un registro de trabajo recuperable, no un secreto que debería existir solo mientras se lee. Escribir «clave nueva abajo» en un canal es también un aviso para todo el que pueda buscar ahí más tarde: gente que entre el trimestre que viene, quien tenga permiso de exportación de auditoría y quien en el futuro alcance una copia de seguridad. Las guías de escaneo de secretos lo tratan como una vía conocida de dispersión; la ayuda en español de Anthropic sobre claves API insiste en no compartirlas en claro y en rotarlas si se han visto comprometidas. Slack, por su parte, documenta reglas de prevención de pérdida de datos que escanean tokens de API precisamente porque el historial del canal los retiene.

Extiende un runbook de emergencia sobre la mesa y el peligro no es «entrar en la consola del proveedor y generar una clave nueva». Son los pasos alrededor de ese clic. Alguien captura la clave vieja y pregunta a un compañero «¿es esta?». Alguien hace una captura de toda la consola, así que la barra de direcciones, otros nombres de proyecto y una cifra de facturación aterrizan juntos en Fotos. Alguien genera la clave nueva, el compañero no está en el puesto, y el canal recibe un «úsalo ya». Las tres convierten el texto en claro en un objeto que se va a conservar.

Las unidades compartidas y git se escapan más. Un .env en crudo en una carpeta de equipo, o un commit de ejemplo que todavía lleva una clave, es otra copia. La sincronización en la nube escribe ese archivo en cada dispositivo con sesión. Cambiar el archivo después no borra la cadena de commits antiguos. Una copia local de un solo archivo de hasta 5 GB debería convertirse en texto cifrado en la pestaña actual antes de guardarse, en lugar de subir un .env en claro como un documento cualquiera. Cifrar archivo de UsePwd hace cifrado local por flujo con AES-256-GCM y escribe .lock / .enc. El archivo no se sube por defecto. Eso es «quédate tú un archivo cifrado», no «mete la clave en el chat».

Una ventana de chat entrega texto en claro. Copiar es fácil en ambos lados. El coste es que el espacio de trabajo, el índice de búsqueda y las copias de seguridad tienen cada uno una copia. Los adjuntos de correo funcionan igual: en cuanto un .env o un bloc de notas viaja como adjunto, el servidor de correo y ambos clientes tienen el archivo completo.

Un enlace cifrado de un solo uso entrega «un identificador de texto cifrado más material de descifrado que se queda en el dispositivo». El enlace de un solo uso de UsePwd cifra el texto en la pestaña actual con Web Crypto y AES-256-GCM, y solo envía texto cifrado al servidor. La clave de descifrado se añade después de # en s.html?id={id}#{key}. Crear y leer funcionan al instante: ninguna de las dos partes se registra. El servidor guarda texto cifrado, un TTL en horas y un recuento de lecturas. No ve el texto en claro, y no hay un sistema de cuentas que pueda «recuperarlo por usuario».

Poner la clave después de # atiende los registros de acceso del host y la línea de petición HTTP: el navegador no envía el fragmento como parte de la petición. Esa capa se desglosa en Por qué el fragmento # de una URL no aparece en los registros del servidor. Este artículo cubre la capa siguiente. Aunque la clave no entre en una línea de petición de UsePwd, pegar el enlace completo en el chat sigue guardando la dirección entera en ese producto. Quien tenga la URL completa puede abrir la página de lectura y descifrar hasta agotar el recuento. El enlace de un solo uso limita cuánto vive el texto cifrado en el servidor y cuántas veces se puede leer. No impide que el destinatario haga una captura o reenvíe el enlace.

Si el secreto debe guardarse mucho tiempo, sincronizarse entre dispositivos o recuperarse más adelante, no uses el enlace de un solo uso y no trates el historial del chat como una caja fuerte. Eso es trabajo de un gestor de contraseñas. UsePwd no ofrece cuentas ni almacén. Cuando se agota el recuento, o si se pierde el enlace, no puede restaurar el secreto por ti.

Si el secreto es una clave maestra de alto valor, un certificado raíz o una semilla de monedero que puede mover fondos, ni un enlace ni un canal de chat bastan. Dilo en persona, usa un medio sin red, o quédate en un canal de extremo a extremo que ya tengáis establecido. Un esquema de fragmento no detiene un equipo ya comprometido, una extensión del navegador que pueda leer la pestaña actual, ni una URL completa proyectada en la pared de una sala de reuniones.

La copia de un archivo es otro camino: convierte un .env en claro en .lock / .enc en esta máquina y luego pon el texto cifrado en una unidad. Pasa la contraseña de desbloqueo por un canal que no sea el archivo mismo. No comprimas las dos herramientas en una sola promesa. El enlace de un solo uso gobierna cuántas veces se puede leer un secreto corto. Cifrar archivo gobierna un archivo cifrado que tú te quedas.

Volvamos a la pregunta. Cuando vacían las variables de entorno de una plataforma cloud, las claves viejas hay que revocarlas. No hay atajo. La clave nueva no debe volver a una ventana de chat porque el chat, por defecto, guarda texto en claro que se busca, y el sentido de rotar es que la cadena vieja muera al momento: no deberías gastar el mismo minuto en fabricar una copia que va a vivir más. Cuando un compañero la necesita una vez, usa el enlace de un solo uso: cifrado en local, ábrelo al instante. Cuando necesitas una copia que guardas tú, usa Cifrar archivo. Ambas páginas, como este artículo, solo tienen el selector de idioma a la derecha de la barra superior. No hay inicio de sesión.