Reportan Hackeo del Registro Civil de Chile de datos de 10 millones de personas

Foro web publicó el 15 de diciembre el acceso a una base de datos que habría sido robada desde el Registro Civil de Chile. Esta institución no ha dado información oficial al respecto, y desde el perfil de X (Twitter) se niega que la base de datos pertenezca a ese servicio. Hemos analizado la filtración y el origen de los datos parece ser otro.

Reportan Hackeo de datos del Registro Civil

El 15 de diciembre de 2025 se publicó el acceso a una base de datos que habría sido robada desde el Servicio de Registro Civil e Identificación (Registro Civil) dependiente del Ministerio de Justicia y Derechos Humanos del Gobierno de Chile. La información se compartió en un foro web por parte de un perfil creado recientemente en diciembre de 2025.

La información se compartió gratuitamente en un único archivo que contiene datos de más de 10.500.000 personas, aparentemente de nacionalidad chilena y extranjera.

¿Qué datos fueron hackeados?

La información compartida posee los siguientes datos:

• Rol Único Nacional (RUN, llamado RUT)
• Nombre completo
• Fecha de nacimiento
• Marcas de tiempo del registro o extracción de los datos

El archivo compartido NO contiene datos biométricos (como huellas dactilares, reconocimiento facial, etc.), claves o contraseñas (como clave única) ni ningún otro dato similar.

¿De qué fecha son estos datos?

El archivo filtrado tiene valores de marcas de tiempo del supuesto registro (por parte del servicio) u obtención (por parte de los hackers) de los datos.
Todas las fechas pertenecen a un único día del mes de marzo del año 2020, fecha en la que probablemente se generó esa base de datos filtrada o fecha en que se generó.

Aunque fue compartido el 15 de diciembre de 2025, el archivo filtrado tiene fecha del mes de octubre del año 2025.

¿De dónde se obtuvieron estos datos?

Se ignora el origen de estos datos: si salieron del registro Civil o de otras fuentes gubernamentales o de un servicio privado.

Hasta el momento no hay comunicación oficial del Registro Civil, pero desde su cuenta de X (Twitter) este servicio ha dado respuesta a consultas indicando que la base de datos difundida no correspondería a ese servicio.

El principal argumento dado es que la base de datos identifica el Rol Único Nacional (RUN) como «rut»; en el caso del registro Civil usarían «run».

¿Son reales estos datos?

Se ha podido comprobar que las fechas de nacimiento y «rut» coinciden con los nombres de personas conocidas. Por ejemplo:

Sin embargo, no hay seguridad de la integridad de todos los datos, es decir de la certeza de que la información es «precisa, completa, consistente y válida» y que no hayan sido alterados voluntaria o involuntariamente.

Esto se confirma con varios «errores» encontrados en esta base de datos filtrada

Errores de integridad en los datos filtrados

Hay varios errores en los campos relaciones con el nombre completo y con la fecha de nacimiento.

Fechas de nacimientos recientes erróneas

Se encuentran en la base de datos fechas de nacimiento que contienen los años 2018, 2019 y 2020, es decir personas que habrían nacido reciéntemente. Sin embargo, muchos de estos datos NO coinciden con los RUN que debería ser, al menos mayor a 20.000.000. Es decir, para esas personas, la «fecha de nacimiento» no coincide con la real.

Fechas de nacimientos futuras

Según los datos del campo «timestamp», se puede afirmar que toda esta base de datos se creó en menos de una hora de un día de marzo del año 2020.
Hay «fechas de nacimiento» posteriores a esa fecha, lo cual no sería posible.
(No hay «fechas de nacimiento» para años posteriores al 2020).

Además, tampoco estas fechas se corresponden con el RUN/edad real de la persona.

Fechas de nacimiento con valor 0

Para al menos 2,5 millones de personas (casi el 25% de la base de datos) se registra un valor de 0 para su fecha de nacimiento.
Podría corresponder a personas extranjeras que al no nacer en Chile tienen ese valor. Sin embargo, pudimos confirmar que varias de esas personas sí nacieron en Chile.

Fechas de nacimiento nulas o desconocidas

