Continuando con nuestra serie de artículos sobre el grave problema de seguridad informática ocurrido en la penúltima semana de octubre de 2026, explicaremos cómo se clasifican los problemas de seguridad informática para luego advertir sobre ellos y facilitar el acceso a las soluciones. De lo que se trata es de separar la realidad de la falsa información proporcionada por el sensacionalismo y el odio al lenguaje de programación.

PHP2Shell fue una vulnerabilidad grave y explotada antes de que se hiciera pública su existencia y es una más en la serie de vulnerabilidades que se irán descubriendo en los próximos meses gracias al uso de la inteligencia artificial. Esto obligará a los responsables de servicios web a estar atentos a su aparición y a la de las soluciones.

Pero antes de seguir con el artículo, quiero destacar algunas aclaraciones sobre cosas que dije en el artículo anterior.

• Conexión a bases de datos: Cuando dije que a las bases de datos solo se puede acceder desde el servidor, hablaba de buenas prácticas, no de imposibilidades técnicas. Permitir el acceso solo desde el servidor garantiza que las credenciales solo las tengan quienes estén autorizados a realizar las operaciones de lectura, escritura, eliminación y actualización de datos. De esta forma se protege la información sensible.
• Distinción entre contenido PHP y no PHP: No necesariamente el contenido PHP debe estar separado del contenido HTML, siempre que esté entre etiquetas identificadoras. El contenido que no es PHP no se interpreta como código durante el procesamiento, pero se utiliza para dar formato a la salida.
• Generación de CSS: Aunque puede generar contenido en formatos CSS, JSON o HTML, la práctica habitual es que el contenido CSS esté en una hoja externa que se invoca desde una página con extensión .html o .php.
• Usos de PHP: Si bien, en su forma tradicional, PHP no puede usarse para comunicaciones en tiempo real, existen extensiones, aplicaciones y bibliotecas que le dan esa funcionalidad.
• Necesidad de un servidor: PHP no necesita un servidor web; se puede usar desde la línea de comandos o incluso mediante interfaces gráficas. Pero no está pensado para ese uso, por lo que, en general, los desarrolladores prefieren otras alternativas.
• Versiones y vulnerabilidades: Al ser un lenguaje de programación de más de 30 años, PHP tiene varias versiones y subversiones. No todas las vulnerabilidades que aparecen ni todos los parches que se publican afectan por igual. Lo ideal es actualizar cada vez que se publique una nueva versión estable.

Cómo se clasifican los problemas de seguridad informática

Para entender qué es PHP2Shell, debemos entender primero cómo funciona el sistema de detección y corrección de errores en informática.

El identificador CVE

Las letras CVE corresponden al acrónimo de Vulnerabilidades y Exposiciones Comunes (Common Vulnerabilities and Exposures) y se refieren a un sistema internacional estandarizado que contiene las vulnerabilidades de seguridad que se descubrieron y se hicieron públicas. Cada identificador adquiere esta forma:

• CVE: Como dijimos, indica que se trata de una vulnerabilidad común.
• AÑO: Indica el año en que se le asignó el ID o se hizo público el error.
• NÚMERO: Es el identificador secuencial único (debe tener un mínimo de cuatro dígitos.

El objetivo es que todas las personas involucradas en su detección, mitigación o solución sepan que se están refiriendo al mismo problema.

Las etapas entre el descubrimiento y la asignación del CVE son:

Etapa 1: Descubrimiento

Los errores en el software son detectados generalmente por investigadores, integrantes de la comunidad de desarrolladores, herramientas automatizadas, aficionados participantes de programas de caza de bugs y, en los últimos tiempos, por modelos de inteligencia artificial.

Etapa 2: Reporte confidencial

Si una persona detecta un bug y lo hace público antes de que los desarrolladores tengan tiempo de encontrar una solución, es una invitación abierta a los delincuentes informáticos para aprovecharlo. Lo ideal es que lo comunique en forma privada a los desarrolladores o a una entidad asignadora de CVE, dándoles un plazo prudencial para el desarrollo del parche.

Etapa 3: Validación y asignación del CVE

Una vez que se comprueba que el bug es reproducible y constituye un problema de seguridad, se le asigna un CVE. Esto puede hacerse de dos formas:

• En caso de que el desarrollador sea un CNA autorizado (como Microsoft, Google, GitHub o Red Hat), este se ocupa de generar y asignar el número CVE.
• En caso de que el desarrollador no lo sea, la solicitud se envía a la organización sin fines de lucro MITRE Corporation. Esta entidad, financiada por el gobierno de Estados Unidos, es la encargada de administrar el sistema CVE.

Etapa 4: Publicación

Ya sea que el parche esté listo o no, si se vence el plazo de confidencialidad, la corporación MITRE publica en su sitio web una entrada que contiene:

• El identificador CVE.
• Una breve descripción del fallo.
• Enlaces al aviso del fabricante y al parche, si está disponible.

Etapa 5: Agregado de información

Otra vez interviene el gobierno norteamericano, pero esta vez directamente a través del Instituto Nacional de Estándares y Tecnología (NIST, por sus siglas en inglés). El NIST maneja la Base de Datos Nacional de Vulnerabilidades (NVD). En esta base de datos se agrega la siguiente información:

• La puntuación CVSS (Common Vulnerability Scoring System): Es una nota del 0,0 al 10,0 que indica la gravedad del bug. Cuanto más alta, más grave.
• Clasificación CWE (Common Weakness Enumeration): Indica el tipo de fallo.
• Software afectado (usando el formato CPE, Common Platform Enumeration): Indica una lista exacta de las versiones vulnerables de los programas afectados.

¿Qué pasa fuera de Estados Unidos?

El artículo se concentró en el sistema norteamericano porque en la Unión Europea no existe una agencia centralizada para la clasificación de problemas informáticos y se apoya en la base de datos del NVD para su trabajo. Sin embargo, en los últimos tiempos está impulsando proyectos para reducir la dependencia de bases de datos extranjeras mediante el Centro Europeo de Competencia en Ciberseguridad (ECCC). Como parte de eso, 13 de mayo de 2025, la Agencia de la Unión Europea para la Ciberseguridad (ENISA) puso en marcha la EUVD (European Vulnerability Database), una base de datos europea de vulnerabilidades.

Además de la información de Mitre y NVD incluye:

• Información sobre desarrolladores de software y fabricantes de hardware.
• Detalle de los equipos de respuesta a incidentes.
• Información sobre vulnerabilidades explotadas.

Otras entidades de respuesta son:

• CERT-EU: Es un equipo de respuesta a incidentes informáticos que puedan afectar a las instituciones de la UE. Analiza las vulnerabilidades globales (CVE) y emite alertas específicas sobre cómo pueden afectar a las instituciones relacionadas.
• CSIRT nacionales: Cada país tiene el suyo (por ejemplo, CERT-ES en España). Actúan cuando se publica un CVE crítico (como PHP2Shell). Se ocupan de difundir la información en el idioma local y trabajar con las instituciones y empresas locales para solucionarlos.

Artículo original