Nieuws
image

Wikipedia in read-only mode nadat malafide script tal van admin-accounts compromitteert

donderdag 5 maart 2026, 21:13 door Redactie, 9 reacties
Laatst bijgewerkt: 06-03-2026, 12:50

Wikipedia was vanavond enige tijd in read-only mode nadat een malafide script dat als onderdeel van een test werd uitgevoerd talloze admin-accounts compromitteerde. Via deze gecompromitteerde accounts werden artikelen op Meta-Wiki gevandaliseerd en verwijderd, alsmede code geïnjecteerd om het script verder te verspreiden. De code werd automatisch uitgevoerd bij bezoekers van gecompromitteerde pagina's. Het ging daarbij alleen om pagina's van Meta-Wiki, de community site voor projecten van de Wikimedia Foundation, de stichting die onder andere Wikipedia host.

Op zowel Reddit als Hacker News wordt gemeld dat een security engineer van de Wikimedia Foundation een test uitvoerde waarbij willekeurige user scripts werden uitgevoerd. Deze tests voerde de engineer uit onder zijn eigen account, dat over veel rechten beschikt, waaronder de mogelijkheid om CSS en JavaScript aan te passen dat op elke Wikipedia-pagina draait.

Eén van de scripts die de engineer gebruikte voor zijn test was een malafide script dat een paar jaar geleden was gebruikt voor het aanvallen van twee alternatieve Wiki-projecten. Nadat de engineer het script uitvoerde begon het zich vervolgens op Meta-Wiki te verspreiden, waarop werd besloten om alle Wikimedia-projecten in read-only te plaatsen en alle user JavaScript tijdelijk uit te schakelen. Inmiddels zijn alle Wiki's weer terug in read write mode, maar sommige functionaliteit is nog steeds uitgeschakeld. Een medewerker van de Wikimedia Foundation zou via Discord hebben laten weten dat er geen permanente schade is veroorzaakt of persoonlijke informatie gelekt.

Update

De Wikimedia Foundation is met een korte reactie gekomen, waarin het bevestigt dat een medewerker een fout maakte en stelt dat het beveiligingsmaatregelen gaat treffen voor user JavaScript, om soortgelijke incidenten in de toekomst lastiger te maken. Daarnaast zouden alleen op Meta-Wiki pagina's zijn verwijderd.

Reacties (9)
Reageer met quote
05-03-2026, 22:58 door Anoniem
Op zowel Reddit als Hacker News wordt gemeld dat een security engineer van de Wikimedia Foundation, de stichting die Wikipedia host, een test uitvoerde waarbij willekeurige user scripts werden uitgevoerd. Deze tests voerde de engineer uit onder zijn eigen account, dat over veel rechten beschikt, waaronder de mogelijkheid om CSS en JavaScript aan te passen dat op elke Wikipedia-pagina draait.

Zoiets test je toch eerst uit in een testomgeving. Niet in de productieomgeving.
(En nee, een testomgeving hoeft niet 100% van all de data te bevatten, maar wel al de code)

Of heb ik dat in mijn 30+ jaren werkervaring (als oa. programmeur, applicatiebeheerder, en ruim 15 jaar als Oracle DBA) altijd verkeerd begrepen.
Hebben we dan uberhaubt nog testomgevingen nodig?
Dat bespaart natuurlijk wel weer resources.
Reageer met quote
06-03-2026, 02:25 door Anoniem
Tip: bezoek Wikipedia met JavaScript uitgeschakeld. Veel prettigere ervaring.
Reageer met quote
06-03-2026, 03:45 door Anoniem
Op staande voet ontslaan. Dit is gewoon incompetentie.
Reageer met quote
06-03-2026, 07:16 door [Account Verwijderd]
Leermomentje..
Reageer met quote
06-03-2026, 08:32 door musiman
Heeft wikipedia geen testomgeving? Het was mijns inziens een beetje dom om zo'n gevaarlijk script op de productie omgeving los te laten.
Reageer met quote
06-03-2026, 10:19 door Anoniem
Door Anoniem: Op staande voet ontslaan. Dit is gewoon incompetentie.

Of het nieuwe werken. ;-)

Hoe oud was die security engineer en hoeveel werkervaring had hij/zij/het?
Waren er procedures en heeft hij/zij/het zich daar netjes aan gehouden?
Reageer met quote
06-03-2026, 12:02 door Anoniem
Door Anoniem:
Op zowel Reddit als Hacker News wordt gemeld dat een security engineer van de Wikimedia Foundation, de stichting die Wikipedia host, een test uitvoerde waarbij willekeurige user scripts werden uitgevoerd. Deze tests voerde de engineer uit onder zijn eigen account, dat over veel rechten beschikt, waaronder de mogelijkheid om CSS en JavaScript aan te passen dat op elke Wikipedia-pagina draait.

