# Anuncios de seguridad de Docker [Suscribirse al feed RSS de seguridad](/security/security-announcements/index.xml) ## Actualización de seguridad de Docker Desktop 4.71.0: CVE-2026-5843 El 27 de abril se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.71.0](/desktop/release-notes/#4710): - Se abordó la vulnerabilidad [CVE-2026-5843](https://www.cve.org/cverecord?id=CVE-2026-5843), que permitía la ejecución de código de contenedor a host en el backend de inferencia MLX de Docker Model Runner. ## Actualización de seguridad de Docker Desktop 4.68.0: CVE-2026-5817 El 7 de abril se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.68.0](/desktop/release-notes/#4680): - Se abordó la vulnerabilidad [CVE-2026-5817](https://www.cve.org/cverecord?id=CVE-2026-5817), que permitía la ejecución de código de contenedor a host en el backend de inferencia vllm-metal de Docker Model Runner. ## Actualización de seguridad de Docker Desktop 4.67.0: CVE-2026-33990 El 30 de marzo se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.67.0](/desktop/release-notes/#4670): - Se abordó la vulnerabilidad [CVE-2026-33990](https://www.cve.org/cverecord?id=CVE-2026-33990), que consistía en un ataque SSRF en el cliente de registro OCI de Docker Model Runner. ## Actualización de seguridad de Docker Desktop 4.62.0: CVE-2026-28400 El 23 de febrero se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.62.0](/desktop/release-notes/#4620): - Se abordó la vulnerabilidad [CVE-2026-28400](https://www.cve.org/cverecord?id=CVE-2026-28400), que consistía en una inyección de banderas en tiempo de ejecución en Docker Model Runner. ## Actualización de seguridad de Docker Desktop 4.62.0: CVE-2026-2664 El 23 de febrero se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.62.0](/desktop/release-notes/#4620): - Se corrigió la vulnerabilidad [CVE-2026-2664](https://www.cve.org/cverecord?id=CVE-2026-2664), una lectura fuera de límites en el módulo del kernel gRPC-FUSE. ## Actualización de seguridad de Docker Desktop 4.54.0: CVE-2025-13743 El 4 de diciembre se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.54.0](/desktop/release-notes/#4540): - Se corrigió la vulnerabilidad [CVE-2025-13743](https://www.cve.org/cverecord?id=CVE-2025-13743), donde se descubrió que los paquetes de diagnóstico de Docker Desktop incluían PATs de Hub caducados en la salida del registro debido a la serialización del objeto de error. ## Actualización de seguridad de Docker Desktop 4.49.0: CVE-2025-9164 El 23 de octubre se corrigió una vulnerabilidad en Docker Desktop para Windows en el lanzamiento de la versión [4.49.0](/desktop/release-notes/#4490): - Se corrigió la vulnerabilidad [CVE-2025-9164](https://www.cve.org/cverecord?id=CVE-2025-9164), en la que el instalador de Docker Desktop para Windows era vulnerable al secuestro de DLL (DLL hijacking) debido a un orden de búsqueda de DLL inseguro. El instalador busca las DLL requeridas en la carpeta de descargas del usuario antes de revisar los directorios del sistema, permitiendo la escalada de privilegios locales mediante la colocación de DLL maliciosas. ## Actualización de seguridad de Docker Desktop 4.47.0: CVE-2025-10657 El 25 de septiembre se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.47.0](/desktop/release-notes/#4470): - Se corrigió la vulnerabilidad [CVE-2025-10657](https://www.cve.org/CVERecord?id=CVE-2025-10657), en la que la función de restricciones de comandos del socket de Docker de Enhanced Container Isolation ([Docker Socket command restrictions](/enterprise/security/hardened-desktop/enhanced-container-isolation/config/#command-restrictions)) no funcionaba correctamente únicamente en la versión 4.46.0 de Docker Desktop (se ignoraba su configuración). ## Actualización de seguridad de Docker Desktop 4.44.3: CVE-2025-9074 _Última actualización: 20 de agosto de 2025_ El 20 de agosto se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.44.3](/desktop/release-notes/#4443): - Se corrigió la vulnerabilidad [CVE-2025-9074](https://www.cve.org/CVERecord?id=CVE-2025-9074), en la que un contenedor malicioso ejecutándose en Docker Desktop podía acceder al Docker Engine e iniciar contenedores adicionales sin requerir el montaje del socket de Docker. Esto podría permitir el acceso no autorizado a los archivos del usuario en el sistema host. Enhanced Container Isolation (ECI) no mitiga esta vulnerabilidad. ## Actualización de seguridad de Docker Desktop 4.44.0: CVE-2025-23266 _Última actualización: 31 de julio de 2025_ Estamos al tanto de [CVE-2025-23266](https://nvd.nist.gov/vuln/detail/CVE-2025-23266), una vulnerabilidad crítica que afecta al NVIDIA Container Toolkit en modo CDI hasta la versión 1.17.7. Docker Desktop incluye la versión 1.17.8, la cual no se ve afectada. Sin embargo, las versiones anteriores de Docker Desktop que incluían versiones previas del kit de herramientas pueden verse afectadas si el modo CDI se habilitó manualmente. Actualiza a Docker Desktop 4.44 o posterior para asegurarte de estar utilizando la versión corregida. ## Actualización de seguridad de Docker Desktop 4.43.0: CVE-2025-6587 _Última actualización: 3 de julio de 2025_ El 3 de julio se corrigió una vulnerabilidad en Docker Desktop en el lanzamiento de la versión [4.43.0](/desktop/release-notes/#4430): - Se corrigió la vulnerabilidad [CVE-2025-6587](https://www.cve.org/CVERecord?id=CVE-2025-6587), donde las variables de entorno del sistema confidenciales se incluían en los registros de diagnóstico de Docker Desktop, lo que permitía una posible exposición de secretos. ## Actualización de seguridad de Docker Desktop 4.41.0: CVE-2025-3224, CVE-2025-4095 y CVE-2025-3911 _Última actualización: 15 de mayo de 2025_ El 28 de abril se corrigieron tres vulnerabilidades en Docker Desktop en el lanzamiento de la versión [4.41.0](/desktop/release-notes/#4410). - Se corrigió la vulnerabilidad [CVE-2025-3224](https://www.cve.org/CVERecord?id=CVE-2025-3224), que permitía a un atacante con acceso a la máquina de un usuario realizar una escalada de privilegios al actualizar Docker Desktop. - Se corrigió la vulnerabilidad [CVE-2025-4095](https://www.cve.org/CVERecord?id=CVE-2025-4095), donde las políticas de Registry Access Management (RAM) no se aplicaban al usar un perfil de configuración de macOS, permitiendo a los usuarios descargar imágenes de registros no aprobados. - Se corrigió la vulnerabilidad [CVE-2025-3911](https://www.cve.org/CVERecord?id=CVE-2025-3911), que permitía a un atacante con acceso de lectura a la máquina de un usuario obtener información confidencial de los archivos de registro de Docker Desktop, incluidas las variables de entorno configuradas para los contenedores en ejecución. Te recomendamos encarecidamente actualizar a Docker Desktop [4.41.0](/desktop/release-notes/#4410). ## Actualización de seguridad de Docker Desktop 4.34.2: CVE-2024-8695 y CVE-2024-8696 _Última actualización: 13 de septiembre de 2024_ Dos vulnerabilidades de ejecución remota de código (RCE) en Docker Desktop relacionadas con las Docker Extensions fueron reportadas por [Cure53](https://cure53.de/) y corregidas el 12 de septiembre en el lanzamiento de la versión [4.34.2](/desktop/release-notes/#4342): - [CVE-2024-8695](https://www.cve.org/cverecord?id=CVE-2024-8695): Una vulnerabilidad de ejecución remota de código (RCE) a través de una descripción/changelog de extensión manipulados que podía ser explotada por una extensión maliciosa en Docker Desktop en versiones anteriores a la 4.34.2. [Crítica] - [CVE-2024-8696](https://www.cve.org/cverecord?id=CVE-2024-8696): Una vulnerabilidad de ejecución remota de código (RCE) a través de una publisher-url/additional-urls de extensión manipuladas que podía ser explotada por una extensión maliciosa en Docker Desktop en versiones anteriores a la 4.34.2. [Alta] No se encontraron extensiones existentes en el Extensions Marketplace que explotaran estas vulnerabilidades. El equipo de Docker monitoreará de cerca y revisará diligentemente cualquier solicitud para publicar nuevas extensiones. Te recomendamos encarecidamente actualizar a Docker Desktop [4.34.2](/desktop/release-notes/#4342). Si no puedes actualizar de inmediato, puedes [deshabilitar las Docker Extensions](/extensions/settings-feedback/#turn-on-or-turn-off-extensions) como medida temporal. ## Depreciación de inicios de sesión con contraseña en la CLI cuando se exige SSO _Última actualización: julio de 2024_ Cuando se introdujo por primera vez la obligación de [SSO obligatorio](/enterprise/security/single-sign-on/connect/), Docker proporcionó un período de gracia para seguir permitiendo el uso de contraseñas en la CLI de Docker al autenticarse en Docker Hub. Esto se permitió para que las organizaciones pudieran adoptar la obligación de SSO con mayor facilidad. Se recomienda a los administradores que configuren SSO que alienten a los usuarios de la CLI [a cambiar a Tokens de Acceso Personal](/enterprise/security/single-sign-on/#prerequisites) antes de que finalice este período de gracia. El 16 de septiembre de 2024 finalizará el período de gracia y las contraseñas ya no podrán autenticarse en Docker Hub a través de la CLI de Docker cuando se exija SSO. Los usuarios afectados deben cambiar a usar PATs para continuar iniciando sesión. En Docker, queremos que la experiencia sea lo más segura posible para nuestros desarrolladores y organizaciones, y esta depreciación es un paso esencial en esa dirección. ## Certificación ISO 27001 y atestación SOC 2 Tipo 2 _Última actualización: junio de 2024_ Docker se complace en anunciar que ha recibido la atestación SOC 2 Tipo 2 y la certificación ISO 27001 sin excepciones ni no conformidades mayores. La seguridad es un pilar fundamental para las operaciones de Docker, el cual está integrado en nuestra misión general y estrategia de la empresa. Los productos de Docker son fundamentales para nuestra comunidad de usuarios, y nuestra atestación SOC 2 Tipo 2 y la certificación ISO 27001 demuestran el compromiso continuo de Docker con la seguridad ante nuestra base de usuarios. Para obtener más información, consulta el [Anuncio en el blog](https://www.docker.com/blog/docker-announces-soc-2-type-2-attestation-iso-27001-certification/). ## Aviso de seguridad de Docker: Múltiples vulnerabilidades en runc, BuildKit y Moby _Última actualización: 2 de febrero de 2024_ En Docker priorizamos la seguridad y la integridad de nuestro software, así como la confianza de nuestros usuarios. Investigadores de seguridad de Snyk Labs identificaron y reportaron cuatro vulnerabilidades de seguridad en el ecosistema de contenedores. Una de las vulnerabilidades, [CVE-2024-21626](https://scout.docker.com/v/CVE-2024-21626), concierne al entorno de ejecución de contenedores runc, y las otras tres afectan a BuildKit ([CVE-2024-23651](https://scout.docker.com/v/CVE-2024-23651), [CVE-2024-23652](https://scout.docker.com/v/CVE-2024-23652) y [CVE-2024-23653](https://scout.docker.com/v/CVE-2024-23653)). Queremos asegurar a nuestra comunidad que nuestro equipo, en colaboración con los informantes y los mantenedores de código abierto, ha estado trabajando diligentemente en la coordinación e implementación de las correcciones necesarias. Estamos comprometidos con el mantenimiento de los más altos estándares de seguridad. Publicamos versiones corregidas de runc, BuildKit y Moby el 31 de enero y lanzamos una actualización para Docker Desktop el 1 de febrero para abordar estas vulnerabilidades. Además, nuestros últimos lanzamientos de BuildKit y Moby incluyeron correcciones para [CVE-2024-23650](https://scout.docker.com/v/CVE-2024-23650) y [CVE-2024-24557](https://scout.docker.com/v/CVE-2024-24557), descubiertas respectivamente por un investigador independiente y a través de iniciativas de investigación interna de Docker. | | Versiones afectadas | | :--------------------- | :-------------------- | | `runc` | <= 1.1.11 | | `BuildKit` | <= 0.12.4 | | `Moby (Docker Engine)` | <= 25.0.1 y <= 24.0.8 | | `Docker Desktop` | <= 4.27.0 | ### ¿Qué debo hacer si tengo una versión afectada? Si estás utilizando versiones afectadas de runc, BuildKit, Moby o Docker Desktop, asegúrate de actualizar a las últimas versiones vinculadas en la siguiente tabla: | | Versiones corregidas | | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------ | | `runc` | >= [1.1.12](https://github.com/opencontainers/runc/releases/tag/v1.1.12) | | `BuildKit` | >= [0.12.5](https://github.com/moby/buildkit/releases/tag/v0.12.5) | | `Moby (Docker Engine)` | >= [25.0.2](https://github.com/moby/moby/releases/tag/v25.0.2) y >= [24.0.9](https://github.com/moby/moby/releases/tag/v24.0.9) | | `Docker Desktop` | >= [4.27.1](/desktop/release-notes/#4271) | Si no puedes actualizar a una versión no afectada de inmediato, sigue estas mejores prácticas para mitigar el riesgo: - Utiliza únicamente imágenes de Docker de confianza (como las [Docker Official Images](/docker-hub/image-library/trusted-content/#docker-official-images)). - No compiles imágenes de Docker a partir de fuentes o Dockerfiles que no sean de confianza. - Si eres cliente de Docker Business que utiliza Docker Desktop y no puedes actualizar a la versión v4.27.1, asegúrate de habilitar las características de [Hardened Docker Desktop](/enterprise/security/hardened-desktop/) como: - [Enhanced Container Isolation](/enterprise/security/hardened-desktop/enhanced-container-isolation/), que mitiga el impacto de la vulnerabilidad CVE-2024-21626 en el caso de ejecutar contenedores a partir de imágenes maliciosas. - [Image Access Management](/enterprise/security/hardened-desktop/image-access-management/) y [Registry Access Management](/enterprise/security/hardened-desktop/registry-access-management/), que otorgan a las organizaciones control sobre qué imágenes y repositorios pueden acceder sus usuarios. - Para las vulnerabilidades CVE-2024-23650, CVE-2024-23651, CVE-2024-23652 y CVE-2024-23653, evita utilizar frontends de BuildKit de fuentes que no sean de confianza. Un frontend de imagen suele especificarse como la línea `#syntax` en tu Dockerfile, o con la bandera `--frontend` al usar el comando `buildctl build`. - Para mitigar la vulnerabilidad CVE-2024-24557, asegúrate de utilizar BuildKit o de deshabilitar la caché al compilar imágenes. Desde la CLI, esto se puede hacer mediante la variable de entorno `DOCKER_BUILDKIT=1` (por defecto para Moby >= v23.0 si el plugin buildx está instalado) o la bandera `--no-cache`. Si estás utilizando la API HTTP directamente o a través de un cliente, se puede hacer lo mismo configurando `nocache` a `true` o `version` a `2` para el [punto de enlace de la API /build](https://docs-docker.esdocu.com/reference/api/engine/version/v1.44/#tag/Image/operation/ImageBuild). ### Detalles técnicos e impacto #### CVE-2024-21626 (Alto) En runc v1.1.11 y versiones anteriores, debido a la filtración de ciertos descriptores de archivos, un atacante puede obtener acceso al sistema de archivos del host haciendo que un proceso de contenedor recién generado (desde `runc exec`) tenga un directorio de trabajo en el espacio de nombres del sistema de archivos del host, o engañando a un usuario para que ejecute una imagen maliciosa y permita que un proceso de contenedor obtenga acceso al sistema de archivos del host a través de `runc run`. Los ataques también pueden adaptarse para sobrescribir binarios del host de forma semi-arbitraria, permitiendo escapes completos del contenedor. Ten en cuenta que al usar entornos de ejecución de nivel superior (como Docker o Kubernetes), esta vulnerabilidad se puede explotar ejecutando una imagen de contenedor maliciosa sin configuración adicional o pasando opciones de directorio de trabajo específicas al iniciar un contenedor. La vulnerabilidad también se puede explotar desde los Dockerfiles en el caso de Docker. _El problema se corrigió en runc v1.1.12._ #### CVE-2024-23651 (Alto) En BuildKit <= v0.12.4, dos pasos de compilación maliciosos ejecutándose en paralelo que compartan los mismos montajes de caché con subrutas podrían provocar una condición de carrera, haciendo que los archivos del sistema host sean accesibles para el contenedor de compilación. Esto solo ocurrirá si un usuario intenta compilar un Dockerfile de un proyecto malicioso. _El problema se corrigió en BuildKit v0.12.5._ #### CVE-2024-23652 (Alto) En BuildKit <= v0.12.4, un frontend de BuildKit o Dockerfile malicioso que use `RUN --mount` podría engañar a la función que elimina los archivos vacíos creados para los puntos de montaje para que elimine un archivo fuera del contenedor desde el sistema host. Esto solo ocurrirá si un usuario utiliza un Dockerfile malicioso. _El problema se corrigió en BuildKit v0.12.5._ #### CVE-2024-23653 (Alto) Además de ejecutar contenedores como pasos de compilación, BuildKit también proporciona APIs para ejecutar contenedores interactivos basados en imágenes compiladas. En BuildKit <= v0.12.4, es posible usar estas APIs para solicitar a BuildKit que ejecute un contenedor con privilegios elevados. Normalmente, la ejecución de dichos contenedores solo está permitida si la autorización especial `security.insecure` está habilitada tanto por la configuración de buildkitd como permitida por el usuario que inicializa la solicitud de compilación. _El problema se corrigió en BuildKit v0.12.5._ #### CVE-2024-23650 (Medio) En BuildKit <= v0.12.4, un cliente o frontend de BuildKit malicioso podría diseñar una solicitud que provocara la caída del demonio de BuildKit con un pánico (panic). _El problema se corrigió en BuildKit v0.12.5._ #### CVE-2024-24557 (Medio) En Moby <= v25.0.1 y <= v24.0.8, el sistema clásico de caché del constructor es propenso a la intoxicación de la caché (cache poisoning) si la imagen se compila desde cero (`FROM scratch`). Además, los cambios en algunas instrucciones (siendo las más importantes `HEALTHCHECK` y `ONBUILD`) no provocarían una pérdida de caché. Un atacante con conocimiento del Dockerfile que alguien está usando podría intoxicar su caché haciendo que descargue una imagen especialmente diseñada que se consideraría un candidato de caché válido para algunos pasos de compilación. _El problema se corrigió en Moby >= v25.0.2 y >= v24.0.9._ ### ¿Cómo se ven afectados los productos de Docker? #### Docker Desktop Las versiones v4.27.0 y anteriores de Docker Desktop están afectadas. La versión v4.27.1 de Docker Desktop se lanzó el 1 de febrero e incluye parches de binarios para runc, BuildKit y dockerd. Además de actualizar a esta nueva versión, alentamos a todos los usuarios de Docker a utilizar diligentemente las imágenes y los Dockerfiles de Docker y a asegurarse de que solo utilizan contenido de confianza en sus compilaciones. Como siempre, debes revisar los requisitos del sistema de Docker Desktop para tu sistema operativo ([Windows](/desktop/setup/install/windows-install/#system-requirements), [Linux](/desktop/setup/install/linux/#general-system-requirements), [Mac](/desktop/setup/install/mac-install/#system-requirements)) antes de actualizar para garantizar una compatibilidad total. #### Docker Build Cloud Cualquier nueva instancia de constructor de Docker Build Cloud se aprovisionará con las últimas versiones de Docker Engine y BuildKit y, por lo tanto, no se verá afectada por estas CVEs. Las actualizaciones también se han implementado en los constructores existentes de Docker Build Cloud. _Ningún otro producto de Docker se ve afectado por estas vulnerabilidades._ ### Enlaces a avisos - Runc - [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv) - BuildKit - [CVE-2024-23650](https://github.com/moby/buildkit/security/advisories/GHSA-9p26-698r-w4hx) - [CVE-2024-23651](https://github.com/moby/buildkit/security/advisories/GHSA-m3r6-h7wv-7xxv) - [CVE-2024-23652](https://github.com/moby/buildkit/security/advisories/GHSA-4v98-7qmw-rqr8) - [CVE-2024-23653](https://github.com/moby/buildkit/security/advisories/GHSA-wr6v-9f75-vh2g) - Moby - [CVE-2024-24557](https://github.com/moby/moby/security/advisories/GHSA-xw73-rw38-6vjc) ## Text4Shell CVE-2022-42889 _Última actualización: octubre de 2022_ Se ha descubierto la vulnerabilidad [CVE-2022-42889](https://nvd.nist.gov/vuln/detail/CVE-2022-42889) en la popular biblioteca Apache Commons Text. Las versiones de esta biblioteca anteriores a la 1.10.0 se ven afectadas por esta vulnerabilidad. Te recomendamos encarecidamente actualizar a la última versión de [Apache Commons Text](https://commons.apache.org/proper/commons-text/download_text.cgi). ### Escanear imágenes en Docker Hub Los escaneos de seguridad de Docker Hub activados después de las 12:00 UTC del 21 de octubre de 2021 ahora identifican correctamente la CVE Text4Shell. Los escaneos anteriores a esta fecha no reflejan actualmente el estado de esta vulnerabilidad. Por lo tanto, te recomendamos activar los escaneos enviando nuevas imágenes a Docker Hub para ver el estado de la CVE Text4Shell en el informe de vulnerabilidades. Para obtener instrucciones detalladas, consulta [Escanear imágenes en Docker Hub](/docker-hub/repos/manage/vulnerability-scanning/). ### Docker Official Images afectadas por la vulnerabilidad CVE-2022-42889 Cierto número de [Docker Official Images](/docker-hub/image-library/trusted-content/#docker-official-images) contienen las versiones vulnerables de Apache Commons Text. A continuación se enumeran las Docker Official Images que pueden contener las versiones vulnerables de Apache Commons Text: - [bonita](https://hub.docker.com/_/bonita) - [Couchbase](https://hub.docker.com/_/couchbase) - [Geonetwork](https://hub.docker.com/_/geonetwork) - [neo4j](https://hub.docker.com/_/neo4j) - [sliverpeas](https://hub.docker.com/_/sliverpeas) - [solr](https://hub.docker.com/_/solr) - [xwiki](https://hub.docker.com/_/xwiki) Hemos actualizado Apache Commons Text en estas imágenes a la versión más reciente. Es posible que algunas de estas imágenes no sean vulnerables por otras razones. Te recomendamos que también revises las directrices publicadas en los sitios web de origen. ## Log4j 2 CVE-2021-44228 _Última actualización: diciembre de 2021_ La vulnerabilidad [Log4j 2 CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) en Log4j 2, una biblioteca de registro de Java muy común, permite la ejecución remota de código, a menudo desde un contexto que está fácilmente disponible para un atacante. Por ejemplo, se descubrió en servidores de Minecraft que permitían escribir los comandos en los registros de chat, ya que luego se enviaban al registrador. Esto la convierte en una vulnerabilidad muy seria, ya que la biblioteca de registro se usa ampliamente y puede ser sencilla de explotar. Muchos mantenedores de código abierto están trabajando arduamente con parches y actualizaciones para el ecosistema de software. Las versiones vulnerables de Log4j 2 son las versiones 2.0 a la versión 2.14.1 inclusive. La primera versión corregida es la 2.15.0. Te recomendamos encarecidamente actualizar a la [versión más reciente](https://logging.apache.org/log4j/2.x/download.html) si puedes. Si estás utilizando una versión anterior a la 2.0, tampoco eres vulnerable. Es posible que no seas vulnerable si utilizas estas versiones, ya que tu configuración puede mitigar esto o las cosas que registras pueden no incluir ninguna entrada del usuario. Sin embargo, esto puede ser difícil de validar sin comprender detalladamente todas las rutas de código que pueden registrar y de dónde pueden obtener entradas. Por lo tanto, probablemente querrás actualizar todo el código que utilice versiones vulnerables. > CVE-2021-45046 > > Como actualización a la vulnerabilidad [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), la solución realizada en la versión 2.15.0 estaba incompleta. Se han identificado problemas adicionales que se rastrean con [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) y [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105). > Para una solución más completa de esta vulnerabilidad, te recomendamos actualizar a la versión 2.17.0 cuando sea posible. ### Escanear imágenes en Docker Hub Los escaneos de seguridad de Docker Hub activados después de las 17:00 UTC del 13 de diciembre de 2021 ahora identifican correctamente las CVE de Log4j 2. Los escaneos anteriores a esta fecha no reflejan actualmente el estado de esta vulnerabilidad. Por lo tanto, te recomendamos activar los escaneos enviando nuevas imágenes a Docker Hub para ver el estado de la CVE de Log4j 2 en el informe de vulnerabilidades. Para obtener instrucciones detalladas, consulta [Escanear imágenes en Docker Hub](/docker-hub/repos/manage/vulnerability-scanning/). ## Docker Official Images afectadas por la CVE de Log4j 2 _Última actualización: diciembre de 2021_ Cierto número de [Docker Official Images](/docker-hub/image-library/trusted-content/#docker-official-images) contienen las versiones vulnerables de la CVE de Log4j 2-2021-44228. La siguiente tabla enumera las Docker Official Images que pueden haber contenido las versiones vulnerables de Log4j 2. Hemos actualizado Log4j 2 en estas imágenes a la versión más reciente. Es posible que algunas de estas imágenes no sean vulnerables por otras razones. Te recomendamos que también revises las directrices publicadas en los sitios web de origen. | Repositorio | Versión corregida | Documentación adicional | | :------------------------------------------------------ | :----------------------------- | :---------------------------------------------------------------------------------------------------------------------- | | [couchbase](https://hub.docker.com/_/couchbase) | 7.0.3 | [Couchbase blog](https://blog.couchbase.com/what-to-know-about-the-log4j-vulnerability-cve-2021-44228/) | | [Elasticsearch](https://hub.docker.com/_/elasticsearch) | 6.8.22, 7.16.2 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) | | [Flink](https://hub.docker.com/_/flink) | 1.11.6, 1.12.7, 1.13.5, 1.14.2 | [Flink advice on Log4j CVE](https://flink.apache.org/2021/12/10/log4j-cve.html) | | [Geonetwork](https://hub.docker.com/_/geonetwork) | 3.10.10 | [Geonetwork GitHub discussion](https://github.com/geonetwork/core-geonetwork/issues/6076) | | [lightstreamer](https://hub.docker.com/_/lightstreamer) | Esperando info | Esperando info | | [logstash](https://hub.docker.com/_/logstash) | 6.8.22, 7.16.2 | [Elasticsearch announcement](https://www.elastic.co/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2) | | [neo4j](https://hub.docker.com/_/neo4j) | 4.4.2 | [Neo4j announcement](https://community.neo4j.com/t/log4j-cve-mitigation-for-neo4j/48856) | | [solr](https://hub.docker.com/_/solr) | 8.11.1 | [Solr security news](https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228) | | [sonarqube](https://hub.docker.com/_/sonarqube) | 8.9.5, 9.2.2 | [SonarQube announcement](https://community.sonarsource.com/t/sonarqube-sonarcloud-and-the-log4j-vulnerability/54721) | | [storm](https://hub.docker.com/_/storm) | Esperando info | Esperando info | > [!NOTE] > > Aunque las imágenes de [xwiki](https://hub.docker.com/_/xwiki) pueden ser detectadas como vulnerables por algunos escáneres, los autores creen que las imágenes no son vulnerables por la CVE de Log4j 2 ya que los archivos jar de la API no contienen la vulnerabilidad. > La imagen de [Nuxeo](https://hub.docker.com/_/nuxeo) está en desuso (deprecated) y no será actualizada.