Livewire en Filament updates: achterlopen is een security-risico

In juli 2025 kreeg Livewire v3 een kritieke kwetsbaarheid: CVE-2025-54068, remote code execution via de hydratie van componenten. Elk Filament-panel op een kwetsbare Livewire-versie liep mee risico.

Dat is geen bijzonder incident. Het laat zien hoe een Laravel-admin in de praktijk werkt: je bouwt op een stapel pakketten die je niet zelf schrijft, en die stapel moet je bijhouden.

Wat er bij CVE-2025-54068 aan de hand was

Livewire laat de browser en de server samen een component beheren. De state van zo'n component reist mee in de requests. De server bouwt de component daarna weer op uit die gegevens. Dat heet hydratie.

Bij CVE-2025-54068 kon een aanvaller dit mechanisme misbruiken om eigen code op de server uit te voeren. Het ging om Livewire v3. De fix kwam in een nieuwe release van Livewire.

Wat dit voor jou betekent:

• RCE betekent dat een aanvaller op je server code draait met de rechten van je webserver-gebruiker.
• Vanaf dat punt kan hij je .env lezen, de database benaderen en bestanden plaatsen.
• Je hoefde hiervoor niet zelf iets fout te doen. Een verouderde dependency was genoeg.

Wij werken hier bewust met het CVE-nummer en niet met uitgebreide exploitdetails. De exacte werking staat in de officiële advisory. Gebruik die als bron, niet een blogpost van een derde.

Waarom Filament hier direct bij hoort

Filament v3 is gebouwd op Livewire. Elke tabel, elk formulier en elke modal in een Filament-panel is een Livewire-component. Een kwetsbaarheid in Livewire is dus een kwetsbaarheid in je panel.

Dat maakt het lastig te zien. Je composer.json noemt filament/filament. Livewire staat er vaak niet eens direct in. Het komt binnen als afhankelijkheid. Wie alleen naar zijn eigen directe pakketten kijkt, mist de laag eronder.

Daar komt bij dat een Filament-panel zelden een onschuldig dashboard is. Het is meestal de beheeromgeving van je hele bedrijf:

• Klantgegevens en bestellingen
• Gebruikers en rollen
• Uploads, exports en facturen
• Integraties met betaalprovider, boekhouding en voorraad

Een gecompromitteerd panel is daarom bijna altijd een datalek. Lees daarvoor ook ons artikel over datalek melden bij de Autoriteit Persoonsgegevens.

Het patroon: publiek bereikbaar, zelden bijgewerkt

We zien bij audits vaak dezelfde combinatie. Het panel staat op /admin op het openbare internet. De applicatie is opgeleverd, werkt, en niemand heeft hem sinds de oplevering aangeraakt.

Dat is precies het profiel waar aanvallers naar zoeken. Bij kwetsbaarheden in populaire frameworks scannen ze breed. Ze zoeken niet jouw bedrijf. Ze zoeken elke server die op de oude versie draait.

Je risico is dus niet afhankelijk van hoe interessant je bent. Het hangt af van hoe lang je achterloopt.

Vergelijk het met Magento. Ook daar zagen we met TrojanOrders, CosmicSting en SessionReaper hoe snel een bekend lek op grote schaal wordt misbruikt. Laravel-apps zijn niet immuun voor datzelfde mechanisme.

Een update-beleid dat je kunt volhouden

Zeg niet "we updaten regelmatig". Schrijf op wat regelmatig is. Een bruikbaar beleid past op een A4:

De termijnen zijn een voorstel. Pas ze aan op je eigen risico en je eigen capaciteit. Belangrijker dan de exacte getallen is dat iemand eigenaar is.

Wie krijgt het bericht?

Een beleid zonder alarm werkt niet. Zorg dat iemand het weet als er een advisory uitkomt:

• Abonneer je op de security advisories van Laravel, Livewire en Filament op GitHub.
• Zet composer audit in je CI-pipeline.
• Laat de pipeline falen bij een bekende kwetsbaarheid, niet alleen een waarschuwing tonen.
• Wijs één persoon of één team aan dat de melding oppakt.

composer audit in de praktijk

composer audit

Draai dit lokaal, maar vooral in CI. Dan krijg je ook een melding op dagen dat niemand aan het project werkt.

composer audit --locked

Met --locked controleert Composer wat in composer.lock staat. Dat is de versie die je daadwerkelijk uitrolt. Dat wil je weten.

Twee kanttekeningen, eerlijk gezegd:

1. composer audit kent alleen bekende, gepubliceerde advisories. Een zero-day ziet het niet.
2. Een groene audit betekent niet dat je veilig bent. Het betekent dat er niets bekends openstaat.

Gebruik de tool als vangnet, niet als vervanging van aandacht.

Updaten zonder paniek

Een update van Livewire of Filament binnen dezelfde hoofdversie is meestal klein. Toch rol je hem niet blind uit. Een veilige volgorde:

composer update livewire/livewire --with-dependencies
php artisan test

Dan staging, een handmatige check van de belangrijkste panel-flows, en daarna productie. Heb je geen tests? Dan is dit het moment om de kritieke flows te dekken. Denk aan inloggen, een resource aanmaken, een export draaien en een bestand uploaden.

Zonder tests ga je updates uitstellen omdat je ze eng vindt. Dat uitstel is zelf het risico.

Beperk wie het panel kan bereiken

Updaten verkleint de kans dat een bekend lek werkt. Netwerkbeperking verkleint de kans dat iemand je panel kan bereiken. Doe beide.

