El nuevo Gitea RCE permite a los escritores de repositorios instalar un gancho Git para ejecutar comandos de Shell – CYBERDEFENSA.MX

Gitea, la plataforma Git autohospedada, ha solucionado una vulnerabilidad crítica de ejecución remota de código. Un usuario con acceso normal de escritura al repositorio puede convertir el contenido del parche controlado por el atacante en un gancho Git activo y ejecutar comandos de shell como la cuenta de servicio de Gitea.

Seguimiento como CVE-2026-60004 (Puntuación CVSS: 9,8), la falla afecta a las versiones 1.17 y posteriores de Gitea antes de la 1.27.1 y se solucionó en 1.27.1. La llamada API vulnerable requiere autenticación y permiso de escritura en el repositorio. Pero Gitea habilita el registro de forma predeterminada, por lo que un visitante externo puede crear una cuenta y un repositorio normales en una instalación sin cambios y luego explotar el error sin credenciales preexistentes.

Actualizar a 1.27.1 es la solución. Gitea dijo el 27 de julio que las instancias de Gitea Cloud se actualizarían automáticamente. El aviso de Gitea del 28 de julio no dice que la falla haya sido explotada en la naturaleza, pero incluye un código de prueba de concepto (PoC) público.

Deshabilitar el registro abierto puede eliminar la ruta de creación de cuenta pública mientras se implementa la actualización, pero no soluciona la falla ni protege contra usuarios existentes con acceso de escritura al repositorio.

Ciberseguridad

La falla fue reportada por un investigador de seguridad. Shai Rod, que se hace llamar NightRang3r. Gitea acredita a NightRang3r como el reportero de su aviso.

La gitea ruta afectada invoca reqToken()que rechaza solicitudes sin un usuario registrado. La ruta sin credenciales previas proviene del proyecto configuración predeterminadaque deja el registro abierto, no requiere aprobación manual ni por correo electrónico, no marca a los nuevos usuarios como restringidos y no impone ningún límite predeterminado de creación de repositorio.

El error se encuentra en el POST /api/v1/repos/{owner}/{repo}/diffpatch punto final. Según Gitea aviso de seguridadel punto final aplica un parche proporcionado dentro de un clon temporal desnudo compartido. Invocación de compilaciones vulnerables git apply con --index, --recount, --cachedy --binaryañadiendo el -3 Opción de respaldo de tres vías cuando el servidor ejecuta Git 2.32 o posterior.

Un atacante envía el mismo parche dos veces para crear una colisión agregar/agregar. El respaldo de tres vías verifica la ruta indexada aunque la operación utilice --cached. Debido a que el clon temporal está desnudo, su raíz es $GIT_DIR. Un archivo ejecutable ubicado en hooks/post-index-change por lo tanto, llega al directorio de enlaces de Git y se activa. Git lo ejecuta mientras actualiza el índice.

El PoC inicia sesión con una cuenta normal, crea un repositorio privado inicializado, envía el parche malicioso dos veces y recupera el resultado del comando. No necesita devolución de llamada saliente. El gancho almacena el resultado en objetos Git, crea una rama que contiene el resultado y permite al atacante recuperarlo a través de HTTP inteligente autenticado.

Al 29 de julio de 2026, ninguna de las fuentes primarias citadas informa si la falla fue explotada antes o después de que la versión 1.27.1 estuviera disponible.

La explotación exitosa otorga al atacante los privilegios de la cuenta del sistema operativo Gitea. Dependiendo de cómo esté aislada la instancia, Gitea dijo que eso podría exponer secretos de aplicaciones y entornos, repositorios montados, credenciales y contenidos de bases de datos, credenciales de OAuth y servicios internos accesibles.

Ciberseguridad

La explotación aún requiere acceso de escritura al repositorio, Git 2.32 o posterior, un habilitado diffpatch ruta y un sistema de archivos temporal ejecutable y grabable. El registro predeterminado permite que un usuario externo obtenga el acceso de escritura requerido en una instalación sin cambios.

Es fácil pasar por alto la solución en el registro de cambios. Gitea cambió el clon temporal de desnudo a no desnudo. El comentario de código advierte explícitamente que los comandos de Git que usan --index puede operar en el árbol de trabajo. El cambio se fusionó y se respaldó el 26 de julio de 2026.

