PHP Vulnerability-Fix heute 16 Uhr

[Florian]

Ja es gibt was neues: CVE-2026-115560

Die Lücke betrifft laut PHP nur ungewöhnlich konfigurierte Webanwendungen. Das Risiko wird als gering eingestuft

Updates werden erst noch kommen. Wenn man auf Nummer sicher gehen will, soll man session.upload_progress.enabled=0 setzen.

[@ITS]

Da die Unsicherheiten so groß sind.

Mein Neffe arbeitet als IT-Security Specialist bei einem Cyber-security Unternehmen.
Er hat mir heute ein Screen geschickt, dass er gerade den Exploit vorhin erstmal auf 8.4.26 geschafft hat. (also ungepatchte Version)

Jedoch sagt er (auch im Vorfeld schon) dass hier soviel Informationen für jede einzelne Version und Sapi benötigt werden, dass es nicht wirklich realistisch sein wird.
Zudem war sein erfolgreicher Versuch nun auf mod_php geschrieben und da es war meines Wissens was ich gelesen habe auch eher anfällig.
Ob es für FPM auch möglich oder gleich Aufwendig ist, konnte er noch nicht einschätzen aber bekomme wieder eine Information wem es Interessiert.

Soll nicht heißen, dass ich das Risiko hier runterspiele, nur dass nicht alles so ist wie es in den Medien hochgepusht wird u.a. der Typ der in 38sek ein Webserver übernommen hat, wovon man keinerlei Informationen zu seinem Setting hatte bzw. das ganze auf einer lokalen Ebene passierte usw.

[omexlu]

Ja es gibt was neues: CVE-2026-115560

Die Lücke betrifft laut PHP nur ungewöhnlich konfigurierte Webanwendungen. Das Risiko wird als gering eingestuft

Updates werden erst noch kommen. Wenn man auf Nummer sicher gehen will, soll man session.upload_progress.enabled=0 setzen.

Danke sehr, sollte man das jetzt bei KeyHelp machen oder ist alles erstmal safe so?

[Ralph]

Ja es gibt was neues: CVE-2026-115560
Die Lücke betrifft laut PHP nur ungewöhnlich konfigurierte Webanwendungen. Das Risiko wird als gering eingestuft
Updates werden erst noch kommen. Wenn man auf Nummer sicher gehen will, soll man session.upload_progress.enabled=0 setzen.

Ja supi, am besten die Kisten alle abschalten ... "die uvm." (also so gut wie alle, quasi) können mir auch mal langsam den Hobel blasen
https://thehackernews.com/2026/10/urgen ... tched.html

... nuh kommen die vorgesehenen Schnüffel Backdoors nach 20 Jahren doch noch ans Licht, vermutlich dank KI oder weiß der Teufel ...

[omexlu]

Die Frage ist jetzt sollten wir das deaktivieren für Kundenwebsites und eigentlich müsste es ja auch dann fürs Panel deaktiviert werden?

[@ITS]

Ja es gibt was neues: CVE-2026-115560

Die Lücke betrifft laut PHP nur ungewöhnlich konfigurierte Webanwendungen. Das Risiko wird als gering eingestuft

Updates werden erst noch kommen. Wenn man auf Nummer sicher gehen will, soll man session.upload_progress.enabled=0 setzen.

Danke sehr, sollte man das jetzt bei KeyHelp machen oder ist alles erstmal safe so?

Hier nochmal als Zitat oben, vielleicht wars vorher nicht gut lesbar ? ^^
Es wird dir keiner deine Entscheidung in deinem Ermessen abnehmen können.

Zusammengefasst:
- Nur bei ungewöhnlich konfigurierte Webanwendungen.
- als Gering eingestuft somit nicht so tragisch. Und wart ab es folgen sicher noch welche..
- Updates werden kommen (Geduld, dann folgt das wohl auch für KH)
- Wenn man Helikopter ist und sicher gehen will, siehe oben die manuelle Lösung.

Wichtig waren die Patches jetzt und auch hier siehe mein Post oben, das ist auch womöglich nach Einschätzung eines Sicherheit Spezialisten der es schon durchgespielt hat, nicht so einfach ohne alle Parameter zu kennen, auszunutzen.

[nik736]

@kremsy:
Du benutzt eine alte KeyHelp Version, da heißt der Befehl noch "keyhelp run repo-update".
Du musst auch noch die Standard PHP Version deines Betriebssystem aktualisieren. Z.B mit "keyhelp run package-update"

@nik736:
Welches OS, welche OS-Version und welche Architektur nutzt dein Server? Was sagt "keyhelp-php74 -v"?

@fpiel
Ja, wie gesagt.

keyhelp-php74 -v
PHP 7.4.33 (cli) (built: Aug 20 2025 08:16:57) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v15.5.0, Copyright (c) 2002-2026, by ionCube Ltd.
with SourceGuardian v17.0.0, Copyright (c) 2000-2025, by SourceGuardian Ltd.
with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies

Welcome to Ubuntu 22.04.5 LTS (x86_64)

[nik736]

