# Cómo leer un CVE y saber en diez minutos si te afecta > Un CVE es un identificador, no una alerta ni un parche. Así se lee la ficha, se comprueba si el código está expuesto y se prioriza con KEV y EPSS. > Por José Maldonado · Ciberseguridad · 2026-10-27 PHP fue el recordatorio de la semana. Los dos fallos divulgados el 21 de octubre, CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código sin credenciales en cualquier instalación del lenguaje que sirva páginas web, y el [aviso de CISA](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) remite en el mismo documento a las alertas de la NSA, del NCSC británico y del Centro Canadiense para la Ciberseguridad. El proyecto publicó cuatro versiones corregidas ese mismo día, de la 8.5.12 a la 8.2.35, y con actualizar a una de ellas el agujero queda cerrado. El problema no es que falten identificadores, sino que sobran y llegan sin contexto. Un boletín corporativo puede traerte cuarenta CVE en una mañana y ninguno tocarte, mientras el que sí te afecta aparece en la tercera línea de un correo que nadie ha leído. Saber cómo leer un CVE consiste en separar el número de lo que significa: qué código lleva el fallo, si ese código está en tu inventario, si alguien puede alcanzarlo desde fuera y si hay pruebas de que se esté explotando. Los datos públicos permiten ordenar ese ruido sin adivinar. El catálogo [KEV de CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), en su versión del 23 de octubre, reúne 1.756 vulnerabilidades con evidencia de explotación real, mientras el fichero diario de [EPSS](https://www.first.org/epss/) puntúa 395.308 CVE con una mediana de 0,0063 de probabilidad a 30 días. Menos del 0,5% de lo que se publica tiene prueba de que alguien lo esté usando para atacar. Con ese presupuesto de atención, la decisión se toma con un orden fijo y en diez minutos. ## ¿Qué es exactamente un CVE y qué no es? Un CVE es un identificador único que el programa CVE asigna a un fallo concreto, y en PHP lo asigna el propio proyecto como CNA, la autoridad que lo describe. No es una nota, ni una alerta, ni la prueba de que exista un exploit. La consecuencia práctica es que un CVE sin ficha no sirve de mucho, y la ficha es lo que se lee. El registro de CVE-2026-109618, publicado el 21 de octubre en el formato 5.2, trae la descripción técnica, las versiones afectadas, el vector que firma el propio proyecto y la referencia al aviso del fabricante. Ahí está lo que necesitas para decidir, y ahí empieza el trabajo que poca gente hace: leer el registro antes de mirar el número del titular. Conviene añadir una cosa que los boletines esconden: el identificador cuenta fallos, no despliegues. Los dos CVE de PHP describen primitivas distintas del mismo motor y se corrigen con la misma actualización, así que quien planifique dos ventanas de mantenimiento habrá duplicado el trabajo y el riesgo de dejar una rama a medias. ## ¿Cómo se lee una ficha campo a campo? La ficha se lee de arriba abajo, pero con un orden distinto al del documento, porque el dato que decide no es la nota. Empieza por las versiones, sigue por la descripción y deja el CVSS para el final: cuando llegues al vector ya sabrás si el resto te importa o no. Campo Qué te dice Qué decisión toma Descripción Qué condición dispara el fallo y qué logra quien lo explota Si el escenario encaja con tu despliegue Versiones afectadas El rango exacto, con la versión corregida al lado Si tu instalación cae dentro \`defaultStatus\` Qué ocurre con las versiones que no aparecen Si descartas el resto del inventario Vector CVSS 4.0 Condiciones del ataque e impacto, métrica a métrica Cuánto pesa si el código está expuesto CWE La familia de error del código Si toca parchear o basta mitigar Referencias Aviso del fabricante y de terceros Qué actualizar y qué comprobar después En el caso de PHP, el rango arranca en la rama 8.2 y llega hasta la 8.4.26, con la 8.5.11 como techo de la rama más nueva, y la ficha marca \`defaultStatus: unaffected\` para todo lo que queda fuera. Ese campo ahorra discusiones: un servidor con la 7.4 no entra en este fallo concreto. Y si tu versión aparece en la lista, el mismo registro te da la corregida y no hay nada que interpretar. El vector del ejemplo es \`CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N\`, que el proyecto puntúa 9.2 y etiqueta como crítica. La lectura útil está en dos letras: \`AC:H\` y \`AT:P\` significan que el ataque no funciona a la primera contra cualquier servidor, sino que depende de condiciones de ejecución y de ganar una carrera en memoria. No lo vuelve inofensivo, pero explica por qué un 9.2 no equivale a un exploit universal que se lanza en diez minutos. Ese número tampoco es el que parece. La [especificación CVSS 4.0](https://www.first.org/cvss/v4.0/specification-document) obliga a etiquetar cada puntuación, y lo que se publica es una CVSS-B: solo métricas base, con las de amenaza y entorno en el valor por defecto que asume el peor caso. El CWE completa la lectura con la familia del error, y el aviso enlazado te dice qué hacer con el sistema encendido. Siemens, por ejemplo, ya había añadido su equipo RUGGEDCOM APE1808 a la lista de productos afectados en el propio registro, porque el fallo viajaba dentro de un producto suyo que nadie habría buscado como PHP. ## ¿Tengo este código, es alcanzable y está expuesto? Con la ficha abierta, la pregunta que decide es más aburrida que la del titular: ¿está este código en algo que yo ejecuto? CISA lo advierte en el propio aviso, porque PHP suele viajar dentro de otros programas y su presencia no se ve a simple vista en el inventario. Un WordPress en un hosting compartido con mod\_php es el caso evidente; la consola de administración de un fabricante que embebe PHP también cuenta, aunque nadie la llame PHP en el recuento. La alcanzabilidad recorta la lista otra vez. Si el fallo se dispara al procesar una petición HTTP, todo lo que escuche en internet está al alcance de cualquiera; si vive en una librería que solo carga un binario interno conectado por un socket local, la probabilidad de que alguien llegue hasta ahí baja, aunque no desaparece. Anota el alcance de lo que compruebas, porque un negativo sin alcance se convierte en una excusa y no en una decisión. La exposición y el valor del activo son las dos piezas que ninguna base de datos pública te va a dar, y son justo las que separan dos decisiones opuestas con la misma versión instalada. Hay casos en los que el código vulnerable no es tuyo y aun así te alcanza. Los ocho certificados intermedios de eMudhra que los navegadores bloquearon el 17 de octubre no estaban en ningún servidor propio, pero sí en el almacén de confianza de los clientes que se conectaban a ellos, como repasamos al [reconstruir aquel incidente](https://observatorioblockchain.com/ciberseguridad/certificados-tls-emudhra-comprometidos/). Lo que decide es dónde está el código, no de quién es la máquina que lo ejecuta. ## ¿Cómo se prioriza cuando hay veinte fichas abiertas? El orden importa más que la fórmula. La secuencia que defiende el [marco de priorización de Software Security](https://softwaresecurity.com/frameworks/vulnerability-prioritization/) coloca la evidencia de explotación delante de cualquier nota y después añade los hechos locales que ninguna base de datos conoce. 1. Busca el CVE en el KEV y, si aparece, trátalo como urgencia con fecha. 2. Mira el EPSS del día con su fecha y la versión del modelo. 3. Lee el CVSS 4.0 o los valores de SSVC como consecuencia, nunca como probabilidad. 4. Confirma que el componente vulnerable está en el artefacto desplegado. 5. Comprueba alcanzabilidad y exposición, y cuenta lo desconocido como expuesto. 6. Ajusta el plazo por el valor del activo y guarda la evidencia. Los dos primeros pasos se resuelven con dos consultas. CISA añade una vulnerabilidad al KEV cuando hay identificador, evidencia fiable de explotación y una acción de remediación clara; el intento de explotación cuenta, mientras que un escaneo o una prueba de concepto pública no bastan. El EPSS de FIRST estima cada día la probabilidad de actividad de explotación observada en los próximos 30 días, y su cola es cortísima: en el fichero del 25 de octubre, el percentil 90 se queda en 0,0383. El EPSS no se multiplica por el CVSS, aunque sea tentador. FIRST advierte de que ese producto no tiene lectura interpretable, porque uno es una probabilidad calibrada y el otro una escala ordinal de severidad, así que multiplicar añade ruido con apariencia de rigor. El caso de Strapi que documenta ese mismo marco sirve para verlo en la práctica. CVE-2023-22894 entró en KEV el 8 de octubre con plazo de tres días, y al día siguiente el EPSS le daba 0,034, por debajo del percentil 90. Si hubieras ordenado la cola por EPSS, ese fallo se habría quedado al final. La lista de CISA ya lo había puesto el primero, y esa es la diferencia entre una política de parches y una política de espera. El movimiento contrario también existe. Los dos CVE de PHP tenían un EPSS del 5% el 22 de octubre y del 12% el 24, mientras el fichero del 25 les asigna casi el 100%, sin entrada en el KEV y sin aviso de explotación activa de CISA en las fuentes públicas que he consultado. Un salto así no dice qué pasó, pero demuestra que una foto de anteayer no sirve para decidir hoy: anota la fecha y la versión del modelo junto a cada puntuación. ## ¿Cuáles son los errores que más caro salen? El primero es parchear por la nota. Un 9.8 en una librería que solo usa un servicio interno sin salida a internet consume la ventana de mantenimiento que necesitaba el 7.0 del portal público, y ese intercambio se hace sin darse cuenta. La nota mide la consecuencia de un ataque exitoso en el peor supuesto, no la probabilidad de que alguien llegue a tu servidor concreto con el exploit adecuado. Ese primer error se arregla con una pregunta incómoda: qué rompe al parchear y qué rompe si no lo haces. La respuesta no está en ningún catálogo público, sino en tu mapa de servicios y en el calendario de guardias del equipo. El segundo es descartar un CVE porque su CVSS sea mediocre. Una nota baja no dice nada sobre si alguien lo está usando: un 6.5 con atacantes activos es una urgencia hoy mismo, mientras un 9.8 sin exploit público puede esperar al ciclo normal. Si el activo está expuesto y el fallo aparece en la lista de explotados, la discusión sobre el número sobra y solo retrasa el parche. El tercero es fiarse del escáner sin mirar la versión real. Los escáneres fallan en los dos sentidos: no ven PHP embebido en un producto de terceros, como avisa CISA, y a veces marcan como vulnerable un paquete que la distribución ya corrigió con un parche retroportado. Comprueba el número en el binario que corre y no en el fichero de dependencias, y contrasta con el aviso de la distribución cuando el paquete venga de un repositorio. ## El identificador abre la conversación Diez minutos bastan para saber si un CVE te toca, pero solo si aceptas que la respuesta puede ser «todavía no lo sé». El identificador te dice dónde mirar; el inventario, la exposición y la evidencia de explotación son los que toman la decisión, y esos datos los tienes tú, no el fabricante ni el catálogo de CISA. En el ciclo de octubre pasó con PHP y con las [vulnerabilidades del kernel de Linux](https://observatorioblockchain.com/ciberseguridad/vulnerabilidades-kernel-linux-octubre-2026-parche/), que llegaron con la misma prisa y con la misma pregunta de fondo. La próxima ficha que se abra en tu bandeja merece tres comprobaciones antes que cualquier otra: qué versión corre de verdad en el servidor, si el fallo está en el KEV y qué fecha lleva el EPSS que estés leyendo.