Este artículo va dirigido a: personas que crearon un proyecto en CAMPFIRE, apoyaron uno, recibieron un reembolso o se registraron como socios; y a desarrolladores y operadores que usan GitHub y la nube en el trabajo. Este artículo se basa en los avisos oficiales de CAMPFIRE y no describe técnicas de ataque.
Qué deben hacer ahora los usuarios
Compruebe si está afectado: el correo de notificación tiene un asunto fijo
Desde el 24 de abril de 2026, la empresa envía correos individuales a las personas afectadas, con el asunto en japonés "【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告" (disculpas e informe sobre una posible filtración de información de clientes). Los grupos afectados son:
- Algunos propietarios de proyectos y comunidades que usaron el servicio hasta el 9 de abril de 2026
- Patrocinadores que pagaron con PayPal (1 de enero de 2021 – 19 de abril de 2026) o con el pago diferido Kondo-barai (3 de enero de 2022 – 24 de abril de 2023)
- Patrocinadores que recibieron reembolsos por transferencia bancaria (6 de enero de 2022 – 5 de marzo de 2026)
- Socios registrados hasta el 5 de marzo de 2025
- Personas que editaron los datos bancarios en la página de su cuenta en 2020
Si encaja en alguno de estos grupos pero no encuentra el correo, siga igualmente los pasos.
No abra enlaces en mensajes sobre reembolsos o cuentas de pago
Los datos en riesgo son nombre, dirección, número de teléfono, dirección de correo electrónico y datos de cuenta bancaria. Si recibe mensajes como «vuelva a registrar su cuenta para recibir su reembolso» o «confirme a dónde debemos enviar sus fondos», no abra el enlace; si es necesario, inicie sesión en CAMPFIRE desde un marcador o escribiendo usted mismo la dirección. La empresa afirma que nunca pide PIN por teléfono ni por correo electrónico (conceptos básicos: qué es el phishing).
Revise sus extractos bancarios
La empresa afirma que los datos bancarios que podrían haberse filtrado no pueden, por sí solos, utilizarse para retirar efectivo ni realizar transferencias. Pide que se ponga en contacto de inmediato con su banco o con la empresa si ve transacciones desconocidas. Si usa banca en línea, activar las notificaciones de transacciones facilita esta revisión.
Rechace paquetes contra reembolso que no esperaba
Como se incluyen direcciones, la empresa advierte sobre estafas que envían paquetes contra reembolso que usted nunca pidió. Compruebe el remitente y el contenido antes de aceptarlos.
Cambie las contraseñas reutilizadas en otros servicios
La empresa pide que quienes usen la misma dirección de correo electrónico y contraseña en otros servicios las cambien como medida de precaución. Las contraseñas no están entre los datos enumerados, pero deje de reutilizarlas ahora; un gestor de contraseñas es la forma práctica de hacerlo.
Propietarios de proyectos: informen también a su equipo
Si una empresa o un grupo gestiona su proyecto, el personal puede recibir correos que se hacen pasar por avisos de pago o de revisión. Acuerden en equipo verificar los cambios en la cuenta de pago desde el panel de CAMPFIRE y nunca actúen solo siguiendo instrucciones recibidas por correo electrónico.
La línea dedicada de la empresa es el 0120-188-070 (de 10:00 a 19:00 JST, solo días laborables desde julio; gratuita dentro de Japón), y en Japón la línea de consulta policial #9110 atiende las preocupaciones por fraude.
Qué ocurrió (según los avisos de CAMPFIRE)
La empresa publicó una serie de avisos desde el 3 de abril de 2026 hasta su informe de investigación del 2 de junio. Todo lo que se indica a continuación figura en los avisos oficiales de la empresa.
2 de abril de 2026, ~22:50 JST
Se identificó un acceso no autorizado de un tercero a la cuenta de GitHub utilizada para la gestión del sistema, y es posible que parte del código fuente haya sido visto (según el primer aviso).3 de abril
Se detectaron operaciones sospechosas en algunos repositorios de GitHub; se eliminaron las cuentas relacionadas y se sustituyeron las credenciales posiblemente robadas. Se publicó el primer aviso (en ese momento no se confirmó ninguna filtración de datos personales).7 de abril
Se identificó la causa de la filtración de la credencial de GitHub.14 de abril
Segundo aviso: la cuenta de GitHub pudo ver el nombre y los datos de contacto de un socio comercial, así como los nombres y las direcciones de correo electrónico de 413 personas que trabajaron en desarrollo. Se notificó a la Comisión de Protección de Información Personal de Japón.20 de abril
Se detectó un acceso no autorizado a un entorno de nube utilizado para negocios internos; las cuentas y recursos utilizados indebidamente se detuvieron y desactivaron.22–24 de abril
El tercer aviso informó de indicios de acceso no autorizado en parte de un sistema que gestiona información de clientes. El cuarto aviso (24 de abril) dio a conocer el alcance de la posible filtración (225.846 registros únicos de usuarios afectados) y comenzaron las notificaciones individuales.27–28 de abril
El quinto aviso precisó el desglose. El 28 se abrió una línea de consultas específica.30 de mayo / 2 de junio
Se completó la investigación forense externa (30 de mayo). El 2 de junio la empresa publicó los resultados de la investigación y las medidas de prevención.
- Algunos propietarios de proyectos y comunidades
- Nombre, dirección, número de teléfono, dirección de correo electrónico, datos de cuenta bancaria. 108.784 registros (53.869 con datos bancarios)
- Algunos patrocinadores
- Nombre, dirección, número de teléfono, dirección de correo electrónico, datos de cuenta bancaria. 118.010 registros (4.307 con datos bancarios)
- Socios
- Nombre. 1.282 registros
- Categoría poco clara (p. ej., registro en curso)
- Datos de cuenta bancaria de personas que los editaron en la página de su cuenta en 2020. 10.521 registros
- Otros
- 413 registros de nombres y direcciones de correo electrónico relacionados con trabajos de desarrollo fueron visibles
- Datos de tarjetas de crédito
- No incluidos
- Hallazgos forenses
- Se obtuvieron credenciales y claves de API almacenadas en un entorno de nube específico, algunos archivos de datos sin información personal, y nombres de tablas e información de configuración. Durante la exploración, un registro con datos personales se mostró como resultado de una consulta. No se encontraron indicios de que archivos con datos personales hubieran sido transferidos fuera
- Evaluación de la empresa
- Como en algunas áreas no se recopilaron registros, no puede descartar que se hayan visto datos
- Daño secundario
- En el momento de los avisos no se había informado de ningún daño derivado del uso indebido de los datos
Para desarrolladores y operadores: del token de GitHub a la nube interna
El informe del 2 de junio de la empresa es inusualmente específico sobre la secuencia y la causa. La figura muestra la ruta tal como la describió la empresa, con la configuración que impide o limita el daño en cada etapa a la derecha.
1. Credencial de GitHub emitida a un empleado
Subida involuntariamente a un servidor de proyectos personales
↓→
Política de la organización: bloquear tokens clásicos, limitar la duración
2. Repositorios de la organización
Parte del código fuente y datos de 413 empleados visibles
↓→
Permisos predeterminados mínimos, sin datos personales en los repositorios
3. De la información de GitHub a las credenciales de la nube
↓→
Sin claves de nube de larga duración (usar autenticación de corta duración)
4. Parte del área de gestión de la nube interna
Se obtuvieron credenciales, claves de API y nombres de tablas
↓→
Registros de auditoría en todas partes, alertas ante acciones inusuales
5. Datos de clientes en 225.846 registros únicos de usuarios afectados en riesgo
↓→
Inventariar los datos de clientes fuera de producción
Según la empresa, el servicio funciona en un entorno separado del entorno de nube donde se encontró el acceso no autorizado, y no se identificó ningún uso indebido ni manipulación de la plataforma de servicio. Aun así, los datos de los clientes quedaron en riesgo porque se podía acceder a ellos desde la nube comercial interna.
La empresa afirma que la credencial en cuestión solo debía manejarse en entornos bajo su control y con los permisos mínimos necesarios, y que sus mecanismos y reglas para la gestión de credenciales y el diseño de permisos eran insuficientes. Las medidas que la empresa afirma haber completado incluyen:
- Dejar de depender de tokens de acceso personal y pasar a métodos de autenticación con permisos limitados
- Revisar los permisos de acceso predeterminados dentro de la organización
- Reforzar la recopilación de registros de auditoría y las alertas
- Introducir una herramienta de análisis de vulnerabilidades en el código
Si quiere hacer lo mismo en su organización, empiece por estas tres.
Establezca una política de tokens de acceso personal en su organización de GitHub
En la configuración de la organización, «Personal access tokens», GitHub permite a los propietarios de la organización:
- Impedir que los tokens de acceso personal (clásicos) accedan a los recursos de la organización
- Exigir la aprobación de un administrador para los tokens de grano fino (el tipo más reciente, limitado a repositorios y permisos específicos)
- Definir una duración máxima de los tokens
Como nunca se puede impedir por completo que un token de trabajo acabe en un equipo o servidor personal, la defensa realista es asegurarse de que, si eso ocurre, deje de funcionar pronto y pueda acceder a muy poco.
Mantenga las claves de nube de larga duración fuera de sus repositorios
La empresa afirma que el tercero utilizó la información visible en GitHub para encontrar y obtener credenciales de la nube. Si GitHub Actions despliega en su nube, cambie a autenticación de corta duración mediante OpenID Connect (OIDC), que emite credenciales temporales para cada ejecución, y mantenga las claves de acceso de larga duración fuera de los repositorios y de los archivos de configuración.
Primero revise sus repositorios, incluido el historial, y revoque y reemita cualquier clave que encuentre; consulte cómo detectar secretos antes del commit con gitleaks. La protección de push de GitHub, que bloquea los envíos que contienen secretos, es gratuita para repositorios públicos y está disponible para privados como parte de GitHub Secret Protection de pago.
Anote todos los lugares donde se guardan datos de clientes fuera de producción
Plataformas de análisis, herramientas internas, paneles de administración de soporte, CSV exportados. Por muy bien protegida que esté la producción, una copia de los datos de clientes en otro entorno puede seguir filtrándose. Para cada ubicación, registre quién tiene credenciales para leerla y si las operaciones quedan registradas.
CAMPFIRE afirma que no puede descartar que se hayan visto datos porque algunas áreas no tenían registros. Cuando no hay registros de operaciones, no se puede demostrar que nadie haya visto los datos.
Opinión de este sitio: diseñe los tokens suponiendo que saldrán de los equipos de la empresa
La empresa afirma que una credencial de GitHub emitida a un empleado se subió involuntariamente a un servidor que el empleado usaba para desarrollo personal. Esto no se trata de una persona en concreto; refleja algo que es cierto en cualquier organización: los desarrolladores también escriben código fuera del trabajo. No se puede reducir a cero la probabilidad de que un token de trabajo salga de los equipos gestionados. Por eso, evitar las filtraciones no basta; los tokens deben diseñarse para que, si alguno se filtra, caduque rápidamente y pueda acceder a muy poco.
En Corea del Sur, en el mismo año, la clave de acceso de un solo desarrollador bastó para llegar a todo el código fuente y a las credenciales de producción de TVING (la brecha de datos de TVING). La vía de entrada común en los incidentes japoneses de ese año se explica en las brechas de 2026 se produjeron con credenciales legítimas.
Fuentes (registro público)
Los hechos de este artículo se basan en las siguientes fuentes públicas. No especulamos sobre métodos no revelados.
- CAMPFIRE, Inc., aviso de acceso no autorizado a una cuenta de GitHub (3 de abril de 2026; en japonés) — campfire.co.jp
- Ídem, segundo aviso (14 de abril de 2026) — campfire.co.jp
- Ídem, tercer aviso (22 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., disculpas e informe sobre una posible filtración de datos personales por acceso no autorizado (24 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., seguimiento sobre el alcance de la posible filtración (27 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., apertura de una línea de consultas específica (28 de abril de 2026) — campfire.co.jp
- CAMPFIRE, Inc., resultados de la investigación del incidente de acceso no autorizado (2 de junio de 2026) — campfire.co.jp
- GitHub Docs, «Setting a personal access token policy for your organization» — docs.github.com / «About push protection» — docs.github.com / «About security hardening with OpenID Connect» — docs.github.com
Historial de actualizaciones
2026-10-19: Se corrigió la unidad de personas al recuento oficial de registros de usuarios únicos, se distinguió la posible exposición de los hallazgos confirmados y se conservaron las categorías que se solapan sin sumarlas.
2026-09-30: Primera publicación, basada en los avisos de CAMPFIRE desde el primer aviso del 3 de abril de 2026 hasta el informe de investigación del 2 de junio. Los recuentos de registros siguen el desglose del informe del 2 de junio.
Lecturas recomendadas
- Otro caso japonés de este año: Medica Shuppan (datos bancarios de profesionales médicos y autores)
- Estafas derivadas: qué es el phishing / cómo elegir un gestor de contraseñas
- Desarrolladores: cómo detectar secretos antes del commit con gitleaks / Git autohospedado frente a la seguridad de GitHub / nociones básicas de .env y claves de API
- Mismo patrón: brechas que se produjeron con credenciales legítimas / la brecha de datos de TVING
- Otros incidentes de 2026: brechas de datos y ciberataques en 2026