vLLM 0.31 verhardt multimodale requests, terwijl iCloud-spoofing een oud mailrisico blootlegt

vLLM 0.31.0 combineert sneller herstarten met strengere standaardgrenzen voor multimodale requests; voor bestaande deployments is dit dus tegelijk een interessante én potentieel brekende upgrade. Een technische disclosure laat daarnaast zien hoe iCloud-mail ooit als willekeurige @icloud.com-afzender kon worden misbruikt, al meldt de onderzoeker dat Apple dit eind 2025 had verholpen.

vLLM 0.31.0: sneller herstarten, maar eerst configuratie en requestpaden nalopen

vLLM 0.31.0 is uit. De release voegt vllm preload toe: een daemon die post-quantisatiegewichten in GPU-geheugen resident houdt tussen engine-herstarts. Ook zijn vllm snapshot create/restore-snapshots via CRIU experimenteel beschikbaar voor een volledig geïnitialiseerde TP1-engine. Dat kan vooral nuttig zijn voor lokale of eigen serving waar laadtijd en warm-up van grote modellen een operationeel probleem zijn.

De belangrijkere upgrade-notitie is beveiliging. Per-request mm_processor_kwargs en media_io_kwargs worden nu standaard geweigerd; een vertrouwde deployment moet daar expliciet --trust-request-mm-kwargs voor zetten. Verder neemt de prefix-cachehash voortaan de bron van extra keys én het LoRA-pad mee, zodat een LoRA-naam en cache_salt niet meer kunnen botsen. De release herstelt ook een situatie waarin oude entries in een multimodale receiver-cache verse payloads konden overschrijven.

Niet blind bijwerken: tokenizer_mode="slow" verdwijnt, een Mamba-cacheoptie krijgt een andere naam, enkele quantisatiepaden zijn vervangen of geschrapt en XPU-graphs staan voortaan standaard aan. Maak dus een stagingtest met echte multimodale requests, LoRA’s, prefix caching en je eigen start/stop-proces; snelle restarts zijn pas waardevol als tokenpariteit, geheugenpiek en API-compatibiliteit behouden blijven. Release notes met securitywijzigingen en breaking changes

iCloud-spoofingdisclosure: geldige mailauthenticatie was geen bewijs van de zichtbare afzender

SEC Consult beschrijft twee inmiddels verholpen fouten in Apples iCloud-mailinfrastructuur. Volgens het onderzoek konden verschillen tussen interne parsers worden misbruikt om een From:-header anders te laten beoordelen dan de daadwerkelijk bezorgde versie. Daardoor zou een aanvaller berichten als een willekeurig @icloud.com-adres kunnen laten verschijnen, terwijl SPF, DKIM en DMARC volgens de getoonde proeven alsnog slaagden.

Dit is geen nieuw, nog openstaand lek. De gepubliceerde disclosure-tijdlijn zegt dat de eerste proof of concept in 2024 stopte met werken, dat er daarna een tweede bypass werd gevonden, en dat SEC Consult in december 2025 bevestigde dat de uiteindelijke fixes het oorspronkelijke probleem verhielpen. De publicatie van 1 oktober maakt vooral de technische keten en de lange afstemming openbaar; Apple zou een bounty van 15.000 dollar hebben toegekend.

De nuttige les voor mailbeveiliging is breder dan iCloud: een groen SPF/DKIM/DMARC-resultaat bewijst niet automatisch dat alle lagen hetzelfde afzenderadres hebben geïnterpreteerd. Ontvangers en filters kunnen aanvullend letten op verschillen tussen zichtbare afzender, envelope sender/Return-Path en ontvangen headers. Dat is hoogstens een extra detectiesignaal, geen vervanging voor correcte parser- en providerfixes. Technische disclosure en volledige tijdlijn · Lobsters-discussie

Eén Qwen-gebruikersrapport is geen exfiltratiebewijs, wel een reden om tool-egress te begrenzen

Een gebruiker meldt dat zijn lokaal draaiende Qwen3.8-Flash-Next tijdens een productzoektaak een browsertool naar een Alibaba Cloud-URL met een signed querystring wilde sturen. De auteur stopte de sessie vóór verder onderzoek en vermoedt zelf dat het om een hallucinatie kan gaan, bijvoorbeeld een patroon uit trainingsdata. De post bevat geen onafhankelijke bevestiging dat de request is uitgevoerd, dat de URL door het model is gegenereerd zonder andere context, of dat er gegevens zijn verstuurd.

Daarmee is dit geen aanwijzing dat Qwen data exfiltreert. Het is wél een bruikbaar voorbeeld van waarom een lokale modelserver niet automatisch een veilige agentomgeving wordt zodra hij een browser- of HTTP-tool krijgt. Ook een volledig lokaal gewicht kan een externe URL voorstellen; de werkelijke netwerkactie gebeurt vervolgens in de toolrunner.

Beperk in zulke workflows uitgaande domeinen en methodes, log toolcalls inclusief bestemmingshost, toon redirects en vraag bevestiging vóór uploads of onbekende endpoints. Behandel een URL bovendien als onbetrouwbare invoer: een signed URL kan tijdelijk toegang geven tot een object, maar zegt zonder inspectie niets over herkomst of bedoeling. Gebruikersrapport en volledige toolcall

Zelf-gehoste SSH-tunnel is handig, maar een dynamische localhost-proxy vraagt harde grenzen

Een technisch recept bouwt een deelbare HTTPS-tunnel met alleen OpenSSH en nginx: ssh -R 0:localhost:8080 krijgt op de server een vrije poort, waarna nginx een subdomein naar 127.0.0.1:<poort> proxyt. Daarbovenop komt een tijdelijke URL-token via nginx’ secure_link-module. Voor een previewserver zonder externe tunneldienst is dat een heldere, kleine bouwsteen.

De veiligheid hangt echter volledig aan de details. De basale configuratie maakt een poortnummer feitelijk het enige geheim; de uitgebreidere versie voegt een tijdgebonden token toe, maar de proxyregel blijft dynamisch naar loopbackpoorten verwijzen. Een HN-deelnemer wijst erop dat een te brede configuratie verkeer naar willekeurige luisterende localhostpoorten kan laten doorsturen en zo firewallverwachtingen kan doorbreken. Dat is een analyse uit de discussie, geen onafhankelijk exploitrapport, maar de configuratie verdient precies daarom een threat model.

Gebruik dit niet als generiek productiepatroon zonder restricties: beperk welke remote forwards een SSH-account mag openen, scheid de tunnelhost van andere lokale diensten, voorkom poort-hergebruik zonder tokenrotatie en kies sterke toegangsbescherming. Controleer ook wat sshd en nginx werkelijk binden op jouw host. Recept en volledige configuratie · HN-discussie met securitykritiek

Verder nog

• ncdu-zig krijgt een onderhoudsfork: rcalixte/ncdu positioneert zich als bijgewerkte fork van de ncurses-disk-usageanalyzer, nu als Zig-implementatie. De repository noemt Zig 0.17, een POSIX-achtig systeem, ncurses en libzstd als vereisten. Dat is een klein maar welkom signaal voor wie ncdu op minimale servers gebruikt; controleer build en gedrag wel zelf voordat je een bestaande package-versie vervangt. Repository · Lobsters-discussie