Framework waarschuwt voor datalek via derde partij

Laptopfabrikant Framework waarschuwt klanten voor een datalek via een derde partij. Daarbij hebben aanvallers voornamelijk namen en adressen ingezien, maar geen financiële data of bestelgeschiedenis.

Framework schrijft dat op vrijdag in een e-mail naar klanten. Het aantal tips dat Tweakers over het lek binnenkreeg, wijst op een grote groep getroffen klanten, hoewel het precieze aantal slachtoffers niet te verifiëren is.

De oorsprong van het lek ligt bij Metabase, de databaseprovider die Framework gebruikt. Dat bedrijf liet op donderdag weten slachtoffer te zijn geweest van een hack via een zerodaylek. Aanvallers wisten versie 1.58 en hoger van de software te treffen. Metabase raadt gebruikers aan hun tokens en inloggegevens aan te passen en gebruikerssessies te beëindigen.

Bij het datalek bij Framework zijn geen gegevens als bestelgeschiedenis, betaalinformatie of identiteitsbewijzen betrokken. Het gaat om:

• Volledige naam
• E-mailadres
• Login-IP-adressen
• Verzend- en factuurinformatie
• Land
• Adres
• Stad
• Staat
• Postcode
• Telefoonnummer
• Bedrijf

Het is onduidelijk of die informatie ook op straat is komen te liggen. Metabase en Framework zeggen dat aanvallers de informatie hebben ingezien, maar niet of ze die hebben gedownload of gekopieerd.

Reacties (66)

[virtualpimp]

Metabase is geen databaseprovider. Het is een business intelligence tool, oftewel een dashboard-laag bovenop databases die je al hebt draaien. Metabase levert die databases niet, het maakt er verbinding mee. De term komt waarschijnlijk uit Framework's eigen mail, waar staat ongelukkig geformuleerd.

our business intelligence database provider

[Reactie gewijzigd door virtualpimp op 7 augustus 2026 09:05]

[86ul]

Bijdeze de tekst die ik ontvang heb:

Dear Valued Framework Customer,


We are writing to inform you of a data breach at our business intelligence database provider Metabase that resulted in an attacker accessing customer names, email addresses, phone numbers, and addresses. Your information was in the database that was accessed in this breach. This breach did not include order or payment information.


We have full details on the incident below. We are deeply sorry for this breach of information, and are reviewing and improving our methodology for data storage in external database vendors.


We are also in the process of notifying the regulatory authorities in each region where relevant regulations exist. Note that while regulations in most regions do not require notification for breaches of names, email addresses, phone numbers, and addresses, we are sending this email to you regardless to ensure you have visibility and can take any actions needed.


What happened?


On August 6th, 2026 at 9am Pacific Time, Metabase notified us of a breach of their systems with the following email message:


On Monday, August 3, we discovered that Metabase Cloud was attacked by someone utilizing an unknown (“0-day”) security vulnerability in versions 1.58 and above. We immediately blocked the endpoints used for the attack, then quickly identified and patched the vulnerability. We notified law enforcement, and we have engaged with a third party forensics firm to conduct an independent investigation.


Your instance of Metabase was vulnerable to this 0-day. Therefore, to protect your company, we recommend you:


Rotate the credentials for every database connected to your instance; and


Review the admin accounts on your instance and remove anything you don't recognize.


We also discovered that the attacker was able to gain access to your instance. We created a report on the actions we believe the attacker took on your instance, which includes log files, and which you can get from the Metabase Store at [removed url].


