PHP2Shell (CVE-2026-109618 og CVE-2026-109619): hvað fyrirtæki sem keyra PHP ættu að gera núna

Tæknimaður með fartölvu að vinna við netþjónarekka

Hinn 21. október 2026 gaf PHP-verkefnið út PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 til að laga tvo veikleika sem „geta gert kleift að keyra kóða úr fjarlægð án auðkenningar“. Á mannamáli: hver sem getur sent HTTP-beiðni á vefinn þinn gæti mögulega keyrt sinn eigin kóða á þjóninum þínum. Viðkomandi þarf ekkert lykilorð, og í sumum uppsetningum virkar árásin áður en forritið þitt hefur keyrt eina einustu línu. Veikleikarnir tveir hafa fengið nafnið PHP2Shell, og PHP gefur báðum einkunnina 9,2 (CVSS 4.0, á kvarðanum upp í 10).

Þessi leiðarvísir er fyrir þá sem þurfa að bregðast við: eigendur PHP-vefja og netverslana, upplýsingatæknistjóra og alla sem hafa birgja sem keyrir PHP fyrir þá. Hann var skrifaður 22. október 2026, daginn eftir útgáfuna, upp úr öryggistilkynningum PHP-verkefnisins sjálfs, leiðbeiningum netöryggisstofnana einstakra ríkja og þeim tölum sem fyrirtæki hafa birt. Þar sem heimildum ber ekki saman segjum við frá því.

Í stuttu máli

Uppfærðu PHP sjálft og endurræstu það síðan. Að uppfæra WordPress, Drupal, Laravel eða viðbót lagar þetta ekki. Gallinn er í PHP, undir forritinu þínu.
Allar PHP-uppsetningar sem svara vefbeiðnum falla undir, samkvæmt PHP: PHP-FPM, Apache með mod_php, php-cgi, FrankenPHP og LiteSpeed. PHP telur Apache með mod_php í mestri hættu.
Næstum helmingur PHP-vefja keyrir grein sem PHP-verkefnið gefur ekki lengur út (okkar lestur á gögnum W3Techs, sjá hér á eftir). Fyrir þær greinar er enginn opinber pakki til að setja upp.
Stillingar og eldveggir kaupa tíma, ekki öryggi. PHP telur upp bráðabirgðaráðstafanir og segir að þær „geri uppsetningu ekki örugga“.
Ef þú getur ekki plástrað í dag gefa stofnanirnar í Bandaríkjunum, Bretlandi og ESB sömu ráð: taktu kerfið af netinu þangað til þú getur það.

Hvað gerðist, í tímaröð

19. ágúst 2026. Rannsakendur hjá Wiz finna fyrri gallann, samkvæmt tilkynningu þeirra, og tilkynna öryggisteymi PHP um gallana 24. ágúst. Rannsakenda frá nokkrum öðrum fyrirtækjum er einnig getið í öryggistilkynningum PHP.
20. október. CVE-númerin leka á netið tveimur dögum fyrir fyrirhugaða birtingu. PHP flýtir útgáfunni um einn dag, til 21. október kl. 14:00 UTC, og segir öllum að búa sig undir hana.
21. október, kl. 03:02 UTC. Cloudflare virkjar eldveggsreglur fyrir alla viðskiptavini sem nota WAF fyrirtækisins, ókeypis áskriftarleiðin meðtalin. Síðar greinir fyrirtækið frá því að það hafi „orðið vart við árásarumferð sem beindist að viðskiptavinum okkar“ og séð árásaraðila „breyta árásarkóðanum (payload) til að reyna að komast fram hjá vörnum okkar“.
21. október, um kl. 14:00 UTC. PHP birtir lagfæringarnar og öryggistilkynningu sína. Sama dag beina bandaríska CISA, breska NCSC, CERT-EU og sameiginleg yfirlýsing framkvæmdastjórnar ESB, ENISA, CERT-EU, Europol og landsbundinna CSIRT eininga ESB því öll til fyrirtækja og stofnana að plástra tafarlaust.

Hversu alvarlegt er þetta?

Þrennt greinir þetta frá venjulegri mánaðarlegri uppfærslu.

