Summary
- Metabase said an attacker exploited a previously unknown vulnerability affecting version 1.58 and above, with self-hosted installations potentially exposed until patched.
- n8n confirmed that an unauthorised party queried data through its Metabase environment, accessing 136 records, including five containing bcrypt-hashed Cloud passwords.
- The incident shows how analytics platforms can inherit sensitive database access and become consequential third-party dependencies.
A zero-day attack against Metabase has produced a confirmed downstream data exposure at German workflow automation company n8n, turning a vulnerability in an analytics platform into a broader third-party security incident.
Metabase disclosed on 6 August that its Cloud service had been attacked using a previously unknown vulnerability affecting versions 1.58 and above. The company blocked the endpoints used in the attack and patched the flaw, while Metabase Cloud customers were upgraded by the provider. Self-hosted installations running affected versions require their own updates.
The vulnerability allowed an attacker who gained access to a Metabase instance to inject arbitrary SQL against the application’s database. Metabase said that access could provide administrator control of the instance and, from there, expose application configuration, credentials stored for connected databases, and data reachable through those connections.
The consequences are now visible in a European customer environment. n8n said it was informed of the Metabase incident on 6 August and subsequently established that an unauthorised third party had accessed and queried data available through its internal Metabase environment. The unauthorised activity itself took place on 3 August.
n8n confirmed that 136 records containing names and email addresses were accessed across its users, including both self-hosted and n8n Cloud users. Five of the records also contained bcrypt-hashed passwords belonging to n8n Cloud accounts. Passwords belonging to self-hosted users are not shared with n8n.
The investigation also identified an older n8n bug that had caused 25 Cloud account passwords to be stored in plain text. n8n said it considered it unlikely that those records were accessed during the Metabase incident, but contacted all 25 account holders as a precaution. It also rotated potentially affected credentials, reviewed audit logs, and notified its data protection officer and the Berlin Commissioner for Data Protection and Freedom of Information.
n8n cannot identify exactly which of the 136 records were returned because, it said, the queries involved selected a variable and non-deterministic set of rows each time they ran. That uncertainty places a limit on the precision of the exposure assessment even though the overall number of queried records is known.
The relatively small confirmed dataset does not diminish the significance of the access path. Analytics systems are deployed precisely because they can query information held across operational databases, customer systems, warehouses, and internal reporting environments. Their usefulness depends on connectivity, but those connections can also give an attacker who compromises the analytics layer a path beyond the reporting interface itself.
Metabase’s description of the vulnerability illustrates that distinction. Administrative control of an affected instance could expose credentials for databases connected to it, placing the security boundary around an analytics tool in direct contact with other parts of the data estate.
The n8n disclosure also shows why downstream investigations continue after a supplier has patched the original service. Once a compromised platform has queried customer environments, affected organisations still need to establish which data was available, which queries were executed, whether credentials were exposed, and whether unrelated historical weaknesses alter the possible impact.
There is no indication in n8n’s disclosure that its broader service was taken over or that all user records were exposed. The company instead identified a limited set of queried records and a separate group of accounts treated cautiously because of the older password-storage issue.
Metabase has published fixed point releases across affected supported branches and an attack pattern for organisations examining self-hosted installations. It says versions below 58 are not affected by this vulnerability.
The immediate vulnerability has been patched, but the incident gives analytics software a less benign place in third-party risk assessments. When reporting systems sit between multiple databases, their compromise can turn a single application flaw into an investigation across the wider data environment.
