Drupal kondigt opnieuw release van kritieke update aan voor versies 7 en 8

Drupal heeft opnieuw gewaarschuwd voor een patch voor een kritiek lek in versie 7 en 8 van zijn contentmanagementsysteem. Die komt op 25 april uit buiten de normale updateplanning. Waar Drupal bij het eerdere lek sprak van highly critical, hanteert het hier de aanduiding critical.

Daardoor lijkt de ernst van de nieuwe kwetsbaarheid, met kenmerk CVE-2018-7602, minder te zijn dan die van het lek waarvoor het Drupal-team eind maart patches uitbracht. De ernst is wel zodanig dat het team het nodig acht om de release, die buiten de normale planning plaatsvindt, aan te kondigen. Het team geeft geen details, maar schrijft dat het om een follow-up van het vorige lek gaat en dat het ook hier weer mogelijk is dat er binnen enkele uren of dagen exploits voor worden ontwikkeld.

De release vindt op 25 april plaats tussen 16:00 en 18:00 UTC, wat neerkomt op 18:00 en 20:00 lokale tijd. De update komt uit voor versies 7.x, 8.4.x en 8.5.x, waarbij gebruikers van de eerste en de laatstgenoemde release op normale wijze kunnen updaten. Het team raadt gebruikers van versie 8.4.x aan om eerst naar 8.4.8 te updaten en dan later naar een wel ondersteunde versie zoals 8.5.3. Op het genoemde tijdstip wil het Drupal-team meer informatie beschikbaar maken op zijn beveiligingspagina. Er zou geen databaseupdate vereist zijn.

Bij het vorige lek waarschuwde het team ook dat er exploits ontwikkeld zouden worden, wat vervolgens ook gebeurde. Al duurde dit iets langer dan verwacht. Het team waarschuwde op 13 april voor 'geautomatiseerde aanvallen' op ongepatchte Drupal-versies. Vervolgens waarschuwde een beveiligingsbedrijf een week geleden dat varianten van het Tsunami-botnet het op ongepatchte sites hebben gemunt.

Reacties (48)

[BCage]

Ik heb ruim een jaar aan een Drupal 8 project gewerkt en het enige wat ik daar geleerd heb is dat ik nooit meer uit vrije wil Drupal zou gebruiken.

In versie 8 is Symfony als basis genomen. Alles wat ze van Symfony hebben overgenomen is van hoge kwaliteit en werkt perfect. Alles wat nog door Drupal zelf wordt gedaan is dat niet. Zelfs na een jaar ontwikkeling en ervaring was er niets wat in Drupal makkelijker te ontwikkelen was t.o.v. een project wat enkel Symfony als basis had gehad. Als CMS systeem voor onervaren ontwikkelaars is het veel te ingewikkeld, als framework voor ervaren ontwikkelaars werkt het alleen maar tegen je t.o.v. puur Symfony of Laravel.

De databaselaag is een black box die zeer inefficiente tabellen en queries genereert, de back-end is verouderd en niet intuitief, rechtenmanagement is een zooitje, de (gelukkig deprecated, maar nog veel voorkomende) render arrays zijn echt een gedrocht en de documentatie is daarbij ook nog een onoverzichtelijk oerwoud.

Ik besef me dat dit als een flamebait klinkt nu, maar zo is het niet bedoeld. Het is de oprechte ervaring van 14 maanden intwikkeling in Drupal 7 en 8 door ervaren ontwikkelaars.

[kwaakvaak_v2]

Veel ontwikkelaars en vooral de 'ervaren' mensen willen geforceerd alles in code doen, wat logisch is gezien hun achtergrond. Maar dat is precies wat je in Drupal niet moet doen. Het is gemaakt om 95% van wat je wilt via sitebuilding te doen, en je vooral niet druk te maken over inefficiënte database structuren, render arrays en wat al niet meer. Op het moment dat je stopt met daar tegen te vechten, werkt het systeem voor je, alleen die schakelaar kunnen PHP developers niet omzetten.