Árásaraðilinn þarf ekkert nema beiðni. Enga innskráningu, og enginn þarf að smella á tengil. Öryggistilkynning PHP lýsir misnotkun sem sýnt hefur verið fram á gegn Apache með mod_php „þar sem óauðkennd beiðni getur hrundið árásinni af stað áður en nokkur forritskóði keyrir“. Wiz sýndi árásir á nýjustu útgáfur WordPress, Drupal og Joomla og bendir á að „jafnvel einfalt ‚Hello World‘ forrit sem keyrir á PHP-útgáfu sem veikleikinn nær til getur verið berskjaldað“. Kóði sem keyrður er á þennan hátt hefur réttindi notandaaðgangs vefþjónsins, sem á flestum vefjum getur lesið stillingar forritsins: lykilorð gagnagrunnsins, API-lykla, aðgangsupplýsingar að pósti og greiðslukerfum. Fyrir seinni gallann, CVE-2026-109619, staðfestir PHP einnig minnisleka: gögn úr minni þjónsins leka út, jafnvel án fullrar kóðakeyrslu.

Útbreiðslan er gríðarleg. Samkvæmt W3Techs keyrir PHP 69,3% þeirra vefja þar sem vitað er hvaða forritunarmál er notað á þjóninum (tölur frá 22. október 2026). Unit 42 hjá Palo Alto Networks telur yfir 22,6 milljónir tilvika opin á netinu sem hugsanlega eru berskjölduð, samkvæmt eigin skönnun á netinu, og greinir frá því að að minnsta kosti ein evrópsk ríkisstjórn hafi tekið vef sinn úr loftinu í varúðarskyni.

Þróun árásarkóða gengur hratt. CERT-EU greinir frá því að fyrstu frumgerðir árásarkóða (proof of concept) „séu farnar að ganga manna á milli“. Öryggisfyrirtækið watchTowr segir að hunangsgildrur þess (honeypots) hafi skráð misnotkun frá 21. október. Cloudflare greinir frá árásarumferð. Og Wiz segir að rannsakendur þess hafi notað gervigreindarlíkön í gegnum allt ferlið, þannig að einn rannsakandi hafi á einni viku unnið það sem „hefði tekið teymi í heimsklassa marga mánuði“. Árásaraðilar sem aðlaga árásarkóða að þinni PHP-útgáfu hafa sömu verkfæri.

Til að gæta sanngirni gagnvart hinni hliðinni: þegar CISA birti viðvörun sína 21. október hafði stofnunin ekki orðið vör við misnotkun, og hvorugur gallinn var þá kominn í skrá hennar yfir þekkta misnotaða veikleika (Known Exploited Vulnerabilities). Red Hat metur vandann „mikilvægan“ (Important) frekar en alvarlegan, því hefðbundinn Red Hat Enterprise Linux-þjónn keyrir PHP-FPM, þar sem misnotkun er erfiðari. Erfiðari er ekki ómöguleg: PHP staðfestir að ein árásarleið að seinni gallanum virkar líka á PHP-FPM. Ekkert af þessu breytir því hvað þú ættir að gera. Það breytir aðeins því hversu mikinn fyrirvara þú færð.

Hvaða útgáfu ertu með? Tölurnar

W3Techs birtir líka hvaða PHP-útgáfur vefir keyra og byggir þá á þeim vefjum sem gefa upp útgáfuna sína. Þegar tvær töflur þess frá 22. október 2026 eru lagðar saman fæst þetta:

PHP-grein	Hlutfall PHP-vefja	Lagfæring frá PHP-verkefninu
8.3, 8.4, 8.5	um 34%	Já: 8.3.36, 8.4.27, 8.5.12
8.2	um 18%	Já: 8.2.35. En 8.2 sjálf nær endalokum líftíma 31. desember 2026
8.0, 8.1	um 14%	Engin útgáfa. 8.0 og 8.1: aðeins bakfærsla í frumkóða (backport)
7.x	26,9%	Engin útgáfa. 7.4: aðeins bakfærsla í frumkóða; 7.3 og eldri: ekkert
5.x og eldri	7,8%	Ekkert

Um 48% PHP-vefja keyra því grein sem PHP-verkefnið gefur enga lagfærða útgáfu út fyrir, og önnur 18% fá lagfæringuna sína núna en missa stuðning eftir tíu vikur.

Tveir fyrirvarar. W3Techs sér aðeins þá vefi sem sýna útgáfuna sína. Og Linux-dreifing gæti hafa plástrað gamla grein sjálf: Ubuntu hefur gert það, eins og fram kemur hér á eftir. Útgáfunúmerið eitt og sér segir þér ekki hvort þú ert varinn. Útgáfa pakkans frá framleiðandanum þínum segir það.