Versión 1.27.1 enviado el 27 de julio, y el aviso de seguridad siguió el 28 de julio. Las notas de la versión enumeraron el cambio en MISC como «refactor: git patch apply», no en SEGURIDAD.

Rod tenía obtuvo una vista previa del RCE junto con un problema de inclusión de archivos separadocon un PoC recuperando /etc/passwd desde un host Gitea 1.27.0. Esta cuestión parece corresponder a un tema aparte cambio incluido en 1.27.1 que alteró tanto el renderizador del modo Org de Gitea #+INCLUDE las rutas se devuelven como texto sin formato en lugar de leerse desde el sistema de archivos del servidor. Gitea no ha publicado un aviso por separado o CVE para el problema de la inclusión de archivos.

Investigador publica GitLab RCE PoC que permite a usuarios autenticados ejecutar comandos como Git – CYBERDEFENSA.MX

El investigador de seguridad Yuhang Wu en Depthfirst ha publicado un exploit de prueba de concepto (PoC) funcional que ejecuta comandos como git en un GitLab autoadministrado sin parches 18.11.3 servidor.

Un usuario autenticado normal lo activa confirmando dos cuadernos Jupyter diseñados y solicitando su diferencia. La cadena no necesita derechos de administrador, acceso al corredor de integración continua (CI), interacción con la víctima ni acceso al proyecto de otro usuario.

El exploit público es específico de GitLab. 18.11.3 en x86-64; los errores subyacentes de Oj afectan versiones más amplias. Las gamas afectadas son GitLab Community Edition (CE) y Enterprise Edition (EE). 15.2.0 a través de 18.10.7, 18.11.0 a través de 18.11.4y 19.0.0 a través de 19.0.1.

Las primeras versiones fijas son 18.10.8, 18.11.5y 19.0.2. Oj es un analizador JSON de alto rendimiento para Ruby con importante código C nativo.

Gemas publicadas 3.13.0 a través de 3.17.1 son vulnerables; 3.17.3 es la primera versión publicada que contiene ambas correcciones. Las fallas afectan a Free, Premium y Ultimate. Ruby en sí no se ve afectado.

Ciberseguridad

La explotación exitosa se ejecuta como git. Su alcance efectivo depende del aislamiento de la implementación, pero puede incluir código fuente, secretos de Rails, credenciales de servicio, datos de CI/CD y servicios internos accesibles desde la aplicación. GitLab.com fue parcheado el 10 de junio.

Los clientes dedicados no necesitan ninguna acción. Los operadores autogestionados deben pasar a una versión compatible que contenga la solución. Los usuarios de Helm y Operador deben verificar la versión de GitLab dentro de la imagen del servicio web, no solo el gráfico o la versión del Operador. Depthfirst dijo que no tenía conocimiento de explotación en estado salvaje hasta el 24 de julio.

Ni el primera revelación en profundidad ni las notas de la versión de GitLab del 10 de junio enumeran identificadores CVE o puntuaciones CVSS para los dos errores de la cadena. Ninguno de los dos proporciona una solución temporal; ambos dirigen a los operadores autogestionados a actualizarse.

Hacker News ha preguntado a GitLab sobre el estado, la clasificación y la evidencia de explotación de CVE. También preguntó en profundidad sobre la portabilidad de los exploits y si existe una mitigación temporal compatible. Las respuestas están pendientes. Depthfirst enumera nueve CVE para otras fallas del DO encontradas en la misma revisión.

El renderizador de portátiles de GitLab pasa controlado por el repositorio .ipynb JSON a Oj::Parser.usual.parse Dentro de un longevo trabajador de Puma. Eso envía datos del cuaderno controlado por el atacante al estado de analizador nativo de Oj dentro del proceso de solicitud de GitLab.

profundidad primero análisis técnico muestra cómo un error controla un puntero de devolución de llamada, mientras que el otro filtra una dirección de montón necesaria para limitar la búsqueda de aleatorización del diseño del espacio de direcciones (ASLR).

Oj almacena el estado de anidamiento en una pila fija de 1024 bytes, pero nunca comprueba si la profundidad la excede. Por lo tanto, los arreglos profundamente anidados pueden escribir 0x01 bytes en el estado del analizador adyacente. El exploit corrompe buf.headlo que hace que Oj pase un puntero interior falsificado a realloc(). Una asignación posterior de Ruby Array recupera la misma región jemalloc de 3584 bytes y sobrescribe p->start.

