PHP2Shell-scans lopen terug, terwijl lokale agentruntimes en GPU-unlocks nieuwe grenzen tonen

Wiz ziet het aantal publiek bereikbare PHP2Shell-doelen afnemen, maar waarschuwt dat mislukte massale exploits geen reden zijn om patches uit te stellen. Voor lokale AI meldt OpenJet een opvallend andere route: meerdere codingagents delen één gewichtsdoorloop op een RTX 3090, met forse maar nog onbevestigde snelheidsclaims.

Verder is er nieuw, voorzichtig te lezen detail over GPU-unlocks op oudere NVIDIA-generaties. InclusionAI heeft bovendien nieuwe Ling-weights én een base-checkpoint gepubliceerd.

PHP2Shell: minder blootstelling, maar aanvallers proberen ketens wel degelijk

Wiz rapporteert sinds de publieke bekendmaking van PHP2Shell ongeveer 67% minder verschillende publiek bereikbare kwetsbare machines in zijn telemetrie. Het aantal organisaties met minstens één blootgestelde kwetsbare instantie zou in dezelfde periode met 47,9% zijn gedaald. Dat zijn trends uit de eigen scanpopulatie: zij bewijzen niet welk deel door patchen, isoleren, uitfaseren of veranderde scanwaarneming komt.

Nieuw is vooral het detail over actieve pogingen. Wiz zag twee varianten van een publieke exploitkit. De nieuwere variant bereikte in de eigen honeypot herhaaldelijk de bedoelde memory-exhaustion-fase, maar de vervolgstap om procesadressen te lekken mislukte telkens; geen van de waargenomen bronnen stuurde daarna een eindpayload. De onderzoekers schrijven dat verschillen in PHP-build, extensies, geheugenlimiet en workerindeling zo’n keten kunnen breken. Ook moeten opeenvolgende requests op dezelfde Apache-worker landen.

Dat is een concretere stand van zaken dan de sterk geconfigureerde demonstratie uit de namiddagupdate van gisteren. Het is nadrukkelijk geen vrijspraak voor kwetsbare servers: Wiz verwijst naar publieke meldingen van succesvolle compromittering van gunstig geconfigureerde honeypots en verwacht dat betere tooling de barrières kan verlagen. Voor beheerders blijft de actie dus patchen of mitigeren; laat een mislukte scan of een afwijkende deployment niet als veiligheidstest gelden. Wiz: telemetrie, waargenomen ketens en beperkingen · HN-discussie

OpenJet wil vier lokale codingagents tegelijk bedienen

OpenJet heeft volgens de maker een multi-agentmodus toegevoegd aan zijn gespecialiseerde CUDA-engine voor Qwen3.8-27B op een RTX 3090. In plaats van per gesprek de modelgewichten opnieuw door de GPU te lezen, voegt de engine de actieve volgende tokens en speculative drafts samen in één batch. Iedere gewichtsdoorloop kan dan werk voor meerdere gesprekken doen; context en attention blijven wel per agent afzonderlijk.

De auteur rapporteert voor vier korte gesprekken 64–72 tok/s per agent, of 256–288 tok/s gezamenlijk, tegenover 72–80 tok/s totaal voor de gebruikte llama-server --parallel 4-vergelijking. Bij vier codingagents noemt hij 150–200 tok/s totaal. De nieuwe server heeft een gedeelde, gepagineerde KV-pool van 132K tokens, bewaart gedeelde system prompts eenmaal en verwerkt nieuwe prompts in stukjes naast lopende decode.

Dit is een echte uitbreiding sinds de namiddagupdate van zondag 11 oktober, die vooral de pariteit en lange-contextmetingen voor de toenmalige enkele conversatiestroom behandelde. De relevante vraag verschuift van topsnelheid voor één chat naar respons onder gelijktijdig agentwerk. De cijfers zijn echter uitsluitend metingen van de maker op één modelquant en kaart; aanwezigheid- en repetition-penalties ontbreken en de Q4-engine is beperkt tot maximaal acht agents. Vergelijk daarom eigen toolloops, lange prefill, kwaliteit en foutgedrag voordat dit een standaardruntime wordt. Meting, ontwerp en beperkingen

GPU-unlockverhaal verbreedt van Ampere naar oudere generaties — maar blijft een testlabroute

Een uitgebreide community-uitleg stelt dat publieke unlocks voor bepaalde Turing-, Ampere- en Ada-kaarten de throughput kunnen verhogen voor tensoroperaties met FP32-accumulatie. Volgens de auteur raakt dit onder meer FP16/BF16, TF32 en op Ada FP8; gewone CUDA-FP32 en veel bandwidth-gebonden single-stream decode zouden er juist weinig aan hebben. Als voorbeelden noemt de post metingen van ongeveer een verdubbeling in ruwe instructierate op specifieke kaarten, terwijl reële workloads eerder door het vermogenslimiet begrensd kunnen worden.

