Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2025-56800 — Vulnerabilidad de omisión de autenticación local en la aplicación de escritorio de Reolink | Kitploit
Herramientas/GitHubGitHub/shinycolumn/cve-2025-56800
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónAutenticación
GitHubshinycolumn/cve-2025-56800

CVE-2025-56800

Vulnerabilidad de omisión de autenticación local en la aplicación de escritorio de Reolink

Ver Repositorio
hace 10 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2025-56800

Vulnerabilidad de omisión de autenticación local en la aplicación de escritorio de Reolink

1. Resumen

Reolink Icon
  • Nombre: Aplicación de escritorio de Reolink
  • Versión: 8.18.12
  • Vendedor: Reolink
  • CWE: CWE-290: Omisión de autenticación mediante suplantación
  • CVSS: 5.1 MEDIO
  • Cadena de vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

2. Resumen

La aplicación de escritorio de Reolink (versión 8.18.12) contiene una vulnerabilidad de omisión de autenticación local en su función de pantalla de bloqueo. El código fuente de la aplicación no está empaquetado en un archivo ASAR, lo que deja la lógica de autenticación crítica, como la verificación de contraseña, expuesta en texto plano dentro de los archivos JavaScript del lado del cliente. Simplemente modificar la lógica en este código expuesto es suficiente para neutralizar la comprobación de contraseña y omitir la pantalla de bloqueo.

3. Detalles

La contraseña de la pantalla de bloqueo se almacena y se recupera mediante código JavaScript en el paquete de recursos local, específicamente:

root@kitploit:~
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js

El código relevante registra un controlador para el comando get_settings_lock_screen_password, que devuelve la contraseña almacenada de la propiedad a.settingsManager.lockScreenPassword:

root@kitploit:~
this.registerCommonCmd(
  "get_settings_lock_screen_password",
  "",
  R(function () {
    return N(this, function (e) {
      return [2, a.settingsManager.lockScreenPassword];
    });
  }),
);

Dado que esta lógica reside completamente en el lado del cliente, un atacante puede modificar el valor de retorno a "" (una cadena vacía), omitiendo efectivamente la pantalla de bloqueo:

root@kitploit:~
return [2, ""];

Después de modificar y guardar este archivo, la aplicación tratará la pantalla de bloqueo como si no tuviera contraseña, otorgando así acceso sin ninguna autenticación.

Esta vulnerabilidad permite que cualquier atacante local con acceso al sistema de archivos omita la autenticación a nivel de aplicación y obtenga acceso completo a la interfaz y la configuración de la aplicación.

Dado que la contraseña no se valida contra ninguna fuente externa y está expuesta mediante JavaScript modificable, esta pantalla de bloqueo no ofrece protección real.

4. Prueba de concepto (PoC)

El contenido del código puede ser manipulado ejecutando poc.py.

La siguiente captura de pantalla muestra la pantalla de bloqueo de la aplicación Reolink antes del parche, con una solicitud de contraseña habilitada: PoC La siguiente captura de pantalla muestra la aplicación después de aplicar el parche y reiniciarla, sin que se muestre ninguna solicitud de contraseña: PoC

5. Recomendaciones

El código de la aplicación debe empaquetarse en un archivo ASAR, y debe implementarse un proceso de verificación de integridad, como comprobar el valor hash o la firma del archivo ASAR, al iniciar. Cualquier aplicación que haya sido manipulada debe bloquearse para que no se ejecute.

La lógica de autenticación crítica, como la verificación de contraseña de la pantalla de bloqueo, debe manejarse dentro del código binario nativo, que es más difícil de manipular, en lugar de en JavaScript, siempre que sea posible, o procesarse mediante comunicación del lado del servidor.

6. Referencias

  • https://www.cve.org/CVERecord?id=CVE-2025-56800
  • https://nvd.nist.gov/vuln/detail/CVE-2025-56800
Descargar herramienta