Kritieke kwetsbaarheid in Calder Boekhouden actief misbruikt

Illustratie bij dit bericht.
Aanvallers maken actief misbruik van een kwetsbaarheid in Calder Boekhouden. Er is inmiddels een update beschikbaar, maar volgens onderzoekers is alleen updaten niet genoeg.
Omdat aanvallers voor het uitkomen van de patch al binnen konden komen, adviseren onderzoekers om sleutels en sessietokens te vervangen.
Wat er precies gebeurde
Organisaties wordt aangeraden te controleren op onbekende beheeraccounts en op automatische doorstuurregels.
Het misbruik werd ontdekt nadat een beheerder verdacht verkeer in de logbestanden aantrof. Vervolgonderzoek wees uit dat aanvallers al langer toegang hadden.
Als het al misbruikt wordt, is patchen alleen niet genoeg. Ga uit van compromittatie.
Dit is precies waarom je logging langer dan dertig dagen wil bewaren.
Precies dit. Ik heb het hier net getest en kan het bevestigen.
Enig idee of er ook een workaround is zonder te patchen? We zitten midden in een changefreeze.
Het is te makkelijk om de beheerder de schuld te geven. Als je geen budget en geen tijd krijgt, gebeurt het gewoon niet.
Dat is te kort door de bocht. De documentatie zegt iets anders, maar de praktijk geeft jou gelijk.
Wat ik hier mis is een fatsoenlijke risicoanalyse. Nu is het weer paniek op basis van één score.
Zolang leveranciers geen SBOM meeleveren blijft dit dweilen met de kraan open. Je weet gewoon niet wat er in dat ding zit.
Wat mij vooral opvalt: geen woord over hoe lang de aanvallers binnen zaten. Dat zegt meestal genoeg.
Goed punt, maar Het hangt sterk af van je configuratie. Standaard staat die optie namelijk uit.
Dat is te kort door de bocht. Het hangt sterk af van je configuratie. Standaard staat die optie namelijk uit.
Klassieke fout: de client controleert de rechten, de server niet. Zie je nog verrassend vaak.
Eens, met een kanttekening: Ik heb het hier net getest en kan het bevestigen.
Iemand een IoC-lijst gezien? De melding zelf bevat weinig concreets waar je in je SIEM iets mee kan.
Het echte risico zit in de koppelingen. Systeem A is misschien veilig, maar de API-token in systeem B niet.
Melden bij de toezichthouder is verplicht, maar in de praktijk zie je dat organisaties eerst hun juristen bellen.
Precies dit. Dat geldt voor de zakelijke variant, thuisgebruikers hebben die knop helemaal niet.
Mooi dat er een patch is, maar wat doe je met apparatuur die end-of-life is? Die staat er over vijf jaar nog.
Dat is te kort door de bocht. Bij ons werkte dat namelijk alleen als je ook de bijbehorende dienst herstart.
Blijft bijzonder dat we telemetrie normaal zijn gaan vinden. Uitzetten kan meestal wel, maar het staat nooit standaard uit.
Kan iemand uitleggen waarom hier authenticatie ontbreekt? Dat is toch geen ontwerpfout van gisteren.
Dank, dat verklaart wel het een en ander. Bij ons werkte dat namelijk alleen als je ook de bijbehorende dienst herstart.
Voor de thuisgebruiker: controleer even je router. Die dingen krijgen zelden vanzelf een update.
CVSS 9.8 en dan geen automatische update. Dat is in 2026 echt niet meer uit te leggen aan je klanten.
Shodan geeft nu al duizenden hits op de kwetsbare versie. Dit gaat nog wel even door.
Aanvullend: Zolang het budget bij een andere afdeling ligt, verandert er niets aan.