@kremsy:
Du benutzt eine alte KeyHelp Version, da heißt der Befehl noch "keyhelp run repo-update".
Du musst auch noch die Standard PHP Version deines Betriebssystem aktualisieren. Z.B mit "keyhelp run package-update"

@nik736:
Welches OS, welche OS-Version und welche Architektur nutzt dein Server? Was sagt "keyhelp-php74 -v"?

@fpiel
Ja, wie gesagt.

keyhelp-php74 -v
PHP 7.4.33 (cli) (built: Aug 20 2025 08:16:57) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v15.5.0, Copyright (c) 2002-2026, by ionCube Ltd.
with SourceGuardian v17.0.0, Copyright (c) 2000-2025, by SourceGuardian Ltd.
with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies

Welcome to Ubuntu 22.04.5 LTS (x86_64)

Hat inzwischen auch bei mir geklappt, danke.

[Ralph]

Da ist immer noch einiges im Gange (viele WP Hacks und Malware Uploads über die letzten Tage) ... also, ich denke momentan darüber nach noch überall das empfohlene "session.upload_progress.enabled=0" zu setzen, 2 Fragen habe ich dazu noch ...

Wenn ich die zusätzlich PHP Anweisung (session.upload_progress.enabled=0) über das Panel setze sehe ich in der entsprechenden "user_php*.conf"

Code: Select all

php_admin_value[session.upload_progress.enabled] =

also bei allen Anweisungen mit Value = 0 oder off wird es nur leer angezeigt ... ist das so richtig, ohne value?

Sind die folgenden Befehle so korrekt um die Anweisung in alle .conf Files einzufügen?
Bei mir ist in allen *.conf (account templates) "php_admin_value[display_errors] =" gesetzt, ich verwende es hier einfach mal als Markierung zum daruntersetzen.

Code: Select all

find /opt/keyhelp/php/*/etc/php-fpm.d/ -type f -name "*.conf" -exec sed -i '/php_admin_value\[display_errors\] =/a php_admin_value[session.upload_progress.enabled] =' {} +
systemctl restart keyhelp-php*

Code: Select all

find /etc/php/8.2/fpm/pool.keyhelp.d/ -type f -name "*.conf" -exec sed -i '/php_admin_value\[display_errors\] =/a php_admin_value[session.upload_progress.enabled] =' {} +
systemctl restart php8.2-fpm

Mir ist bewusst, dass diese Anweisungen wieder überschrieben werden bei einem neuen abspeichern der PHP User config ... ist aber Ok, weil in die account_templates und php_settings Tables, möchte ich ungerne eine temp. Vulnerability Mitigation setzen.

[Ralph]

da stimmt was nicht ... wenn ich es so eingebe im Panel:
session.upload_progress.enabled = off
oder
session.upload_progress.enabled = 0
wird daraus in der .conf:
php_admin_value[session.upload_progress.enabled] =

wenn es so eingegeben wird:
session.upload_progress.enabled=0
bleibt der 0 Wert erhalten
php_admin_value[session.upload_progress.enabled] = 0


und die nette KI sagt ...

1. Warum KeyHelp das so generiert
KeyHelp nutzt für die Pool-Konfigurationen fast ausschließlich die Direktive php_admin_value. Da ein „Flag“ (php_admin_flag) intern anders verarbeitet wird, mappt das Panel Boolesche Werte (On/Off) oft standardmäßig auf Strings ab.

2. Das Problem mit Sicherheitsmitigationen (aktueller Fall)
Obwohl das für Standard-Direktiven wie display_errors funktioniert, entsteht bei den aktuellen Sicherheitswarnungen (rund um die PHP2Shell-Lücken und die ganz neue Folgelücke CVE-2026-115560 vom 23. Oktober 2026) ein Problem.
Die offizielle Empfehlung des PHP-Core-Teams lautet hierfür explizit, den Wert hart auf 0 (oder Off) zu setzen, um die Session-Upload-Pfade im Interpreter sicher zu blockieren:

Code: Select all

session.upload_progress.enabled = 0
# bzw.
php_admin_value[session.upload_progress.enabled] = 0

also müssten die Befehle dementsprechend geändert werden, oder?

Code: Select all

find /opt/keyhelp/php/*/etc/php-fpm.d/ -type f -name "*.conf" -exec sed -i '/php_admin_value\[display_errors\] =/a php_admin_value[session.upload_progress.enabled] = 0
' {} +

systemctl restart keyhelp-php*

find /etc/php/8.2/fpm/pool.keyhelp.d/ -type f -name "*.conf" -exec sed -i '/php_admin_value\[display_errors\] =/a php_admin_value[session.upload_progress.enabled] = 0
' {} +

systemctl restart php8.2-fpm

[Ralph]

Yes, da gibt es anscheinend ein parsing Problem, mit Leerzeichen und Null bzw. Off Werten, bei einem Wert > 0 ist es egal ob da ein Leerzeichen enthalten ist, dieser erscheint jedenfalls korrekt in der .conf: ... wie z.b. php_admin_value[max_execution_time] = 60