Skref 1: finndu allar PHP-uppsetningar sem þú keyrir

Þú plástrar ekki það sem þú hefur ekki skráð, og PHP felur sig vel. Breska NCSC biður fyrirtæki og stofnanir að finna öll PHP-kerfi, fyrst þau sem snúa að netinu, og bætir við: „ekki takmarka leitina við úreltar PHP-útgáfur“. Sameiginleg yfirlýsing ESB varar við því að sumar vörur „geti orðið fyrir áhrifum af þessum veikleikum þótt þær virðist ekki nota PHP beint“.

Hvar á að leita:

Vefir og netverslanir: WordPress og WooCommerce, Drupal, Joomla, Magento og Adobe Commerce, Shopware, PrestaShop, TYPO3, og allt sem byggt er á Laravel eða Symfony.
Gleymdu kerfin: smávefir fyrir herferðir, gömul tungumálaútgáfa, sviðsetningar- og prófunarþjónar sem eru aðgengilegir af netinu, vefpósturinn eða þjónustuborðið sem einhver setti upp fyrir mörgum árum.
Gámar: hver gámamynd sem byggð er á grunnmyndinni php ber sitt eigið PHP. Uppfærsla á hýsilvélinni gerir ekkert fyrir hana.
Stjórnborð hýsingar: cPanel, Plesk og svipuð stjórnborð koma með eigin PHP-smíðar við hliðina á þeirri sem fylgir kerfinu. Hver útgáfa sem er virk í stjórnborðinu er sérstakt atriði sem þarf að uppfæra.
Vörur með PHP innanborðs: tilbúinn búnaður (appliances), vöktunartól, CRM-kerfi, þjónustuborðskerfi og stjórnviðmót frá framleiðendum. Hollenska NCSC heldur úti opinberum lista yfir slíkar vörur ásamt stöðu þeirra, birgi fyrir birgi.
Birgjar: hýsingarfyrirtækið þitt, vefstofan þín, hver sú þjónusta þar sem þú veist að PHP liggur undir. Spurðu þá skriflega hvaða PHP-útgáfur keyra kerfin þín og hvenær þau verða plástruð.

Skráðu fyrir hvert og eitt kerfi: PHP-útgáfuna, hvernig PHP keyrir (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, gámur), hvort kerfið er aðgengilegt af netinu og hver getur plástrað það.

Skref 2: plástraðu, í réttri röð

Byrjaðu á því sem er aðgengilegt af netinu, og þar innan á uppsetningum með Apache mod_php.

Á studdri grein (8.2 til 8.5). Uppfærðu í 8.5.12, 8.4.27, 8.3.36 eða 8.2.35, eða í pakka dreifingarinnar þinnar sem inniheldur lagfæringuna. PHP segir að Linux-dreifingar hafi fengið plástrana fyrir fram. Staðfest hingað til:

Ubuntu: lagfærðir pakkar fyrir hverja útgáfu frá 14.04 til 26.10. Á 22.04 og nýrri koma þeir með venjulegum uppfærslum; á 20.04 og eldri þarf áskrift að Ubuntu Pro, sem er ókeypis fyrir allt að fimm vélar (tilkynning Canonical).
Debian: php8.4 8.4.27 fyrir Debian 13 (DSA-6574-1) og php8.2 8.2.35 fyrir Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: öryggistilkynning Red Hat, RHSB-2026-013, telur upp pakkana fyrir hverja útgáfu.
Remi-pakkasafnið, mikið notað fyrir nýrri PHP á kerfum úr Red Hat-fjölskyldunni: 21. október benti CERT-EU á að þar væru engir pakkar komnir á útgáfudeginum og ráðlagði að skipta yfir í pakka dreifingarinnar eða smíða úr frumkóða. Athugaðu hvort safnið hefur náð að bæta úr því áður en þú treystir á það.

Á PHP 7.4, 8.0 eða 8.1. PHP-verkefnið gefur enga útgáfu út fyrir þessar greinar. Öryggisteymi þess gerði lágmarks bakfærslur í frumkóða fyrir greinarnar þrjár, sem hjálpa ef þú þýðir PHP sjálfur. Annars verður lagfæringin að koma frá framleiðandanum þínum (Ubuntu Pro nær til dæmis yfir PHP 7.4 á Ubuntu 20.04) eða með því að færa PHP í nýrri útgáfu. Ráð CISA til allra á 8.1 eða eldri sem geta ekki uppfært eru afdráttarlaus: taktu kerfið úr sambandi þangað til það hefur verið plástrað eða fært í nýrri útgáfu.