Oj asigna una clave de objeto de 65.565 bytes, trunca su longitud a 29 en un campo firmado de 16 bits y devuelve 29 bytes que contienen el puntero de asignación de claves en vivo. GitLab lleva ese puntero a la diferencia del cuaderno renderizado, dándole al exploit la fuga de dirección necesaria para limitar la búsqueda de ASLR. En el GitLab perfilado de dos trabajadores 18.11.3 instalación, la búsqueda solía tardar entre cinco y diez minutos. Los investigadores proyectaron de una a dos horas en el rango más amplio de trabajadores maduros.

Ciberseguridad

Dos archivos de cuaderno ordenados léxicamente en uno diffs_stream La solicitud mantiene ambas etapas dentro del mismo trabajador Puma, que reutiliza el analizador Oj de proceso global. El primer archivo corrompe la devolución de llamada y genera un error que GitLab detecta antes de continuar con la diferencia. El siguiente análisis invoca el puntero sobrescrito y llega system() a través de una secuencia de gadgets específica de la construcción.

El manifestación pública empaqueta la cadena en un GitLab local 18.11.3 laboratorio x86-64 y hace que el trabajador de Puma se conecte nuevamente como git.

Depth informó por primera vez los errores de Oj el 21 de mayo, y el mantenedor fusionó las correcciones el 27 de mayo. DO 3.17.3 enviado el 4 de junio. Los investigadores informaron sobre la cadena GitLab el 5 de junio; Depthfirst dijo que GitLab lo confirmó el 8 de junio.

GitLab lanzó las versiones fijas el 10 de junio y resolvió el informe el 17 de julio, según profundidadprimero. Una revisión de The Hacker News encontró que GitLab enumeró el DO 3.17.3 aparece debajo de las correcciones de errores en lugar de en la tabla de correcciones de seguridad y no describe la cadena RCE de diferencias del cuaderno.

Grok Build cargó repositorios Git completos en xAI Storage, no solo los archivos que leyó – CYBERDEFENSA.MX

La CLI de codificación Grok Build de xAI estaba cargando repositorios Git completos, con el historial de confirmación completo y todo, en un depósito de Google Cloud Storage ejecutado por xAI, no solo los archivos que necesitaba una tarea de codificación.

Un investigador que publica como cerebroversión de prueba 0.2.93capturó una de esas cargas, clonó el paquete git de la solicitud interceptada y recuperó un archivo que al agente se le había dicho claramente que no abriera.

La carga se realizó en un canal separado del modelo en sí, y es difícil discutir la división de bytes. En un repositorio de 12 GB de archivos que el modelo nunca leyó, el modelo dirige el tráfico a /v1/responses llegó a aproximadamente 192 KB, mientras que el canal de almacenamiento a /v1/storage movió 5,10 GiB, una brecha de aproximadamente 27.800 veces entre lo que necesitaba el modelo y lo que dejaba la máquina.

Esa carga de almacenamiento se ejecutó en 73 fragmentos de aproximadamente 75 MB, cada uno de los cuales devolvió HTTP 200, y a través del tamaño del investigador barrió el tamaño total del repositorio rastreado. El cubo de destino, grok-code-session-tracesse nombra en binario y en etapas metadata.json cuyas rutas por archivo apuntan a gs://grok-code-session-traces/.

El archivo no leído fue src/_probe/never_read_canary.txtplantado con un marcador único. La clonación del paquete capturado lo recuperó palabra por palabra junto con el historial de confirmación completo del repositorio, y la misma prueba se replicó en un segundo repositorio no relacionado. Las capturas lo que establecen es transmisión, aceptación y almacenamiento, no entrenamiento.

El desmontaje no afirma que xAI esté entrenado en el código, que el personal lo lea o que los archivos ignorados por git siempre sean barridos. Los archivos rastreados más el historial es lo que muestra el cable.

Ciberseguridad

El camino de los secretos es separado y más sencillo. Cuando Grok lee un archivo, su contenido pasa al turno del modelo y se realiza un seguimiento. .env fue con ellos sin redactar, canario API_KEY y DB_PASSWORD valores y todo. El mismo contenido también llegó a un session_state archivo destinado al almacenamiento. Los secretos plantados eran falsos, por lo que no se filtró nada real en la prueba. El comportamiento sigue siendo el problema: un archivo de credenciales que el agente leyó durante una tarea salió y se almacenó sin redacción.

