Brotli-fout blijkt breder dan Node; Apple opent iOS-onderzoek en Wild 0.11 verbreedt linkerroute

De Brotli-kwetsbaarheid die eerder vooral als Node2Shell naar buiten kwam, blijkt volgens een nieuw overzicht een bredere afhankelijkheids- en deploymentopgave: Python, Bun, Envoy en Istio hebben concrete patches, maar de blootstelling hangt af van waar onbetrouwbare Brotli-data wordt gedecodeerd. Apple opent ondertussen zijn jaarlijkse aanvraagronde voor een iPhone met ruime iOS-onderzoeksrechten. Voor toolchainbouwers brengt Wild 0.11 standaard Wasm-linking en een flink uitgebreid compatibiliteitspad.

Brotli-CVE vraagt inventarisatie buiten Node.js

De einde-dagupdate van woensdag 21 oktober behandelde de Node.js-updates voor CVE-2026-111497. Een nieuw overzicht beschrijft nu ook gefixte routes voor de onderliggende Brotli-library, Python-pakketten, Bun, Envoy, Istio en libcurl. De concrete wijziging is dus niet een tweede Node-release, maar een bredere lijst van software die dezelfde decoder meelevert of aanroept.

Volgens dit overzicht moeten Python-omgevingen met Brotli tot en met 1.2.0 naar 1.2.1 en die met brotlicffi 1.2.0.x naar 1.2.1.0. Het wijst erop dat onder meer requests/urllib3, httpx, aiohttp en Scrapy zo’n decoder kunnen activeren zodra de optionele package is geïnstalleerd. Voor proxies zijn onder meer Envoy 1.40.0, 1.39.3, 1.38.6 en 1.37.8 genoemd; Istio noemt 1.29.9, 1.30.6 en 1.31.2. De upstreamfix staat in Brotli 1.2.1 en ook in gepatchte oudere lijnen 1.0.10 en 1.1.1.

Dat maakt een dependency-scan alleen onvoldoende: controleer lockfiles en images, maar ook welke draaiende clients of servers werkelijk Content-Encoding: br verwerken. Een kwetsbare decoder kan volgens de bron zowel via een gecomprimeerde request body als via een response van een onbetrouwbare server bereikbaar zijn. Als patchen nog niet kan, noemt het overzicht het vóór de decoder weigeren van br-requests en -responses als tijdelijke beperking; alleen br uit Accept-Encoding verwijderen is daarbij niet genoeg. De bron waarschuwt bovendien dat advisorydatabases de Python-packages mogelijk nog niet correct koppelen aan deze CVE.

De bijnaam HTTP2Shell suggereert ten onrechte een HTTP/2-fout of een probleem in iedere HTTP-server. Ook in de HN-discussie wordt erop gewezen dat handmatige Brotli-decodering buiten HTTP mogelijk is en dat de praktische ernst per configuratie verschilt. Baseer de prioriteit daarom op bereikbare decodeerpaden, niet op de naam.

Overzicht met versies, decodeerpaden en tijdelijke maatregelen · HN-discussie

Apple neemt aanvragen voor research-iPhones aan

Apple accepteert tot 30 oktober aanvragen voor zijn Security Research Device Program. Een toegelaten onderzoeker krijgt volgens Apple een speciaal gefuseerde iPhone in een jaarlijks verlengbare bruikleenconstructie. Het apparaat biedt shelltoegang, eigen entitlements, eigen tooling en zelfs aanpassing van de kernel, zonder dat de onderzoeker daarvoor de normale iOS-beveiliging hoeft te omzeilen.

Dat is relevant voor iOS-securityonderzoek omdat de standaardhardware juist bedoeld is om zulke toegang te weren. Apple noemt toegang tot softwarepreviews, betaprogramma’s en een onderzoeksgemeenschap, en zegt dat ontdekte kwetsbaarheden automatisch voor de Apple Security Bounty in aanmerking komen. Het programma sluit Apple Pay en third-party apps uit, en deelname vereist een bewezen onderzoekstrackrecord, verblijf in een toegelaten land of regio en goedkeuring door Apple.

