Alerta crítica: Se ha publicado la CVE-2026-105223, una vulnerabilidad de severidad CRÍTICA con una puntuación CVSS de 9.1 que afecta a la librería kubernetes-client del desarrollador maclof en versiones desde la 0.17.0 hasta la 0.32.0 (excluida). El fallo reside en la desactivación de la verificación de certificados TLS en las funciones parseKubeconfig() y parseKubeconfigFile() cuando el fichero kubeconfig carece de certificate-authority-data, ignorando además la directiva insecure-skip-tls-verify. Esto permite a un atacante en posición de intermediario (on-path) suplantar al servidor de la API de Kubernetes, capturar credenciales y manipular el tráfico.
Resumen ejecutivo
| Identificador | CVE-2026-105223 |
|---|---|
| Fabricante | maclof |
| Producto | kubernetes-client |
| Fecha de publicación | 2026-10-04 |
| Severidad | CRÍTICA |
| Puntuación CVSS | 9.1 (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N) |
| Prioridad | 205 (según puntuación RyzerBot) |
| Acción recomendada | Revisar el aviso oficial del fabricante y aplicar la actualización o mitigación publicada. La versión 0.32.0 corrige el problema. |
Qué es la vulnerabilidad
La CVE-2026-105223 es una vulnerabilidad de validación incorrecta de certificados, clasificada bajo la categoría CWE-295 (Improper Certificate Validation). El fallo se localiza en la librería kubernetes-client de maclof, un cliente PHP para interactuar con la API de Kubernetes.
El problema aparece en las funciones parseKubeconfig() y parseKubeconfigFile(), responsables de procesar los ficheros de configuración kubeconfig. Cuando dicho fichero no incluye la clave certificate-authority-data (que contiene la autoridad de certificación (CA) del clúster), la librería desactiva por completo la verificación TLS en lugar de aplicar lo que indique la directiva insecure-skip-tls-verify.
Este comportamiento es especialmente grave porque, aunque el administrador haya configurado explícitamente insecure-skip-tls-verify: false (o no lo haya definido, lo que por defecto debería implicar verificación), la librería ignora esa configuración y establece una conexión sin validar el certificado del servidor. En la práctica, cualquier conexión a un clúster cuyo kubeconfig no contenga la CA explícita queda expuesta a un ataque de tipo man-in-the-middle.
El commit correctivo 924c0b935fa538ed6b4b0948127609e99d0e6f34 y la versión 0.32.0 abordan este fallo. La referencia técnica al código vulnerable se encuentra en el archivo src/Client.php, líneas 309-312 de la versión 0.31.0.
La vulnerabilidad fue publicada inicialmente por NVD el 2026-10-04 y posteriormente confirmada por CVE.org el 2026-10-05. La puntuación CVSS de 9.1 refleja el alto impacto en la confidencialidad e integridad de las comunicaciones, aunque el vector requiere cierta complejidad de ataque (AC:H) y la presencia de un atacante en la ruta de red (AT:P).
Es importante destacar que la librería afectada es un componente de terceros utilizado en aplicaciones PHP que se comunican con clústeres de Kubernetes. La explotación exitosa podría comprometer no solo las credenciales de acceso al clúster, sino también la integridad de las operaciones realizadas a través de la API, incluyendo la manipulación de cargas de trabajo o la exfiltración de datos sensibles almacenados en etcd.
El fabricante ha publicado la versión corregida 0.32.0 en el repositorio oficial de GitHub, junto con el commit de parche correspondiente. Se recomienda encarecidamente a los equipos que utilicen esta librería que actualicen a la versión más reciente o apliquen las mitigaciones indicadas en el aviso oficial.
Productos y versiones vulnerables
La vulnerabilidad CVE-2026-105223 afecta a la librería kubernetes-client del desarrollador maclof. Según la información publicada por CVE.org y NVD, las versiones afectadas son las siguientes:
| Producto | Fabricante | Versiones afectadas | Versión corregida |
|---|---|---|---|
| kubernetes-client | maclof | Desde 0.17.0 hasta antes de 0.32.0 | 0.32.0 |
La versión 0.32.0 incluye la corrección de esta vulnerabilidad, tal y como se refleja en las notas de la versión publicadas en el repositorio oficial del proyecto. No se han publicado otras versiones afectadas o mitigaciones parciales en las fuentes consultadas.
Impacto y riesgo
La vulnerabilidad ha sido clasificada con una puntuación CVSS de 9.1 y un nivel de severidad CRÍTICO según el vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Esta puntuación refleja un impacto alto en la confidencialidad e integridad de los datos, aunque la complejidad de ataque se considera alta y se requiere una posición de red privilegiada (atacante en la ruta de comunicación).
El fallo se produce en las funciones parseKubeconfig() y parseKubeconfigFile(). Cuando un archivo kubeconfig no incluye el campo certificate-authority-data, la librería desactiva la verificación de certificados TLS, ignorando además la directiva insecure-skip-tls-verify. Esto significa que la conexión con el servidor de la API de Kubernetes no valida la identidad del servidor, lo que permite a un atacante en la ruta de red (on-path) suplantar al servidor de la API.
Las consecuencias prácticas de una explotación exitosa incluyen:
- Captura de credenciales: el atacante puede interceptar tokens Bearer o credenciales Basic enviadas por el cliente.
- Manipulación del tráfico: el atacante puede alterar las comunicaciones WebSocket o REST entre el cliente y el servidor de la API.
- Compromiso del clúster: con las credenciales capturadas, un atacante podría obtener acceso no autorizado al clúster de Kubernetes y realizar acciones administrativas.
Dado que esta librería se utiliza en entornos de automatización y gestión de Kubernetes, el riesgo es especialmente relevante en despliegues donde el archivo kubeconfig se genera o distribuye sin incluir la autoridad de certificación correspondiente.
Estado de explotación conocida
Las fuentes consultadas (NVD y CVE.org) no publican información sobre explotación activa de esta vulnerabilidad. No se ha confirmado ni documentado ningún caso de explotación en entornos reales hasta la fecha de publicación de este análisis. La ausencia de esta información no debe interpretarse como una garantía de seguridad, sino como una limitación de los datos disponibles.
Se recomienda encarecidamente aplicar la actualización a la versión 0.32.0 o posterior, incluso sin evidencia de explotación activa, dado el nivel de criticidad asignado.
Indicadores de compromiso (IOC)
No se han extraído indicadores de compromiso (IOC) estructurados de las fuentes consultadas. El campo enrichment.ioc se encuentra vacío, por lo que no se dispone de IOC publicados para esta vulnerabilidad. No deben inventarse indicadores que no estén respaldados por las fuentes oficiales.
En ausencia de IOC específicos, se recomienda a los administradores revisar los registros de conexión de los clientes que utilicen esta librería, prestando especial atención a conexiones TLS no validadas o a intentos de autenticación con credenciales capturadas.
Cómo comprobar si estás afectado
Para determinar si tu despliegue utiliza una versión vulnerable de maclof/kubernetes-client, debes verificar la versión instalada del paquete y revisar la configuración de los archivos kubeconfig que maneja la aplicación. La vulnerabilidad afecta a las versiones 0.17.0 hasta 0.31.x (anteriores a 0.32.0).
Pasos para la verificación
- Identifica la versión del cliente: Revisa el archivo de dependencias de tu proyecto (por ejemplo,
composer.jsonsi usas Composer) o ejecuta el comando de listado de paquetes de tu gestor de dependencias para confirmar la versión exacta demaclof/kubernetes-clienten uso. - Inspecciona los archivos kubeconfig: Localiza los archivos de configuración de Kubernetes que consume la aplicación. Presta especial atención a los bloques
clustersyusers. - Comprueba la presencia de
certificate-authority-data: Si en la definición del clúster no se incluye el campocertificate-authority-data(o la rutacertificate-authority), el cliente, en las versiones afectadas, deshabilitará la verificación TLS de forma automática. - Revisa la directiva
insecure-skip-tls-verify: Verifica si este parámetro está presente en tu configuración. El comportamiento inseguro se produce incluso cuando esta opción no está definida o está establecida afalse, ya que el fallo provoca que se omita la verificación del certificado del servidor API.
Nota importante: El problema radica en las funciones
parseKubeconfig()yparseKubeconfigFile(). Si tu aplicación construye la configuración mediante estos métodos y el kubeconfig carece de la autoridad certificadora, la conexión se realizará sin validar la identidad del servidor.
Mitigación y actualización
La acción principal recomendada es revisar el aviso oficial del fabricante y aplicar la actualización o mitigación publicada. Según los datos disponibles, el proyecto ha publicado la versión 0.32.0 que aborda esta deficiencia.
Medidas a considerar
- Actualizar el paquete: Si tu infraestructura lo permite, actualiza
maclof/kubernetes-clienta la versión 0.32.0 o posterior. Consulta las notas de la versión en el repositorio oficial del proyecto para confirmar los cambios aplicados. - Revisar el commit de corrección: El proyecto ha publicado un commit específico (
924c0b935fa538ed6b4b0948127609e99d0e6f34) que puedes revisar para entender el alcance del parche si necesitas aplicar un hotfix manual en tu copia del código. - Completar los kubeconfig: Como medida temporal, asegúrate de que todos los archivos kubeconfig utilizados incluyan el bloque
certificate-authority-datacon el certificado de la autoridad certificadora del clúster. Esto evita que el cliente entre en la ruta insegura. - Evitar entornos intermedios no confiables: Dado que el ataque requiere posición de intermediario (on-path), minimiza la exposición de las comunicaciones con el API server a redes no confiables mientras se completa la actualización.
Advertencia: No se debe confiar en la opción
insecure-skip-tls-verifycomo mecanismo de protección. El fallo de seguridad precisamente ignora esta directiva y desactiva la verificación sin que el administrador lo haya solicitado explícitamente.
Checklist para administradores
- ☐ He identificado la versión exacta de
maclof/kubernetes-clienten todos los entornos (desarrollo, staging, producción). - ☐ He confirmado si alguna versión en uso está en el rango afectado (0.17.0 hasta 0.31.x).
- ☐ He auditado todos los archivos kubeconfig que consume la aplicación para verificar la presencia de
certificate-authority-data. - ☐ He revisado los logs de conexión para detectar posibles advertencias relacionadas con la verificación TLS.
- ☐ He planificado la actualización a la versión 0.32.0 o posterior en función de las notas de la versión publicadas por el fabricante.
- ☐ He comprobado que no existen credenciales (tokens Bearer o credenciales Basic) almacenadas en claro en los kubeconfig que pudieran verse comprometidas.
- ☐ He notificado al equipo de desarrollo y seguridad sobre la necesidad de revisar el código que invoca
parseKubeconfig()yparseKubeconfigFile(). - ☐ He verificado que las conexiones al API server se realizan a través de redes confiables o mediante mecanismos de seguridad adicionales (VPN, mTLS, etc.).
Preguntas frecuentes
¿Qué versión de kubernetes-client corrige esta vulnerabilidad?
Según las referencias publicadas, la versión 0.32.0 del paquete maclof/kubernetes-client incluye la corrección. Se recomienda consultar las notas de la versión en el repositorio oficial para confirmar los detalles del parche.
¿Cómo puedo saber si mi kubeconfig es vulnerable?
Si tu archivo kubeconfig no incluye el campo certificate-authority-data en la definición del clúster y estás utilizando una versión del cliente entre 0.17.0 y 0.31.x, la conexión se realizará sin verificar el certificado TLS del servidor. Revisa también si el parámetro insecure-skip-tls-verify está presente, aunque el fallo ocurre independientemente de su valor.
¿Qué puede hacer un atacante si explota esta vulnerabilidad?
Un atacante con capacidad de interceptar el tráfico de red (posición on-path) podría suplantar al servidor de la API de Kubernetes. Esto le permitiría capturar tokens Bearer o credenciales Basic y manipular el tráfico REST o WebSocket, comprometiendo la confidencialidad e integridad de las comunicaciones.
¿El uso de HTTPS en el endpoint del API server evita el problema?
No. El fallo consiste precisamente en que el cliente desactiva la verificación del certificado. Aunque la conexión se realice mediante HTTPS, el cliente no valida que el certificado presentado pertenezca al servidor legítimo, por lo que la comunicación puede ser interceptada por un tercero.
¿Debo rotar las credenciales de acceso a Kubernetes?
Si tienes indicios de que un entorno afectado ha estado operando con kubeconfig incompletos y en una red potencialmente comprometida, es recomendable rotar los tokens y credenciales de servicio. Esta medida es especialmente importante si la aplicación maneja credenciales con privilegios elevados.
¿Existen indicadores de compromiso (IOC) publicados?
No publicado por las fuentes consultadas. No se han extraído IOC estructurados de las fuentes oficiales disponibles para esta vulnerabilidad.
Fuentes oficiales
Para obtener información detallada y actualizaciones sobre esta vulnerabilidad, consulta las siguientes referencias:
- NVD – Detalle de CVE-2026-105223
- Repositorio oficial del proyecto kubernetes-client
- Notas de la versión 0.32.0
- Commit de corrección
- Issue de seguimiento en GitHub
- Código afectado en Client.php
- Aviso de VulnCheck
Mantente atento a las actualizaciones del fabricante y aplica las medidas correctivas tan pronto como sea posible en tu entorno.