Capital de Tokens
El 24 de octubre de 2026, el video de Platzi «Por qué el hackeo a PHP es el fin del internet abierto» reunió varias historias inquietantes: dos fallos críticos en PHP, certificados digitales construidos con claves débiles, preocupaciones sobre agentes de IA con acceso a servicios sensibles y la posibilidad de que gobiernos y empresas reduzcan su dependencia de redes públicas.
La pregunta es legítima: ¿estamos dejando atrás una internet donde casi todo puede conectarse con todo? Pero la respuesta no se obtiene sumando titulares. Los incidentes tienen causas distintas, algunas afirmaciones carecen de evidencia pública suficiente y, sobre todo, cerrar las redes no equivale a hacerlas seguras.
La tesis de este artículo es diferente del catastrofismo: la IA aumenta la presión sobre un sistema de confianza que ya tenía puntos débiles; la respuesta sostenible es controlar mejor identidades, privilegios y conexiones, no declarar muerto internet.
Ya explicamos la mecánica, versiones corregidas e historia de descubrimiento de PHP2Shell en un análisis anterior. Aquí miramos el panorama más amplio.
1. Dos incidentes reales, dos clases distintas de riesgo
PHP2Shell: un fallo compartido que atraviesa aplicaciones
El 21 de octubre de 2026, la PHP Foundation publicó cuatro versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Dos problemas de gestión de memoria, CVE-2026-109618 y CVE-2026-109619, podían permitir ejecución remota de código sin autenticación en condiciones determinadas. Los investigadores demostraron rutas de explotación; los operadores debían actualizar.
El aspecto estructural importa más que el titular: una vulnerabilidad en el runtime afecta a numerosas aplicaciones que lo comparten. El código de una tienda o una institución puede estar correctamente escrito y seguir expuesto por una dependencia común. Cloudflare desplegó reglas WAF antes de la divulgación, pero la protección de perímetro no reemplaza el parche del componente afectado.
Una cifra muy repetida sobre adopción de PHP no mide cuántos servidores estaban vulnerables, mucho menos cuántos fueron comprometidos. Intentos de ataque, instalaciones expuestas y ataques exitosos son métricas diferentes.
eMudhra: cuando falla el emisor de confianza
El 17 de octubre, un investigador comunicó un problema de entropía en claves privadas correspondientes a ocho autoridades certificadoras intermedias de eMudhra. Google confirmó que la debilidad podía permitir falsificar certificados HTTPS para clientes que aún confiaran en esas autoridades. Apple comenzó a bloquear las rutas de confianza afectadas el 19 de octubre.
Eso no significa que HTTPS haya sido descifrado globalmente, ni que todas las comunicaciones cifradas sean transparentes para un atacante. El problema era la posibilidad de emitir certificados falsamente confiables bajo ciertas cadenas de confianza, un riesgo distinto de romper los algoritmos criptográficos.
La propia eMudhra afirma que siete intermediarias no llegaron a producción y la octava no emitió certificados finales. Esa declaración es parte de la investigación del incidente, no prueba de que todos los dispositivos estén protegidos. Google y Apple documentaron sus bloqueos; equipos y aplicaciones con almacenes de certificados obsoletos merecen atención especial.
La lección común entre PHP2Shell y eMudhra es la dependencia compartida: bibliotecas y autoridades de confianza se convierten en puntos de concentración del riesgo.
2. ¿La IA provocó esta ola de vulnerabilidades?
El video propone una conexión temporal con modelos de pesos abiertos, particularmente una versión reciente de DeepSeek, y con versiones modificadas que reducen mecanismos de rechazo (abliteration).
Es plausible que las herramientas de IA aceleren el análisis de código, el descubrimiento de fallos y la producción de pruebas de concepto. Pero de esa capacidad no se deduce que un modelo concreto haya provocado incidentes distintos durante la misma semana.
En PHP2Shell hay una cronología mejor documentada. La PHP Foundation indica que había pistas del problema desde 2024; investigadores de Calif y OpenAI comunicaron hallazgos importantes el 11 de agosto de 2026 y Wiz presentó resultados adicionales el 24 de agosto. La publicación de octubre llegó después de meses de coordinación y parches difíciles. Un lanzamiento de modelo a mediados de octubre no explica retrospectivamente esa investigación.
Tampoco existe, en las fuentes oficiales consultadas para este análisis, una atribución verificable que conecte al mismo actor, modelo o herramienta con los incidentes de PHP, eMudhra y otros proveedores mencionados en el video.
Correlación temporal no es causalidad. Para demostrar la hipótesis harían falta trazas verificables, atribución técnica, análisis de herramientas empleadas y una línea temporal consistente. Una hipótesis puede orientar una investigación; no debe presentarse como conclusión.
La consecuencia práctica sí es clara: si encontrar fallos se abarata, el mantenimiento, el triage y el despliegue de parches deben acelerarse también. La PHP Foundation señala expresamente el papel del financiamiento, de sus mantenedores y de la revisión humana, incluso cuando se usan asistentes de IA.
3. Los agentes cambian la superficie de ataque
No hace falta un modelo sin restricciones para crear problemas serios. Basta con conectar un agente suficientemente útil a correo, repositorios, terminales, gestores de contraseñas o sistemas financieros y entregarle permisos demasiado amplios.
Un asistente que solo redacta recomendaciones tiene un impacto potencial distinto del que puede leer secretos, enviar solicitudes, ejecutar comandos o cambiar registros. El riesgo se mueve del texto generado a las acciones autorizadas.
OWASP describe la excessive agency mediante tres causas recurrentes: demasiadas funcionalidades, permisos excesivos y autonomía mal delimitada. También advierte sobre prompt injection: contenido de una página, un documento o una herramienta intenta convertirse en instrucciones para el agente.
Imaginemos un agente que investiga una vulnerabilidad. Lee una página externa que aparenta ser documentación y contiene una orden de enviar variables de entorno a una URL. Si trata esa página como una instrucción del usuario y tiene acceso a los secretos, un texto no confiable puede convertirse en una acción privilegiada.
Para contenerlo, se necesitan controles fuera del modelo:
- Credenciales por servicio y de privilegio mínimo, preferiblemente de corta duración.
- Herramientas de lectura separadas de las que escriben, borran o transfieren dinero.
- Aprobación explícita para acciones sensibles, límites de gasto y registros auditables.
- Validación estricta de destinos y parámetros antes de emitir solicitudes externas.
- Aislamiento de ejecuciones y protección frente a instrucciones incrustadas en fuentes no confiables.
Que un agente sea capaz de hacer algo no prueba que esté autorizado a hacerlo. Y quitarle la conexión a internet tampoco resuelve el problema de un usuario interno, una clave robada o un archivo malicioso.
4. ¿Hacia la era de las intranets?
La predicción central del video es que el miedo llevará a empresas y gobiernos a aislar servicios y favorecer redes privadas. Hay una parte razonable: reducir la exposición pública de paneles administrativos, bases de datos y sistemas industriales disminuye oportunidades de ataque.
Pero hay una diferencia entre tres diseños:
| Diseño | Beneficio principal | Límite importante |
|---|---|---|
| Todo expuesto en internet | Acceso y conectividad sencillos | Amplía la superficie atacable |
| Red privada o segmentada | Reduce rutas de entrada y movimiento | No impide abusos desde dentro |
| Zero Trust + segmentación | Verifica identidad, dispositivo y permisos por recurso | Requiere operar políticas y monitoreo |
El NIST SP 800-207 es explícito: estar dentro de una red local no otorga confianza automática. Zero Trust desplaza el criterio de confianza desde la ubicación de red a las identidades, los activos y la autorización de cada acceso.
Para infraestructuras físicas, CISA publicó en abril de 2026 una guía para aplicar estos principios a tecnología operacional, donde seguridad, disponibilidad y restricciones de equipos antiguos requieren compromisos especiales.
De aquí surge un escenario más probable que «el fin de internet»: internet seguirá conectando sistemas, pero muchas funciones sensibles estarán detrás de identidades verificadas, pasarelas restringidas, redes separadas y aprobaciones. Es una evolución arquitectónica, no una ruptura inevitable de la red global.
5. Una arquitectura práctica para pequeños equipos
Pensemos en un negocio con un sitio web, un bot de atención, automatizaciones y una base de datos. No necesita construir un internet privado. Sí necesita poner fronteras entre componentes.
Un esquema defendible sería:
- Publicar solo la puerta necesaria: web o API autenticada. Nada de bases de datos, paneles de administración o acceso SSH abierto indiscriminadamente.
- Mantener los datos en una capa privada: el servicio público conversa con una API estrecha, no con credenciales administrativas de la base de datos.
- Dar a los agentes identidades propias: una credencial de solo lectura para consultas y otra, aislada, para escrituras expresamente autorizadas.
- Separar entornos: desarrollo, CI y producción con secretos y permisos diferentes; los resultados de herramientas externas nunca equivalen a políticas.
- Actualizar dependencias y certificados: inventario, avisos de proveedor, pruebas de regresión, despliegues rápidos y capacidad de revertir.
- Medir lo que sucede: alertas sobre privilegios, intentos fallidos, tráfico extraño, acceso a secretos y cambios de configuración.
Esta estrategia funciona tanto en un proveedor cloud como en un pequeño servidor Linux. El objetivo no es eliminar conexiones, sino reducir lo que un único fallo puede alcanzar.
6. Cómo leer las afirmaciones más fuertes del video
| Afirmación | Qué permite concluir la evidencia |
|---|---|
| «PHP tuvo dos fallos críticos» | Confirmado, con CVE, versiones corregidas y análisis de mantenedores. |
| «Una autoridad de certificados tenía claves débiles» | Confirmado para intermediarias concretas; los bloqueos de confianza ya comenzaron. |
| «Una versión específica de DeepSeek causó la ola» | No demostrado con atribución técnica pública suficiente. |
| «Los agentes que acceden a herramientas abren nuevos riesgos» | Riesgo real y documentado, cuyo impacto depende de permisos, límites y conexiones. |
| «Internet abierto se termina» | Predicción, no conclusión respaldada por una medición del cierre de redes. |
El video de Platzi cumple una función valiosa: conectar noticias dispersas y exigir atención a la seguridad. Su límite es saltar de incidentes constatados a una historia causal y un pronóstico general con más seguridad de la que permite la evidencia.
La pregunta que importa
¿Seguirá existiendo internet abierto? Con la evidencia disponible al 24 de octubre de 2026, no hay razones para declarar su final. Sí las hay para abandonar la suposición de que una dirección inaccesible, una red corporativa o un chatbot bien instruido son defensas suficientes.
La seguridad de esta etapa depende menos de construir muros absolutos y más de responder cuatro preguntas: quién entra, qué puede leer, qué puede modificar y cómo detectamos un abuso.
El futuro no tiene por qué ser una colección de intranets aisladas. Puede ser una internet interconectada con fronteras de confianza mucho mejor definidas.
Fuentes
- Platzi — Video que motiva el análisis (24/10/2026).
- PHP Foundation — Seguridad, historia del descubrimiento y versiones corregidas (21/10/2026).
- Cloudflare — Medidas WAF contra PHP2Shell (21/10/2026).
- Google — Bloqueo de intermediarias eMudhra (20/10/2026).
- Apple — Estado y alcance del incidente eMudhra (23/10/2026).
- eMudhra — Declaración y cronología de la incidencia (actualizada 22/10/2026).
- OWASP — Top 10 para aplicaciones con modelos de lenguaje.
- NIST — SP 800-207, Zero Trust Architecture.
- CISA — Principios Zero Trust para tecnología operacional (29/04/2026).