De onderzoeksruimte is niet hetzelfde als een vrij te gebruiken ontwikkeltoestel. Het toestel blijft eigendom van Apple, mag niet als dagelijks apparaat mee en moet op de locatie van de deelnemer blijven. Kwetsbaarheden die met het toestel worden gevonden, moeten direct aan Apple worden gemeld — of bij third-party code aan de betreffende derde partij. In de HN-discussie leidde dat tot debat over disclosurevrijheid; de programmapagina verplicht rapportage, maar beschrijft geen volledig publicatiebeleid. Onderzoekers die dit traject overwegen, moeten de contractvoorwaarden daarom zelf op die grens controleren.

Apple Security Research Device Program · HN-discussie

Wild 0.11 maakt Wasm standaard en nadert kernelmodule-compatibiliteit

Wild 0.11.0 zet zijn Wasm-feature standaard aan. Daarmee kan de linker Wasm linken, al ontbreekt ondersteuning voor debug-informatie nog. De release breidt ook de GNU-linker-scriptimplementatie zo ver uit dat Wild volgens de releasenotes Linux-kernelmodules kan linken en dicht bij het linken van de Linux-kernel zelf komt.

Voor Rust- en systems-toolchains is dat een concreet compatibiliteitssignaal: Wild wil niet alleen korte linktijden halen, maar ook meer van de lastige opties en objectformaten van bestaande builds dragen. De release voegt onder meer ELF COMDAT-ondersteuning, linker-scriptcommando’s, AArch64-relaxaties en diverse flags rond executable-stack- en CET-beleid toe. De build vraagt nu minstens Rust 1.99.0.

Ook de Mac-port vordert, maar is nog uitdrukkelijk niet standaard geactiveerd. Wild kan zichzelf op macOS linken en een maintainer gebruikt het daar volgens het project als standaardlinker voor Rust; dat is nog geen brede compatibiliteitsgarantie. De release begrenst daarnaast automatisch het aantal threads op 32 wegens contention op Linux’ per-inode mutex bij grotere aantallen. Test dus eigen linker-scripts, LTO, debug-info, filesystem en doelarchitectuur voordat Wild een reguliere CI- of release-linker wordt.

Wild 0.11.0: release notes · Lobsters-discussie

Undefined behavior is niet hetzelfde als ‘waarschijnlijk segfault’

Een nieuw C++-betoog laat met kleine, gecompileerde voorbeelden zien waarom undefined behavior (UB) niet als een voorspelbare crash moet worden behandeld. In één voorbeeld schrijft een functie naar een volatile variabele en roept daarna std::unreachable() aan. In de getoonde GCC- en Clang-assembly valt de return-instructie weg, waardoor de uitvoering kan doorvallen naar de volgende functie in het binaire bestand.

Een null-pointer-write illustreert hetzelfde punt anders: in de getoonde GCC-uitvoer wordt nul naar adres nul geschreven en volgt ud2, terwijl de broncode 99 schrijft. Met pointerrekenen vanaf null verschijnt juist weer een ogenschijnlijk letterlijke write naar adres 40. De voorbeelden bewijzen niet dat iedere compiler of optimalisatieversie zo handelt; ze onderbouwen wél de beperkte maar belangrijke les dat de taal geen betrouwbare crashsemantiek belooft zodra UB is bereikt.

Voor onderhoud aan C en C++ is de bruikbare reactie niet gokken op het gedrag van de huidige machine, maar waarschuwingen, sanitizers, statische analyse en gerichte tests inzetten. Dat vangt niet alle UB, maar voorkomt dat ‘op onze build crasht het toch’ als veiligheidsaanname in code of review blijft staan.

Voorbeelden met GCC- en Clang-uitvoer · Lobsters-discussie

Verder nog

• Diagnostische logs zijn gegevensdeling: een ontwikkelaar van screenreadersoftware waarschuwt dat bugreport-logs schermtekst, berichten, URL-queryparameters, tokens, documentnamen en klembordinhoud kunnen bevatten. De praktische ontwerpkeuze: maak logbijlagen opt-in, waarschuw concreet en verzamel bij voorkeur een korte reproduceersessie met onschuldige testdata in plaats van een volledige gebruikshistorie. Het is een praktijkbetoog, geen meting naar alle applicaties. Artikel · Lobsters-discussie