Het vergelijk met Symfony gaat ook beetje mank, want het is niet gebouwd boven op symfony, het gebruikt net als veel andere systemen wat componenten ervan. Maar dat is niet veel meer dan de HTTP Kernel, YAML parsers, Events, Console en de router. Voor de rest worden er wat componenten van Zend en de Annotations parser van Doctrine geladen.

Drupal is ook geen framework ala Laravel of Symfony, als dat je verwachting is, moet je gewoon geen Drupal willen gebruiken en tegen je klant durven te zeggen dat je de klus niet kunt doen. Want dat is altijd eerlijker dan een frankensite bouwen die bij elke update uit elkaar lazert. Ik krijg regelmatig sites te zien die door PHP developers zijn gemaakt, en die hangen van hacks aan elkaar omdat ze perse het in code moesten oplossen ipv gewoon de tools gebruiken die het systeem je geeft.

[BCage]

Ik denk dat je daar zeker wel een punt hebt wat betreft het 'stoppen met vechten'. Ik kwam echter binnen op een project waar de keuze al was gemaakt om Drupal te gebruiken. Gezien de site die gemaakt moest worden was dit duidelijk een verkeerde keuze. Ik kon ze in die fase echter niet meer daarvan overtuigen. Er was weinig content en de C van CMS staat toch echt voor content. Veel functionaliteit was maatwerk, dus dan ontkom je er niet aan om zaken in code op te lossen. Mijn bezwaren zijn dus vooral gericht op het moment dat je maatwerk nodig hebt voor je site. En dan heb je toch te maken met Drupal, het framework, en niet meer met Drupal het CMS.

Ik vind overigens de Http Kernel, Events,Routing en Dependency Injection een aanzienlijk onderdeel van een project. Dat mag je gerust de basis noemen en ook wel de naam framework geven. Zonder kennis daarvan kom je in Drupal niet heel ver.

Naar mijn mening is de enige echte 'use case' voor Drupal een corporate site met veel content en meerdere content beheerders. Maar zelfs dan zou ik wel twee keer nadenken voor ik Drupal in zou zetten. Voor alle andere sites zijn er betere en vooral eenvoudigere oplossingen. Die bovendien ook nog eens leuker zijn om mee te werken.

[Tielenaar]

Op wat voor manier ben je opgeleid in Drupal voordat je eraan begon? Heb je een boek gelezen? Cursus gedaan? Online video's gevolgd? Voordat je in een Drupal enterprise omgeving je PHP skills kan gaan toepassen moet je toch wel ruim 6 maanden goede ervaring hebben met Drupal om te weten hoe alles in elkaar zit. En als je dat doorhebt is het (voor mij in ieder geval) een verademing. Drupal is een content management framework en de learning curve is gewoon hoog.
https://www.webpagefx.com...02_cms_learning_curve.jpg

[BCage]

Een leercurve van 6 maanden voor een CMS systeem is een design flaw.

Ik was niet van te voren opgeleid in Drupal. Ik had wel al 20 jaar ervaring met PHP en .NET ontwikkeling, waaronder vrijwel alle grote frameworks en CMS systemen. Ik ben daar vooral binnen gebracht voor mijn ervaring met Symfony.

Ik denk niet dat we het eens worden. Iedereen kiest natuurlijk al snel voor de tools waar hij het meest bekend mee is, dat ontwikkelt toch het snelst. Jij bent gewend met Drupal te werken en weet alles daar snel te vinden. Voor mij was dat niet het geval, en zoals gezegd was daar na een jaar ervaring weinig verandering in gekomen. Deels komt da, doordat Drupal niet de juiste tool was voor het product wat ontwikkeld werd. Maar ik blijf bij mijn standpunt dat Drupal simpelweg geen goed product is en weinig tot geen voordelen biedt ten op zichte van frameworks en wat maatwerk.

[Tielenaar]

Nogal logisch als je Drupal gebruikt voor iets waarvoor het niet bedoeld is. Geef Drupal dan niet de schuld, maar de beslissing van de opdrachtgever.

PHP heeft ook een leercurve. Ik kon na 6 maanden echt nog geen OOP, laat staan design patterns.
Je kan na een maandje best een Drupal site in elkaar draaien met views en content types en dergelijke, misschien dat je al een simpele module kan bouwen. Maar echt niet als je in het diepe wordt gegooid. Dat je verwacht van een enorm complex stuk software dat je dat direct onder de knie hebt is echt waanzin.