La configuración que elegirían la mayoría de los desarrolladores no hizo nada aquí. Con «Mejorar el modelo» desactivado, Grok aún cargó el repositorio y el propio servidor. /v1/settings la respuesta seguía regresando trace_upload_enabled: true. Esa palanca determina si sus datos entrenan el modelo. No rige si su código sale de la máquina. Son dos controles diferentes y sólo uno de ellos estuvo expuesto al usuario.

Cada agente de codificación en la nube tiene que enviar alguna fuente a un modelo remoto para realizar su trabajo, por lo que se espera el primer canal. Enviar todo el repositorio rastreado y su historial es un límite más amplio que enviar los archivos que necesita una tarea.

Un repositorio puede contener código propietario, URL internas, datos de clientes y credenciales que se eliminaron del árbol de trabajo pero que aún se encuentran en el historial de confirmaciones. En propia comparación de herramientas cruzadas de cereblabClaude Code y Codex no enviaron ningún paquete de repositorio; Gemini no envió ninguno en una prueba inactiva, aunque su ejecución de tarea realista fue bloqueada por cuotas antes de terminar.

Grok Build fue el caso atípico. Siguen siendo herramientas en la nube que envían los archivos que abren, por lo que «solo local» es el modelo mental incorrecto para cualquiera de ellas. Pero la recolección al por mayor del espacio de trabajo era específica de Grok Build.

La respuesta de xAI

El 13 de julio lo mismo. 0.2.93 El binario dejó de realizar solicitudes de almacenamiento. cereblab volvió a realizar la prueba seis veces y no vio nada /v1/storage cargas, y el servidor ahora regresó disable_codebase_upload: true y trace_upload_enabled: false.

El desarrollador Peter Dedene informó que la misma bandera fue devuelta a su cuentapor lo que el cierre no fue solo la observación de una sola máquina del cereblab. El cliente probado permaneció 0.2.93 aunque la configuración de su servidor cambió, se trató de un cambio del lado del servidor, no de una solución enviada en una actualización. xAI no ha confirmado si llega a todas las cuentas o es permanente.

Ciberseguridad

Hasta ahora, xAI ha abordado el problema en X en lugar de mediante un aviso de seguridad o una nota de registro de cambios. El Cuenta @SpaceXAI dijo que los equipos empresariales con retención de datos cero nunca tienen código o datos de seguimiento almacenados, que el uso de claves API respeta ZDR y que los consumidores que no lo han habilitado pueden ejecutar /privacy en la CLI para deshabilitar la retención y eliminar datos previamente sincronizados.

Elon Musk fue más allá, dicho todos los datos de usuario cargados hasta ahora serían «borrados total y absolutamente», sin dejar nada atrás. ZDR cubre equipos empresariales y el uso de API, por lo que para suscriptores individuales el /privacy El comando es el control que se ofrece.

Para cualquiera que ya haya ejecutado la herramienta, la decisión es no esperar a xAI. Rote cualquier credencial que Grok haya podido enviar: cualquier cosa que haya leído, cualquier cosa en un archivo rastreado y cualquier cosa en el historial de git que llevaba el paquete, incluido un secreto que usted confirmó y luego eliminó.

Un archivo que fue ignorado y nunca confirmado quedó fuera del paquete. Uno comprometido avanza en la historia y borrarlo más tarde no lo hace retroceder. Un análisis separado de la compilación 0.2.99. Encontré el código de carga todavía en el binario, retenido por la bandera del servidor, por lo que xAI puede volver a activarlo sin una actualización.

Y todavía no ha dicho por qué se cargaron repositorios completos de forma predeterminada, cuánto tiempo se conservaron o cuántos usuarios se vieron afectados. La exclusión voluntaria de la capacitación no es una promesa de que su código permanecerá fijo, y vale la pena comprobar usted mismo lo que sale de la máquina.

Los investigadores descubren un fallo crítico en GitHub CVE-2026-3854 RCE que se puede explotar mediante un solo Git Push – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad de seguridad crítica que afecta a GitHub.com y GitHub Enterprise Server y que podría permitir a un usuario autenticado obtener la ejecución remota de código con un solo comando «git push».

El defecto, rastreado como CVE-2026-3854 (Puntuación CVSS: 8,7), es un caso de inyección de comandos que podría permitir a un atacante con acceso push a un repositorio lograr la ejecución remota de código en la instancia.