Para 8.046 personas su año de nacimiento es 1917.
Para 2.300 personas su fecha de nacimiento es «19170101», es decir el 1 de enero de 1917.
La frecuencia esperada es de 22 personas por cada día del año 1917, sin embargo la frecuencia del 1 de enero es casi 100 veces eso: 2.300.

El 19170101 puede corresponder realmente a un «Default Value» asociado a personas de las que no se tenía información de la fecha de nacimiento, por tanto el sistema devolvía este valor.

¿Por qué este año? Probablemente el origen de estos datos (de esas 2.300 personas) fue creado el año 2017 y al programador le pareció que el valor mínimo a entregar era el año 1917, 100 años atrás.

Nombres con valor «Fonasa» o «Isapre»

Existen 398 personas que tienen «Fonasa» en su nombre; mientras que los nombres de 139 personas contienen»Isapre».
Coincidentemente, estas personas NO tienen su nombre completo, y «Fonasa/Isapre» está reemplazando:

• uno de sus nombres
• ambos nombres
• uno de sus apellidos
• nombres completo

De hecho, los nombres de algunas personas incluyen el nombre de la isapre, por ejemplo «Isapre Cruz Blanca S.A.» o  «Isapre Banmedica S.A.». En estos casos, no aparece ninguno de sus nombres ni apellidos.

Errores de codificación de caracteres

Varios nombres aparecen completos y muestran correctamente letras ñ y vocales con tilde.
Sin embargo, otros muestran Ñ mayúsculas, Ñ erróneas (\\Ufffd\..) y problemas al codificar tildes.

La razón más probable de estos «errores» es que la base de datos filtrada se construyó a partir de varias fuentes (no una única base de datos de un organismo) o, más precisamente, usando un integrador.

Los datos filtrados probablemente fueron obtenidos a partir de la explotación de un «Integrador» (Middleware) de datos del sistema de salud de personas residentes en Chile el año 2020

Según el LLM Gemini (IA de Google), «en Chile existen servicios (como I-Med, Cajas de Compensación o Portales de Licencias Médicas) que actúan como un «hub» cuando se les entrega un dato como el RUT/RUN». Estos servicios responden informando, por ejemplo, si una persona (mediante el RUN) está en Fonasa, en Isapre o si no está registrado.

Esto explicaría por qué varios datos tienen errores de formatos y de valor, ya que el integrador toma datos de diferentes fuentes, que tienen sus propios formatos. El integrador está correctamente programado para mostrar todos estos datos de forma homogénea, pero el bot del hacker atacante no fue tan finamente programado.

Por esto algunos «nombres» y «fechas de nacimiento» contienen valores erróneos, porque probablemente el bot programado obtuvo un dato (parámetro o ítem) diferente; como el de una persona que no está en los registros (valores 0 o 19170101); o la afiliación de salud (fonasa o Isapre) en lugar del nombre, del apellido o del nombre completo.

La razón que da fuerza a esta idea es que la base de datos no cumple con el formato JSON, que debe respetar pares de clave:valor (ejemplo «nombre»:»Nombre Completo») y contiene un valor para el cual no hay una clave. Esto se ve al final del valor de la clave «rut» en donde tienen (todos los datos) asociados estos valores:

• 0
• 1
• null

Se ha encontrado 0, 1 y null para personas vivas, muertas; para hombres y mujeres de diferentes edades; y para Fonasa o Isapre.

Lo que podría significar estos valores es la capacidad de la persona en ese momento de comprar o no un bono de salud:

• 0 significaría que NO puede, porque es Fonasa A o porque es una carga familiar
• 1 significaría que SÍ puede
• null significaría que no está en la base de datos porque: es niño, es extranjero sin registro o porque no está en ningún sistema de salud.

Por lo tanto, a la espera de información oficial, quien construyó esta base de datos en marzo de 2020 parece haber explotado un integrador como el de un validador de bonos o licencias médicas, de una empresa o institución estatal del sector salud o de la superintendencia de Salud, inyectando 10 millones de RUN y obteniendo este cúmulo de datos que no tiene un único formato y que contiene errores.

No sería, por tanto, una única base de datos robada a algún servicio, sino que es un Frankenstein de datos robados gracias a una vulneración explotada en ese momento.