Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Desarrollador afirma que Claude Opus 5 borró una base de datos de producción en minutos


Un desarrollador informó que Claude Opus 5 de Anthropic, operando en modo Ultracode, borró accidentalmente una base de datos de producción completa en aproximadamente diez minutos mientras trabajaba en un proyecto web personal. El incidente ocurrió cuando el desarrollador reconstruía páginas de comparación y conectó la IA directamente a una instancia de Supabase.




Un desarrollador ha informado que Claude Opus 5 de Anthropic, funcionando en modo Ultracode, borró accidentalmente toda una base de datos de producción en aproximadamente diez minutos mientras trabajaba en un proyecto web personal.

Según la publicación de Reddit, el incidente ocurrió mientras el desarrollador reconstruía páginas de comparación y conectó Claude Opus 5 directamente a una instancia de Supabase con acceso amplio. Se le instruyó al agente de IA que analizara el repositorio de GitHub del proyecto y ejecutara autónomamente los comandos necesarios para corregir problemas de esquema y contenido.

Durante este proceso, Claude ejecutó un comando de migración de Prisma que apuntaba a la base de datos de producción, lo que resultó en un reinicio que eliminó todas las tablas y vació los conjuntos de datos principales, incluyendo herramientas, usuarios, reseñas, "me gusta" y entradas de comparación.

El registro compartido por el desarrollador muestra a Claude creando progresivamente archivos temporales de TypeScript y ejecutando comandos antes de señalar repentinamente un problema potencial.

Registros compartidos por el desarrollador

Claude Opus 5 borró los datos

Se informa que los mensajes del agente pasaron de actualizaciones de estado rutinarias a mostrar preocupación: “Necesito detenerme y comprobar algo. Es posible que haya causado daños”. Poco después, Claude emitió una alerta clara: “La base de datos ha sido borrada.

Esto es culpa mía, y necesito decírtelo inmediatamente”. En una explicación detallada, el agente afirmó que había ejecutado prisma migrate diff con un --shadow-database-url apuntando a la URL de producción de Supabase.

Debido a que Prisma reinicia la base de datos shadow antes de reproducir las migraciones, esta mala configuración trató efectivamente el entorno en vivo como desechable y desencadenó una reconstrucción completa del esquema desde una carpeta de prisma/migrations desactualizada.

Aunque el proyecto en cuestión fue descrito como de bajo riesgo, con datos en gran parte recreables, la escala del impacto fue significativa. El desarrollador dice que se borraron las 22 tablas, eliminando cerca de 130 herramientas y 21 configuraciones de comparación, mientras que algunas tablas clave como BlogPost y ApiKey desaparecieron por completo porque no estaban representadas en el conjunto de migraciones heredadas.

El desarrollador añadió que la recuperación fue posible gracias a las copias de seguridad existentes y a los datos conservados en otros modelos y fuentes, pero el incidente obligó a una reconstrucción inesperada del contenido del sitio.

La historia ha llamado la atención en línea entre desarrolladores y profesionales de la seguridad, especialmente aquellos que experimentan con agentes de codificación de IA en entornos reales. Muchas respuestas han enfatizado que los asistentes de IA potentes nunca deben conectarse directamente a bases de datos de producción sin un aislamiento estricto y controles de acceso basados en roles.

Las recomendaciones de mejores prácticas incluyen el uso de instancias dedicadas de prueba (staging) o sandboxes, imponer credenciales de solo lectura por defecto y requerir la aprobación humana para cualquier comando que altere el esquema, como prisma migrate, drop o truncate. Otros han señalado la necesidad de planes de ejecución más transparentes, modos de prueba en seco (dry-run) y vistas previas claras de los cambios antes de que los agentes apliquen modificaciones en la base de datos.

Incluso cuando los datos subyacentes son de bajo riesgo, la pérdida repentina de contenido de producción puede interrumpir las operaciones, dañar la confianza y exponer estrategias de respaldo frágiles.

A medida que las herramientas de codificación de IA se vuelven más capaces, las organizaciones que las integren en tuberías de CI/CD, flujos de trabajo de infraestructura como código o tareas de gestión de bases de datos deben tratarlas como cualquier otra cuenta de sistema potente: limítalas a entornos estrictamente delimitados, supervisa sus acciones y asume que cualquier comando que puedan ejecutar, eventualmente lo harán.

Para los lectores que estén explorando Claude Opus 5 o agentes similares, la conclusión clave es clara: mantén tus experimentos en entornos aislados, mantén copias de seguridad robustas y nunca des a una IA libertad total sobre los datos de producción sin múltiples capas de protección y revisión.


Fuentes:
https://cybersecuritynews.com/claude-opus-5-wiped-data/

0 comments :

Post a Comment

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.