En resumen: El repositorio PHP de sury es una fuente de terceros muy extendida de paquetes de PHP en Debian (packages.sury.org) y Ubuntu (PPA ondrej/php). Permite varias versiones de PHP en paralelo y ramas más nuevas que las de la distribución. Tras PHP2Shell se proporcionaron allí, según los informes, compilaciones para todas las ramas de la 5.6 a la 8.5. Pero el justificante para su servidor solo lo dan el nivel del paquete y el registro de cambios, no los avisos de seguridad de Debian o Ubuntu.
Qué es el repositorio sury
Detrás de sury.org está Ondřej Surý. Según la página de su proyecto, empaqueta como desarrollador de Debian los paquetes de PHP para Debian desde PHP 5, y los paquetes oficiales de PHP de Debian y Ubuntu se basan en su trabajo. Además de ese trabajo, opera un repositorio propio con paquetes de PHP que pueden instalarse en paralelo.
Para Debian, el repositorio está en packages.sury.org; para Ubuntu se ofrece como PPA ondrej/php. Según la página del proyecto, los fallos se comunican mediante un gestor de incidencias en Codeberg, no por correo electrónico. El mantenimiento se hace, según sus propias indicaciones, sobre todo en su tiempo libre; para versiones más antiguas de las distribuciones hay una oferta comercial a través de Freexian.
Muchos administradores y proveedores de alojamiento usan el repositorio porque ofrece ramas de PHP más nuevas que las que trae la distribución, o porque las aplicaciones necesitan una versión determinada.
En qué se distingue de los paquetes de Debian
La diferencia más importante para la seguridad: los paquetes de sury.org no entran en los avisos de seguridad de Debian ni de Ubuntu. El Debian Security Tracker solo muestra el estado de los paquetes oficiales. Si allí figura que php8.4 en trixie está corregido, eso no dice nada sobre un php8.4 de sury.org en el mismo servidor.
| Característica | Paquetes oficiales de Debian y Ubuntu | sury.org |
|---|---|---|
| Editor | Debian o Canonical | Ondřej Surý como persona individual |
| Avisos de seguridad | DSA, DLA, USN | ninguno de estos avisos |
| Versiones | una rama por versión | varias ramas en paralelo |
| Número de versión tras la corrección | Debian en parte nueva versión upstream, Ubuntu normalmente número antiguo con nuevo nivel de paquete | por lo general la versión upstream actual |
| Justificante | Aviso y registro de cambios | Registro de cambios y versión del paquete |
Para las empresas esto significa una dependencia de una persona individual para un componente central. No es motivo para evitar el repositorio, pero sí para asumirlo de forma consciente: con supervisión, justificante y un plan B.
El repositorio sury PHP tras PHP2Shell: comprobar el estado
Primero aclare si el servidor usa sury y para qué paquetes. Los comandos son de solo lectura.
# ¿Está sury registrado como fuente de paquetes?
grep -rEl "sury|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# ¿De qué fuente procede el paquete instalado?
apt policy php8.3-fpm
# Versión instalada y entrada del registro de cambios sobre los CVE
dpkg-query -W -f='${Package}\t${Version}\n' 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null
zgrep -E "CVE-2026-10961[89]" /usr/share/doc/php8.3-fpm/changelog.Debian.gz
En las ramas actuales, la corrección se reconoce por lo general por la versión upstream 8.5.12, 8.4.27, 8.3.36 u 8.2.35 en el nombre del paquete. En ramas antiguas como 7.4 u 8.1 no hay una versión de destino oficial; ahí, la entrada del registro de cambios es el justificante más importante. Si falta, pregunte a través del gestor de incidencias del proyecto o trate el paquete como no aclarado.
Ramas antiguas de PHP desde sury: una comodidad engañosa
El repositorio facilita operar PHP 7.4 o incluso 5.6 en un Debian actual. Según los informes, también hubo para esas ramas compilaciones contra PHP2Shell. Para la situación aguda es útil, pero solo desplaza el problema de fondo: el proyecto PHP ya no mantiene esas ramas y la próxima vulnerabilidad las afectará de nuevo.
Quien mantiene así viva una aplicación antigua debería preguntarse con honestidad hasta cuándo. Lo que vale para PHP 8.1 y anterior lo resume la página PHP 8.1 y anterior: qué rige ahora. Las alternativas comerciales con sus límites las describe el artículo Soporte a largo plazo para versiones antiguas de PHP.
No mezcle en un servidor, sin control, paquetes de PHP de la distribución y de sury.org. Las dependencias entre extensiones y bibliotecas pueden llevar en la próxima actualización a cambios inesperados de paquetes.
Recomendaciones para operar con sury
- Documentar qué servidores usan sury y para qué ramas.
- Fijar el origen, por ejemplo mediante APT pinning, para que los paquetes de PHP procedan de una sola fuente.
- Supervisar las actualizaciones, porque sin DSA ni USN falta el aviso habitual. Ayuda una comparación periódica de
apt list --upgradable. - Reiniciar tras cada actualización, para cada versión instalada por separado. Cuántas funcionan en paralelo lo muestra el artículo Varias versiones de PHP en un servidor.
- Apoyar si su empresa depende del repositorio. La página del proyecto menciona las donaciones y el soporte comercial como vías.
¿Volver a los paquetes de la distribución?
No todo servidor que hoy usa sury lo sigue necesitando. A menudo el repositorio se incorporó hace años porque la distribución de entonces solo traía una versión de PHP más antigua. Entre tanto, por ejemplo Debian 13 trixie entrega PHP 8.4, que según el Debian Security Tracker está corregido frente a PHP2Shell. Si su aplicación funciona con esa versión, la vuelta atrás puede poner fin a la dependencia de una fuente de terceros.
La vuelta atrás es un pequeño proyecto de migración. Compruebe primero qué extensiones necesita la aplicación y si la distribución las ofrece. Pruebe la aplicación con el paquete de la distribución en una copia antes de quitar la fuente sury. Después, los avisos de seguridad vuelven a llegar por las vías habituales y el justificante se apoya en DSA o USN en lugar de solo en un registro de cambios.
Donde siga siendo necesaria una versión más nueva o más antigua que la de la distribución, sury sigue siendo una opción razonable. Pero entonces la decisión debería tomarse de forma consciente y documentarse.
¿Cómo ayuda PHP SOS en concreto?
- Averiguamos qué paquetes de PHP de sus servidores proceden de sury.org, de la distribución o de otras fuentes.
- Comprobamos el estado de PHP2Shell por rama mediante la versión del paquete y el registro de cambios y reiniciamos todos los servicios.
- Configuramos el pinning y la supervisión de actualizaciones y eliminamos las ramas que ya no se necesitan en el marco del refuerzo de servidores.
- Para las ramas antiguas planificamos el paso a una versión compatible.
Preguntas frecuentes
¿Es el repositorio sury un repositorio oficial de Debian?
No. Lo opera Ondřej Surý que, según su propia página, empaqueta PHP para Debian desde hace mucho como desarrollador de Debian. Pero no es el archivo de seguridad de Debian y para sus paquetes no hay avisos de seguridad de Debian.
¿Ha proporcionado sury.org paquetes contra PHP2Shell?
Según los informes, se proporcionaron compilaciones para todas las ramas de la 5.6 a la 8.5. Aun así, compruebe usted mismo el estado en su servidor mediante la versión del paquete y el registro de cambios, porque los informes no sustituyen un justificante para su sistema.
¿Hace sury.org que las versiones antiguas de PHP vuelvan a ser seguras?
Una compilación para una rama antigua puede cerrar una vulnerabilidad concreta. No cambia que el proyecto PHP ya no mantiene esas ramas. Para un funcionamiento seguro a largo plazo sigue siendo necesario pasar a una versión compatible.
¿Cómo averiguo si mi servidor usa sury?
Busque sury u ondrej en las fuentes de paquetes bajo /etc/apt y compruebe con apt policy de qué fuente proceden los paquetes de PHP instalados.