El 70% de internet corre sobre un proyecto con un solo empleado a jornada completa
Cerca del 70% de los sitios web que declaran un lenguaje de servidor usan PHP, según W3Techs. Pero la organización que sostiene ese software tiene una estructura que sorprende: Elizabeth Barron, directora ejecutiva de The PHP Foundation, es su única empleada a jornada completa. El resto son 14 contratistas, en su mayoría a tiempo parcial, más una junta directiva voluntaria. La financiación llega de donaciones y subvenciones.
Esa proporción —el lenguaje que mueve WordPress, Drupal o Magento frente a un equipo que cabe en una sala pequeña— deja de ser una anécdota cuando aparecen fallos de seguridad. Y eso es exactamente lo que ocurrió esta semana con PHP2Shell.
Qué es PHP2Shell y por qué se parcheó un día antes de lo previsto
La fundación publicó dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9,2 sobre 10 en el sistema CVSS. Permiten que un atacante no autenticado ejecute código en el servidor y lea memoria de procesos, donde pueden viajar contraseñas, tokens de autenticación, claves de API y certificados, según la investigación de Wiz recogida por WIRED.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasEl alcance es enorme: afecta a todas las instalaciones de PHP que sirven peticiones web, desde la versión 5 publicada en julio de 2004, aunque solo las ramas 8.2 y posteriores reciben parche. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según Help Net Security. La propia fundación fue tajante: «No hay mitigaciones completas, actualizar es la única opción segura».
La cronología: de una revisión interna en 2024 a millones de intentos de ataque
El problema no nació esta semana. La fundación identificó una de las vulnerabilidades en 2024, durante una revisión de seguridad, pero entonces no encontró una vía de explotación conocida y su corrección era compleja. La historia se completó en 2026 desde fuera: Calif avisó al equipo el 11 de agosto, OpenAI llegó por su cuenta y Wiz informó el 24 tras cinco días de investigación.
El 20 de octubre se filtraron los identificadores de los dos fallos y el proyecto adelantó un día la publicación del parche. Cloudflare registró después millones de intentos de ataque, según contó su CEO a Reuters. Antes de eso, Amazon asegura que su red de señuelos MadPot detectó un intento el 17 de octubre procedente de una IP anonimizada, cuatro días antes de la divulgación pública. La fundación, en cambio, dice no tener evidencia de explotación real antes de la publicación ni en webs ya parcheadas.
Por qué este fallo no se arregla como un plugin desactualizado
Aquí está la parte que muchas startups subestiman. El error está en PHP, no en un plugin ni en un tema de WordPress. Eso significa que no basta con actualizar el contenido del sitio: hay que actualizar PHP en cada servidor y preservar la compatibilidad con aplicaciones y extensiones que quizá escribió alguien que ya no está en la empresa.
El resultado se vio en Europa: varios sitios del gobierno finlandés —incluido el Servicio Nacional de Topografía— quedaron inaccesibles, y también cayeron webs del gobierno francés y del puerto de Rotterdam, según WIRED citando a Reuters. El NCSC británico recomendó sacar de línea cualquier sistema que no se pudiera parchear de inmediato. En paralelo, Palo Alto Networks confirmó que todas las versiones de PAN-OS y Panorama estaban afectadas.
El nuevo ritmo de la IA: meses de investigación comprimidos en horas
Este episodio deja una lección incómoda. Los equipos de Wiz y Calif encontraron los fallos parcialmente con agentes de IA: menos búsqueda manual, más velocidad. Matt Suiche, investigador de la firma de ciberseguridad Tolmo, reprodujo un exploit funcional en menos de un día y lo describió como algo que «no existía hace un año».
Neatsun Ziv, CEO de Ox Security, puso números a ese cambio: el tiempo que tardan los atacantes en encontrar un exploit nuevo y lanzarlo contra internet pasó de semanas a días y, desde abril de 2026, con la llegada del modelo Mythos de Anthropic, a horas. Para una startup, la ventana entre que hay parche y hay ataques ya no se mide en semanas: se mide en horas.
La otra cara de la IA: encuentra más fallos, pero satura a quien los revisa
Barron describió el efecto con honestidad. La IA ayuda al equipo a encontrar errores que llevaban una década escondidos y acelera la programación, algo clave cuando faltan manos. Pero también aumenta la carga de trabajo: el proyecto recibe casi el doble de propuestas de cambio de código que hace un año, mientras «el número de colaboradores no se ha duplicado».
El cuello de botella no es detectar: es revisar. Y la revisión recae en unas pocas personas con experiencia. La propia fundación reconoció que el retraso en el parche anterior fue un «fallo estructural» causado por el proceso de decisión de su equipo de seguridad y su falta de recursos, según CNBC. En palabras de Barron, PHP está «increíblemente infrafinanciado» para la dependencia que tienen de él empresas y gobiernos.
Qué significa esto para tu startup
Si tu producto corre sobre WordPress, Laravel, Drupal, PrestaShop o cualquier stack que use PHP, esto no es una noticia de infraestructura ajena: es una tarea pendiente. Tres acciones concretas:
- Audita tu versión real de PHP, no la que crees que tienes. En hosting compartido se consulta en el panel de control; en WordPress, en Herramientas → Estado del sitio; en servidor propio, con
php -vy una página dephpinfo(). Compara el número con 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si estás en 8.1 o anterior, no hay parche oficial: toca migrar. - Trata la actualización como un proyecto de compatibilidad. Prueba en staging, revisa extensiones y dependencias heredadas, y agenda una ventana de despliegue. Una subida de PHP puede romper código que lleva años funcionando sin que nadie lo mire.
- Pon un WAF por delante, pero no lo confundas con la solución. Cloudflare desplegó reglas para todos sus clientes, incluidos los planes gratuitos, según su CTO Dane Knecht. Son una red de contención, no el parche.
Y una tarea de higiene que suele quedar fuera del backlog: haz inventario de plugins abandonados, subdominios de campañas viejas y sitios que ya nadie mantiene. El software más antiguo suele ser también el que corre versiones de PHP sin soporte, y ahí es donde entran este tipo de fallos.
Conclusión: la dependencia invisible que nadie pone en el presupuesto
Hay una lección estratégica que va más allá de PHP. Cuando tu startup elige un stack, está comprando (gratis) una dependencia de infraestructura crítica que quizá no tenga financiación proporcional a su peso. Eso no significa abandonar el open source: significa asumir que la seguridad no es responsabilidad de quien mantiene la librería, sino tuya. Si el fallo está en la base, la actualización del plugin no rescata a nadie.
Tres preguntas que conviene responder esta semana: ¿qué versión de PHP corre tu producción?, ¿quién es responsable de actualizarla y con qué frecuencia?, y ¿tienes logs suficientes para saber si alguien intentó entrar? Según Ox Security, la mayoría de las empresas solo se enteraría de una brecha si sus datos aparecieran vendiéndose en la dark web. Mejor saberlo antes.
Fuentes
- Xataka: Casi todo internet se sostiene en PHP (fuente original)
- CNBC: Why governments pulled websites offline over the decades-old PHP programming language
- WIRED: Critical PHP Vulnerabilities Are Setting the Internet on Fire
- Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