Á PHP 7.3 eða eldri. Ekkert kemur frá PHP-verkefninu. Nema einhver framleiðandi plástri enn útgáfuna sem þú keyrir stendur valið á milli þess að færa sig í nýrri útgáfu og að taka kerfið úr sambandi.

Endurræstu eftir uppfærslu. Uppsetning pakka kemur ekki í stað þess PHP sem þegar er í keyrslu. Tilkynning Ubuntu segir það hreint út: „líklega þyrfti að endurræsa“ forritið. Endurræstu PHP-FPM, Apache, LiteSpeed eða gáminn á hverjum þjóni. Athugaðu síðan útgáfuna sem vefþjónninn keyrir í raun, ekki bara php -v á skipanalínunni, sem getur verið önnur PHP-smíð.

Gámar: smíðaðu gámamyndirnar þínar upp á nýtt úr plástraðri grunnmynd og settu þær aftur í rekstur. Plástraður hýsill sem keyrir gamla gámamynd er enn berskjaldaður.

Hýsing í umsjá þjónustuaðila: spurðu þjónustuaðilann um dagsetningu og útgáfu, og athugaðu svo sjálfur.

Skref 3: ef þú getur ekki plástrað í dag

Öryggistilkynning PHP telur upp bráðabirgðaráðstafanir og kynnir þær með viðvörun: þær „draga úr útsetningu fyrir tilteknum árásarleiðum en gera uppsetningu ekki örugga“. Í stuttu máli, fyrir þann sem rekur þjónana þína:

Fyrir CVE-2026-109618: stilltu memory_limit=-1 þannig að forritið geti ekki breytt því (til dæmis með php_admin_value í pool-stillingum PHP-FPM eða í stillingum Apache); stilltu lágt post_max_size (PHP leggur til 8M án skráaupphleðslu, 32M með henni); takmarkaðu stærð beiðna, fjölda reita og fjölda multipart-hluta í vefþjóninum eða milliþjóninum (proxy); og notaðu minnistakmörkun í gámi eða cgroup, aldrei RLIMIT_AS eða RLIMIT_DATA.
Fyrir CVE-2026-109619: stilltu session.upload_progress.enabled=0 í php.ini eða í stillingum þjónsins (ekki með ini_set() eða í .user.ini skrá) og endurræstu öll vinnsluferli (workers). Á PHP 8.5 skaltu líka stilla fatal_error_backtraces=0.

Tvær viðvaranir. Lotustillingin sem fór víða 20. október lokar aðeins leiðum að seinni gallanum, eins og meðlimur í öryggisteymi PHP benti á; hún gerir ekkert gegn þeim fyrri. Og memory_limit=-1 fjarlægir minnisþak PHP sjálfs, svo ein þung beiðni getur nú klárað minni þjónsins. Notaðu þá stillingu samhliða minnistakmörkun í gámi eða cgroup.

Vefforritaeldveggur hjálpar, svolítið. Reglur Cloudflare eru sjálfkrafa virkar í öllum áskriftarleiðum með WAF fyrirtækisins, ókeypis leiðin meðtalin, og Palo Alto Networks og aðrir framleiðendur hafa birt sínar eigin varnir. Cloudflare segir viðskiptavinum þó enn að plástra PHP „jafnvel með WAF-vörnum“, og fyrirtækið fylgdist með árásaraðilum breyta árásarkóðanum til að smeygja sér fram hjá reglum þess. WAF ver líka aðeins þá umferð sem fer í gegnum hann. Ef þjónninn þinn svarar á eigin IP-tölu getur árásaraðili farið fram hjá honum.

Ef ekkert af þessu er hægt að gera fljótt benda CISA, CERT-EU, NCSC og sameiginleg yfirlýsing ESB öll í sömu átt: taktu kerfið af opna netinu þangað til búið er að laga það. Viðhaldssíða í einn dag kostar minna en endursmíðaður þjónn.

Skref 4: athugaðu hvort þú hafir þegar orðið fyrir árás