Zoiets test je toch eerst uit in een testomgeving. Niet in de productieomgeving.
(En nee, een testomgeving hoeft niet 100% van all de data te bevatten, maar wel al de code)

Of heb ik dat in mijn 30+ jaren werkervaring (als oa. programmeur, applicatiebeheerder, en ruim 15 jaar als Oracle DBA) altijd verkeerd begrepen.
Hebben we dan uberhaubt nog testomgevingen nodig?
Dat bespaart natuurlijk wel weer resources.

Dat is in traditionele omgevingen vaak nog steeds wel het geval.

Maar clouddiensten als Netflix of Spotify werken op een hele andere manier.
Daar worden wijzigingen meteen naar productie gezet en een selectief groep live gebruikers worden doorgestuurd naar de nieuwe versie. Bij problemen rollen ze het terug, gaat het goed, worden er meer mensen toegelaten om het testen totdat de versie uiteindelijk uitgerold is voor alle gebruikers.

Ze doen wel unittests vanuit hunb code e.d. , maar de eindgebruiker is eigenlijk de "acceptie"tester zonder dat ze dit door hebben. Hierdoor heb je veel minder infra/resources nodig dan bij een traditionele OTAP straat.
Reageer met quote
06-03-2026, 13:16 door Anoniem
Door Anoniem:
Door Anoniem:
Op zowel Reddit als Hacker News wordt gemeld dat een security engineer van de Wikimedia Foundation, de stichting die Wikipedia host, een test uitvoerde waarbij willekeurige user scripts werden uitgevoerd. Deze tests voerde de engineer uit onder zijn eigen account, dat over veel rechten beschikt, waaronder de mogelijkheid om CSS en JavaScript aan te passen dat op elke Wikipedia-pagina draait.

Zoiets test je toch eerst uit in een testomgeving. Niet in de productieomgeving.
(En nee, een testomgeving hoeft niet 100% van all de data te bevatten, maar wel al de code)

Of heb ik dat in mijn 30+ jaren werkervaring (als oa. programmeur, applicatiebeheerder, en ruim 15 jaar als Oracle DBA) altijd verkeerd begrepen.
Hebben we dan uberhaubt nog testomgevingen nodig?
Dat bespaart natuurlijk wel weer resources.

Dat is in traditionele omgevingen vaak nog steeds wel het geval.

Maar clouddiensten als Netflix of Spotify werken op een hele andere manier.
Daar worden wijzigingen meteen naar productie gezet en een selectief groep live gebruikers worden doorgestuurd naar de nieuwe versie. Bij problemen rollen ze het terug, gaat het goed, worden er meer mensen toegelaten om het testen totdat de versie uiteindelijk uitgerold is voor alle gebruikers.

Ze doen wel unittests vanuit hunb code e.d. , maar de eindgebruiker is eigenlijk de "acceptie"tester zonder dat ze dit door hebben. Hierdoor heb je veel minder infra/resources nodig dan bij een traditionele OTAP straat.


Hoe is dit dan ongemerkt door hun "unit-tests" heen gekomen?


Deze werkwijze in de cloud komt op mijn juist over als zeer ouderwets.
Uit mijn begin tijd toen resources (zoals bv opslag) nog hardstikke duur waren.

Maar juist tegenwoordig, waar dat soort resources schaalbaar en "spotgoedkoop" zijn, zou je juist verwachten dat ze een testomgeving hebben. Al dan niet met alle data. Maar wel met alle code en een representatief stukje data.
Zodat je dit soort scripts kunt testen voordat je je productieomgeving overhoop haalt zoals nu gebeurd is.
Recovery kost ook tijd en geld. (en slechte PR)


Het blijft op mij (als oude lul) overkomen als onprofessioneel en onzorgvuldig.
Niet weten wat je script(s) gaan doen. Maar wel productie vernaggelen.
Reageer met quote
09-03-2026, 09:13 door Joep Lunaar
Evident een fout dat in de test met te veel privileges werd uitgevoerd, zeker omdat het ging om user scripts.
Aangezien de test werd uitgevoerd in het kader van een security review en het probleem snel werd ontdekt, mag je aannemen dat dit incident bijdraagt aan het verbeteren van de veiligheid van mediawiki.

NB, wikipedia en aanverwante websites behoren tot de drukst bezochte websites ter wereld en hoewel het aan gebruikers veel toestaat (bewerken van pagina's, lemmata) en er veel gebruikersaccounts zijn, is het aantal ernstige veiligheidsincidenten laag. Open source in combinatie met goede governance is veel waard.

Voor hen die niet goed bekend zijn met de systemen van Wikipedia:
- mediawiki is de naam van de programmatuur achter wikipedia
- mediawiki is ook de naam van de development community
- mediawiki.org is de wiki van die community
- mediawiki.org draait, net als wikipedia, mediawiki
Zie: https://www.mediawiki.org
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search
Certified Secure Full Stack Training 2026 Salt Road: Compromised Components