Kurz gesagt: Das sury PHP-Repository ist eine weit verbreitete Drittquelle für PHP-Pakete unter Debian (packages.sury.org) und Ubuntu (PPA ondrej/php). Es erlaubt mehrere PHP-Versionen nebeneinander und neuere Zweige als die Distribution. Nach PHP2Shell wurden dort laut Berichten Builds für alle Zweige von 5.6 bis 8.5 bereitgestellt. Den Nachweis für Ihren Server liefern aber nur Paketstand und Changelog, nicht die Sicherheitsmeldungen von Debian oder Ubuntu.
Was das sury-Repository ist
Hinter sury.org steht Ondřej Surý. Laut seiner Projektseite paketiert er als Debian-Entwickler seit PHP 5 die PHP-Pakete für Debian, und die offiziellen PHP-Pakete von Debian und Ubuntu beruhen auf seiner Arbeit. Neben dieser Arbeit betreibt er ein eigenes Repository mit PHP-Paketen, die sich parallel installieren lassen.
Für Debian liegt das Repository unter packages.sury.org, für Ubuntu wird es als PPA ondrej/php angeboten. Fehler werden laut Projektseite über einen Issue-Tracker auf Codeberg gemeldet, nicht per E-Mail. Die Pflege geschieht nach eigenen Angaben überwiegend in der Freizeit; für ältere Distributionsversionen gibt es ein kommerzielles Angebot über Freexian.
Viele Admins und Hoster setzen das Repository ein, weil es neuere PHP-Zweige bietet, als die Distribution mitbringt, oder weil Anwendungen eine bestimmte Version brauchen.
Was es von den Debian-Paketen unterscheidet
Der wichtigste Unterschied für die Sicherheit: Pakete aus sury.org fallen nicht unter die Sicherheitsmeldungen von Debian oder Ubuntu. Der Debian Security Tracker zeigt nur den Stand der offiziellen Pakete. Steht dort, dass php8.4 in trixie korrigiert ist, sagt das nichts über ein php8.4 aus sury.org auf demselben Server.
| Merkmal | Offizielle Debian- und Ubuntu-Pakete | sury.org |
|---|---|---|
| Herausgeber | Debian bzw. Canonical | Ondřej Surý als Einzelperson |
| Sicherheitsmeldungen | DSA, DLA, USN | keine dieser Meldungen |
| Versionen | ein Zweig je Release | mehrere Zweige parallel |
| Versionsnummer nach Fix | Debian teils neue Upstream-Version, Ubuntu meist alte Nummer mit neuem Paketstand | in der Regel aktuelle Upstream-Version |
| Nachweis | Meldung und Changelog | Changelog und Paketversion |
Für Unternehmen bedeutet das eine Abhängigkeit von einer Einzelperson für eine zentrale Komponente. Das ist kein Grund, das Repository zu meiden, aber ein Grund, sie bewusst zu tragen: mit Überwachung, Nachweis und einem Plan B.
sury PHP-Repository nach PHP2Shell: Stand prüfen
Zuerst klären Sie, ob und für welche Pakete der Server sury nutzt. Die Befehle sind rein lesend.
# Ist sury als Paketquelle eingetragen?
grep -rEl "sury|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# Aus welcher Quelle stammt das installierte Paket?
apt policy php8.3-fpm
# Installierte Version und Changelog-Eintrag zu den CVEs
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
Bei aktuellen Zweigen erkennen Sie den Fix in der Regel an der Upstream-Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 im Paketnamen. Bei alten Zweigen wie 7.4 oder 8.1 gibt es keine offizielle Zielversion, dort ist der Changelog-Eintrag der wichtigste Beleg. Fehlt er, fragen Sie über den Issue-Tracker des Projekts nach oder behandeln Sie das Paket als ungeklärt.
Alte PHP-Zweige aus sury: ein trügerischer Komfort
Das Repository macht es leicht, PHP 7.4 oder sogar 5.6 auf einem aktuellen Debian zu betreiben. Laut Berichten gab es auch für diese Zweige Builds gegen PHP2Shell. Das ist für die akute Lage hilfreich, verschiebt aber das Grundproblem nur: Das PHP-Projekt pflegt diese Zweige nicht mehr, und die nächste Lücke trifft sie wieder.
Wer auf diesem Weg eine alte Anwendung am Leben hält, sollte sich ehrlich fragen, wie lange noch. Was für PHP 8.1 und älter gilt, fasst die Seite PHP 8.1 und älter: Was jetzt gilt zusammen. Kommerzielle Alternativen mit ihren Grenzen beschreibt der Beitrag Langzeitsupport für alte PHP-Versionen.
Mischen Sie auf einem Server nicht unkontrolliert PHP-Pakete aus der Distribution und aus sury.org. Abhängigkeiten zwischen Erweiterungen und Bibliotheken können beim nächsten Update zu unerwarteten Paketwechseln führen.
Empfehlungen für den Betrieb mit sury
- Dokumentieren, welche Server sury nutzen und für welche Zweige.
- Herkunft festlegen, etwa per APT-Pinning, damit PHP-Pakete nur aus einer Quelle kommen.
- Updates überwachen, denn ohne DSA oder USN fehlt der übliche Hinweis. Ein regelmäßiger Abgleich von
apt list --upgradablehilft. - Neu starten nach jedem Update, für jede installierte Version einzeln. Wie viele parallel laufen, zeigt der Beitrag Mehrere PHP-Versionen auf einem Server.
- Unterstützen, wenn Ihr Unternehmen auf das Repository angewiesen ist. Die Projektseite nennt Spenden und kommerziellen Support als Wege.
Zurück zu den Distributionspaketen?
Nicht jeder Server, der heute sury nutzt, braucht es noch. Oft wurde das Repository vor Jahren eingebunden, weil die damalige Distribution nur eine ältere PHP-Version mitbrachte. Inzwischen liefert etwa Debian 13 trixie PHP 8.4 aus, das laut Debian Security Tracker gegen PHP2Shell korrigiert ist. Wenn Ihre Anwendung mit dieser Version läuft, kann der Rückweg die Abhängigkeit von einer Drittquelle beenden.
Der Rückweg ist ein kleines Migrationsprojekt. Prüfen Sie zuerst, welche Erweiterungen die Anwendung braucht und ob die Distribution sie anbietet. Testen Sie die Anwendung mit dem Distributionspaket auf einer Kopie, bevor Sie die sury-Quelle entfernen. Danach kommen Sicherheitsmeldungen wieder über die gewohnten Wege, und der Nachweis stützt sich auf DSA oder USN statt allein auf ein Changelog.
Wo eine neuere oder ältere Version nötig bleibt als die der Distribution, ist sury weiterhin eine sinnvolle Wahl. Dann sollte die Entscheidung aber bewusst getroffen und dokumentiert sein.
Wie hilft PHP SOS konkret?
- Wir stellen fest, welche PHP-Pakete auf Ihren Servern aus sury.org, aus der Distribution oder aus anderen Quellen stammen.
- Wir prüfen den PHP2Shell-Stand je Zweig über Paketversion und Changelog und starten alle Dienste neu.
- Wir richten Pinning und Update-Überwachung ein und entfernen nicht mehr benötigte Zweige im Rahmen der Server-Härtung.
- Für alte Zweige planen wir den Umstieg auf eine unterstützte Version.
Häufige Fragen
Ist das sury-Repository ein offizielles Debian-Repository?
Nein. Es wird von Ondřej Surý betrieben, der laut eigener Seite als Debian-Entwickler seit Langem PHP für Debian paketiert. Es ist aber nicht das Sicherheitsarchiv von Debian, und für seine Pakete gibt es keine Debian-Sicherheitsmeldungen.
Hat sury.org Pakete gegen PHP2Shell bereitgestellt?
Laut Berichten wurden Builds für alle Zweige von 5.6 bis 8.5 bereitgestellt. Prüfen Sie den Stand auf Ihrem Server trotzdem selbst über Paketversion und Changelog, denn die Berichte ersetzen keinen Nachweis für Ihr System.
Macht sury.org alte PHP-Versionen wieder sicher?
Ein Build für einen alten Zweig kann eine konkrete Lücke schließen. Er ändert nichts daran, dass das PHP-Projekt diese Zweige nicht mehr pflegt. Für einen dauerhaft sicheren Betrieb bleibt der Umstieg auf eine unterstützte Version nötig.
Wie finde ich heraus, ob mein Server sury nutzt?
Suchen Sie in den Paketquellen unter /etc/apt nach sury oder ondrej und prüfen Sie mit apt policy, aus welcher Quelle die installierten PHP-Pakete stammen.