Glugginn opnaðist 20. október, þegar lekinn hófst, og tilkynnt var um árásarumferð morguninn eftir. Ef kerfi var aðgengilegt og óplástrað á þeim tíma lokar plástrun dyrunum en segir þér ekki hvort einhver hafi komist inn á undan. NCSC biður alla sem gátu ekki plástrað strax að leita að ummerkjum um innbrot og að bakdyrum.

Hvað á að leita að, samkvæmt birtum leiðbeiningum og almennum vinnubrögðum við meðhöndlun öryggisatvika:

PHP-ferli sem gera það sem PHP gerir aldrei, svo sem að ræsa skel (shell) eða sækja verkfæri (CISA).
Óvenjulegar multipart-beiðnir sem á eftir fylgja villur vegna minnistakmarka eða endurtekin HTTP 500 svör, PHP-vinnsluferli sem endurræsast án augljósrar ástæðu, og óvenju stórar eða rangt mótaðar PHPSESSID vafrakökur í svörum (Wiz).
Nýjar eða breyttar PHP-skrár í upphleðslumöppum, skyndiminnismöppum eða vefrótinni, nýir stjórnendaaðgangar í vefumsjónarkerfinu þínu, og tímasett verk sem enginn bjó til.

Hreinir annálar eru engin sönnun. Öryggistilkynning PHP um seinni gallann varar einmitt við þessu, og Wiz bendir á að annálar forrita geti innihaldið lítið samhengi.

Ef þú finnur eitthvað skaltu meðhöndla það sem öryggisatvik, ekki sem plástrunarverk. Einangraðu þjóninn, varðveittu sönnunargögnin, fáðu aðila sem sérhæfir sig í viðbrögðum við öryggisatvikum til liðs við þig, og skiptu um öll lykilorð og lykla sem vefþjónninn gat lesið: lykilorð gagnagrunna, API-lykla, aðgangsupplýsingar að greiðslukerfum og pósti, undirritunarlykla. Þar sem seinni gallinn getur látið minnisinnihald leka skaltu íhuga að skipta um þau viðkvæmustu af þessum lykilorðum og lyklum á öllum þjónum sem voru berskjaldaðir og óplástraðir dögum saman, jafnvel þótt engin merki séu um innbrot.

Skref 5: hvað þú gætir þurft að tilkynna

Veikleiki einn og sér er ekki tilkynningarskylt atvik. Misnotaður veikleiki getur verið það.

NIS2: ef þín starfsemi fellur undir tilskipunina og innbrot telst verulegt atvik skal snemmbær viðvörun berast CSIRT einingunni í þínu landi innan 24 tíma. Sjá leiðarvísi okkar um NIS2.
GDPR: ef aðgangur fékkst að persónuupplýsingum þarf að tilkynna eftirlitsyfirvaldinu innan 72 tíma frá því að þú fékkst vitneskju um öryggisbrotið, nema ólíklegt sé að það skapi áhættu fyrir fólk. Sjá leiðarvísi okkar um GDPR.
Netþolslögin (Cyber Resilience Act): ef þú selur hugbúnað eða tæki með PHP innanborðs ertu framleiðandi vörunnar samkvæmt netþolslögunum. Frá 11. september 2026 hefur framleiðendum borið að tilkynna virkt misnotaða veikleika í vörum sínum í gegnum sameiginlegan tilkynningarvettvang netþolslaganna (CRA Single Reporting Platform), eins og sameiginleg yfirlýsing ESB minnir á. Sjá leiðarvísi okkar um netþolslögin.
Viðskiptavinir þínir: ef þú hýsir eða rekur PHP fyrir viðskiptavini munu þeir spyrja. Stutt skrifleg greinargerð (hvað þú keyrir, hvenær það var plástrað, hvað þú athugaðir) svarar flestum þeirra, og það er sama greinargerð og endurskoðandi eða tryggingafélag með netöryggistrygginguna þína mun vilja sjá.

Eftir neyðarástandið: hvað á að breyta

Á flestum vel reknum þjónum verður PHP2Shell plástrað innan nokkurra daga. Það sem það leiddi í ljós um uppsetninguna þína verður enn satt eftir á.