[BCage]

Ik denk dat ik na een ruim jaar ervaring, plus de vergelijking met vele andere frameworks en CMS systemen daar een goede mening over kan vormen.

Daarnaast is de vergelijking met PHP geen goede vergelijking. Programmeren leer je inderdaad niet in een paar maanden. Maar als je eenmaal meerdere talen en frameworks onder de knie hebt dan is het aanleren van nieuwe frameworks en talen niet iets waar je nog een half jaar over doet. Met vele technologien ben ik 'in het diepe' gegooid en al doende maak je dan die vaardigheden je eigen. Je kunt nou eenmaal niet alles van te voren tot in de puntjes beheersen, daarvoor is er simpelweg te veel beschikbaar. Als de basis goed is, dan komt de rest vanzelf.

Als het voor jou goed werkt, dan prima, maar staar je alsjeblieft niet blind op 1 CMS als de eindoplossing. Er zijn vele goede technieken, talen en libaries beschikbaar. Het is leuk om andere manieren van werken te leren en je eigen te maken, daar word je een veel betere ontwikkelaar van. Het is daarmee niet gezegd dat Drupal niet kan werken. Het enige wat ik beweer is dat het, naar mijn mening, geen goede basis is en dat er betere oplossingen beschikbaar zijn. Niet dat er geen werkbare oplossing mee ontwikkeld kan worden.

[kwaakvaak_v2]

Zeker wel.. De admin interface van Drupal loopt 10 jaar achter op de 'competitie' en dat beseft de community zich ook. Ik hoop voor ze dat ze het tij nog kunnen keren, maar het wordt een lastige dobber voor ze. Zijn wat inactieven die nu lopen, waar in mijn optiek https://www.youtube.com/watch?v=zq8pt4dyDiw (HAX) en https://www.youtube.com/watch?v=xTuOeyx9JLQ (Layout builder) op dit moment de meeste potentie hebben.

[the_stickie]

Een weinig efficiënte database kan wel problemen opleveren met performance en scalability. Dat is wellicht geen punt voor een relatief kleine site met niet al te veel bezoekers, maar voor grotere sites die toekomstbestendig moeten zijn of implementaties bij bv enterprises die de gecentraliseerde SQL graag ook nog voor tig andere applicaties gebruiken, is dat wél belangrijk.
De backend (kunnen) negeren is ideaal en aangenaam... tot je erdoor in de problemen komt.

[kwaakvaak_v2]

Ik denk dat jij een probleem zoekt wat niet bestaat uit gebrek aan ervaring met Drupal ansicht.

Toekomstbestendigheid is prima geregeld als je de migratie scripts goed maakt en structuur keurig netjes via de API aanpast.

En wat is precies gecentraliseerde SQL? één SQL server voor alle applicaties? Ik mag toch hopen dat geen enkel 'enterprise' bedrijf wat een serieuze site of sites in de lucht hebbem, toch mensen hebben die wat beter na kunnen denken. Zelfs MySql laat zich tegenwoordig prima horizontaal schalen via bijvoorbeeld een multimaster galera cluster al dan niet met proxysql als loadbalancer er tussen.

Maar als je bedoelt dat meerde applicaties naar dezelfde database moeten schrijven, dan mag je de architect die dat verzonnen heeft per direct degraderen naar een junior. Dat soort koppelingen doe je NOOIT door maar direct in een database te schrijven of lezen, maar gewoon netjes via een API, al dan niet over HTTP.


En dan heb je nog caching, en die is in Drupal 8 (eindelijk) fatsoenlijk geregeld met context aware caching, die qua storage ook nog eens pluggable is.

