CVE-2026-111497 ("http2shell") (Remote Code Execution/RCE) [Update #1]

    • Neu

    Platzhalter; siehe "Node2Shell evolves to HTTP2Shell. Brotli flaw (CVE-2026-111497) blast radius affects many libraries & apps using HTTPs": "Patches are available for libbrotli, Python, C++, NodeJS, bun, Envoy and more coming. Apache and Nginx do not decode brotli by default."

    CVSS v4.0 Score: 9,2 (kritisch)

    (Debian verlinkt auf mehrere CVE-Tracker für CVE-2026-111497.)

    Update #1: Aufgrund der Verbreitung der brotli-Bibliothek ist die vollständige Überprüfung ihrer evtl. lokalen Nutzung etwas aufwendiger; in diesem Post finden sich Beispiele hierzu.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    3 Mal editiert, zuletzt von m_ueberall (25. Oktober 2026 um 09:09)

    • Neu

    Wie finde ich denn raus, ob Brotli nicht nur auf dem Frühstückstisch sondern auch auf einem meiner Debian Server irgendwo als Abhängigkeit mitinstalliert wurde?

    dpkg-query -W -f='$(Version)\n' brotli

    wie es mir die KI vorschlägt, bringt

    Kein Paket gefunden

    Darf ich mich diesbezüglich bereits in Sicherheit wiegen? :/

    • Neu

    Brotli war mir bisher unbekannt und auch auf keinem Serverlein zu finden.

    Aber es ist ein schönes Beispiel, warum man nur stable oder maximal noch oldstable auf Debian-Systemen haben sollte.
    Sind zumindest die, bei denen als Erstes die Updates kommen.

    • Neu
    Zitat von Win98SE4ever

    dpkg-query -W -f='$(Version)\n' brotli

    wie es mir die KI vorschlägt, bringt

    Kein Paket gefunden

    Darf ich mich diesbezüglich bereits in Sicherheit wiegen? :/

    Nur sofern keine speziellen statischen Binaries im Einsatz sind (wie bspw. von curl o.ä.); die Letzteren müssen natürlich mit aktualisierter Bibliothek neu gebaut werden.

    EDIT: Python, Javascript-Laufzeitumgebungen, Proxies und Container können natürlich ebenfalls betroffene Brotli-Dekoder-Kopien enthalten. Hier finden sich ein paar Beispiele für die praktische Überprüfung.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    2 Mal editiert, zuletzt von m_ueberall (25. Oktober 2026 um 08:06)

    • Neu
    Zitat von Win98SE4ever

    dpkg-query -W -f='$(Version)\n' brotli

    wie es mir die KI vorschlägt, bringt

    Kein Paket gefunden

    Darf ich mich diesbezüglich bereits in Sicherheit wiegen? :/

    Leider nein, brotli wird wohl oft statisch eingebunden.

    Ich hatte extra nachgeschaut, da es bei mir wegen uptime kuma wohl gerade gefährlich ist, da nach extern als Dienst im Internet. In meinem Fall (kein Docker) braucht's wohl ein update des nodejs deb Paketes und unter Ubuntu gibt's da leider noch nichts. Ob das Docker image wohl schneller geupdated wird?

    Uptime kuma läuft zwar hinter einem Reverse proxy, so dass ich mir nicht 100% sicher bin, ob verwundbar, die KI meint aber schon, brotli Komprimierung würde wohl vom Apachen in dem Fall nur durchgereicht. Also gar nicht gut.

    Auch in Python wohl statisch eingebunden, falls jemand einen Python Webdienst betreibt.

    • Neu
    Zitat von SiebenG

    Also gar nicht gut.

    Hier als kleiner Tipp, wer Python server oder uptime kuma hinter einem reverse proxy betreibt -- als hotfix bis auch nodejs/Python ein Update bekommt:

    Apache:

    Apache Configuration
        # 1. Strip Accept-Encoding so Node.js never responds or compresses with Brotli
    RequestHeader unset Accept-Encoding

    # 2. Block clients trying to upload malicious Brotli-compressed payloads
    RewriteEngine On
    RewriteCond %{HTTP:Content-Encoding} "br" [NC]
    RewriteRule .* - [F,L]

    Nginx:

    Code
    # Clear Accept-Encoding so Kuma doesn't communicate with clients via Brotli
        proxy_set_header Accept-Encoding "";
        
        # Block clients explicitly sending Brotli compressed request bodies
        if ($http_content_encoding ~* "br") {
            return 415; # Unsupported Media Type
        }

    Mit Hilfe von KI erstellt, für den Apache funktioniert es (allerdings auch erst im zweiten Anlauf), für nginx nicht getestet.

  • m_ueberall 25. Oktober 2026 um 09:10

    Hat den Titel des Themas von „CVE-2026-111497 ("http2shell") (Remote Code Execution/RCE)“ zu „CVE-2026-111497 ("http2shell") (Remote Code Execution/RCE) [Update #1]“ geändert.
    • Neu
    Zitat von SiebenG

    Hier als kleiner Tipp, wer Python server oder uptime kuma hinter einem reverse proxy betreibt...

    Funktioniert das auch, wenn man Uptime Kuma nicht hinter einem Rev Proxy betreibt, sondern im Docker Container über Port, wenn man es in die Apache-Config, der Hauptdomain auf dem Host einfügt?
    EDIT: Was aber ja sowieso nutzlos wäre, denn man könnte Update Kuma ja dann einfach über die Server-IP aufrufen und den vhost damit umgehen.
    Ist ja Quatsch, was ich da schreibe. Vergesst es.

    • Neu
    Zitat von aRaphael

    Funktioniert das auch, wenn man Uptime Kuma nicht hinter einem Rev Proxy betreibt, sondern im Docker Container über Port, wenn man es in die Apache-Config, der Hauptdomain auf dem Host einfügt?

    Verstehe ich nicht ganz... Wie leitest denn von Deiner Hauptdomain auf den kuma port weiter (falls per proxy: dann ja)? Oder direkter Zugriff Hauptdomain:kumaport? Bei letzteren klappts dann nicht.

    • Neu

    EDIT: Da ich Uptime Kuma im docker-Container laufen habe, reicht wohl jetzt schon einfach ein erneutes Pull, da die aktuellen Images von Uptime Kuma (nach dem 22.10) die gepatchten Version von node.js (>=v22.23.4) und brotli schon enthalten dürften. (Falls ich das richtig recherchiert habe)

    Jo, hat geklappt:

    Code
    > docker compose pull
> docker compose up -d
> docker exec -it uptime-kuma node -v
v22.23.4