London property manager breach may have exposed bank details and lockbox codes

1. Executive summary

London property management firm City Relay has notified current and former landlords that intruders accessed its Metabase Cloud analytics instance twice, exploiting a vulnerability in the platform that the company says it was unaware of, and extracted personal data. Potentially stolen data includes names, contact details, bank account numbers, sort codes, IBANs, SWIFT references, account names/addresses, account passwords, and — of particular concern — property access details including locations of stored keys and lockbox codes. City Relay states it has rotated all exposed access and key-storage codes and found no evidence of misuse or unauthorised property access; the specific vulnerability was not identified, and no CISA-KEV exploitation state or CVSS scoring is available in the verified reference data for this item. For EMEA financial services clients, the direct exposure is limited to any relationship with City Relay as a counterparty, but the incident is a live demonstration of the analytics-layer compromise pattern: a BI tool connected to a core transactional database converts a single third-party platform flaw into bulk exfiltration of unencrypted financial and credential data.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The incident occurred at a UK property management company, not a financial entity or an ICT service provider in scope of the referenced articles, and the trigger facts available (third-party cloud compromise, personal data exposure) do not meet the test of changing what an in-scope client must do under any article in the regulatory reference. Clients with their own Metabase or comparable BI-tool deployments should treat this as a prompt for their existing DORA Art. 24 (digital operational resilience testing — general requirements) and DORA Art. 28 (ICT third-party risk — general principles) programmes, but no article is specifically triggered by this item's facts.

3. Technical analysis & attack chain

Confirmed and reported steps:

1. Initial access (confirmed as reported, mechanism unconfirmed): Intruders compromised City Relay's Metabase Cloud instance — a third-party-provided analytics platform — accessing it twice. City Relay attributes this to "a vulnerability in the platform that we were unaware of." The specific vulnerability was not identified by City Relay.
2. Data extraction (confirmed as reported): "Personal data was extracted from the platform." Exposed data categories per the notification: names, email and physical addresses, telephone numbers, financial information, property access details, and account passwords.
3. Financial data exposure: bank account numbers, sort codes, IBANs, SWIFT references, and account names and addresses.
4. Physical-security data exposure: property amenities and access data, including locations of stored keys and codes for lockboxes containing them.
5. Detection and response timeline (single-sourced): One source claims City Relay learned of the intrusion on September 8 and notified affected customers on September 14. This timeline is single-sourced; verify before enforcement or regulatory reliance.
6. Remediation to date: City Relay states all exposed access and key-storage codes were updated, the previously exposed codes no longer work, and it has "no evidence of any unauthorised property access arising from the incident." It reports no evidence the exposed data has been misused, and is investigating with cybersecurity specialists and "the relevant authorities."

Possible vulnerability link — explicitly unconfirmed: Metabase disclosed a zero-day SQL injection flaw on August 6, stating attackers compromised fewer than 3 percent of its customers before fixes were automatically deployed. Metabase has not confirmed that the City Relay incident was part of that campaign, and City Relay did not identify the vulnerability used. Known victims of the Metabase campaign included laptop maker Framework and workflow automation platform n8n. Treat the connection between the August Metabase SQL injection disclosure and this breach as plausible but unverified.

Why the blast radius was large (analyst context from Huntress, quoted in source): Metabase connects to customers' databases, so exposure depends on the access each customer granted it. A Metabase instance linked to a general analytics database exposes only benign metrics; one connected directly to a core transactional database exposes highly sensitive financial records and credentials. The presence of bank account numbers, sort codes, IBANs, SWIFT references, and passwords in the extracted data indicates City Relay's instance had broad access to sensitive operational data. Dray Agha (Huntress) further noted that if the exposed passwords and financial details were stored in readable form, that points to inadequate data protection practices — sensitive financial details should be encrypted or tokenised when held in a database, as a connected reporting tool compromise otherwise creates a massive risk.

Attribution: No threat actor is named in the source material. No attribution claim is made in this advisory.

4. Mitigation & containment

For clients who are City Relay landlords/counterparties:

• P1 (within 24h): Identify any accounts or payment mandates associated with City Relay. Monitor bank accounts for suspicious transactions, per City Relay's own guidance. Treat any inbound communication referencing this breach — payment-detail changes, refund requests, "urgent" landlord correspondence — as suspected phishing until verified out-of-band.
• P1 (within 24h): Change any passwords that were reused on the City Relay platform elsewhere, per the notification's guidance.
• P2 (within 72h): If you hold property managed by City Relay, confirm with them directly that your property's key-storage and access codes were rotated (City Relay states this work is complete, but confirm for your specific properties).

For clients running Metabase or comparable BI/analytics layers (the transferable lesson):

• P1 (within 24h): Audit what database credentials and schemas your BI tool holds. If it connects to a core transactional database with read access to financial or credential data, treat that connection as a standing exfiltration path and revoke or scope it down now.
• P2 (within 72h): Verify your Metabase instance is patched — Metabase's August 6 zero-day SQL injection fixes were automatically deployed for Cloud, but self-hosted instances require manual verification. Do not assume patch state.
• P2 (within 72h): Enforce encryption or tokenisation at rest for financial data (account numbers, sort codes, IBANs, SWIFT references) and hashed credentials in any database reachable by analytics tooling. Readable storage of these fields is the practice this incident indicts.
• P3 (within 7 days): Review authentication and session controls on analytics platforms: enforce SSO/MFA, remove long-lived service credentials where possible, and log query activity on the underlying databases so bulk extraction is detectable.

5. Indicators of compromise

No indicators of compromise available in the source material. No CVE identifier, hashes, domains, IPs, or attacker infrastructure were published for this incident.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules. The source material contains no CVE identifier, no attacker artefacts, no command-line or network indicators, and no distinctive strings from the intrusion. The Metabase SQL injection flaw referenced in the source is disclosed but unlinked to this incident and its technical artefacts are not in the provided material.

7. Sources

• The Register, "London property manager breach may have exposed bank details and lockbox codes," https://www.theregister.com/security/2026/09/17/london-property-manager-breach-may-have-exposed-bank-details-and-lockbox-codes/5297232, 2026-09-17

8. Adverse Trace position

This is a third-party breach with no verified CVSS, CISA-KEV state, or vulnerability identifier — severity cannot be scored from the available data, and we will not inflate it. The impact on EMEA financial services clients is indirect but real in two ways: any client with a landlord/counterparty relationship to City Relay should act on the P1 items above, and every client running a BI/analytics layer against a transactional database should treat this as a concrete example of that architecture's failure mode — a single platform vulnerability plus readable financial data at rest equals bulk exfiltration of banking details and credentials. The possible link to Metabase's August 6 zero-day SQL injection disclosure is unconfirmed by both the vendor and the victim; the September 8 discovery / September 14 notification timeline is single-sourced. We will monitor for a Metabase or City Relay statement confirming or excluding the SQL injection campaign, for any ICO or regulatory action arising from the readable-storage question, and for emergence of phishing kits or fraud campaigns leveraging the exposed banking details and property access data.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.