PHP2Shell på Synology: Hvordan vi oppdaterte seks nettsteder på én dag

PHP2Shell er navnet bransjen bestemte seg for for CVE-2026-109618 og CVE-2026-109619, et par kritiske feil i selve PHP-motoren som tillater uautorisert ekstern kjøring av kode. Detaljer lekket 20. oktober 2026, dagen før den koordinerte avsløringen, og PHP-prosjektet sendte ut nødutgivelser 21. oktober. Fordi feilen befinner seg i tolken og ikke i noen applikasjon, gjør det ingenting å oppdatere WordPress, Joomla eller MediaWiki. Den eneste virkelige løsningen er en ny PHP-bygg. Vi kjører seks offentlige WordPress-nettsteder på Synology-maskinvare, og PHP2Shell betydde at alle måtte bygges opp igjen samme uke. Denne veiledningen dekker hva feilen egentlig er, hvordan du oppdaterer den på DSM gjennom Pakkesenteret, hvordan du håndterer den når nettstedet ditt kjører i en container i stedet, og den ubehagelige sammenligningen mellom det Synology leverte og det de andre NAS-leverandørene har klart så langt.

SynoPower Club-punkt:Våre seks nettsteder ble oppdatert innen én virkedag etter at PHP2Shell-veiledningen kom, og den delen som gjorde det mulig var ikke heltemot, det var Synology som publiserte fiksede pakker på samme dato som veiledningen. Synology-SA-26:14 ble publisert 22. oktober med status Løst og en komplett tabell over fiksede versjoner ned til PHP 7.4. Samme dag publiserte QNAP QSA-26-18 med status Fiksing og ordene Skal annonseres i hver eneste celle med fiksede versjoner, og ASUSTOR svarte ved å slette eldre PHP fra App Central i stedet for å oppdatere den. Hvis du selv er vert for et offentlig nettsted på en NAS, er ikke dette gapet en markedsføringsdetalj. Det er forskjellen mellom å oppdatere en pakke og å fjerne nettstedet ditt fra internett mens du venter.

Hva er PHP2Shell og hvorfor det er annerledes

PHP2Shell er ikke én feil, men en klynge av relaterte minnesikkerhetsfeil i hvordan PHP rydder opp etter en forespørsel som gikk tom for minne. PHP bruker longjmp() for å unngå fatale feil, inkludert minnebrist, og det hoppet hopper over oppryddingskode som normalt ville satt motoren tilbake til en kjent tilstand. Noe av denne tilstanden er global og overlever til neste forespørsel som håndteres av den samme arbeidsprosessen.

CVE-2026-109618 er siden med lite minne. En håndlaget HTTP-forespørsel utnytter minnegrensen mens forespørselsdata bare delvis initialiseres, slik at oppryddingsrutinen går gjennom strukturer som aldri ble fullført. CVE-2026-109619 er siden med bruk etter frigjøring: global tilstand som peker mot frigjort forespørselsminne kan leses av en senere forespørsel på samme arbeider, og det er slik feilen blir til kodeutførelse eller minneavsløring.

To egenskaper gjør PHP2Shell verre enn den vanlige PHP-veiledningen. For det første er den pre-auth. Begge feilene utløses før noen autentisering på applikasjonsnivå kjører, så en påloggingsvegg, en medlemskapsplugin eller et administratorpassord beskytter ingenting. For det andre lekker minneavsløringsvarianten arbeidsprosessminne, og en PHP-arbeider på et WordPress-nettsted inneholder databaselegitimasjon, API-tokens og betalingsnøkler. En vellykket lesing trenger ikke å nå kodekjøring for å ødelegge uken din.

De to PHP2Shell CVE-ene ble scoret til CVSS v4.0 9.2 av PHP-sikkerhetsteamet. Synology scoret dem 9.8 på CVSS v3.1 i sin egen rådgivning. Ulike skalaer, samme konklusjon. Rapporter om utnyttelse er blandede: watchTowr sier at de har sett forsøk mot sitt honeypot-nettverk, mens Bitdefender ikke rapporterte noe i sin telemetri i skrivende stund, og QNAP oppgir at de ikke har mottatt noen rapporter om utnyttelse spesifikt rettet mot QNAP-produkter.

PHP2Shell vs. en vanlig WordPress-utnyttelse

