> De update wordt automatisch geïnstalleerd, ook als WordPress-sites het automatisch updaten van plug-ins hebben uitgeschakeld.

Dat lijkt mij niet de bedoeling.

Zeker bij bijvoorbeeld een WordPress installatie waar het een en ander op en omheen is gebouwd wat moet "blijven werken", wil je de update eerst in een testomgeving testen.

Deze actie geeft bij mij een Red Flag, want WordPress bewijst hiermee dat jouw WordPress-installatie niet van jou is.
Met deze feature zijn "CrowdStrike-ongelukken" niet uit te sluiten.

Nog mooier wordt het als crackers toegang weten te krijgen tot de WordPress-update server en via deze manier een malware-versie van een gecompromitteerde plug-in op iedere WordPress-installatie weten te zetten.

Daarmee is wordpress dus geen optie meer. Blijkbaar sch**t aan wat de eigenaar van de site wil, nl. GEEN updates. Feit dat het KAN is al extreem fout.
Het probleem wordt steeds erger: je bent nergens meer eigenaar van als het online is. De maker van de software besluit wel wat er gebeurt. Eng. Dood eng.

Mompelt iets met 'goede bedoelingen'.
The road to hell is paved with good intentions.

En dít wordt dan niet gecommuniceerd op de home-page van WordPress.org, maar een oplettende gebruiker (@flagship890) moet dít bevestigd krijgen via een forum!?
btw Zie ik zo'n 'geforceerde methode' als een backdoor die nu -nadat deze dus is gebruikt- ook misbruikt kan gaan worden door 'derde'.
Met reversed enginering en network-sniffing kan een -goeie- hacker nu achterhalen hoe zhij misbruik kan maken van deze functie om maar van alles als 'geforceerd uit te rollen'.
Als je als kwaadwillende op grote schaal 'een geforceerde patch' op wp-websites op deze wijze kan uitrollen heb je als web-eigenaar niet meer het volledige beheer en daarmee de controle over je website; Ook al ben je zo'n oplettende gebruiker als Seagull87/@flagship890, het kwaad is dan al geschied, en net zoals bij crowdstrike kan dat tot nare gevolgen leiden.

En dat is waarom je je eerst inleest in het systeem voor je het gebruikt.
in wpconfig.php zet je line:
AUTOMATIC_UPDATER_DISABLED’, true )

En dan gebeurt dat dus niet meer.
Ik ben er ook op tegen ware het niet dat de meeste Wordpress beheerders lui zijn geen kaas hebben gegeten van wat het doet en eigenlijk gewoon niet eens site hadden moeten opzetten. Nog meer dan de helft draait op PHP 7 series zonder alt-php van Cloudlinux wat nog wel gepatched wordt en zelfs Wordpress heeft 7 nog niet eol verklaart in main branch. Dus alle beetjes om een beetje orderlijkheid en veiligheid te verhogen zijn nodig.

Dit is al veel vaker voorgekomen. De meeste beheerders van Wordpress sites weten dat dit kan.
Wordpress maakt hier alleen gebruik van in zeroday updates die actief misbruikt worden.
Ik vind dit juist zeer positief aangezien iedereen plugins kan uitbrengen voor Wordpress.
Dat brengt gevaren met zich mee en het is goed dat die ook in uitzonderlijke gevallen geforceerd verholpen kunnen worden.

Ik snap de mixed-feelings. Tegenwoordig worden de meeste Wordpress sites bij providers afgenomen (met eigen security-base instellingen). Dus de complete controle had je toch al niet en dat is vandaag de dag steeds meer een zegen.

Het wordt gewoon steeds moeilijker om alles in de gaten te houden. Ook al heb je systemen die veel in de gaten houden. Denk dan aan behoorlijk wat FTE's

Ach wel nee, het is juist heel goed!
En als je IETS weet van hoe je een webserver optuigt voor wat betreft bestandspermissies dan is het heel simpel om te voorkomen dat programma's uit eigen beweging dingen gaan updaten.
Dus de paranoide beheerder kan het altijd voorkomen.

wordpress is in de theorie al vaker slachtoffer geweest van crappy plugins enz. en heb zelf ook vage shit zien gebeuren met een echte instance waar ik de beheerder wat mee hielp. dus ik vertrouw heel wordpress niet teminste als er plugins gebruikt worden wat in 95% van de gevallen is.

Je moet behoorlijk selectief zijn in de plugins (kwaliteit) en vooral plugins gebruiken die actief/regelmatig worden bijgewerkt. Maar dat is met alles zo in de IT.

Als je de zaken op orde hebt dan kost je dit echt niet zoveel fte. We handelen 500+ updates af per dag met rond de 5 tot 10 die extra hands-on nodig hebben en hebben momenteel rond de 3000 verschillende plug-ins in beheer. De rest gaat vol geautomatiseerd en hoeven we niks bij te doen.

Als het een keer voorkomt dat een plug-in een zeroday heeft en snellere Patching vereist is dan onze update routines hoeven we maar op 1 knop te drukken om alle bedrijfsomgevingen te updaten. Of zoals laatst met het ACF-akkefietje konden we deze op alle omgevingen tegelijk vervangen met de niet gekaapte variant.

Kost ons rond de 400 euro met volledige inhouse infra per maand en opstart kosten van rond de 2000. Qua tijd investering over een werkweek is het rond de anderhalf uur aan tijd bij IT. Of wel iets minder dan 20 minuten per dag voor update routine van honderden bedrijven.

Als je maar een paar sites hebt, schrijf je je gewoon in voor de plug-in nieuwsbrieven, filtert op keywords als security en zet automatische updates voor alles aan. Dan is zo een investering ook redelijk nutteloos, maar kom je boven de 30 sites om bij te houden dan zijn management platforms geen overbodige luxe. Dat heb je er zo uit qua investering. We hadden onze investering er al binnen minder dan een maand er uit.

Dus nee ik ga niet mee dat het veel fte kost bedrijf zijnde. Gewoon efficiënt werken en automatiseren waar mogelijk. Waar je wel absoluut gelijk in hebt, is je volgende bericht.

Vooronderzoek is belangrijkste, maar dat breng je ook gewoon bij klanten in rekening natuurlijk en je moet altijd uitwijk mogelijkheden onderzoeken en bijhouden. Stel een developer kapt ermee, verkoopt plug-in of kwaliteit daalt dan moet je meteen van dat schip kunnen springen.

En durf gewoon nee te verkopen aan klanten als ze per se een plug-in willen waar je amateuristische opzet ziet of beveiliging risico's. Die klanten ben je liever kwijt dan rijk. En er is genoeg bagger qua plug-ins helaas om te installeren. Onze klanten kunnen geen plug-ins zelf installeren, ze kunnen aanvraag doen, maar zelf hebben ze die optie niet. Voorkomt een sht load aan problemen en zelden commentaar van klanten daar over.

Waarschijnlijk hebben diverse forumleden geen bezwaar als een hacker zich ad beheerder op hun WordPress website kan inloggen indien zij de plug-in hebben geïnstalleerd