Gå til indhold
Springcast
KontaktStart gratis
Nyheder

Derfor tog vi Springcast offline af forsigtighed ved to sårbarheder i PHP

Af Springcast Team oktober 2026 5 min. læsning

Kort fortalt. Efter annonceringen af to kritiske PHP-sårbarheder tog vi den 21. oktober Springcast offline af forsigtighed. Det begrænsede risikoen, men lukkede ikke sårbarhederne. I Springcast Pro var feeds, player, podcast-websites og statistik også midlertidigt utilgængelige. Samme dag installerede vi sikkerhedsopdateringen på alle vores servere og var online igen.
Illustration af en afbrudt forbindelse til en server med et pausesymbol som billede på at gå offline af forsigtighed.

Den 21. oktober 2026 tog vi af forsigtighed Springcasts applikationer midlertidigt offline. Dagen før havde PHP’s sikkerhedsteam annonceret to kritiske sårbarheder i den software, vores applikationer kører på. En opdatering, der lukker dem, fandtes endnu ikke.

Beslutningen fik konsekvenser for dig og dine lyttere. Samme dag var vi online igen. Her kan du læse, hvad der skete, hvorfor vi besluttede det, og hvad du mærkede.

Hvad er PHP?

PHP er et programmeringssprog, som mange webapplikationer er bygget med, også Springcasts. Det kører på vores servere, bag de applikationer, du og dine lyttere bruger. Du installerer ikke selv PHP, og du vedligeholder det heller ikke. Skemaet viser, hvor PHP sidder, og dermed også, hvor sårbarhederne sad.

Forenklet skema i fire lag: du og dine lyttere bruger Springcasts applikationer via browser, app eller podcast-app. De kører på PHP, hvor de to sårbarheder sad. PHP kører på vores servere.
Forenklet skema, ikke en teknisk arkitektur. Sårbarhederne sad i PHP, på vores side.

Hvad blev kendt den 20. og 21. oktober?

PHP’s sikkerhedsteam annoncerede den 20. oktober en sikkerhedsopdatering til to kritiske sårbarheder. Begge fik en alvorlighedsscore (CVSS) på 9,2 på en skala fra 0 til 10. Hvilke PHP-versioner der var berørt, og hvilke versioner der lukker sårbarhederne, offentliggjorde PHP først med udgivelsen den 21. oktober.

Med udgivelsen bekræftede PHP, hvad „kritisk“ betyder her: begge sårbarheder kan muliggøre remote code execution. Nogen ville så kunne få en server til at køre egne kommandoer på afstand og uden at logge ind. Ifølge CERT-EU, cybersikkerhedsteamet for EU’s institutioner, er enhver PHP-installation, der håndterer webforespørgsler, udsat for den risiko (sikkerhedsbulletin 2026-018).

En sårbarhed, der rammer software over hele verden, er ikke bevis for et verdensomspændende angreb, og heller ikke for, at noget blev misbrugt hos Springcast. Men risikoen steg hurtigt.

Efter udgivelsen blev tekniske detaljer diskuteret offentligt, og de første proofs of concept begyndte at cirkulere: eksempelkode, der viser, at et angreb virker. Ifølge CERT-EU gjorde det det mere sandsynligt, at angribere allerede udnyttede sårbarhederne.

For os var annonceringen allerede en grund til ikke at lade vores applikationer være tilgængelige via internettet, så længe opdateringen manglede.

Derfor ventede vi ikke på opdateringen

Den 21. oktober tog vi først mindre forholdsregler. Vi slog midlertidigt upload af lyd og billeder fra; upload via filhåndteringen virkede fortsat. Vi tilføjede også ekstra overvågning og alarmer på vores servere. Derefter tog vi et skridt videre.

Der gik tid mellem annonceringen og opdateringen. Så længe vores applikationer i den periode var tilgængelige via internettet, kørte de på software med kendte sårbarheder, som endnu ikke var lukket.

I den første version af sin sikkerhedsbulletin, før udgivelsen, anbefalede CERT-EU organisationer at forberede sig på opdateringen. Var det ikke muligt at opdatere med det samme, anbefalede CERT-EU at overveje at afskærme internetvendte applikationer, indtil der fandtes en løsning. Det gjorde vi: Vi tog applikationerne offline, indtil sårbarhederne ville være lukket. Hvad det gør og ikke gør, kan du se nedenfor.

Forenklet skema. Øverst: så længe opdateringen mangler, sætter en midlertidig offlinegang en afskærmning mellem internettet og Springcasts applikationer, som kører på PHP med sårbarhederne. Adgangen udefra begrænses; selve sårbarhederne er der stadig. Nederst: de nødvendige trin for genopretning. PHP udgiver opdateringen, Springcast installerer opdateringen, og applikationerne går online igen.
Forenklet skema. Den nederste række viser de trin, der skulle til for genopretning.

At gå offline begrænsede risikoen, men lukkede ikke sårbarhederne. Det skete først, da PHP havde udgivet opdateringen, og vi havde installeret den. Det er to forskellige tidspunkter: at PHP udgiver en opdatering, betyder ikke, at Springcast allerede er opdateret.

Valget havde en pris, og den betalte du og dine lyttere: i en periode virkede Springcast ikke. Vi foretrak den ulempe frem for applikationer, der forblev tilgængelige med kendte, alvorlige sårbarheder, som der endnu ikke fandtes en løsning på.

Hvad du og dine lyttere mærkede

Ud over selve applikationerne viste statussiden for Springcast Pro også disse dele som offline:

  • RSS-feeds, som podcast-apps henter nye episoder fra;

  • playeren, også hvor du har indlejret den på et andet website;

  • podcast-websites;

  • statistik.

Afbrydelsen ramte altså ikke kun dig som podcaster. Podcast-apps kunne midlertidigt ikke hente dit feed, og din indlejrede player og dit podcast-website var ikke tilgængelige.

Den 21. oktober informerede vi kunderne pr. e-mail om afbrydelsen og igen senere samme dag, da vi var online igen. På vores website henviste en meddelelse øverst på siden til statussiderne for Springcast Pro og Springcast Classic, hvor vi lagde opdateringerne ud.

Hvad vi ved om dine data

Vi havde ikke observeret mistænkelig aktivitet, da vi besluttede at gå offline, og heller ikke, da vi kom online igen. Selve afbrydelsen har ikke ført til tab af data: at du midlertidigt ikke kunne komme ind på din konto, betyder ikke, at noget er slettet.

Hvordan det endte

Allerede den 21. oktober installerede vi PHP’s sikkerhedsopdatering på alle vores servere og satte applikationerne online igen. Upload af lyd og billeder virkede også igen som normalt, og hos Springcast Pro var RSS-feeds, player og podcast-websites tilgængelige igen.

Det meldte vi samme eftermiddag på statussiden for Springcast Pro og Springcast Classic. Her skrev vi også, at vi ville holde ekstra godt øje med vores systemer de følgende dage.

Spørgsmål?

Har du et spørgsmål om din egen konto, så kontakt vores support. Status for dit miljø finder du på statussiden for Springcast Pro eller Springcast Classic.

← Tilbage til blog