Kimi K3-agenter fant Redis-hull: sju sikkerhetsutgivelser på én dag

Redis publiserte sju sikkerhetsutgivelser 23. juli, skriver The Hacker News, etter at forskere la ut fungerende proof of concept-kjeder for autentisert ekstern kodekjøring mot standardbygg av Redis 6.2.22, 7.4.9, 8.6.4 og 8.8.0. Redis' egne utgivelsesnotater bekrefter tidspunktet: alle sju taggene gikk ut i løpet av under to timer samme kveld.

Alle fire kjedene går gjennom RESTORE-kommandoen. Streams-kjedene trenger i tillegg EVAL og XGROUP, mens 8.8.0-kjeden krever EVAL og den innebygde RedisBloom-modulen. To av angrepsmålene, 6.2.22 og 7.4.9, var nettopp de versjonene Redis ba folk installere i mai. De inneholdt ikke eierskapssjekken som stopper den nye feilen.

«De underliggende minnefeilene kan føre til ekstern kodekjøring» — Redis, utgivelsesnotater 23. juli

Den første feilen er en use-after-free i Redis Streams. Et manipulert RDB-objekt kan få to konsumenter til å peke på den samme ventelisteoppføringen, slik at begge frigjør den samme minneblokken. Den andre er en out-of-bounds-skriving i TDigest-lasteren i RedisBloom: den allokerte minne ut fra én serialisert verdi, men stolte på et separat kapasitetsfelt som angriperen kontrollerer. Begge de publiserte skriptene ender med å forgifte en hash-funksjon i databasen, slik at et helt vanlig GET-kall utløser system().

The Hacker News fant også at kildekoden i taggen 8.6.4 mangler duplikatsjekken som utgivelsesnotatene viser til. Sjekken dukker først opp i 8.6.5. Kontroller derfor hvilken versjon du faktisk kjører, ikke om Redis «nylig ble patchet».

Funnene knyttes til KI-agenter. Chaofan Shou skrev på X at Kimi K3-agenter fant 19 zero-days i Redis på rundt 90 minutter, og at en annen kjøring produserte eksploiten mot 8.8.0 på 27 minutter.

«Kimi K3-agenter fant 19 zero-days i Redis på cirka 90 minutter» — Chaofan Shou, sikkerhetsforsker, på X

Tallene, tidsbruken og hvor selvstendig agentene arbeidet er selvrapportert. Redis' offentlige spor bekrefter at feilene og rettelsene finnes, men sier ingenting om antallet zero-days eller graden av autonomi. Verken utgivelsesnotatene fra 23. juli eller de gjennomgåtte PoC-repoene meldte om utnyttelse i naturen per 24. juli, og Redis oppga hverken CVE-nummer eller CVSS-score for de to nye feilklassene.

Hva bør du gjøre?

1. Finn eksakt patch-versjon på hver Redis-instans og oppgrader til den rettede utgivelsen i din branch. Kjører du 6.2.22 eller 7.4.9 fra mai, er du fortsatt eksponert.
2. Trekk tilbake RESTORE fra alle brukere som ikke strengt tatt trenger kommandoen. Det kutter begge de publiserte veiene i ett grep.
3. Steng Redis for utrygg nettverkstrafikk. Kjedene krever autentisering, så en eksponert instans med svakt passord er den enkle inngangen.