«Durante una operación de git push, los valores de las opciones de inserción proporcionados por el usuario no se desinfectaron adecuadamente antes de incluirlos en los encabezados de servicio internos», según un Aviso de GitHub por la vulnerabilidad. «Debido a que el formato del encabezado interno utiliza un carácter delimitador que también podría aparecer en la entrada del usuario, un atacante podría inyectar campos de metadatos adicionales a través de valores de opciones de inserción diseñados».

A la empresa de seguridad en la nube Wiz, propiedad de Google, se le atribuye el mérito de descubrir e informar el problema el 4 de marzo de 2026, y GitHub validó e implementó una solución en GitHub.com en dos horas.

La vulnerabilidad también se solucionó en las versiones 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 o posteriores de GitHub Enterprise Server. No hay evidencia de que el problema haya sido explotado alguna vez en un contexto malicioso.

Ciberseguridad

Según GitHub, el problema afecta a GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud con residencia de datos, GitHub Enterprise Cloud con usuarios administrados empresariales y GitHub Enterprise Server.

En esencia, el problema surge del hecho de que los usuarios opciones de inserción de git no se desinfectan adecuadamente antes de que los valores se incorporaran al encabezado interno X-Stat. Debido a que el formato de metadatos internos se basa en un punto y coma como carácter delimitador que también podría aparecer en la entrada del usuario, un mal actor podría aprovechar este descuido para inyectar comandos arbitrarios y ejecutarlos.

«Al encadenar varios valores inyectados, los investigadores demostraron que un atacante podría anular el entorno en el que se procesó el envío, evitar las protecciones de espacio aislado que normalmente limitan la ejecución del enlace y, en última instancia, ejecutar comandos arbitrarios en el servidor», dijo el director de seguridad de la información de GitHub, Alexis Wales. dicho.

Wiz, en un anuncio coordinado, señaló que el problema es «notablemente fácil» de explotar y agregó que permite la ejecución remota de código en nodos de almacenamiento compartido. Alrededor del 88% de los casos son actualmente vulnerables al problema en el momento de su divulgación pública. La cadena de ejecución remota de código encadena tres inyecciones:

  • Inyectar una no producción rieles_env valor para omitir la zona de pruebas
  • Inyectar dir_ganchos_personalizados para controlar para redirigir el directorio de gancho
  • Inyectar repo_pre_receive_hooks con una entrada de gancho diseñada que activa el recorrido de la ruta para ejecutar comandos arbitrarios como usuario de git

«Con la ejecución de código sin espacio aislado como usuario de git, teníamos control total sobre la instancia de GHES, incluido el acceso de lectura/escritura al sistema de archivos y la visibilidad de la configuración del servicio interno», dijo el investigador de seguridad de Wiz, Sagi Tzadik. dicho.

Ciberseguridad

En cuanto a GitHub.com, un indicador de modo empresarial, que está configurado en «verdadero» para GitHub Enterprise Server, tiene por defecto «falso», lo que deja inactiva la ruta de los enlaces personalizados. Pero dado que este indicador también se pasa en el encabezado X-Stat, es igualmente inyectable usando el mismo mecanismo, lo que resulta en la ejecución de código también en GitHub.com.

Para empeorar las cosas, dada la arquitectura multiinquilino de GitHub y su infraestructura backend compartida, la compañía señaló que obtener la ejecución de código en GitHub.com permitía la exposición entre inquilinos, lo que permitía efectivamente a un atacante leer millones de repositorios en el nodo de almacenamiento compartido, independientemente de la organización o el usuario.

A la luz de la gravedad de CVE-2026-3854, se recomienda a los usuarios que apliquen la actualización inmediatamente para una protección óptima.

«Un solo comando git push fue suficiente para explotar una falla en el protocolo interno de GitHub y lograr la ejecución del código en la infraestructura backend», dijo Wiz. «Cuando varios servicios escritos en diferentes idiomas pasan datos a través de un protocolo interno compartido, las suposiciones que cada servicio hace sobre esos datos se convierten en una superficie de ataque crítica».

«Alentamos a los equipos que crean arquitecturas multiservicio a auditar cómo fluye la entrada controlada por el usuario a través de protocolos internos, especialmente cuando la configuración crítica para la seguridad se deriva de formatos de datos compartidos».