Vittu hversu langan tíma plástrun tekur þig. Frá öryggistilkynningu þar til allir þjónar hafa verið endurræstir: klukkustundir, dagar eða vikur? Ef heiðarlega svarið er „við þyrftum að spyrja vefstofuna“, lagaðu það áður en næsti veikleiki kemur. Þegar rannsakendur segja að gervigreind hafi stytt vinnu þeirra við árásarkóða úr mánuðum í viku skaltu gera ráð fyrir að árásaraðilar geti farið jafn hratt.
Haltu yfirlitinu sem þú varst að taka saman við. Það var erfiðasti hluti viðbragðanna, og það úreldist um leið og enginn ber ábyrgð á því.
Komdu þér af PHP-útgáfum sem eru komnar að endalokum líftíma. Vefur á 7.4 eða 8.1 þurfti framleiðanda eða bakfærslu í frumkóða í þetta sinn; næst gæti hvorugt verið í boði. PHP 8.2 nær endalokum líftíma 31. desember 2026, svo vefur sem fer af 8.1 ætti að fara beint í 8.3 eða nýrra. Að færa PHP í nýrri útgáfu þýðir oft að uppfæra þarf forritið líka: grein okkar um endalok Drupal, Umbraco og Kentico sýnir hvað það felur í sér fyrir eitt vefumsjónarkerfi.
Veldu PHP-FPM frekar en mod_php þar sem þú getur. Það var uppsetningin með minni áhættu í þetta sinn.
Hafðu upphleðsluframvindu (upload progress) óvirka ef þú notar hana ekki. Öryggistilkynning PHP leggur til að session.upload_progress.enabled sé áfram óvirkt, líka eftir plástrun, þegar forritið þarf ekki á því að halda.
Skrifaðu tímamörk fyrir plástrun inn í samningana þína. Spurðu hýsingaraðilann og vefstofuna hversu fljótt þau setja inn alvarlegar PHP-lagfæringar, og fáðu svarið skriflega.

Gátlisti fyrir þessa viku

Skráðu allar PHP-uppsetningar, þar á meðal gáma, stjórnborð, vörur frá framleiðendum og sviðsetningarþjóna.
Plástraðu kerfi sem snúa að netinu fyrst, og byrjaðu á Apache mod_php.
Endurræstu öll PHP-ferli og athugaðu útgáfuna sem vefþjónninn gefur upp.
Smíðaðu gámamyndir upp á nýtt og settu þær aftur í rekstur.
Þar sem þú getur ekki plástrað í dag skaltu beita bráðabirgðastillingum PHP, beina umferð í gegnum WAF eða taka kerfið úr sambandi.
Biddu birgja og hýsingaraðila um PHP-útgáfu sína og dagsetningu plástrunar, skriflega.
Farðu yfir annála og breytingar á skrám á öllu sem var berskjaldað og óplástrað frá 20. október.
Ákveddu hvort tilkynningarskylda (NIS2, GDPR, netþolslögin) eigi við.
Skipuleggðu flutning af PHP 8.1 og eldri, og af 8.2 fyrir 31. desember.

Hvar við getum hjálpað

Flest fyrirtæki skortir ekki viljann til að plástra. Það sem þau skortir er skýr mynd af því hvað þau keyra, eða fólk til að vinna verkið þessa vikuna. Þann hluta tökum við að okkur:

Yfirlit og plástrun, á nokkrum dögum. Við finnum PHP-uppsetningarnar þínar á þjónum, í gámum, stjórnborðum hýsingar og hjá birgjum, plástrum þær, endurræsum og sannreynum, og skiljum eftir skriflega skrá yfir hvað var gert og hvenær. Sú skrá er líka svar þitt til viðskiptavina og endurskoðenda.
Burt af gömlu PHP. Forrit sem eru föst á PHP 7.x, 8.0 eða 8.1 af því að kóðinn keyrir ekki á neinu nýrra: við færum þau yfir í studda útgáfu undir þjónustu okkar við viðhald eldri kerfa.
Styrking og föst plástrunarrútína, svo næsta öryggistilkynning verði áætlað verk en ekki neyðarástand.

Ef þú finnur merki um innbrot skaltu fyrst hafa samband við aðila sem sérhæfir sig í viðbrögðum við öryggisatvikum. Við getum tekið að okkur endursmíðina og uppfærsluna samhliða þeim.

Skrifaðu okkur á office@c9group.dev og segðu hvað þú keyrir, og við svörum með því sem við myndum gera fyrst.

Heimildir

Athugað 22. október 2026. Staðan er enn að breytast: einkum gætu staða misnotkunar og pakkar frá framleiðendum hafa breyst síðan.

PHP-verkefnið

Stofnanir

Rannsakendur, framleiðendur og gögn