(If you do not have access to the Metabase Store, are having issues accessing the report, or do not want to click on a link in an unexpected email, you can log into your instance directly and reach us at Help > Get help in the grid menu in the upper right hand corner. We'll confirm this message is from us and email you the report.)


This report is based on our own application logs. We did not query or read the data in your connected databases.


Depending on the jurisdictions in which you operate and kinds of data your instance connects to, you may have notification obligations under applicable laws. If you have concerns in this regard, we recommend you assess potential notification obligations with your company’s legal or compliance experts.


We regret any inconvenience this incident may cause you, and we are here to support you. If you have questions, please reply to this email or email us at [removed email address], and we'll get back to you as quickly as we can.


Sameer Al-Sakran


Founder and CEO


Metabase


We immediately investigated the logs Metabase provided to us and confirmed that our database instance was accessed by the attacker. We confirmed that the following information was accessed:


Full name

Email address

Login IPs

Billing and shipping address information

Country

Address

City

State

Zip code

Phone number

Company


For Framework for Business customers, we are investigating whether the following information may additionally have been accessed:


Company

Phone

VAT

EIN

Billing Email

No other personally identifiable information, order information, or payment information was accessed.


Note that Metabase has additionally flagged:


Important: This is a preliminary update based on our current knowledge.


We are working with a third-party forensic investigation firm to understand the full nature and scope of the event.


We are providing you this interim update in advance of completing our investigation to allow you to better understand any potential impact and secure your data.


Our investigation is ongoing and the information shared now is preliminary.


Please look at the application logs as well as the queries executed that are provided as separate files in the zip file for detailed activity and a potential timeline.


We’re providing you notice of the breach in the meantime to ensure you have the earliest possible visibility. In the event Metabase notifies us of additional information that impacts you, we will send a follow-up email.


What was done to resolve the issue?


After we were notified of the breach by Metabase, we rotated credentials on all databases associated with our Metabase instance and confirmed that there were no changes in admin access or access to systems outside of Metabase.


What steps have you taken to ensure this doesn’t happen in the future?


We are evaluating the breadth and depth of data shared with business intelligence platforms, and scoping down their access to only the columns required for analysis.


Nirav Patel and the Framework Team

[CAPSLOCK2000]

De oorsprong van het lek ligt bij Metabase, de databaseprovider die Framework gebruikt.

Ik ben een beetje klaar met dit frame.

Bij datalekken wordt veel te vaak verwezen naar een of andere partner. De impliciete boodschap is dat het bedrijf zelf onschuldig is en niks verweten kan worden. Daar verzet ik me tegen, ze hebben die partner zelf gekozen.


Als klant heb ik niks met die partners te maken. Ik weet niet eens dat ze er zijn (tot het mis gaat) en ik kan op geen enkele manier kiezen bij welke partners (of partners van partners van partners) mijn data terecht komt. Het is niet voor niets dat de wet de verantwoordelijk bij álle verwerkers legt.

Nu weet ik ook wel dat het in praktijk erg lastig is om te controleren hoe veilig een of ander bedrijf is, zeker van buitenaf, maar het is geen excuus. Het is uiteindelijk hun keuze om een partner te nemen ipv het zelf te doen en welke data die partner krijgt.

Dat ze überhaupt een "business intelligence" partner hebben is ook een keuze. Als ik dan zie welke data die partner heeft dan vraag ik me ook af wat daar dan mee gedaan wordt. Waar is al die gedetailleerde klantinformatie voor nodig? Moet je daarvoor echt weten wat de namen van de klanten zijn, op welk huisnummer ze wonen en wat hun IP-adres is? Dat klinkt mij meer als ordinaire marketingdata data in oren.

Het is net als bij honden. Als een hond bijt moet je boos zijn op het baasje, niet op de hond.

Natuurlijk weet ik ook niet wat er hier precies is misgegaan en in welke mate dat een verwijtbare fout is. Fouten worden overal gemaakt, daar bewust mee omgaan hoort er echter ook bij. Al die 'partners' concurreren met elkaar en proberen de prijs laag te houden, op zich goed, maar security sneuvelt dan snel als eerste. Zeker omdat de meeste bedrijven security nog altijd als iets extra's zien wat je er bij doet, niet als de basis.
Bedrijven als Framework, Bol en ING weten hun eigen systemen wel veilig te houden. Het zijn steeds weer de partners waar het fout gaat. Doe het dan zelf! Maar ja, dat is natuurlijk te duur.

[g86]

En alweer via een derde partij. Als we ergens een account aanmaken, weten we dan eigenlijk welke derde partijen allemaal toegang hebben tot die gegevens?

[logix147]

Helaas hebben bedrijven de externe samenwerkingen nu niet bepaald met NEON letters op hun website staan. Dus om je vraag te beantwoorden: 9 van de 10x niet.

Je kan het ook omdraaien. Je hebt een account op Tweakers. Weet je zelf waar Tweakers deze gegevens allemaal toegankelijk voor heeft?

Je kan daarom hooguit een beetje beveiliging inbouwen door unieke e-mailadressen te gebruiken per bedrijf, dan weet je waar het vandaan komt en of iets dus legitiem is.

Als ik ineens op mijn [e-mail] een incasso verzoek van het CIJB ontvang, dan lijkt me de kans aannemelijk dat tablet reparatie winkel een lekje gehad heeft en dat ik weinig met dat mailtje ga doen.

Dat ik dan vanuit bol.com een mailtje ontvang met dat de bezorger onderweg is. Tja weet ik veel wie ze daarvoor gebruiken, dat kan dus CEVA zijn, die dan weer een DHL/PostNL/DPD/UPS aanwakkert en dat lijkt weer legitiem.

[unf0rg0tt3n]

Bij Gmail kun je een + toevoegen. Bijvoorbeeld: [e-mail]

Dan krijg je altijd een label toegewezen. Dan weet je het ook

[logix147]

Nadeel aan de allom bekende + gmail oplossing is dat alles alsnog in het hoofdpostvak eindigt en bij echte fraude je gewoon beschikt over het hoofdmail adres.

Op de manier zoals Simplogin/Proton het aanbied is dat je zoveel aliassen kan aanmaken zoals je zelf wilt - vanuit deze aliassen ook kan mailen en dat de ontvanger nooit jouw hoofdmailadres kan zien.

dus tweakers @ randomdomein . xyz kan ik mee antwoorden/ontvangen en dat kan gewoon op mijn bijv iCloud mailbox én gezamelijke mailbox van hotmail binnenkomen. Of mijn echte domeinmail

Ander voordeel dat zo'n systeem heeft is dat ik gewoon een 'vakantie' modus kan aanzetten.

Dan is bijv. alles met reclame weg en ontvang ik enkel alleen belangrijke mail, zonder dat ik van mailprogramma's of wat dan ook afhankelijk ben. Ik fix dit namelijk via Simplogin, niet via andere software o.i.d.

Ik heb dus met een vrij eenvoudige service 100% controle over wat er in komt en uit gaat en waar het in komt. Voeg een paar weekenden unieke wachtwoorden aanmaken toe en je hebt best flink wat privacy.

Nadeel:

• de bezorgapps herkennen mijn pakketten niet meer vanzelf.
• het kan zijn dat je 'positieve' bekendheid online kopen op rekening niet meer automatisch lukt. Er is namelijk weinig over je te vinden.
• Als dit systeem van gekraakt wordt - ben ik natuurlijk de 'zak'.
• Kosten; je moet dit betalen (ik heb gelukkig lifetime) en je moet een domein betalen.

[3raser]

Zijn ze dat niet verplicht te melden in hun privacy statement? Maar ja, wie leest dat.

[iam2noob4u]

In hun privacy statement staat een behoorlijke opsomming van bedrijven... maar Metabase kan ik er niet in vinden.

Ik heb hier en hier gekeken.

Ongeacht of ze het verplicht zijn en of je het leest, de lijst lijkt dus incompleet.

[virtualpimp]

Maar de verklaring claimt zelf nergens dat die opsomming compleet is? Er staat letterlijk dat je data toegankelijk kan zijn voor "external parties (such as third-party technical service providers, mail carriers, hosting providers, IT companies, communications agencies) appointed, if necessary, as Data Processors by the Owner", gevolgd door: "The updated list of these parties may be requested from the Owner at any time."

Metabase valt onder "third-party technical service providers". En die laatste zin is het bruikbare deel, je mag die lijst gewoon opvragen. Dat sluit ook aan op art. 15 AVG, dat recht geeft op "de ontvangers of categorieen van ontvangers". Namen publiceren is niet verplicht, ze op verzoek geven wel.

[iam2noob4u]

Dat zie ik alleen staan in de PDF die je kan downloaden. Dus om erachter te komen dat je gegevens naar Metabase gaan, moet je:

1. de privacy policy opzoeken (of openen bij het registreren van je account)
2. de PDF openen en lezen
3. iemand contacteren
4. wachten op antwoord

In principe heb je gelijk, maar als er een verplichting bestaat, gaat geen rechter dit 'goed genoeg' vinden toch? Ik ken de AVG niet voldoende om dat met zekerheid te kunnen zeggen, maar ik vind het zelf in ieder geval niet goed genoeg.

[virtualpimp]

Waarom Metabase er in de praktijk nooit in staat, zo'n opsomming gaat over diensten waar je data naartoe stuurt. Meta pixel, GA4, HubSpot, Heap, Contentsquare, Hotjar, Klaviyo, Segment, Cloudflare, Stripe. Metabase is een intern dashboard dat kijkt in een database die Framework toch al had. Dat voelt niet als "delen met een derde partij", dus wordt het niet opgegeven.

En dat is geen Framework-dingetje. Bijna niemand vermeldt zijn NextCloud of SharePoint in een privacyverklaring, terwijl daar net zo goed klantgegevens in kunnen staan. Met die maatstaf heeft vrijwel geen enkel bedrijf een complete lijst.

Grappig genoeg staan er bij Framework wel twee interne tools in, Google Workspace en Lever, hun recruitmentsysteem. Dus onmogelijk is het niet, het gebeurt gewoon inconsequent.

[World Citizen]

Google/AI eens naar AI agent scripts die algemene voorwaarden/privacy doorlezen.

Zelf doen is niet realistisch. Ik heb er een paar gedaan en je schrikt je dood. Bv whatsapp. Lees voor 1x in je leven eens zo een hele voorwaarden door en je gaat er direct iets meer op letten. (Ik schrok me (bijna) dood).

Een goede agent kan er al een hoop uit pikken.

[logix147]

Ik heb even Tweakers als voorbeeld genomen.

https://privacy.dpgmedia.nl/nl/document/privacy-policy#4

Hier wordt geen enkele leverancier in benoemd. Dat is dus per bedrijf verschillend hoeverre ze detail van benoemen van de betrokken bedrijven gaan.

@World Citizen

De bedoeling van een Privacy Statement is natuurlijk niet dat ik dit eerst door een AI model moet trekken om erachter te komen welke bedrijven allemaal aan de data zitten, want zoals je zelf al aangeeft. Het is niet geverifieerd dus moet je alsnog onderzoeken of dat lijstje klopt ja/nee en dat is net hetgeen wat zo’n statement eenvoudig duidelijk zou moeten kunnen maken i.p.v. mailen met een lijst van bedrijven, dat afwachten, alvorens jezelf ergens wilt ‘inschrijven’.

En moet ik dan elke 6 maanden checken of de leveranciers gewijzigd zijn? Of elke 3 maanden, of elk jaar?

Kortom; dat is niet te doen en volgens mij ook niet de bedoeling van zo’n lijst.

[Reactie gewijzigd door logix147 op 7 augustus 2026 09:56]

[World Citizen]

Als ik AI de privacy en voorwaarden van Tweakers laat volgen zou daar dit uit komen.

Je zou dit na kunnen lopen of er datalekken zijn geweest bij die bedrijven. Maar die durf ik niet aan. Dat word een beetje te generaliserend.

[AI TEKST NIET GEVERIFIEERD]

De exacte lijst hangt af van de cookiekeuzes die je hebt gemaakt. Als je alle advertentie- en personalisatiecookies accepteert, kunnen onder andere de volgende bedrijven gegevens ontvangen of verwerken via Tweakers/DPG Media.

Grote advertentie- en technologiebedrijven

• Google (Google Ads, DoubleClick, Google Analytics, YouTube)
• Microsoft (Microsoft Advertising/Bing)
• Amazon Advertising
• Meta (Facebook en Instagram)
• LinkedIn
• TikTok
• X (voorheen Twitter)
• Snapchat
• Pinterest

Advertentieplatformen en datapartners

• Criteo
• The Trade Desk
• Index Exchange
• Magnite
• PubMatic
• OpenX
• Xandr (Microsoft)
• Adform
• RTB House
• Quantcast
• TripleLift
• Taboola
• Outbrain
• Yahoo Advertising
• Equativ (voorheen Smart AdServer)
• LiveRamp
• Lotame
• Permutive
• Teads

Analyse en metingen

• Google Analytics
• Contentsquare
• Optimizely (A/B-testen, indien gebruikt)
• Hotjar (op sommige DPG-sites)

[/AI TEKST NIET GEVERIFIEERD]


@logix147 helemaal mee eens.

[Reactie gewijzigd door World Citizen op 7 augustus 2026 09:59]

[Farmeur]

Hier staat "[AI TEKST NIET GEVERIFIEERD]"

ook dit is een signaal dat de schrijver niet zelf acteert, maar zaken aan AI overlaat. Dus hij staat erbuiten en ik sta er ook buiten. "WE" laten het aan AI over. En in dit geval vindt de schrijver het redelijk dat honderden die zijn tekst lezen, het zelf elk apart nagaan, in plaats van dat de schrijver het zélf 1 keer doet. Wat efficienter en beleefder is.

Het is natuurlijk een detail, maar het past wel volledig in de beschrijving die ik in mijn post aangaf in deze draad (5-10 minuten geleden).

[World Citizen]

Ik ben het niet oneens met je maar ik denk dat het vrijwel onmogelijk is dit in een efficiënte tijdspanne te doen. AI kan dat sneller dan ons.

Als ik het zelf doe kan ik ook fouten maken maar dat schrijft niemand erbij

Bv “ZELF GEZOCHT MAAR KAN FOUTEN BEVATTEN”


Ik geloof ook niet echt blind wat iemand -zelf- schrijft en zoek dat ook wel eens na.

[Reactie gewijzigd door World Citizen op 7 augustus 2026 11:52]

[Farmeur]

Aan Logix147. En aan alle andere lezers.

Je zegt "De bedoeling van een Privacy Statement is natuurlijk niet dat ik dit eerst door een AI model moet trekken"

maar daar gaat het wel naar toe.
We hebben in de afgelopen jaren te maken gehad met steeds meer afstand tussen de partijen die met elkaar overleggen, afspraken maken enz.
Toen we nog konden bellen, werd er nummerherkenning ingevoerd. Gevolg: de gebelde laat het nummer rinkelen als het hem/haar niet bevalt.
Toen kwam de fax. Gevolg: je kunt van de klanten afdwingen dat ze faxen en niet meer per telefoon.
In diezelfde tijd kwamen de call centres. Die waren op de eerste plaats bedoeld om af te schermen (en tegelijk geld te verdienen aan het wachten). Gevolg: je kreeg alleen de gewenste persoon te pakken als je daar echt je best voor deed. Of je vanaf het begin recht op dat contact had, deed er niet toe: het systeem bepaalt.
We gaan hier al steeds meer naar afstandelijkheid en automaatjes.
Toen kwam de e-mail. Ik heb vanaf die tijd ongelofelijk brutale en manipulatieve trucjes gezien die vooral bedrijven uithalen om maar vooral afstand te houden, en dus grip te houden. Op dingen die niet deugen of die tijd (dus geld) vragen. Uitstellen van garantieclaims bijvoorbeeld.
En nu hebben we AI. Gevolg: we krijgen een situatie dat de ene AI-bot met de andere in de slag gaat. Op dit moment (zie de post van LOGX147 hierboven) is dat nog een eigen keuze, een "leuk idee". ZOO hip en modern en zo. Maar dit gaat de kant op dat je in de toekomst wel zult moeten. Dus: OVER de hoofden heen van de mensen aan beide kanten, zit AI met elkaar te praten en te strijden en beslissingen te nemen en betalingen te doen.

Dit hele verhaal toont aan dat we steeds verder wegzakken in een taaie rijstebrijpap, waar je je bijna niet meer in kunt bewegen. Waar je geen eigen vrijheid meer hebt. Wat WEL open gelaten wordt, uiteraard, is de mogelijkheid dat je koopt. Kopen, consumeren, de kerntaak van die bedrijven waar aan AI wordt gevraagd om dat te regelen.

En de consument, dat zijn jij en ik, kijkt ernaar en kan er nauwelijks aan ontsnappen.

Ik gebruik die analogie van rijstebrij al vele jaren. Het is hopeloos. Als je maar consumeert, DAT is wat je nog in vrijheid wordt toegelaten. De voorwaarden lezen, en communiceren over gebreken of garantieclaims enzovoort, dat zul je aan je AI moeten overlaten. Die bedrijven zullen andere contacten niet toestaan. Net zoals call centres dat niet deden, maar nu in de overtreffende trap. AI is wat dit betreft een super-call centre. Ik haat die ontwikkeling, en terecht.
En het zou me helemaal niet verbazen als die AI-agents straks onderling zaakjes gaan regelen, buiten de klant om, om het het bedrijf een beetje gemakkelijker te maken. Zoiets heet ook wel corruptie.

NB: dit onderwerp is best ingewikkeld. Ik noem een aantal argumenten en andere dingen. Ik zou het zéér op prijs stellen als de lezer straks, niet de bekende truc gaat uithalen om op 1 argument in te zoomen en vervolgens te roepen "je verhaal deugt van geen kanten". Nee, alleen dat ene argument deugt dan misschien niet of ten dele.

En nu, net als de vorige keer (enkele weken geleden): welterusten allemaal. Laat AI maar doorrazen nietwaar?

[Reactie gewijzigd door Farmeur op 7 augustus 2026 10:33]

[logix147]

Ik kan hier nu niet uit ophalen of dit nu AI is of zelf geschreven tekst, maar ik ben nog van de stempel dat je gewoon zelf informatie opneemt en AI als hulpmiddel inzet.

Algemene voorwaarden zijn gelukkig al dusdanig dat die te begrijpen dienen te zijn door consumenten en AI is een handige aanvulling daarop.

Privacy statements zijn daar nog vrij van en geloof dat de toezichthouders daar al helemaal geen tijd voor hebben, ze kunnen de AVG wetgeving al nauwelijks bijbenen.

Je zou zeggen dat met behulp van AI dat overheid saaie check werk sneller kan, maar daar denken ze bij de toezichthouders zelf helaas anders over.

[Alex3]

En moet ik dan elke 6 maanden checken of de leveranciers gewijzigd zijn? Of elke 3 maanden, of elk jaar?

Als de voorwaarden veranderen moeten ze je vooraf op de hoogte stellen.

[logix147]

Veranderen ze dan de voorwaarden als ze overstappen van leverancier? Dat denk ik niet en volgens zover mij bekend is dat bij een privacy statement nog niet van toepassing dat je daarvan verplicht bent dit bij elke aanpassing door te geven. Ik heb althans geen enkel mailtje van geen enkel bedrijf ooit ontvangen. Ook niet toen Tweakers onderdeel van de nieuwe partij werd.

[3R!K]

En hoeveel keus heb je wanneer je iets gedaan wilt krijgen? Zorgelijke ontwikkelingen.

[Niemand_Anders]

Ja, elke website moet volgens de AVG aangeven welke partijen toegang hebben tot welke gegevens en voor welk doel. Iedereen roept dat privacy belangrijk, maar hoeveel mensen zullen bijvoorbeeld echt de cookie popup lezen en bewust een keuze maken met welke ze gegevens willen delen?

[Schway]

Ja, ze zijn door de GDPR verplicht te vertellen aan wie ze je gegevens vertellen en waarom.

Of iedereen het leest is wat anders.

[Clemens123]

en die derde partij kan deze de gegevens dan ook weer delen zonder dat we daar iets over weten? Of verbiedt de GDPR dat?

[Reactie gewijzigd door Clemens123 op 7 augustus 2026 09:11]

[svennd]

Niet zomaar. Onder de GDPR/AVG hangt het vooral af van de rol van die derde partij en de oorspronkelijke rechtsgrond.

Als die derde partij een verwerker is (bijvoorbeeld een IT-leverancier die gegevens namens jullie verwerkt), dan mag die de gegevens in principe niet zelfstandig verder delen. Een subverwerker inschakelen vereist voorafgaande specifieke of algemene schriftelijke toestemming van de verwerkingsverantwoordelijke (art. 28 GDPR).

Als de derde partij zelf verwerkingsverantwoordelijke is, kan verdere doorgifte soms wel, maar alleen als daar een geldige rechtsgrond voor bestaat en de doorgifte verenigbaar is met het oorspronkelijke doel. Ook gelden transparantie- en informatieplichten richting betrokkenen.

Dus: GDPR verbiedt niet iedere verdere doorgifte, maar een derde partij kan persoonsgegevens zeker niet onbeperkt doorgeven zonder voorwaarden of transparantie.

[Schway]

Dat kan, dan kijk je op hun site voor die info.
Ik doe even een wilde gok en zeg dat ze je gegevens delen met DHL of zo.

[ongeregistreerd]

Nee, als logistieke dienstverlener ben geen (data)verwerker, ook al werkt u als logistieke dienstverlener voor een opdrachtgever. Je bent zelf verwerkingsverantwoordelijke voor de verwerking van persoonsgegevens die noodzakelijk zijn voor uw dienstverlening. Zoals namen, adressen, postcodes, woonplaatsen en eventueel telefoonnummers en e-mailadressen voor track & trace-bezorging.

Dus geen dpa nodig tussen opdrachtgever en logistieke verwerker, en opdrachtgever hoeft dus niet te vertellen wat en wie. Het zijn immers alleen gegevens noodzakelijk voor aflevering van je product.

Logistieke provider is uiteraard wel verantwoordelijk voor veiligheid van die gegevens en tijdig verwijderen van!

https://www.autoriteitper...l/search?keys=logistieke#

[Reactie gewijzigd door ongeregistreerd op 7 augustus 2026 09:23]

[lucatoni]

Hele goede opmerking. Is het überhaupt relavant? Bedrijven denken met (goedkoper) Outsourcing dat verantwoordelijkheid en aansprakelijkheid ook opeens verdwenen is. Sterker nog, praktisch alles (aan IT kant) wordt tegenwoordig uitbesteed bij grote bedrijven. Maar wie is er bewust bezig met de cyber risico's bij deze bedrijven?

[Janspook]

Geen we in de toekomst hier meer van zien door bijvoorbeeld AI?

Best een enge ontwikkeling en uitdaging in de IT-sector

[Gropah]

Dit is wel de angst die heerst bij het management van mijn werkgever. Door LLMs worden sneller bugs gevonden en is men ook in staat om ze sneller te proberen te gebruiken. Of dat is in ieder geval de gedachtegang, die wel kan volgen.

[elmuerte]

Door LLMs worden ook sneller bugs geïntroduceerd. Door LLMs kunnen ook sneller aanvallen uitgevoerd worden. Onder de streep blijft alleen "sneller" over, dus verwacht maar dat er alleen maar meer datalekken komen. Gelukkig is men tegenwoordig verplicht dat de melden.

[demianmonteverd]

Dat melden begint zo langzaamaan ook zinloos te worden voor mij als consument. Als maatschappij moet dit op termijn anders opgelost gaan worden, want dit is niet houdbaar zo.

De discussie om minder tooling in te gaan zetten zou op gang moeten komen, hotjar, metabase, etc.. En de gemelde lekken zouden niet vooral juridisch beoordeeld moeten worden, maar meer beveiligingstechnisch/inhoudelijk om betere beveiligingen te kunnen ontwerpen / opzetten.

Ook zonder LLM's hadden we deze problemen al, er was immers al sprake van meer lekken. Nu moet er een begin gemaakt worden aan het inhoudelijk oplossen en verbeteren. Daar moet de focus op komen, in plaats van het beoordelen op de juridische aspecten, anders blijven we eindeloos doorgaan en kun je de meldingen waar je bankgegevens, pasfoto's en identiteitsbewijzen niet bij betrokken zijn net zo goed negeren. Zelfs op tweakers gaat het te vaak over of er sprake is van nalatig handelen, niet snel genoeg communiceren, etc.. Daar hebben we niet veel aan, ik zou graag zien dat we lessons learned delen, hoe kwamen ze er in, welke beslissingen hebben dit mogelijk gemaakt (citrix, vpn, niet mogen updaten, niet vaak genoeg updaten, etc.), desnoods geef je elk bedrijf 'vrijspraak' als er geen extra gevoelige gegevens (foto's, medische gegevens, afspraken in de toekomst geplanned, etc.) zijn gelekt als ze een after action rapport maken dat voldoende inhoudelijk is. Doe iets dat gaat helpen.

[Blinkin]

Geen onrealistische angst. Bij mijn werkgever zijn we al met AI begonnen om sneller bugs te vinden, uiteraard wordt alles gecontroleerd daar AI nog wel eens fantaseert. We doen dit niet omdat we geloven dat AI nou zo goed is, maar wel omdat we al zien dat het in de praktijk toegepast wordt en effectief kan zijn. Vuur met vuur bestrijden, de aanvaller proberen voor te zijn.

Ik denk dat er inderdaad uitdagende tijden voor de deur staan. Aan de andere kant is bugs oplossen bij veel bedrijven jaren lang een kostenpost geweest. Dat zal nu niet meer gaam standhouden. Op zich geen negatieve ontwikkeling als je het vanuit die hoek bekijkt. Ik vrees alleen dat veel bedrijven dat pas gaan inzien als het te laat is en de burger de dupe is omdat alles op straat ligt.

[The-Source]

Nou beveiliging is altijd een kat en muis spel geweest.
Alleen er zijn altijd meer aanvallers geweest dan verdedigers, maar nu de aanvallers een veel grotere set aan gereedschap hebben met AI zal voorlopig dit niet hierbij blijven.

De algemene verwachting is dat dit nog wel 5 jaar zo zal door gaan (wellicht aan het einde wel minder in frequentie) want tegen die tijd zijn de verdedigers ook (al dan niet door schade en schande) helemaal bij.
En ik heb het niet over dat een verdediger niet zijn best doet maar maar waar het eerst 1 tegen 100 was is het nu 1 tegen 100*100agents (getallen even uit de lucht gegrepen)

En de kracht van AI gebruiken voor exploits is dus het aaneenschakelen van kleine op zichzelf staande bugs die door slim gebruik tot een veel grote footprint leiden

[Kabouterplop01]

Veel meer, al dat soort zaken wordt uitbesteed. Maar er zijn maar weinig toko's die de investering willen doen om een gedegen beveiligd systeem op te tuigen.
Dat kun je wel zien aan het aantal ransomware cases per dag.

De bedrijven die die data delen denken: " Lekker zeg hoef ik het niet te doen"
Niemand neemt zijn verantwoording, want ze willen zo veel mogelijk geld harken, niet uitgeven.

[maxkranendijk]

Zouden ze deze hack-updates over 1 jaar nog steeds posten? Volgens mij zit ik al in 15 datalekken binnen 1 jaar, maakt het dan nog veel uit? Ik snap best dat hoe vaker je gegevens gehackt worden hoe groter de kans is dat je erbij zit. Maar als een hacker 5 (top 10 hacks) koopt of download heeft die waarschijnlijk 90 a 95% van alle Nederlanders in zijn set.

Ik snap ook nog steeds niet waarom er niet standaard compensatie wordt gegeven aan klanten waarbij hun gegevens op straat komen te liggen. Je kan hier prima (kleine bedragen) voor rekenen net als bij stroom uitval, trein vertraging of internet wat langer uitvalt.

Ik begrijp nooit waarom bedrijven hier niet over nadenken. Je wist ongeveer 5 jaar geleden al dat dit veel meer zou gaan gebeuren. Dat betekent dat je al 5 jaar lang met slimme stagiairs met begeleiding allerlei scenario's had kunnen uitwerken hoe je hier beleid voor maakt zodat er incentives voor bedrijven zijn om hun beveiliging beter op orde te krijgen of oplossingen.

Door al die hacks wordt het bijvoorbeeld ook interessanter om je bestellingen zelf op te halen middels enkel een code zonder dat partijen je (volledige) naam weten en/of adres.

Er is zo weinig creativiteit en ambitie om met oplossingen te komen. Je hoort voornamelijk mensen met argumenten waarom het zo moeilijk is en er niks aan gedaan kan worden. Bv door bedrijven te beboeten zullen enkel de prijzen omhoog gaan omdat bedrijven extra kosten maken voor beveiliging...

[Reactie gewijzigd door maxkranendijk op 7 augustus 2026 10:01]

[Sachertorte]

IP icm met fysiek adres is een wat minder fijne leak.

[rneeft]

Zucht... Nou ja uiteindelijke graven de criminele hun eigen graf. Straks is er gewoon een enorme database met heel de mensheid. Waarom zou partij X nog voor mijn data losgeld willen betalen terwijl mijn data ook al bij Odido en andere is gelekt.

[rustycrab]

Ja goed punt. Is eigenlijk de 'schaarste' (en dus ook de waarde) van de persoonlijke gegevens die door al deze acties afneemt

[Martinez-]

Eigenlijk zou het helemaal mooi zijn als we als land gewoon alles van onze burgers online gooien en het hele businessmodel onderuit halen.

[Standeman]

Volgens mij zijn in Zweden zulke gegevens gewoon al publiek. Je adres, je inkomen en je belasting verleden zijn gewoon door iedereen op te vragen.
Geen idee overigens of hier iets voor te zeggen is of juist niet.

[CAPSLOCK2000]

Zucht... Nou ja uiteindelijke graven de criminele hun eigen graf. Straks is er gewoon een enorme database met heel de mensheid. Waarom zou partij X nog voor mijn data losgeld willen betalen terwijl mijn data ook al bij Odido en andere is gelekt.

Omdat mensen steeds nieuwe data genereren. Hoe nieuwere de data hoe interessanter. Weten wanneer iets verandert in het leven mensen kan heel waardevol zijn voor gerichte reclame.

[The Zep Man]

Waarom is een DBMS/zijn de servers van Metabase Cloud publiekelijk bereikbaar? Dat klinkt als backend software die je liever over een andere beveiligde verbinding wilt benaderen, juist om dit soort situaties te voorkomen.

Het beveiligen van endpoints is lastig. Daarom is het beter om het aanvalsoppervlak te verkleinen door geen directe verbindingen toe te staan.

[Reactie gewijzigd door The Zep Man op 7 augustus 2026 08:53]

[Davidshadow13]

Je ziet in de praktijk tegenwoordig de trend dat veel ook back-office software als SaaS wordt geleverd. Gewoon over het publieke internet met alleen application-level security controls. Bij een zero day als dit heb je dan gewoon geen second-line of defense meer.

[The Zep Man]

Wat ontzettend dom is. Endpoint security is tegenwoordig net als cryptografie en authenticatie: dat wil je niet zelf (alleen) doen. Besteed het uit aan software of oplossingen die specifiek met beveiliging in het achterhoofd zijn gebouwd en die veel meer aandacht krijgen vanuit de security community.

Bij dit kan je spreken van een gebrek aan gelaagde beveiliging en daarmee een stukje nalatigheid.

[Reactie gewijzigd door The Zep Man op 7 augustus 2026 09:02]

[marc1990]

Iemand idee of bedrijven straks wel op hun vingers getikt/ gestraft kunnen worden met NIS2? Ipv om economische redenen alles maar aan het internet te hangen?

[DNN!S]

Als een bedrijf of instelling onder kritieke sectoren valt wel. Maar denk niet dat een laptopfabrikant daar onder valt.

[svennd]

Dit is een GDPR incident of daar straffen uit voorkomen is voornamelijk of die gegevens correct behandelt zijn. NIS2 zou straffen indien ze hun informatica beveiliging niet op orde hebben (wat niet percé het geval is zonder details te kennen) en een sector zijn die onder NIS2 vallen.

Framework zal wel onder de CRA vallen, maar dat is meer voor hun hardware denk ik

[Reactie gewijzigd door svennd op 7 augustus 2026 09:24]