Det meste av det som treffer et offentlig WordPress-nettsted er en plugin-sårbarhet. Mønsteret er kjent: en plugin sender et ødelagt REST-endepunkt, en skanner finner det, du oppdaterer plugin-en, og hullet lukkes. PHP2Shell bryter den vanen fullstendig, og refleksen med å revidere pluginer er bortkastet innsats her.

Aspekt	Typisk CVE for plugin-moduler	PHP2Shell
Hvor insektet bor	Applikasjonskode (plugin eller tema)	Selve PHP-tolkeren
Hvem kan utløse det	Trenger ofte en abonnent- eller administratorrolle	Ingen. Forhåndsgodkjenning, før applogikken kjører
Hjelper det å oppdatere WordPress	Vanligvis ja	Nei. Kjerne- og plugin-oppdateringer er irrelevante.
Stopper en WAF det	Vanligvis, når en regel først finnes	Delvis. Forespørselsformregler går glipp av OOM-banen.
Hva som egentlig fikser det	Plugin-oppdatering	En ny PHP-versjon, ingenting annet
Eksplosjonsradius	Ett nettsted, én funksjon	Alle PHP-nettsteder på boksen, samtidig

Den siste raden er grunnen til at PHP2Shell ble til en hel arbeidsdag i stedet for en ettermiddag. En enkelt delt PHP-pakke på en NAS kan ligge bak et dusin virtuelle Web Station-verter, og et enkelt containerbilde kan være basen for flere nettsteder. Oppdatering er ikke per nettsted, det er per kjøretid, og du må liste opp kjøretidene før du kan hevde at noe er gjort.

Slik vet du om NAS-en din er eksponert

Å finne ut av PHP2Shell-eksponeringen din starter med å skille mellom to forskjellige spørsmål. Inneholder boksen en sårbar PHP-bygg, og er den bygget tilgjengelig fra internett? Synology skiller eksplisitt mellom dette: DSM leverer en intern PHP-komponent som brukes av operativsystemet, og Synology oppgir at den ikke har noen eksternt tilgjengelige moduler og derfor ingen eksponert angrepsflate. Risikoen den tilordner til den komponenten er minimal, og oppdateringen er planlagt for en senere DSM-utgivelse slik at sårbarhetsskanninger slutter å flagge den.

Pakkene som er viktige for PHP2Shell er de som leverer PHP til nettet. Synology lister opp Kalender, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station og WordPress. Hvis du har noen av disse installert og tilgjengelige, er du innenfor rammen.

Sjekk versjoner direkte i stedet for å stole på et dashbord. I Pakkesenteret viser de installerte PHP-pakkene versjonen sin på flisen, og oppdateringsvarselet navngir målbygget. Fra et skall, spør selve kjøretidsprogrammet:

# Synology PHP-pakke (juster banen til versjonen du kjører) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # En containerisert nettstedsdocker-eksekversjon php -v

Grunnen til å insistere på php -v Når du reviderer for PHP2Shell, er det at alle andre signaler lyver. Byggeutdata kan rapportere suksess ved gjenbruk av et hurtigbufret lag, et dashbord kan vise en pakke som aktuell når den kjørende arbeideren ikke er det, og en HTTP-svarheader kan fjernes av et CDN før du i det hele tatt ser den. To av våre seks nettsteder ble rapportert som sunne av administratorskjermene sine mens de fortsatt kjørte en uoppdatert tolk.

Oppdatering av PHP2Shell på Synology i 4 trinn

For et Web Station-nettsted på DSM er hele PHP2Shell-fiksen en Pakkesenteroppdatering. Synology publiserer PHP-sikkerhetsoppdateringer for DSM 7.4, 7.3 og 7.2, og etter at PHP-pakkeoppdateringene starter de avhengige pakkene på nytt, noe som løser problemet. Mail Station er det dokumenterte unntaket og trenger en egen manuell oppdatering.

Skjermbildet ovenfor er fra en av våre egne maskiner morgenen etter PHP2Shell-veiledningen. Merk at "What is New"-panelet navngir oppstrømsversjonen direkte, slik at du kan matche Synology-byggesuffikset med PHP-utgivelsen uten å gjette. Synology-kalenderen vises i den samme oppdateringslisten på 3.0.4-21435, som er nøyaktig den versjonen veiledningen ber om.

