--- title: "Revise su hosting de WordPress frente a la falla de imágenes HEIC" description: "Una revisión de diez minutos para la vulnerabilidad HEIC de WordPress: qué muestra Salud del sitio, qué preguntarle a su hosting y quién debería poder subir archivos." url: "https://webleveling.com/es/blog/vulnerabilidad-heic-de-wordpress-revise-su-hosting/" lang: "es" published: "2026-10-06" modified: "2026-10-06" author: "Cal Hewitt" tags: ["website-security","wordpress","website-maintenance"] image: "https://webleveling.com/og/blog-check-your-wordpress-host-for-image-library-flaws.jpg" alternates: en: "https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws.md" --- # Revise su hosting de WordPress frente a la falla de imágenes HEIC Una revisión de diez minutos para la vulnerabilidad HEIC de WordPress: qué muestra Salud del sitio, qué preguntarle a su hosting y quién debería poder subir archivos. ![Una laptop cerrada y una pequeña libreta con un lápiz junto a un aro de llaves de latón sobre un escritorio de madera.](https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws/wordpress-image-library-flaw-featured.jpg) Usted vio un titular que decía que una foto de iPhone manipulada puede llegar hasta un servidor de WordPress, y ahora se pregunta si su propio sitio está en el camino. Entra a su panel, quizás tiene algunas personas que suben imágenes, y no tiene idea de qué biblioteca de imágenes usa su hosting por debajo. Es una duda razonable, y puede obtener una respuesta clara en unos diez minutos sin tocar un servidor. La pregunta sobre la vulnerabilidad HEIC de WordPress se reduce a tres cosas: qué editor de imágenes usa su sitio, qué versión de libheif ejecuta su hosting y quién puede subir archivos. La primera la lee en su panel, la segunda se la pregunta al hosting, y la tercera la controla usted mismo. **Puntos clave** **Primero, Salud del sitio** Herramientas, Salud del sitio, Información, Manejo de medios muestra su editor de imágenes activo y sus versiones, y toma unos minutos. **Una pregunta al hosting** Pregunte qué paquete libheif usa el proceso web, y si la corrección de la versión 1.23.3 está aplicada o incorporada como backport. **Estreche la puerta** Elimine las cuentas sin uso que pueden subir archivos y desactive las subidas HEIC si su sitio no las necesita. ## Abra Salud del sitio y anote cinco datos WordPress muestra la configuración de manejo de imágenes dentro de su panel, así que no necesita acceso al servidor para el primer paso. Entre como administrador, abra **Herramientas**, luego **Salud del sitio**, después la pestaña **Información**, y expanda **Manejo de medios**. La [documentación de la pantalla Salud del sitio](https://wordpress.org/documentation/article/site-health-screen/) describe este panel, y se lee en menos tiempo del que le tomó leer este párrafo. Copie estos valores en una nota: - **Editor activo**: WordPress documenta que \`WP\_Image\_Editor\_Imagick\` aparece cuando Imagick está activo y \`WP\_Image\_Editor\_GD\` aparece cuando GD está activo. - **Número de versión y cadena de versión de ImageMagick**: Aparecen cuando Imagick está activo. - **Versión de Imagick**: La extensión de PHP que conecta WordPress con ImageMagick. - **Versión de GD y formatos de archivo compatibles**: Aparecen cuando GD está activo. - **Subida de archivos**: El panel muestra si la subida de archivos está habilitada. Después use la opción de exportar en la pestaña Información, o pegue en la nota toda la sección Manejo de medios. [WordPress también explica Salud del sitio](https://wordpress.org/documentation/site-health/) como una revisión general del estado del sitio, así que puede mirar las otras pestañas mientras está ahí. ![Una laptop cerrada junto a una pequeña libreta con marcas de lápiz y un lápiz atravesado sobre un escritorio de madera.](https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws/media-handling-notes-beside-closed-laptop.jpg) Anote el editor activo y las versiones antes de contactar a nadie. ## Entienda qué significa su editor activo El editor que anotó decide qué debe revisar el hosting. WordPress 6.7 agregó la conversión automática de HEIC a JPEG, y la [nota de Make WordPress sobre ese cambio](https://make.wordpress.org/core/2024/08/15/automatic-conversion-of-heic-images-to-jpeg-in-wordpress-6-7/) dice que ocurre cuando el servidor tiene Imagick con compatibilidad con HEIC. La conversión se hace en el servidor, así que un archivo HEIC subido puede llegar a ImageMagick y a libheif antes de que WordPress haga la copia en JPEG. Hacia dónde apunta su resultado de Salud del sitio | Editor activo | Qué sugiere | Qué preguntarle al hosting | | --- | --- | --- | | Imagick | Es posible que HEIC se decodifique en el servidor mediante ImageMagick y libheif | Qué paquete y versión de libheif usa el proceso web, y si la corrección está aplicada | | GD con HEIC en los formatos compatibles | Es posible que GD maneje HEIC en este servidor | Qué biblioteca usa GD para HEIC y cuál es su versión | | GD sin HEIC en los formatos compatibles | Es posible que un archivo HEIC se rechace en lugar de decodificarse | Si algún otro proceso de la cuenta decodifica HEIC | Es posible que Salud del sitio no nombre el paquete exacto de libheif. Por eso el siguiente paso va dirigido a su hosting. ## Envíe a su hosting un mensaje específico Su hosting controla los paquetes del sistema operativo, así que el estado de la corrección tiene que venir de ellos. Envíe los datos de Manejo de medios junto con una pregunta que sea difícil de responder con una tranquilización general. Puede pegar esto: \> ¿Qué paquete y versión de libheif usa el proceso web de este sitio de WordPress para decodificar HEIC o HEIF? ¿Está aplicada o incorporada como backport la corrección del aviso GHSA-x8r2-mggj-j6wr, y se puede desactivar la decodificación de HEIC si el sitio no la necesita? Agregue que desea la respuesta por escrito y con fecha. Los datos útiles en una respuesta son la versión y la compilación del paquete, si los códecs están habilitados y dónde ocurre la decodificación (PHP-FPM, Apache o un proceso aparte). Una frase como «WordPress está actualizado» responde a otra capa. El núcleo de WordPress y las bibliotecas de imágenes del sistema operativo se actualizan por separado, así que pregunte por la biblioteca en sí. ![Una sola ficha con unas pocas líneas de lápiz ilegibles apoyada contra una pequeña campana de escritorio de latón sobre una mesa de madera lisa.](https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws/host-support-note-on-index-card.jpg) Una pregunta escrita, enviada una sola vez, le da una respuesta con fecha para conservar. ## Sepa qué dice el aviso de libheif (publicado el 1 de septiembre de 2026) Esta es la única sección sobre la noticia, y todo lo que contiene proviene de los registros de los propios responsables del proyecto. El proyecto libheif publicó el aviso de GitHub [GHSA-x8r2-mggj-j6wr](https://github.com/strukturag/libheif/security/advisories/GHSA-x8r2-mggj-j6wr) el 1 de septiembre de 2026. Lo califica como Crítico y enumera las versiones 1.18.0 a 1.23.2 de libheif como afectadas, con la 1.23.3 como la versión corregida. La falla es un desbordamiento de búfer en el montón, en el decodificador \`unci\` sin comprimir, que se activa cuando componentes de croma emparejados tienen profundidades de bits distintas. El aviso describe una ruta demostrada de divulgación de archivos y ejecución de código en una implementación exacta: WordPress con PHP Imagick, ImageMagick y libheif. Indica que la explotación depende de la compilación y de la implementación. No lleva número CVE, y las [notas de la versión](https://github.com/strukturag/libheif/releases) del proyecto lo incluyen con una entrada CVE provisional, así que busque el identificador GHSA cuando lo consulte. Un segundo aviso, [GHSA-2jg2-4ch7-h545](https://github.com/strukturag/libheif/security/advisories/GHSA-2jg2-4ch7-h545), se publicó el 25 de agosto de 2026, afecta las versiones hasta la 1.23.1 y se corrigió en la 1.23.2. Los sitios de noticias de seguridad cubrieron la investigación sobre el exploit de WordPress el 5 de octubre de 2026, cuando el aviso ya era público. La [política de seguridad](https://github.com/strukturag/libheif/security) de libheif es donde el proyecto dice que trata los errores de seguridad de memoria en los decodificadores como problemas de seguridad y que solo ofrece correcciones de seguridad para la versión más reciente. Esa es la razón para pedirle a su hosting un número de versión: una compilación anterior a la 1.23.3 es la que hay que parchar, y un paquete más antiguo de una distribución puede traer la corrección como backport, por eso la pregunta incluye esa palabra. La exposición requiere varias cosas a la vez. Requiere una ruta del servidor que decodifique HEIC mediante una compilación afectada de libheif, una vía de subida que acepte el archivo y una cuenta con la capacidad \`upload\_files\`. Su resultado de Salud del sitio y la respuesta de su hosting cubren lo primero. La siguiente sección cubre lo último. ## Limite quién puede subir archivos La [documentación de roles y capacidades](https://wordpress.org/documentation/article/roles-and-capabilities/) de WordPress identifica \`upload\_files\` como la capacidad que controla las subidas a la Biblioteca de medios. Los roles predeterminados de Autor y Editor la tienen, y el rol de Colaborador no. Así que, cada cuenta de Autor o Editor de su sitio, incluidas las antiguas, es una persona que puede enviar un archivo a la biblioteca de imágenes de su servidor. Dedique diez minutos a la pantalla de **Usuarios**: 1. Elimine las cuentas de personas que ya no trabajan con usted. 2. Baje el rol de quien no necesite subir imágenes. 3. Desactive el registro público en **Ajustes**, luego **Generales**, a menos que lo necesite. 4. Revise los roles personalizados, porque un rol personalizado también puede tener \`upload\_files\`. 5. Asegúrese de que cada cuenta restante tenga su propia contraseña segura, y de que quienes la usan sean las personas que usted espera. Cada cuenta que elimine es una vía menos para que un archivo llegue al servidor, y toda la lista se revisa en unos minutos. ![Un aro de llaves de latón sencillas sobre una bandeja de madera, con una llave colocada aparte de las demás.](https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws/upload-keys-set-apart-on-tray.jpg) Cada cuenta que puede subir archivos es una llave. Conserve solo las que se usan. ## Desactive las subidas HEIC si no las necesita Si nadie de su equipo envía fotos directamente desde un iPhone, rechazar los archivos HEIC y HEIF antes de que el servidor los decodifique elimina la ruta que describe el aviso. Pídale a su hosting o a su desarrollador que bloquee esos tipos de archivo, y luego pruebe una subida normal de JPEG y PNG para que su equipo pueda seguir agregando imágenes. Si su equipo sí sube fotos de iPhone, mantenga HEIC activado hasta que el hosting confirme libheif 1.23.3 o una corrección incorporada como backport. WordPress 7.1 agrega el procesamiento de medios del lado del cliente, descrito en una [nota de Make WordPress del 22 de julio de 2026](https://make.wordpress.org/core/2026/07/22/client-side-media-processing-in-wordpress-7-1/). Donde está activo, puede reducir cuánto manejo de HEIC ocurre en el servidor. Las versiones anteriores y las rutas del lado del servidor siguen necesitando la respuesta del hosting, así que siga enviando la pregunta. ## Esté atento a las señales que exigen una respuesta Una biblioteca parchada y una lista corta de cuentas que suben archivos lo dejan en buena posición. Revise el sitio de vez en cuando en busca de estas señales, y trate cualquiera de ellas como un motivo para actuar: - Usuarios que no reconoce. - Archivos PHP modificados, o archivos nuevos en la carpeta de subidas u otros directorios públicos. - Redirecciones que usted no configuró. - Advertencias de malware, una suspensión del hosting o reportes de abuso por tráfico saliente. - Fallos inexplicables de PHP, o actividad en la Biblioteca de medios que no reconoce. Si ve alguna, la [guía de WordPress para un sitio hackeado](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) enumera los pasos. En resumen: conserve una copia de la evidencia, contacte al hosting, analice los archivos y la base de datos, y cambie las credenciales después de la limpieza. Nuestro artículo sobre [qué hacer en las primeras 24 horas después de un hackeo](https://webleveling.com/es/blog/hackearon-mi-sitio-web-que-hacer/) explica ese orden. Tenga una copia de seguridad actual antes de cambiar algo, y nuestra guía para [respaldar el sitio web de una pequeña empresa](https://webleveling.com/es/blog/como-hacer-copia-de-seguridad-de-un-sitio-web-de-negocio/) cubre la rutina. ![Un disco duro externo junto a un cuaderno de espiral cerrado con un bolígrafo encima, sobre un escritorio ordenado.](https://webleveling.com/blog/check-your-wordpress-host-for-image-library-flaws/backup-drive-beside-closed-notebook.jpg) Haga una copia de seguridad nueva antes de cambiar ajustes o de pedirle a un hosting que cambie los suyos. ## Mantenga esta revisión separada de las actualizaciones de plugins Sus plugins son otra capa. Un aviso de un plugin se corrige desde su panel, y un aviso de una biblioteca de imágenes lo corrige su hosting en el servidor. Nuestro artículo sobre [revisar los plugins de WordPress en busca de actualizaciones de seguridad urgentes](https://webleveling.com/es/blog/revisar-plugins-de-wordpress-actualizaciones-de-seguridad/) cubre el lado del panel, y el artículo sobre la [advertencia de vulnerabilidad en plugins de WordPress](https://webleveling.com/es/blog/alerta-de-vulnerabilidad-de-plugin-de-wordpress/) explica cómo leer esos avisos. Si su hosting no puede nombrar la versión de la biblioteca que usted ejecuta, es útil saberlo cuando lea nuestra guía para [elegir un hosting web para una pequeña empresa](https://webleveling.com/es/blog/alojamiento-web-barato-para-un-pequeno-negocio/). Los registros del servidor también son donde puede ver qué visitantes automatizados llegan a su sitio, algo que cubre nuestro artículo sobre [ver qué agentes de IA visitan su sitio web](https://webleveling.com/es/blog/vea-que-agentes-de-ia-visitan-su-sitio-web/). ## Decida cuándo pedir ayuda Usted puede hacer la primera pasada: Salud del sitio, el mensaje al hosting, la limpieza de usuarios y el ajuste de HEIC. Pida ayuda cuando el hosting no pueda nombrar la biblioteca, cuando maneje más de un sitio o una copia de pruebas, cuando haya que desactivar HEIC sin romper las subidas de su equipo, o cuando vea cualquiera de las señales anteriores. Una [auditoría de seguridad del sitio web](https://webleveling.com/es/servicios/auditoria-de-seguridad-web/) relaciona los ajustes que usted ve en WordPress con la biblioteca que el servidor realmente carga, revisa la respuesta del hosting y termina con una lista escrita de lo que hay que cambiar. El [mantenimiento del sitio web](https://webleveling.com/es/servicios/mantenimiento-de-sitios-web/) continuo y el [hosting](https://webleveling.com/es/servicios/alojamiento-web/) cubren las actualizaciones posteriores. **Cuestionario: ¿Está listo para revisar su biblioteca de imágenes?** 1. ¿Dónde encuentra en WordPress su editor de imágenes activo? - Apariencia, luego Temas - Herramientas, luego Salud del sitio, luego Información, luego Manejo de medios **(respuesta correcta)** - Ajustes, luego Lectura - Plugins, luego Plugins instalados 2. ¿Qué versión de libheif indica el aviso como la corrección? - 1.18.0 - 1.23.2 - 1.23.3 **(respuesta correcta)** - 1.17.9 3. Su hosting responde «WordPress está actualizado». ¿Qué debería preguntar a continuación? - Nada, eso lo responde todo - Qué paquete y versión de libheif usa el proceso web, y si la corrección está aplicada o incorporada como backport **(respuesta correcta)** - Si debería reinstalar WordPress - Si su tema está al día ## Preguntas frecuentes sobre la vulnerabilidad HEIC de WordPress **¿Existe un CVE para el problema de WordPress con HEIC y libheif?** El aviso GHSA-x8r2-mggj-j6wr de libheif no lleva número CVE. Busque el identificador GHSA o consulte las notas de la versión de libheif. **¿Qué versiones de libheif están afectadas?** El aviso enumera las versiones 1.18.0 a 1.23.2 de libheif, con la 1.23.3 como la versión corregida. **¿Todos los sitios de WordPress usan libheif?** No. Depende de si su servidor decodifica HEIC mediante ImageMagick y libheif, algo que muestran su resultado de Salud del sitio y la respuesta de su hosting. **¿Dónde reviso si mi sitio usa Imagick o GD?** Abra Herramientas, luego Salud del sitio, luego Información, luego Manejo de medios, y lea la línea Editor activo. **¿Puede un Autor subir medios en mi sitio?** Sí. Los roles predeterminados de Autor y Editor de WordPress tienen la capacidad \`upload\_files\`, y el rol de Colaborador no. **¿Una versión actual de WordPress significa que el servidor está parchado?** No. El núcleo de WordPress y las bibliotecas de imágenes del servidor se actualizan por separado, así que pídale al hosting la versión de libheif. ## Para cerrar Revise su biblioteca de imágenes en tres pasos: lea Salud del sitio, envíe a su hosting la pregunta sobre libheif y limite quién puede subir archivos. El aviso tiene fecha del 1 de septiembre de 2026, enumera las versiones 1.18.0 a 1.23.2 de libheif como afectadas y nombra la 1.23.3 como la corrección. Las respuestas de su hosting le dicen en qué situación está su sitio. Cuando tenga la respuesta del hosting archivada, la misma nota sirve para el próximo aviso de una biblioteca, y su lista de usuarios se mantiene lo bastante corta para revisarla en pocos minutos. Una respuesta por escrito, una copia de seguridad y una lista ordenada de cuentas hacen que las actualizaciones posteriores sean más rápidas de manejar. Si quiere una segunda opinión, [Web Leveling](https://webleveling.com/es/) puede relacionar lo que muestra Salud del sitio con lo que ejecuta su servidor, revisar la respuesta del hosting y darle una lista escrita de cambios mediante nuestra [auditoría de seguridad del sitio web](https://webleveling.com/es/servicios/auditoria-de-seguridad-web/). Trabajamos con pequeñas y medianas empresas de todo el país y del extranjero. [Envíenos los datos de Manejo de medios y la respuesta del hosting](https://webleveling.com/es/contacto/), y los revisaremos con usted. ## Términos Palabras sobre bibliotecas de imágenes en este artículo Toque un término para ver qué significa. **libheif.** Una biblioteca de código abierto que lee archivos de imagen HEIC y HEIF. **HEIC.** El formato de imagen que los iPhone usan de forma predeterminada para las fotos. **Imagick.** Una extensión de PHP que permite a WordPress usar ImageMagick para procesar imágenes. **GD.** Una biblioteca gráfica de PHP que WordPress puede usar en lugar de Imagick. **upload\_files.** La capacidad de WordPress que permite a una cuenta agregar archivos a la Biblioteca de medios. **GHSA.** Un identificador de aviso de seguridad de GitHub, que se usa cuando un problema no tiene número CVE. **Backport.** Una corrección de seguridad aplicada a una versión anterior de un paquete sin pasar a la versión más reciente. - [Cómo revisar los plugins de WordPress en busca de actualizaciones de seguridad](https://webleveling.com/es/blog/revisar-plugins-de-wordpress-actualizaciones-de-seguridad/): Haga la revisión de seguridad de sus plugins de WordPress en unos diez minutos: liste cada plugin, compare versiones con los avisos, respalde, actualice sin riesgo y reconozca las señales de alerta. - [Seguridad de Elementor 4.3.2: instálela y revise sus administradores](https://webleveling.com/es/blog/vulnerabilidad-de-elementor-crea-administradores/): Elementor 4.3.2 corrige la falla de 4.3.0 y 4.3.1 que deja que un enlace manipulado cree un administrador de WordPress. Instálela, revise Usuarios y vea qué pasa con Pro. - [Actualización de seguridad de WordPress 7.1.2: qué hacer hoy](https://webleveling.com/es/blog/actualizacion-de-seguridad-wordpress-7-1-2/): WordPress 7.1.2 corrige una falla crítica que los atacantes empezaron a sondear en horas. Sepa qué revisar hoy, cómo actualizar con seguridad y las señales de que hubo compromiso.