Dit verfijnt het beeld uit de einde-dagupdate van zaterdag 24 oktober, die een Ampere-module al als experimenteel prefill- en matrixpad afbakende. De nieuwe bijdrage beschrijft ook waarom de schrijver geen vergelijkbare route voor consumenten-Blackwell verwacht: daar zou de vroegere firmwareaanvalsvector niet beschikbaar zijn door een andere root of trust. Dat is technische analyse van een individuele auteur, geen bevestiging van NVIDIA of een onafhankelijke securityaudit.

De praktische grens verandert niet: dit is geen gewone tuningoptie voor een werkmachine. Het gaat om code die vóór de normale driver werkt, kan met toekomstige drivers onbruikbaar worden en levert geen extra VRAM of algemene versnelling op. Wie al op oudere hardware experimenteert, moet afzonderlijk prefill, decode, stroom, stabiliteit en de gebruikte kernels meten — en een productiekaart erbuiten houden. Technische analyse en eigen metingen

Ling-3.1-Flash-1019 krijgt weights en een base-checkpoint

InclusionAI heeft Ling-3.1-Flash-1019 gepubliceerd, naast Ling-3.1-Flash-base voor verdere training. Het model heeft volgens de modelkaart 560 miljard parameters, waarvan 25 miljard per token actief zijn, en een contextvenster van één miljoen tokens. De release is daarmee niet alleen een bijgewerkt chatcheckpoint, maar biedt onderzoekers ook een uitgangspunt voor eigen post-training.

De maker schrijft de update hogere scores toe op onder meer AutomationBench-AA (62% naar 68%) en zijn Artificial Analysis Intelligence Index (41 naar 44). Die cijfers zijn leveranciersresultaten; ze laten niet zien hoe het model presteert bij een eigen harness, quantisatie, taal of toolstack. Een kleine maar praktische kanttekening uit de community: het SGLang-voorbeeld in de README zou nog naar de eerdere modelnaam verwijzen.

Voor teams met voldoende inferencecapaciteit is vooral het base-model interessant als zij werkelijk een domeinspecifiek vervolgtraject willen onderzoeken. Voor de meeste lokale opstellingen blijft 560B totaalparameters een harde infrastructuurgrens, ook met slechts 25B actieve parameters. Chatcheckpoint · base-checkpoint · Reddit-signaal

Debian-discussie: wie draagt de last van automatische review?

Een Debian Developer schrijft geen uploads meer naar de NEW-queue te willen doen zolang hij niet kan afzien van een automatische LLM-review. In het aangehaalde reviewresultaat staat dat de output niet door een lid van het DFSG-team is gecontroleerd, fout kan zijn en geen pakketbeslissing vormt. De schrijver betwist onder meer dat deze brede geautomatiseerde stap zonder voorafgaande consensus past bij eerdere projectafspraken.

Dit is geen formele aankondiging van nieuw Debian-beleid, maar wel een scherp praktijkgeval voor open-sourcegovernance. De ontwikkelaar prefereert reproduceerbare en herstelbare checks zoals Lintian boven niet-deterministische tekst die een maintainer zelf moet beoordelen of weerleggen. In de HN-discussie staat daar de ervaring tegenover dat modelreview soms echte fouten vindt; een terugkerend argument is dat de persoon of het team dat de automatisering inzet de output eerst zelf zou moeten beoordelen voordat de last bij een bijdrager belandt.

De vraag is daarmee niet alleen of een modelreview nuttige signalen kan geven, maar ook hoe opt-in, menselijke verantwoordelijkheid, bezwaar en doorlooptijd zijn ingericht. Zonder die grenzen kan een extra reviewlaag netto wachttijd en ongerichte reactielast toevoegen. Bericht aan debian-devel · HN-discussie

Verder nog

• Gforth 1.0 documenteert zijn stabiele oppervlak: de Forth-implementatie legt nu vast welke woorden permanent ondersteund horen te blijven en voegt onder meer uitbreidbare recognizers in de tekstinterpreter, bronlocaties in backtraces, multitasking, message queues en C-callbacks toe. De release notes melden ook een IP-updateoptimalisatie die loopgedomineerde programma’s volgens het project met een factor twee kan versnellen. Dat is een projectclaim, geen algemene benchmark; de kracht van Gforth ligt volgens een HN-bijdrage juist in de portable threaded-code-VM en dictionary images, niet in native executables. Release notes · HN-discussie