En PHP2Shell-felle som er verdt å nevne for Web Station-brukere: en DSM-maskin kan ha flere PHP-grener installert samtidig, og hver virtuelle vert er bundet til én profil. Å oppdatere standardprofilen hjelper ikke et nettsted som er festet til en annen gren. List opp profilene først, oppdater alle, og sjekk deretter bindingen til hvert nettsted under Web Service.

Hvilke DSM-pakker er berørt

Synology-setningen på PHP2Shell er smalere enn panikken antydet. Bare systemer som kjører visse PHP-avhengige pakker er berørt, og Synology Drive er eksplisitt ikke en av dem. IDrive er på listen, men er tredjepartsprogramvare.

• Nettrettet og høyeste prioritet. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer og phpMyAdmin. Disse serverer PHP til alle som kan nå dem.
• E-post og kalender. Mail Station trenger en manuell oppdatering etter PHP-pakken. Synology Kalender har sin egen faste versjon på 3.0.4-21435.
• DSMs interne komponent. Tilstede, men ikke eksternt tilgjengelig, oppdatering utsatt til en senere DSM-utgivelse, risiko vurdert som minimal av Synology.
• Containere er ikke tildekket. En PHP-kjøretidsfil i Container Manager kan du oppdatere. Ingen pakkeoppdatering vil berøre den, noe som er den vanligste grunnen til at en NAS-eier tror de er ferdige når de ikke er det.

Hvis du fortsatt bruker en DSM-utgivelse eldre enn 7.2, anbefaler Synology at du midlertidig deaktiverer de berørte pakkene inntil en oppdatert versjon er tilgjengelig. DSM 7.2 er i seg selv markert som «end of life» i setningen, selv om den mottok disse PHP-oppdateringene.

Det harde PHP2Shell-tilfellet er PHP 7.3 og eldre. Synology vil ikke fikse 7.3 fordi grenen er slutten av sin levetid, og upstream publiserte ingenting i det hele tatt for 7.3 og tidligere. Linux-distribusjoner sendte backports for noen gamle strømmer, men en Synology PHP-pakke er ikke en distribusjonspakke. Hvis et nettsted trenger 7.3 eller 5.6 for å kjøre, kommer det ingen patch, og de ærlige alternativene er å flytte nettstedet til en støttet gren, legge det bak en WAF, eller ta det av det offentlige internett.

Hvordan eiere av containernettsteder håndterer PHP2Shell

Fem av våre seks nettsteder kjører WordPress i Docker i stedet for Web Station, og det er der PHP2Shell blir interessant, fordi Pakkesenteret ikke kan hjelpe deg. Kjøretiden er det imaget inneholder, og å gjenoppbygge et image er ikke det samme som å oppdatere det.

PHP2Shell-feilen vi traff først, og den som mest sannsynlig vil ramme andre, er at en gjenoppbygging av et tilpasset bilde bruker det hurtigbufrede basislaget på nytt. En ufestet FRA Taggen betyr ikke «fersk». Et av imagene våre hadde blitt gjenoppbygd fire dager tidligere og inneholdt fortsatt en PHP-bygg fra juli 2025, mer enn et år med sikkerhetsrettelser bakover, fordi ingenting hadde tvunget Docker til å hente basen på nytt.

# Feil: bruker i stillhet om igjen det basislaget som er mellomlagret lokalt docker build -t mysite. # Riktig: hent alltid basisbildet på nytt docker build --pull -t mysite. # Hent deretter bare opp tjenesten du mener, uten å starte sovende sibling docker compose up -d --no-deps wordpress # Og bekreft det som faktisk betyr noe docker exec wordpress php -v

Den andre PHP2Shell-feilen er enda verre fordi den rapporterer suksess. Byggeutdata sendes gjennom hale skjuler en byggefeil, siden utgangskoden til en pipeline tilhører den siste kommandoen i den, og sett -e utløses aldri. Komponeringstrinnet gjenskaper deretter beholderen fra det gamle bildet, skriver ut Startet, og du går videre fra et uoppdatert nettsted som ser nylig utplassert ut. Sjekk byggeresultatet på egenhånd, og bekreft med php -v etterpå.

