PHP Apocalypse abgewendet

So Freund, wir  sind wieder online. Wieso wieder Online fragt Ihr, na wegen PHP2SHELL !

PHP Apocalypse abgewendet

PHP hat zwar früher als erwartet das Embargo für die PHP Patche freigegeben, aber dank eines Geniestreichs, waren unsere Server schneller wieder am Netz als andere, denn die Mirrors der Updatepakete waren nicht aktuell. Hätte man auf die gewartet, hätte es Stunden dauern können.

Was ist überhaupt passiert:

Security advisory: Critical remote code execution vulnerabilities, update now

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

  • RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
  • RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

How to update:

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
  • Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
  • PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
  • If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
  • Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

  • Set memory_limit=-1, preferably in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size. For applications that don’t require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

  • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

The advisories linked above have the full technical details.

Quelle: php.net

Da 24h Zeit waren wurden heute Mittag im Geheimen bereits das Update für Fedora kompiliert. Daher konnte man die Pakete bereits früher haben als die Mirrors. Letztendlich wurden die dann über unsere Updateserver verteilt, so daß alle unsere Server das für ein normales Update wie jedes andere behandelt haben.

Linux am Dienstag – Programm für den 20.10.2026

Diesmal bei Linux am Dienstag … Linux Prüfung –  Netzwerk 101 … die 11. Ausgabe. Wollen wir doch mal sehen, ob man mit dem Wissen schon was reißen kann 😉

Linux am Dienstag – Programm für den 20.10.2026

u.a. im Programm am 20.10.2026, ab 19:00 Uhr:

    • Linux – Prüfung XI – Das Netzwerk (Marius)
    • Datenschutz – Chatbots geben Inhalte an Werbeunternehmen weiter
    • Sicherheit – 800 Supermarktkühlschränke gehackt
    • Sicherheit – Palo-Alto Firewalls haben Root RCE
    • Sicherheit – Notebooks-billiger gehackt
    • Sicherheit – 2 deutsche Verwaltungen gehackt

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/linux

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

So schlechte Scams, daß man Lachen muß.

Heute mal wieder was lustiges: Unser RZ Betreiber warnte seine Kunden vor gefälschten „Ihre Domain läuft aus“ Mails, was in Deutschland gar nicht passieren kann, weil sich Domains automatisch verlängern, und das kam rein:

 

 

 

Wenn es der Hinweis von Thunderbird nicht weggeben hätte, oder der Empfänger einer Domain, die es nicht mehr gab, dann wäre der Inhalt dieser Scammail gewesen:

Analyse

Es gibt zwar eine Kyberio GmbH, aber die sitzt nicht in Berlin und schon gar nicht in einer „Mustergasse 123“ 😀

Als wenn das nicht genug wäre, welche Domain wäre denn am Ablaufen? Das wird gar nicht gesagt 🙂

Die verdächtige Telefonnummer aus Berlin … +49 30 123 45 67 😀 Ich hätte mich fast weggeworfen vor Lachen!! 😀

Die Header

Return-path: <weinelta@weinelt.at>
Envelope-to: <XXX@spamtrap.de>
Delivery-date: Wed, 14 Oct 2026 01:16:24 +0200
Received: from at1.login24.at ([37.252.190.58] helo=weinelt.at)
	by x.de with esmtps  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.99.5)
	(envelope-from <weinelta@weinelt.at>)
	id 1xGljM-0000000GADu-04Gb
	for XXX@Spamtrap.de;
	Wed, 14 Oct 2026 01:16:24 +0200
Received: by at1.login24.at (Postfix, from userid 10013)
	id C7C27D061D95C; Mon, 12 Oct 2026 20:15:19 +0000 (UTC)
To: info@bionelle.de
Message-ID: <1791836119.133711.79183816@landkreis-gifhorn.de>
Date: Mon, 12 Oct 2026 20:15:19 +0000
From: Kundenbetreuung <Support@landkreis-gifhorn.de>

Da haben wir:

– Den Empfänger den nicht mehr geben kann + wir stehen nicht drin, also BCC Kopie wie bei Spammern üblich.

– Der Landkreis Gifhorn schickt keine Mails über Domainverlängerungen ab

– Am Return-path: <weinelta@weinelt.at> und dem „Received: from at1.login24.at ([37.252.190.58] helo=weinelt.at)“ Header ist ersichtlich, es kam von einem gehackten Konto der Weinelt.at Seite und nein, daß ist kein Tippfehler für weinwelt.at .. der Mann heißt Weinelt 😉

– nichts im Header deutet auf Kyberio hin.

Wer von Euch auf so eine Email reinfällt, darf drin schwimmen, aber nicht auf Rettung hoffen, denn die Rettungskräften mußten erstmal herzlich Lachen über soviel Fail in Zeiten von KI Fakes.