Sans
Préstamo en curso
Gamma
Verificación en dos pasos activada
Parches desplegados a tiempo! es hora te hacer pruebas para como afecta un entorno vulnerable
Leex
Épsilon
Verificación en dos pasos activada
Ahora sí todo el mundo está blindado!!!!!!!! :v Yijaaaaaaaaaaaaaaaaaaaaaa. Por cierto, el comentario del 70% más a mi favor, ¿sabes cuántas ventas en internet de themes? Por ejemplo, yo soy el vivo ejemplo: dejé de comprar themes originales de WP, bonitos y todo eso, ya que indexaban bien en Google, full SEO y todo lo configuraba yo bien chido y :v lo que viven es metiendo la pata. Dejé de invertir en themes.
perez2005
Épsilon
Verificado
Verificación en dos pasos activada
Verificado por Binance
Hasta el FBI sacó comunicado, debe ser algo grave entonces
Tronlar
Gamma
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Sí, también lo he visto y es cierto.
La división de ciberseguridad del FBI alertó sobre las dos vulnerabilidades de PHP (CVE-2026-109618 y CVE-2026-109619) y recomendó actualizar cuanto antes.
Incluso indicaron que, si no era posible aplicar la actualización inmediatamente, se valorase dejar temporalmente fuera de línea los sistemas vulnerables.
Así que sí, parece que esta vez la cosa iba bastante en serio 😅
Fuente: Associated Press, que recoge la alerta del FBI:
https://apnews.com/article/php-websites-fbi-europe-vulnerability-a0af9576808a0963efca8df14d4b5183
soyjuli_us
Beta
SEO
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Creo que estamos entrando en una etapa bastante interesante, pero también complicada para quienes trabajamos con desarrollo e infraestructura.
Con herramientas como REA (Reverse Engineer Anything) y los avances de la inteligencia artificial, la ingeniería inversa y el análisis de código están alcanzando niveles de automatización que antes requerían muchísimo más tiempo y conocimiento especializado.
Mi impresión es que en los próximos meses y años veremos aparecer una cantidad importante de vulnerabilidades que probablemente llevan mucho tiempo ocultas.
Nos espera un proceso largo de descubrimientos, parches, actualizaciones y seguramente las eternas discusiones sobre cuál lenguaje o tecnología es más seguro. 😅
Pero también veo algo positivo: esta presión puede obligar a mejorar las prácticas de desarrollo, auditoría y mantenimiento del software.
La IA está cambiando las reglas del juego, tanto para quienes buscan vulnerabilidades como para quienes tenemos que defender la infraestructura.
Y creo que apenas estamos comenzando.😅
Con herramientas como REA (Reverse Engineer Anything) y los avances de la inteligencia artificial, la ingeniería inversa y el análisis de código están alcanzando niveles de automatización que antes requerían muchísimo más tiempo y conocimiento especializado.
Mi impresión es que en los próximos meses y años veremos aparecer una cantidad importante de vulnerabilidades que probablemente llevan mucho tiempo ocultas.
Nos espera un proceso largo de descubrimientos, parches, actualizaciones y seguramente las eternas discusiones sobre cuál lenguaje o tecnología es más seguro. 😅
Pero también veo algo positivo: esta presión puede obligar a mejorar las prácticas de desarrollo, auditoría y mantenimiento del software.
La IA está cambiando las reglas del juego, tanto para quienes buscan vulnerabilidades como para quienes tenemos que defender la infraestructura.
Y creo que apenas estamos comenzando.😅
Leex
Épsilon
Verificación en dos pasos activada
Así mismo es!!!
LA IA es buenísima, te ayuda mucho, pero también todo esto en resumen, más dolores de cabeza xD.
Carlos Frias
1
Ro
Verificación en dos pasos activada
Verificado por Binance
¡Usuario popular!
Suscripción a IA
Sobre lo que se comentó de que el primer parche no funcionaba, ya hay una novedad oficial que conviene añadir al hilo, pero con sus condiciones concretas.
PHP publicó el 23 de octubre un aviso adicional sobre el progreso de subida de sesiones, asociado a CVE-2026-115560. Describe una combinación poco habitual: configurar session.serialize_handler como php_binary o php_serialize, cambiarlo a php durante la ejecución antes de session_start(), y mantener habilitado el progreso de subida. Recomiendan desactivar esa función hasta la próxima versión correctiva. Si ya la desactivaste siguiendo el aviso anterior, indican mantenerla así.
Eso merece atención, pero no demuestra por sí solo que las «tres vías» mencionadas antes sean tres bypass confirmados del parche. Para afirmar eso haría falta la referencia técnica, la compilación probada y las condiciones de reproducción. Los dos CVE originales tienen sus correcciones publicadas; este aviso posterior hay que tratarlo con su propio alcance.
La directiva es esta, aplicada en el php.ini o en la configuración administrativa que carga el PHP de la web antes de procesar las peticiones:
Con FPM no contaría con ponerla en .user.ini ni con un ini_set() dentro de la aplicación. Después hay que reiniciar todos los workers afectados y comprobar su configuración. Esto no sustituye actualizar el intérprete para los dos fallos originales, y puede afectar a las barras de progreso que dependan de esa función.
En mi empresa y con servidores de clientes pasé dos días revisando este incidente; se sumaron también los avisos independientes de Node.js y Java. Lo que más trabajo dio fue comprobar qué estaba ejecutándose de verdad: había varias ramas, procesos que seguían con el binario anterior y componentes con su propio runtime. Por eso no daría por terminada la intervención viendo únicamente que el panel se actualizó o que una descarga acabó bien.
La revisión forense fue otra parte del trabajo: cruzar peticiones, registros del WAF, errores de procesos, archivos modificados y mecanismos de persistencia. Una petición con firma del exploit acredita un intento; para hablar de ejecución exitosa hacen falta más pruebas. Tampoco una fecha reciente en un PHP basta para llamarlo webshell: puede ser una actualización legítima, y hay que contrastarlo antes de tocarlo.
En lo que revisé no encontré evidencia de explotación exitosa. Eso tiene un alcance concreto y no lo convertiría en «todos estamos blindados». El cierre que le puedo explicar a un cliente es qué runtime y compilación quedaron verificados, qué procesos se renovaron, qué rastros se revisaron y qué limitaciones tuvo esa revisión.
Dejo la actualización del 23, que es la fuente para ese escenario adicional: https://www.php.net/archive/2026.php#2026-10-23-1
PHP publicó el 23 de octubre un aviso adicional sobre el progreso de subida de sesiones, asociado a CVE-2026-115560. Describe una combinación poco habitual: configurar session.serialize_handler como php_binary o php_serialize, cambiarlo a php durante la ejecución antes de session_start(), y mantener habilitado el progreso de subida. Recomiendan desactivar esa función hasta la próxima versión correctiva. Si ya la desactivaste siguiendo el aviso anterior, indican mantenerla así.
Eso merece atención, pero no demuestra por sí solo que las «tres vías» mencionadas antes sean tres bypass confirmados del parche. Para afirmar eso haría falta la referencia técnica, la compilación probada y las condiciones de reproducción. Los dos CVE originales tienen sus correcciones publicadas; este aviso posterior hay que tratarlo con su propio alcance.
La directiva es esta, aplicada en el php.ini o en la configuración administrativa que carga el PHP de la web antes de procesar las peticiones:
INI:
session.upload_progress.enabled = OffCon FPM no contaría con ponerla en .user.ini ni con un ini_set() dentro de la aplicación. Después hay que reiniciar todos los workers afectados y comprobar su configuración. Esto no sustituye actualizar el intérprete para los dos fallos originales, y puede afectar a las barras de progreso que dependan de esa función.
En mi empresa y con servidores de clientes pasé dos días revisando este incidente; se sumaron también los avisos independientes de Node.js y Java. Lo que más trabajo dio fue comprobar qué estaba ejecutándose de verdad: había varias ramas, procesos que seguían con el binario anterior y componentes con su propio runtime. Por eso no daría por terminada la intervención viendo únicamente que el panel se actualizó o que una descarga acabó bien.
La revisión forense fue otra parte del trabajo: cruzar peticiones, registros del WAF, errores de procesos, archivos modificados y mecanismos de persistencia. Una petición con firma del exploit acredita un intento; para hablar de ejecución exitosa hacen falta más pruebas. Tampoco una fecha reciente en un PHP basta para llamarlo webshell: puede ser una actualización legítima, y hay que contrastarlo antes de tocarlo.
En lo que revisé no encontré evidencia de explotación exitosa. Eso tiene un alcance concreto y no lo convertiría en «todos estamos blindados». El cierre que le puedo explicar a un cliente es qué runtime y compilación quedaron verificados, qué procesos se renovaron, qué rastros se revisaron y qué limitaciones tuvo esa revisión.
Dejo la actualización del 23, que es la fuente para ese escenario adicional: https://www.php.net/archive/2026.php#2026-10-23-1
Tronlar
Gamma
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
PHP2Shell: CISA añade CVE-2026-109618 y CVE-2026-109619 a su catálogo KEV
CISA añadió el 26 de octubre las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell, a su catálogo de vulnerabilidades explotadas conocidas (KEV).
Son vulnerabilidades del propio PHP que, bajo determinadas condiciones, pueden permitir ejecución remota de código (RCE) sin autenticación.
Además de su inclusión en KEV, ya se ha observado actividad intentando explotarlas y existen pruebas de explotación con RCE exitoso en honeypots.
¿Qué versiones están corregidas?
Las actualizaciones de PHP que solucionan el problema se publicaron el 21 de octubre.Para las ramas actuales:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
Por ejemplo, Plesk ya ha publicado actualizaciones específicas para las versiones de PHP que distribuye.
No es un problema exclusivo de WordPress
Esto no es una vulnerabilidad de WordPress ni de un CMS concreto, sino de PHP.Por tanto, puede afectar a servidores que tengan WordPress, Joomla, Drupal, scripts propios u otras aplicaciones PHP, siempre que estén utilizando una versión vulnerable y se den las condiciones necesarias para explotarla.
Si administráis vuestro propio VPS o servidor, yo comprobaría qué versión de PHP está funcionando y actualizaría cuanto antes si está afectada.
Tener firewall, cerrar puertos que no utilizamos, etc. ayuda, pero no sustituye las actualizaciones de seguridad del propio PHP.
¿Cuántos servidores pueden estar expuestos?
Censys ha creado un tracker específico para PHP2Shell utilizando sus escaneos de Internet:https://php2shell.censys.com/
Permite ver la evolución de las versiones de PHP observadas en Internet, hosts potencialmente afectados, países, redes, etc.
Importante: que Censys detecte una versión aparentemente vulnerable no significa automáticamente que ese servidor sea explotable. Puede existir un parche aplicado por el proveedor o distribución sin cambiar el número de versión, y también depende de la configuración del servidor.
Para quien tenga curiosidad por infraestructura y dispositivos expuestos en Internet, también está el dashboard de Shadowserver:
https://dashboard.shadowserver.org/
Ahí se pueden consultar estadísticas de servicios y dispositivos expuestos, vulnerabilidades observadas, fabricantes, modelos, países, etc.
Fuentes
CISA KEV:https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Censys - PHP2Shell Exposure Tracker:
https://php2shell.censys.com/
Shadowserver Dashboard:
https://dashboard.shadowserver.org/
Plesk - CVE-2026-109618 / CVE-2026-109619:
https://support.plesk.com/hc/en-us/...mote-code-execution-in-PHP-shipped-with-Plesk
The Record - PHP vulnerabilities añadidas al KEV:
https://therecord.media/php-vulnerabilities-cisa-kev
Si tenéis un VPS administrado por vosotros, yo echaría un vistazo a la versión de PHP que tenéis instalada por si acaso.
Leex
Épsilon
Verificación en dos pasos activada
Nojo y yo pensando que era WordPress!! XDDDDDDDD ya estaba hasta creando aparte una web en Node.js, ahí practicando, y nuestro amigo @CARLOS Frías sacó también que Nodejs también tiene sus debilidades :v jaja
Temas similares
