Auditamos NEXIA Switch de forma continua con nuestra propia herramienta de pruebas de intrusión, sobre un servidor de laboratorio aislado. Cuando encontramos un hueco lo cerramos, lo verificamos y añadimos una prueba de regresión que impide que reaparezca — y recién entonces lo publicamos acá.
Por qué contamos esto. La seguridad no se demuestra
diciendo “somos seguros”, sino mostrando cómo respondemos. Cada
entrada de abajo es un problema que ya no existe en tu instalación, con la fecha
en que se cerró. No publicamos detalles que sirvan para explotar nada: solo el
qué, el arreglo y la garantía de que no vuelve.
Cómo trabajamos cada hallazgo
| Paso | Qué hacemos |
|---|---|
| 1 · Hallazgo | Lo reproducimos en el laboratorio aislado y le asignamos severidad. |
| 2 · Parche | Corregimos la causa raíz, no el síntoma. |
| 3 · Regresión | Sumamos una prueba automática o una regla que detecta el problema si alguien lo reintroduce. |
| 4 · Publicación | Documentamos acá el qué y el arreglo, sin receta de explotación. |
Registro de parches
2026-08-10 · Esquema de la API expuesto (severidad media)
- El problema. El documento OpenAPI (
/openapi.json) se servía sin autenticación. No filtra datos de clientes ni credenciales, pero sí el mapa completo de endpoints y parámetros de la API — información que un atacante usa para preparar su ataque. La interfaz interactiva (/docs,/redoc) ya estaba deshabilitada; faltaba el esquema crudo. - El parche. Se bloqueó la ruta en el borde (nginx), de modo que
responde
404desde internet. El panel y la API siguen funcionando igual; solo se retiró la exposición del esquema. - La regresión. El bloqueo quedó incorporado al instalador, así que toda
instalación nueva o actualizada nace con la ruta cerrada. Nuestra herramienta de
auditoría verifica en cada corrida que responda
404.
¿Creés que encontraste un problema de seguridad? Escribinos a
support@nexianetworks.com. Respondemos y, si aplica, lo verás publicado
acá una vez parcheado.