To mindre merknader. Tagg det gamle bildet før du gjenoppbygger, fordi et bilde beholder taggen sin og gir deg et gratis tilbakestillingspunkt som er mye billigere enn et øyeblikksbilde. Og ikke forvent at en bildeoppdatering oppgraderer applikasjonen: det offisielle WordPress-bildeinngangspunktet kopierer bare kjernefiler når dokumentroten er tom, så å gjenskape en container på et nyere bilde lar en eksisterende installasjon ligge nøyaktig der den var. Vi bekreftet dette på en oppstartskopi før vi tok i bruk produksjon, og WordPress-versjonen flyttet seg ikke.

Hvorfor deaktivering av session.upload_progress bare dekker halvparten

PHP2Shell-avbøtningsmiddelet som sirkulerer for maskiner som ikke kan oppdateres, er å sette session.upload_progress.aktivert = 0, og på DSM som ligger i Web Station under Innstillinger for skriptspråk, i Kjerne-fanen i PHP-profilen. Det er verdt å gjøre. Det er ikke en løsning, og gapet er viktig.

Stien for opplastingsfremdrift for økten er bare én av måtene inn. Varianten for minneavsløring nås gjennom vanlig håndtering av flerdelte forespørsler og krever ikke sesjonsfunksjonen i det hele tatt, så å slå av funksjonen lar denne banen stå åpen. PHP-prosjektet har sagt direkte at det ikke finnes noen fullstendige begrensninger, og at oppdatering er den eneste sikre løsningen. Imunify360 rapporterer at ingen regler for øyeblikket blokkerer banen for lite minne til CVE-2026-109618, og Elastic bemerker at innstillingen for opplastingsfremdrift lukker de bekreftede sesjonsbanene, men ikke alle varianter.

Du vil også se minnegrense = -1 foreslått, basert på logikken om at feilen nås gjennom en minneutgang. Behandle det som en byttehandel, ikke en gevinst. Å fjerne grensen på en offentlig webserver endrer én feilmodus til en annen, og på en NAS med et delt minnebudsjett inviterer det arbeiderpoolen til å uttømme hele maskinen i stedet.

Kantfiltrering er PHP2Shell-laget som virkelig legger til noe, fordi det ser dekryptert trafikk og ruteren din ikke gjør det. Cloudflare har implementert administrert regelbeskyttelse for PHP2Shell, AWS la til CVE-2026-109619-dekning i versjon 2.3 av sin PHP-administrerte regelgruppe, og Azure Front Door leverte regel 99006001, som er deaktivert som standard. Fellesskapsregler for Snort og Suricata finnes på GitHub, men de offisielle regelsettene for Snort og Emerging Threats hadde ikke publisert noe i skrivende stund, så en funksjon for forebygging av NAS-inntrenging kommer ikke til å redde deg her. Den kan uansett ikke lese innsiden av TLS.

Hvilken NAS-leverandør leverte faktisk en løsning

Dette er den delen av PHP2Shell-historien som bør påvirke hva du kjøper. Upstream PHP ble utgitt 21. oktober. Her var de fire største forbruker- og prosumer-NAS-leverandørene dagen etter, hentet fra deres egne veiledningssider i stedet for fra dekningen.

Selger	Rådgivende	Status	Rettede versjoner publisert
Synology	Synology-SA-26:14, 22. okt. 2026	Løst	Ja. Alle grener fra PHP 7.4 til 8.4, pluss Kalender og Mail Station
QNAP	QSA-26-18, 22. oktober 2026	Fiksing	Nei. Hver rad har ordet Skal annonseres
ASUSTOR	Pensjonering av eldre PHP, 22. oktober 2026	Pensjonisttilværelse, ikke en lapp	Nei. PHP 7, 7.3, 7.4 og 8.1 er fjernet fra App Central.
UGRØNN	Ingen funnet	Ukjent	Ingen veiledning funnet for UGOS Pro

Synology publiserte en komplett PHP2Shell-versjonstabell samme dag som veiledningen, og markerte veiledningen som Løst. En DSM-eier som leste den, måtte utføre en handling den ettermiddagen: åpne Pakkesenteret, klikk på Oppdater, bekreft. Det er hele utbedringsprosessen, og det er grunnen til at Web Station-maskinene våre ble ferdige på minutter i stedet for dager.