Drupal.org is denk ik één van de drukste Drupal 7 sites ter wereld qua niet anoniem verkeer, wat lastiger te cachen is en die draait eigenlijk best aardig op relatief weinig hardware (https://www.drupal.org/drupalorg/hardware)

Of wat te denken van Grammy.com die elk jaar tijdens de live uitzending 4.6m+ unieke bezoekers trekt, met meer dan 18.5m page views.

Dus nee, ik denk inderdaad dat het wel los zal lopen met de schaalbaarheid van de database plus als je op dat niveau speelt, zijn de kosten voor de schaalbaarheid meestal niet je grootste probleem

[the_stickie]

Ik ben geen devver, (ik doe infra) en in de enterprises waar ik tot nog toe zat werd geen Drupal gebruikt. Dus wat dat betreft heb je gelijk: ik heb geen ervaring met Drupal in grote omgevingen en ik reageer vooral op je eigen commentaar wat betreft inefficiënte databases waar je het gevecht niet moet mee voeren. Mijn ervaring leert dat inefficiëntie een bron van zorgen kan (zal?) zijn.

Gecentraliseerd hoeft niet te betekenen één server, op dat gebied heb je inderdaad veel aan een goeie dba/dbe, dat laat ik aan hen over. Maar in mijn ervaring wordt er juist wél vaak gekozen voor één performant cluster voor (bijna) alle applicaties en dan géén MySQL.
Wat caching betreft: ik ben fan. Máár niét als excuus voor gebrek aan core performance. De eerste zoveel gebruikers na een update hebben ook recht op een snelle site/applicatie, er is niet in alle omstandigheden de mogelijkheid om een cache warmup te doen.

Waar ik het niet eens mee ben is dat de kosten van schaalbaarheid wel mee vallen. Mijn taak is al vaak geweest bottlenecks tracen voor allerhande shared omgevingen. Alleen al die kost is niet te verwaarlozen. En dan heb ik het nog niet over de prijs van de infrastructuur waarop het draaien moet, de licenties van de benodigde software en de supportkosten. En raar maar waar, heel vaak komt het neer op een kleinere, minder kritische applicatie die een ware resource hog is, omdat men het "niet belangrijk" vond.

[the_stickie]

Je mening wordt ondersteund door een ellenlange lijst CVE's. Men zou kunnen argumenteren dat een CVE en patch positief is, maar het zegt ook wel iets over de kwaliteit van (de beveiliging van) de software als er versie na versie opnieuw criticals ontdekt worden, meestal dan nog over verschillende versies heen.

Wat meespeelt is denk ik dat Drupal 'geboren' is als projectje van een enkele ontwikkelaar in 2001 (toen was de focus op security nog veel minder) en dat het zeer snel gegroeid is met, weerom, vooral focus op features. Open Source en uitbreidbaarheid heeft, volgens mij, weinig bijgedragen aan belangrijke zaken als documentatie en veiligheid omdat god-weet-ik-wie met wat zelf aangeleerde php kon bijdragen.
Ondertussen is Drupal Core wel matuurder geworden, maar dan rest nog een onoverzichtelijke zee aan ronduit slechte modules die wel gewoon 'published' zijn, en een historische codebase waar heus nog wel wat werk aan is.

* the_stickie is ook geen fan

[Jorick]

Het aantal CVE's zegt niet zoveel over de kwaliteit of veiligheid van een systeem. Als je bijvoorbeeld kijkt naar die lijst van Drupal dan dateren veel van die CVE's uit 2015 en 2016 en zijn die voornamelijk van toepassing op oudere versies van (6 en 7). Het aantal CVE's in 2017 en 2018 is een stuk lager en dat zal deels te maken hebben dat de Core van Drupal sinds versie 8 flink verbeterd is en dat versie 6 niet meer ondersteund wordt. Overigens zegt het aantal CVE's ook niet zoveel zonder naar de ernst/impact te kijken. Maar als je puur naar het aantal CVE's kijkt en dat afzet tegen die van bijvoorbeeld Wordpress en hoeveel er daarvan van het afgelopen jaar dateren dan lijkt het met Drupal wel mee te vallen.

[teek2]

Hmm ja als niet ervaren ontwikkelaar had ik toch redelijk snel een site met contact formulier, agenda, google ads, inschrijf formulier voor nieuwsbrief via mailchimp en nieuwsberichten posten aan de praat hoor. Ik merk weinig van het zooitje. Updaten zou wel meer a la wordpress mogen, drush is een beetje onhandig maar verder vind ik het prima werken. Het systeem van blokken, views en modules moet even klikken maar daarna is het redelijk overzichtelijk, imho.

[Reactie gewijzigd door teek2 op 24 juli 2024 21:01]

[Pizzalucht]

Ik vind het persoonlijk een kwalijke zaak dat ze bij de nieuwe patch vermelden dat dit gaat om een opvolging van de vorige patch, SA-CORE-2018-002. Dit zegt dus dat de patch van SA-CORE-2018-002 het probleem niet helemaal heeft gedicht.

Er is inmiddels perfect duidelijk wat het probleem was dat SA-CORE-2018-002 dicht (blog: https://research.checkpoint.com/uncovering-drupalgeddon-2/ POC: https://github.com/a2u/CVE-2018-7600/blob/master/exploit.py). Door te vertellen dat dit een opvolging is van de vorige patch geef je aanvallers informatie, zij weten nu precies in welk stuk code ze moeten gaan zoeken naar lekken die de patch heeft gemist.

Ik vrees dan ook dat er exploits komen voordat de patch uit is.

[HeAdWaVe74]

De mogelijlkheid om via het admin panel een core update te doen zou ook wel makkelijk zijn.

Nu doe ik dat via FTP en dus als ik op werk of vakantie ben, heb ik een probleem

[Zidane007nl]

Waarom niet via drush? Ik gebruik dit nu een aantal jaar en het is echt een verademing. 1 commando en Drupal is up-to-date.

[kwaakvaak_v2]

Liever niet. maar ik snap dat het voor sommige mensen wel handig kan zijn. Persoonlijk die ik liever een git pull or laat ik het CI/CD systeem een artifact maken en deploy ik die.

FTP is een gammel langzaam protocol en mag wat mij betreft per direct afschaft worden.

[Ventieldopje]

En bovendien onveilig.. helaas zien veel hosts SSH nog als boeman en kun je SFTP of rsync wel op je buik schrijven.

[Verwijderd]

FTP is een gammel langzaam protocol en mag wat mij betreft per direct afschaft worden.

Gammel? Wellicht maar niet traag. Je krijgt vrijwel altijd de volle bandbreedte met een kleine overhead.

[kwaakvaak_v2]

in theorie wel ja, alleen hebben veel hosting partijen (budget) vaak de FTP geknepen. En dan mag je dus 15K files uploaden proberen te uploaden via een afgeknepen rietje.

[Tielenaar]

Bij Drupal 8 heb je al snel duizenden bestanden om te uploaden. Dat werkt voor geen meter over FTP. Doe mij maar Git releases. Je pusht je tag naar productie (uploaden kost paar seconden), en doet gewoon een checkout daar. Dat is een code switch dat meestal in een seconde of 2 volledig klaar is. Daarnaast kan je een rollback doen die even snel is.

[faim]

Het is wel raak de laatste tijd, kan mij voorstellen dat Drupal gebruikers er ook een beetje simpel van worden. Telkens op tijden dat de update uitkomt zo snel mogelijk moeten updaten, want anders ben je ontzettend vatbaar voor de lek.

[Tielenaar]

Als Drupal developer vind ik deze aanpak alleen maar goed. Daarnaast is Drupal voor wat meer Enterprise level websites, en daar hoort een goed onderhoud gewoon bij. Als je daar niet mee om kan gaan, dan moet je ver weg blijven van Drupal.
Geen enkel software pakket heeft nooit dit soort issues, en 2 per jaar is echt peanuts vergeleken met de geschiedenis die andere pakketten met zich meebrengen.

[faim]

Nou ja, een auto-update feature anno 2018 zou geen overbodige luxe zijn...

Daarnaast is Drupal voor wat meer Enterprise level websites, en daar hoort een goed onderhoud gewoon bij.

Enterprise websites gebruiken geen Drupal, maar huren een media bedrijf in om een fatsoenlijke custom website te laten maken.

[Tielenaar]

Dat kan prima met Drupal. Grote bedrijven willen alleen graag met dure closed source pakketten werken, dus die kiezen niet zo snel voor Drupal. Dit totaal zonder reden.
Zolang je maar een team van devs hebt die weten wat ze aan het doen zijn kan het gewoon.
Auto update is echt not done. Je moet zoiets testen, je kan er niet vanuit gaan dat zo'n update die zomaar gepusht wordt door het core team niks sloopt. Als je dat toelaat is het eind zoek. Onderhoud is gewoon onderdeel van Drupal.

Paar voorbeeldjes van prima enterprise level drupal sites:
https://www.dhlparcel.nl/
https://www.ntvg.nl/
https://www.thuisarts.nl/
http://globalpets.academy/

RTL doet veel met Drupal en ook TMG gaat over op Drupal. Etc..

[kwaakvaak_v2]

en toen werd je wakker? Waarom denk je dat enterprise bedrijven als Pfizer en Burda juist al hun verschillende custom build one off's aan het consolideren zijn naar Drupal? Juist! omdat het hoe vreemd het ook mag klinken voor de meeste goedkoper is. Je hoeft je redacteuren maar voor één CMS te trainen ipv 20, je bent niet meer afhankelijken van één bepaalde leverancier als je aanpassingen wilt.

[[Yellow]]

Ik denk ook dat ze nu niet meer met een cynische sneer richting Wordpress opmerkingen zullen maken dat ze zoveel beter zijn dan WP...

Edit: Nogal wat fanboys hier blijkbaar. Ik zeg alleen dat ze altijd wat neerbuigend over WP veiligheid deden en ze dat nu niet meer kunnen doen. Om me nu daarvoor -1 te geven...

[Reactie gewijzigd door [Yellow] op 24 juli 2024 21:01]

[kwaakvaak_v2]

Beide hebben hun sterke kanten. Wil je een relatief eenvoudig systeem met een top notch admin/editor ervaring neem je Wordpress. Heb je structured content nodig, verschillende content types, view builders voor editors etc nodig neem je Drupal.

Het zijn gewoon verschillende tools, voor verschillende markten gemaakt. Niks mis lijkt mij..

[al0a]

Er zijn nog genoeg redenen waarom Drupal zoveel beter is dan Wordpress.

[[object Object]]

Wat zijn voor jou de zwaarst wegende redenen om dit te zeggen? Ik kom van een Wordpress achtergrond en ben me aan het verdiepen in Drupal, het is mij op dit moment nog om het even

[Smuey]

Ga anders even kijken in de code van Wordpress, wat verder dan dat mooie grafische schilletje. Het is leuk voor een blog, maar voor al het andere zijn er betere alternatieven.

OT: Hoe is het geregeld met het updaten van Drupal? Werkt dat een beetje simpel of loop je het risico dat er na een update e.e.a. niet meer gaat werken? Kan me voorstellen dat beheerders van Drupal-sites hier nou niet bepaald op zitten te wachten namelijk...

[Reactie gewijzigd door Smuey op 24 juli 2024 21:01]

[Tielenaar]

Drupal vereist een wat complexere release flow en kan je niet zomaar updaten door een knopje in te drukken. Meestal heb je een lokale omgeving waar je via de command line de nieuwe packages downloadt, als je automatische tests hebt dan kan je dan natuurlijk draaien, maar verder moet je wel even kijken of het in grote lijnen nog werkt. Zo'n security update zorgt over het algemeen niet voor een andere werking van de core, daarvoor moet je alleen opletten bij grote versie updates.
Vervolgens stuur je je changes naar je repo, en die uiteindelijk naar de productieomgeving, waar je weer via een commando de boel kan updaten.
Het ligt heel erg aan de omgeving. Als je bijvoorbeeld bij Acquia host, dan zijn er een scala aan tools en trucs beschikbaar om dit vrij soepel en snel te laten verlopen.
Je hoeft in ieder geval niet via FTP dingen te uploaden. Het kan, maar dat is geen doen.

[Smuey]

Dat lijkt in ieder geval al wat meer op een gezonde workflow dan ik bij sommige andere pakketten heb gezien. Interessant, bedankt voor de uitleg!

[GoBieN-Be]

Op een simpele shared hosting, die geen shell toegang levert, is FTP je enige optie. Je moet dan een hoop mappen wissen (of verplaatsen) en opnieuw uploaden en dan een update script draaien.
Wordpress is wat dat betreft wel een stuk makkelijker om up te daten.

Mijn ervaring is met Drupal 7 trouwens.

[Reactie gewijzigd door GoBieN-Be op 24 juli 2024 21:01]

[Tielenaar]

Met Drupal 8 is shared hosting nog een stukje lastiger geworden. De codebase is een stuk logger dan Wordpress en bevat veel meer files dan D7, maar het kan nog wel.
Bij Drupal hoort eigenlijk een beetje serieuze hosting, behalve misschien als je niet actief aan de site ontwikkelt. In dat geval zal je met FTP wel overweg moeten kunnen, maar het schiet echt niet op. Ik heb ook zo'n site draaien en updaten via FTP is echt een geklooi.
Bij Yourhosting hebben ze PatchMan aanstaan, en die patcht dit soort security dingen automatisch. Dat is ook een optie.

[Pizzalucht]

Minor versie updates in Drupal Core kun je zonder problemen uitvoeren. Zelfs als dat ongewenst is kun je voor deze security issues een patch toepassen waardoor alleen de lekke code wordt aangepast.

[Jorick]

Updaten is goed te doen met behulp van Drush of Composer. Sinds Drupal 8 is Drupal Core ook via Composer te updaten waardoor je Drush niet per se meer nodig hebt. Het is wel aan te bevelen om eerst een back-up te maken (met name een dump van je database) en in een testomgeving de update te testen alvorens je hem uitrolt naar de live-omgeving. Op deze manier kun je een update binnen een paar minuten doorgevoerd hebben.

[Tielenaar]

Het zijn twee totaal verschillende pakketten die je eigenlijk niet met elkaar zou moeten vergelijken. Ze hebben allebei hun eigen doelgroep.
Drupal is custom/enterprise oriented, Wordpress is wat meer geschikt voor standaardoplossingen die je in elkaar kan klikken. Heeft allebei z'n voordelen, maar ik kan persoonlijk totaal niet overweg met de programmeerstijl van Wordpress.

[kwaakvaak_v2]

echte structured content is voor mij de belangrijkste en als je dat goed doet een prima separatie tussen content en vorm. Dat laatste is bij Wordpress wat lastiger omdat een groot deel van je content types en vorm in het thema zitten.

[NaliXL]

@[Yellow] Er wordt anders wel vlot en adequaat op bedreigingen gereageerd. Niet om te beweren dat dat bij Wordpress niet zo zou zijn overigens.

[Tielenaar]

De Wordpress community is heel anders, die reageert niet zo snel over het algemeen. Het aantal security issues valt bij WP nog best mee, vooral als je de populariteit meerekent.

[[Yellow]]

Dat klopt. Ze reageren er adequaat op. Maar als ik het nivo van de laatste en de voorlaatste 'hacks' zie wordt ik toch niet heel erg vrolijk. Ze waren erg, hoe zal ik het voorzichtig zeggen, basic namelijk.

[tszcheetah]

Sinds de PoC-code van het vorige lek is gepubliceerd schijnen sites automatisch geinfecteerd te worden met cryptominers en andere nare troep (bron).

Aangezien het hier om een follow-up gaat en de aankondiging slechts 48u vantevoren is (en dus geen week, zoals de afgelopen keer), is mijn verwachting dat het lek eenvoudiger te vinden en daarna te misbruiken is (immers is nu al bekend in welke hoek het zit, anders was het geen follow-up). Het zou me niks verbazen als het deze keer geen 2 a 3 weken duurt voordat er exploitcode beschikbaar komt...

Ook wordt deze keer niet gezegd dat Drupal 6 kwetsbaar is (vorige keer wel); uit voorzorg lijkt het me voor beheerders van dergelijke sites verstandig om ook de community patches in de gaten te houden.

[Tielenaar]

Als je nu nog een D6 site hebt draaien dan vraag je om problemen natuurlijk

[Tielenaar]

Vergelijk de frequentie voor de gein is met security issues van elk ander pakket in omloop.
Dank.