Een admin-panel hoeft meestal niet voor de hele wereld open te staan. Je medewerkers werken vanaf een bekend kantoor of via een VPN.

Een voorbeeld voor nginx, waarbij het panel alleen voor een vast IP-adres of VPN-bereik openstaat:

location /admin {
    allow 203.0.113.10;   # kantoor
    allow 198.51.100.0/24; # VPN
    deny all;

    try_files $uri $uri/ /index.php?$query_string;
}

Let op: de IP-adressen hierboven zijn voorbeeldadressen. Vervang ze door je eigen adressen. Vergeet ook niet dat Livewire eigen endpoints heeft onder een eigen pad. Test dus altijd of het panel nog werkt en of een niet-toegestaan IP echt een 403 krijgt.

Wanneer is dit overkill? Als je panel bedoeld is voor externe gebruikers, zoals klanten of partners, werkt een IP-beperking niet. Dan zijn sterke authenticatie, 2FA en rate limiting je belangrijkste lagen.

Alternatieven voor een IP-allowlist:

• Een VPN of zero-trust-laag vóór het panel
• Een WAF-regel die /admin alleen toestaat voor bepaalde landen of netwerken
• Basic auth als extra drempel, naast de gewone login

Meer over bot- en aanvalsverkeer lees je in ons stuk over WAF en bot-bescherming.

Uploads zijn de tweede kans voor een aanvaller

Als de eerste weg dicht is, zoekt een aanvaller een tweede. Uploads zijn een klassieker. Filament maakt het makkelijk om bestanden te uploaden, en dat vraagt om een paar bewuste keuzes.

• Beperk toegestane bestandstypen expliciet, niet alleen via de extensie.
• Sla uploads op buiten de webroot, of op een disk die geen PHP uitvoert.
• Zorg dat de webserver in de uploadmap nooit .php uitvoert.
• Valideer grootte en MIME-type op de server.
• Serveer gebruikersbestanden nooit met een gok op het type.

In nginx voorkom je uitvoering in een uploadmap zo:

location ^~ /storage/ {
    location ~ \.php$ { return 403; }
}

Een succesvolle upload van een PHP-bestand plus een kwetsbaarheid is vaak het verschil tussen een incident en een drama. Meer praktische punten staan in onze Filament-beveiligingschecklist.

De rest van de basis

Een update-beleid staat niet op zichzelf. Controleer ook deze punten:

• APP_DEBUG=false in productie.
• Sterke wachtwoorden en 2FA voor alle panelgebruikers.
• Rollen en policies per resource, zodat niet iedere beheerder alles kan.
• Rate limiting op de loginroute.
• Logging van inlogpogingen en wijzigingen, met een melding bij afwijkend gedrag.
• Back-ups die een aanvaller niet kan wissen.

Voor een bredere lijst: Laravel security checklist voor productie.

Wat te doen als je achterloopt

Is je panel al een tijd niet bijgewerkt? Begin hier.

1. Maak een back-up en controleer dat je hem kunt terugzetten.
2. Draai composer audit en schrijf op wat er openstaat.
3. Bekijk welke versies van Laravel, Livewire en Filament je gebruikt.
4. Update eerst de pakketten met bekende kwetsbaarheden.
5. Zet het panel tijdelijk achter een IP-beperking terwijl je werkt.
6. Controleer logs en bestanden op sporen van misbruik uit de periode dat je kwetsbaar was.

Punt 6 slaan mensen te vaak over. Een update dicht het gat, maar haalt niemand weg die al binnen is. Vermoed je dat je gehackt bent? Volg dan ons stuk over incident response en neem contact op.

Veelgestelde vragen

Wat was CVE-2025-54068?

Een kritieke kwetsbaarheid in Livewire v3 uit juli 2025. Via de hydratie van componenten kon een aanvaller code op de server uitvoeren (RCE). Filament-panels op een kwetsbare Livewire-versie liepen daarmee ook risico. De details en de gefixte versie vind je in de officiële advisory.

Moet ik elke update van Filament direct installeren?

Security-fixes: ja, zo snel mogelijk. Reguliere minor- en patchreleases kun je in een vast ritme bundelen, bijvoorbeeld maandelijks. Major-upgrades plan je apart, met testen en een terugvalplan.

Is composer audit genoeg om veilig te blijven?

Nee. Het vindt bekende, gepubliceerde kwetsbaarheden in je dependencies. Het vindt geen fouten in je eigen code en geen zero-days. Zie het als een goed vangnet in je pipeline, naast tests, review en monitoring.

Moet mijn Filament-panel achter een IP-beperking of VPN?

Als alleen je eigen team het gebruikt: ja, dat is een goedkope en effectieve extra laag. Gebruiken klanten of partners het panel, dan werkt dat niet en leg je de nadruk op 2FA, rate limiting en rolbeheer.

Hoe weet ik welke Livewire-versie mijn Filament-app gebruikt?

Draai composer show livewire/livewire. Daar zie je de geïnstalleerde versie. Met composer why livewire/livewire zie je welk pakket hem binnenhaalt.

Draait jouw Laravel- of Filament-applicatie al een tijd zonder onderhoud? Wij doen een korte check van je versies, je panel-toegang en je uploads, en vertellen eerlijk wat nodig is en wat niet. Meer over onze aanpak lees je op /laravel/filament en /security/laravel, of neem direct contact op via /contact.