• /
  • EnglishEspañolFrançais日本語한국어Português
  • Inicia sesiónComenzar ahora

Te ofrecemos esta traducción automática para facilitar la lectura.

En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.

Crea una propuesta

NR26-10: vulnerabilidades del entorno de ejecución de PHP (CVE-2026-109618, CVE-2026-109619)

|View as Markdown (English)

Vulnerability Identifier: NR26-10

Priority: Crítico

Resumen:

Se revelaron dos vulnerabilidades críticas (CVSS 9.2) en el entorno de ejecución de PHP. Afectan a las versiones de PHP 5.4.0 y posteriores que atienden requests web. El proyecto PHP publicó correcciones el 21 de octubre de 2026.

Los servicios de New Relic no se ven afectados, y New Relic no ha identificado ninguna evidencia de explotación de estas vulnerabilidades en su entorno. El agente PHP de New Relic se ejecuta dentro del propio entorno PHP de los clientes y no es en sí mismo el componente vulnerable.

Los clientes que ejecutan aplicaciones PHP, con o sin la instrumentación de New Relic, aún deben evaluar sus versiones de PHP.

Acción recomendada:

No se requiere ninguna acción con respecto a los servicios de New Relic. Sin embargo, New Relic recomienda encarecidamente a los clientes que ejecutan PHP que actualicen a una versión de PHP corregida (a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35). Si no puede actualizar de inmediato, aplique un conjunto de reglas de WAF que cubra estas CVE y limite la exposición a Internet de las aplicaciones afectadas hasta que pueda hacerlo.

Recomendaciones:

  • Paquetes de distribución:
    • Las distribuciones de Linux y los proveedores de LTS recibieron los parches por adelantado. Consulte con el proveedor para obtener paquetes actualizados.
  • Versiones al final de su vida útil (PHP 8.1 y anteriores):
    • Algunas distribuciones y proveedores de LTS proporcionan correcciones retroactivas, por lo que debe comunicarse con el proveedor o actualizar a una versión compatible. Debido a la gravedad, el equipo de seguridad de PHP también ha publicado correcciones retroactivas mínimas de código fuente para PHP 7.4, 8.0 y 8.1 para las organizaciones que compilan desde el código fuente o no tienen un proveedor de LTS.
  • Usuarios de rpms.remirepo.net:
    • Este respositorio mantenido por voluntarios no tendrá actualizaciones el día del lanzamiento. El equipo de PHP insta al usuario a cambiar a paquetes de distribución o compilar desde el código fuente.

Cuando no sea posible aplicar parches de inmediato, las organizaciones deben considerar aislar los recursos orientados a Internet de las redes públicas hasta que se aplique y verifique la corrección.

Mitigación temporal:

Solo una actualización corrige por completo estas vulnerabilidades. Las siguientes medidas reducen la exposición a rutas de ataque específicas, pero no hacen que una instalación sea segura.

CVE-2026-109618 (corrupción de OOM):

  • Establezca memory_limit = -1 de manera que la aplicación no pueda anularlo, como php_admin_value en el grupo FPM o en la configuración de Apache. Compruebe que ninguna configuración de grupo, directorio o aplicación vuelva a establecer un límite finito. Esto elimina el fallo de límite de memoria controlable, pero un fallo de asignación subyacente aún puede alcanzar la ruta de código vulnerable.

  • Establezca un post_max_size bajo: 8 M para la aplicación que no necesita cargas de archivos, 32 M si se requieren cargas. Mantenga upload_max_filesize por debajo de post_max_size.

  • Considere aplicar límites a nivel del servidor web o proxy para el tamaño de la request decodificada, la cantidad de campos de entrada, la cantidad de partes multiparte, la cantidad de encabezados y la profundidad de anidamiento. Estos límites también deben abarcar las requests sin un Content-Length utilizable.

  • Utilice un límite de memoria de contenedor o cgroup como límite de disponibilidad, preferiblemente con una política que elimine solo el proceso de trabajo afectado. No utilice RLIMIT_AS ni RLIMIT_DATA en su lugar, ya que pueden desencadenar el error de asignación vulnerable.

CVE-2026-109619 (estado global obsoleto):

  • Establezca session.upload_progress.enabled=0 y reinicie cada worker. Aplique esto en php.ini, un pool de FPM o una configuración de servidor que surta efecto antes del análisis de la solicitud. No confíe en ini_set() ni en FPM .user.ini. Esto bloquea las rutas de sesión confirmadas, pero no otras variantes.

  • En PHP 8.5, establezca fatal_error_backtraces=0 y reinicie cada worker. Esto bloquea únicamente la ruta de rastreo fatal confirmada.

  • Elimine las configuraciones por request no válidas o en desuso que emiten diagnósticos antes de la inicialización. Ocultar los diagnósticos con error_reporting, display_errors o @ no ayuda.

  • Solucione los errores fatales y los tiempos de espera de ejecución que pueden alcanzar los atacantes, incluidos los fallos en la devolución de llamada, el procesamiento de carga o importación y la limpieza.

Preguntas frecuentes:

  1. ¿Cómo puedo saber qué versión de PHP estoy usando?

    Ejecute php -v en el host o en el contenedor. Para la versión de PHP que ve New Relic, consulte los detalles del host o de la aplicación en la UI de New Relic.

  2. ¿Es necesario actualizar el agente PHP de New Relic?

    Las vulnerabilidades están en el entorno de ejecución de PHP, no en el agente. Actualizar PHP es la solución requerida.

  3. Estoy ejecutando una versión de PHP al final de su vida útil. ¿Qué debo hacer?

    PHP 8.1, 8.0 y todas las ramas 7.x y 5.x no recibirán correcciones oficiales. Compruebe si la distribución de Linux (como Ubuntu o AlmaLinux) ha publicado un parche retroportado y planifique una actualización a una rama compatible.

  4. ¿Cómo puedo saber si mis sistemas han sido objetivo?

    Revise los logs web y de WAF del 21 de octubre de 2026 en adelante. Los indicadores reportados públicamente incluyen el User-Agent php2shell-verify/1.0 y requests a /vuln.php. También busque procesos del servidor web o de PHP que generen comandos de shell, y archivos PHP nuevos o modificados en los directorios web.

  5. ¿Puede un WAF protegerme hasta que aplique el parche?

    Un WAF puede reducir el riesgo. Cloudflare ha publicado reglas de WAF de emergencia para estas vulnerabilidades, y otros proveedores pueden ofrecer una protección similar. Un WAF es una mitigación temporal, no un sustituto de la actualización de PHP.

  6. Tengo preguntas o inquietudes sobre estas vulnerabilidades. ¿A quién debo contactar?

    Si tiene alguna pregunta sobre estas vulnerabilidades en relación con los servicios de New Relic, abra un caso de soporte a través del soporte integrado en la aplicación o comuníquese con el representante de cuenta de New Relic.

Documentos de respaldo:

Información técnica de vulnerabilidades:

Para cualquier necesidad de soporte relacionada con esta comunicación, abra un caso de soporte a través del soporte en la aplicación.

Historial de publicación: 23 de octubre de 2026 - NR26-10 publicado

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.