QNAP publiserte samme dato og listet opp et sett med berørte produkter, inkludert QTS 6.1.0, QTS 5.2.11 og tidligere, QuTS hero h6.1.0, h6.0.x og h5.2.11 og tidligere, QuTScloud c5.2.9 og tidligere, Note Station 3, QNE ADRA, QVR Surveillance på ARM32-modeller og TVR OS. Hver av dem viser statusen Fikser uten fikset versjon. Fordi PHP-kjøretiden er en del av QTS-webkomponentene, er det ingen pakke å oppdatere, så utbedringen må komme som fastvare.

Det QNAP tilbyr PHP2Shell-ofre i mellomtiden er en liste over tiltak, og den er verdt å lese nøye på grunn av hva den ber deg om: deaktiver ruterens portvideresending og UPnP, avpubliser myQNAPcloud-tjenester, flytt ekstern tilgang bak et VPN, begrens administrasjonsportene til klarerte undernett, stopp PHP-baserte applikasjoner du ikke trenger, deaktiver den innebygde webserveren hvis den ikke brukes, og sjekk QuLog Center for tegn på kompromittering. Det er et godt råd for en ikke-oppdatert boks. Det er også, for alle som er vert for et offentlig nettsted, en forespørsel om å slå av nettstedet.

ASUSTOR valgte en tredje løsning. Meldingen deres, datert 22. oktober med tittelen «Legacy PHP Retirement Announcement», fjerner PHP 7, PHP 7.3, PHP 7.4 og PHP 8.1 fra App Central med umiddelbar virkning, anbefaler sikkerhetskopiering av viktige data og ber eiere om kun å bruke PHP 8.3 eller 8.4 fra nå av. Begrunnelsen er forsvarlig, siden oppstrøms kun oppdaterer 8.2 og nyere. Effekten for en eier som kjører et gammelt PHP-program er at kjøretiden forsvinner fra butikken i stedet for å bli fikset, og ASUSTOR oppgir ikke at en oppdatert versjon av 8.3 eller 8.4 er sendt. Legg merke til kontrasten med Synology her, som publiserte en fikset 7.4-versjon på 7.4.33-0131 for akkurat de brukerne ASUSTOR ber om å migrere.

For UGREEN fant vi ingen PHP2Shell-veiledning for UGOS Pro i det hele tatt. Fravær av en offentlig uttalelse er ikke bevis på at et produkt er sårbart, og UGOS Pro leverer kanskje ikke en nettbasert PHP-kjøretidsløsning. Men hvis du er eieren, er ikke taushet et svar du kan handle på, og det er en slags eksponering i seg selv.

Ingenting av dette gjør Synology perfekt. Den vil ikke fikse PHP 7.3, den flagger DSM 7.2 som utgått, og dens egen interne PHP-komponent er fortsatt planlagt i stedet for oppdatert. Poenget er smalere og mer nyttig enn et merkevareargument: den dagen en feil med ekstern kodekjøring før autentisering landet i PHP-motoren, gjorde én leverandør utbedring til en knapp i Pakkesenteret, og de andre gjorde det til et ventespill.

Hvor du finner flere offisielle ressurser

PHP2Shell er to dager gammel i skrivende stund, og situasjonen er fortsatt i endring, så bruk primærkilder i stedet for sammendrag. Det finnes ingen offisiell videodekning fra noen av leverandørene ennå, så listen nedenfor er dokumentasjon snarere enn gjennomganger.

• Synology-SA-26:14 er den autoritative versjonstabellen. Sjekk den på nytt før du oppdaterer, fordi veiledninger blir revidert.
• Synology PSIRT-setningen lister opp de berørte pakkene og forklarer den interne DSM-komponenten og Mail Station-unntaket.
• GitHub-veiledningene GHSA-w8hw-w9fx-j79w og GHSA-6wmf-4rv5-p3rp er lenket fra Synology-veiledningen og beskriver motorens oppførsel i stedet for leverandørens pakking.
• QNAP QSA-26-18 er der en fast firmwareversjon vil vises hvis du kjører QTS eller QuTS hero. Det er siden du skal følge med på, ikke en nyhetsartikkel.
• Ditt eget pakkesenter er det siste ordet om hva som installeres. Rådgivningen forteller deg målbygget, flisen forteller deg hva du faktisk har, og bare php -v forteller deg hva som kjører.