display_errors=0
allow_url_fopen=0
etc:
muss derzeit im Panel so eingegeben werden (ohne Leerzeichen) > allow_url_fopen=0
dann wird daraus in der .conf eine 0 gesetzt, aber mit Leerzeichen getrennt

Code: Select all

php_admin_value[allow_url_fopen] = 0

Es scheint allerdings trotzdem mit den leeren Werten "value =" zu greifen, jedenfalls wird es in der info.php als Off angezeigt, mit allen leer values.

[goldene-zeiten]

Yes, da gibt es anscheinend ein parsing Problem, mit Leerzeichen und Null bzw. Off Werten, bei einem Wert > 0 ist es egal ob da ein Leerzeichen enthalten ist, dieser erscheint jedenfalls korrekt in der .conf: ... wie z.b. php_admin_value[max_execution_time] = 60

display_errors=0
allow_url_fopen=0
etc:
muss derzeit im Panel so eingegeben werden (ohne Leerzeichen) > allow_url_fopen=0
dann wird daraus in der .conf eine 0 gesetzt, aber mit Leerzeichen getrennt

Code: Select all

php_admin_value[allow_url_fopen] = 0

Es scheint allerdings trotzdem mit den leeren Werten "value =" zu greifen, jedenfalls wird es in der info.php als Off angezeigt, mit allen leer values.

Wo genau im Panel müssen diese Direktiven eingestellt werden? Es liest sich so, als ob das als zentrale Einstellung empfohlen würde?

[Tiresias]

Statt die Einstellung über das Panel für einzelne Benutzer vorzunehmen oder die FPM-Pool-Konfigurationen zu bearbeiten, habe ich das über eine zusätzliche INI-Datei für alle installierten KeyHelp-PHP-Versionen gesetzt.

Als root ausführen:

Code: Select all

for dir in /opt/keyhelp/php/*/etc/conf.d; do
    [ -d "$dir" ] || continue
    printf 'session.upload_progress.enabled = Off\n' \
        > "$dir/99-disable-upload-progress.ini"
done

Das Script durchläuft die `conf.d`-Verzeichnisse aller installierten KeyHelp-PHP-Versionen und legt jeweils eine Datei `99-disable-upload-progress.ini` mit folgendem Inhalt an:

Code: Select all

session.upload_progress.enabled = Off

Nach einem Neustart der jeweiligen keyhelp-phpXY-fpm-Dienste werden die neuen Einstellungen wirksam.

Die KeyHelp-PHP-Versionen lesen beim Start neben ihrer eigentlichen `php.ini` auch die zusätzlichen Konfigurationsdateien aus `etc/conf.d` ein.

Damit gilt die Einstellung versionsweit, ohne einzelne Benutzerkonfigurationen oder von KeyHelp generierte FPM-Pool-Dateien ändern zu müssen. Beim erneuten Speichern einer Benutzerkonfiguration bleibt die zusätzliche INI-Datei unberührt.

Kontrollieren kann man dann mit

Code: Select all

for php in /opt/keyhelp/php/*/bin/php; do
    [ -x "$php" ] || continue
    printf '%s: ' "$php"
    "$php" -r 'echo ini_get("session.upload_progress.enabled") ? "ON" : "OFF", PHP_EOL;'
done

Auf meinem Server melden alle installierten KeyHelp-PHP-Versionen (8.2 bis 8.5) anschließend `OFF`. Aber das prüft nicht individuelle Einstellungen per Pool.

Die Einstellung betrifft die zusätzlichen KeyHelp-PHP-Versionen, nicht automatisch das PHP des Betriebssystems.
Explizite `php_value`- oder `php_admin_value`-Anweisungen in FPM-Pools können den Wert überschreiben.
Ob KeyHelp die zusätzlichen Dateien bei zukünftigen PHP-Updates beibehält, ist nicht garantiert.
Anwendungen, die PHPs Session-Upload-Progress-Funktion tatsächlich verwenden, können dadurch beeinträchtigt werden.

Ich meine aber, das ist eine kurzfristige, versionsübergreifende Sicherheitsmaßnahme und einfacher als die Änderung einzelner Benutzerkonfigurationen.

[omexlu]

Hi,

Also ich finde ihr solltest nicht zuviel mit irgendwelchen "Scripten" in den Configs rumspielen, nachher ist das geheule wieder gross.
Der CVE wird als gering eingestuft und nur bei ganz komischen Webapplikationcode zum Problem.

Ich würde sagen endweder auf offiziellen Patch warten, in den einzelnen Domains temporär deaktivieren ODER auf KeyHelp warten, eventuell könnten die einen temporären Patch ausspielen der global das erstmal deaktiviert bis der offizielle PHP-Patch ausgerollt wird.

[Ralph]

Code: Select all

for dir in /opt/keyhelp/php/*/etc/conf.d; do
    [ -d "$dir" ] || continue
    printf 'session.upload_progress.enabled = Off\n' \
        > "$dir/99-disable-upload-progress.ini"
done

Ja, kommt im Grunde auf das gleiche Resultat raus, halt außerhalb der KH *.conf ... es wird so beim speichern nicht überschrieben, ob es greift müsstest mal in die info.php schauen, und später ggf. wieder mauell löschen.