For bakgrunnsinformasjon om å kjøre offentlige nettsteder på virtuelle Synology-maskiner, se vår gjennomgang av flytte en Docker-stack mellom VDSM-gjester dekker øyeblikksbilde- og tilbakestillingsvanene som gjorde denne nødsituasjonen overlevelig.

PHP2Shell-grenser og sikkerhetsnotater

Det er enkelt å oppdatere PHP2Shell på DSM og villedende alle andre steder, så det er verdt å si tydelig om noen begrensninger før du erklærer jobben som fullført.

En PHP2Shell-pakkeoppdatering er ikke en nettstedsrevisjon. Oppdatering av PHP tetter hullet fra det øyeblikket og utover, men hvis boksen var tilgjengelig fra internett mellom 20. og 22. oktober, var den tilgjengelig mens en fungerende utnyttelse var offentlig. Sjekk logger for uventede POST-volumer, se etter filer som dukket opp i skrivbare mapper, og roter eventuell legitimasjon som en PHP-arbeider kan ha hatt. Varianten med minneavsløring gjør rotasjon av legitimasjon til en rimelig forholdsregel snarere enn paranoia.

PHP2Shell-verifisering må målrettes mot den kjørende tolken. Dashboards, byggelogger og responshoder sviktet oss alle minst én gang i løpet av denne runden. Et CDN kan fjerne headeren som ville ha fortalt deg versjonen, en build kan rapportere suksess ved gjenbruk av et hurtigbufret lag, og en pakkeflis kan vise gjeldende mens en gammel arbeider fortsatt betjener. php -v inne i tingen som betjener forespørsler avgjør det.

Containere dekkes ikke av noen PHP2Shell-råd fra leverandører. Dette er verdt å gjenta fordi det er den vanligste falske sikkerhetsfølelsen på en NAS. Hvis nettstedet ditt kjører i Container Manager, forteller Pakkesenter-rapportering av alt oppdatert deg ingenting om nettstedet ditt. Det samme gjelder for tredjepartsapplikasjoner som pakker sin egen runtime.

Konfigurasjonsbegrensninger er delvise per design. Deaktivering av opplastingsfremdrift for økter hjelper, fjerning av minnegrensen bytter én risiko mot en annen, og en funksjon for forebygging av inntrenging i ruteren kan ikke inspisere TLS-trafikk som avsluttes andre steder. Behandle alt dette som tid kjøpt mens du arrangerer en ekte oppdatering, ikke som en erstatning for en.

End-of-life runtime-versjoner har ingen PHP2Shell-sti i det hele tatt. PHP 7.3 og tidligere mottok ingenting fra oppstrøm og ingenting fra Synology. Hvis et nettsted virkelig trenger en ustøttet gren, er avgjørelsen du står overfor migrering, isolering eller tilbaketrekking fra det offentlige internett. Det finnes ikke noe fjerde alternativ, og å late som om det ikke er slik et eldre nettsted blir veien til alt annet på samme boks.

Til slutt, følg med på veiledningen i stedet for nyhetssyklusen. Synology merket SA-26:14 Løste og reviderte den én gang innen seks minutter etter publisering. QNAP har sagt at QSA-26-18 vil bli oppdatert etter hvert som fiksede versjoner blir tilgjengelige. Begge disse sidene vil endres, og versjonsnumrene i denne artikkelen er de som ble publisert 22. oktober 2026.

Referanser

• Synology-SA-26:14 PHP2Shell sikkerhetsrådgivning, publisert 22. oktober 2026, status Løst, med fiksede versjoner for PHP 7.4 til 8.4.
• Synology-erklæring om PHP2Shell-sårbarheter, PSIRT-notatet som viser berørte pakker og DSM-dekning.
• QNAP QSA-26-18, status Utbedrer problemet, berørte produkter er oppført med fiksede versjoner. Annonseres senere.
• Kunngjøring om pensjonering av ASUSTOR Legacy PHP, fjerner PHP 7, 7.3, 7.4 og 8.1 fra App Central.
• Hjelp Net Security med oppstrøms PHP2Shell-utgivelser, som dekker PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 og de kildekode-baserte backportene for eldre grener.

Ofte stilte spørsmål