Maileva Data Breach: How an Application Flaw Exposed 22 Million French Residents

On November 14, 2026, La Poste confirmed to Agence France-Presse (AFP) that its business-mail subsidiary Maileva had suffered a data breach affecting the personal details of 22 million people. France has roughly 68 million residents, so about a third of the population is involved. Maileva belongs to Docaposte, the digital trust and document management arm of the La Poste group. More than 70,000 small, medium, and large organizations use it to print and send about 180 million physical and digital documents a year.

Most coverage focused on the headline number. For security engineers and risk teams, the more useful question is how the attackers got in. This was not a volumetric attack on La Poste’s consumer postal network, and nobody found a misconfigured backup in an open cloud bucket. According to an internal Docaposte client fact sheet dated October 5, 2026, the attackers compromised Maileva’s live production information system through a vulnerability in the platform’s application layer. The breach-monitoring platform FrenchBreaches surfaced the fact sheet on October 9, and Cyberattaque.org corroborated it. The flaw sat in the logic that handles automated mail generation, tracking, and corporate billing, which turned a trusted business-to-business (B2B) print-and-dispatch pipeline into a single point of failure for French healthcare, social housing, and corporate customers.

Maileva breach timeline: from first access to public confirmation

The timeline below is reconstructed from Docaposte’s technical advisories and downstream customer notifications. It shows about a week of quiet access, then bulk data theft, then an attempt to manipulate the mail queue itself.

The attackers first got into Maileva’s production environment on September 9, 2026. They stayed for roughly seven to eight days without triggering a high-severity containment alert. The platform handles close to 500,000 documents a day, and a week of dwell time is plenty to map database schemas, enumerate API endpoints, and run bulk queries against historical tracking tables.

Maileva’s security team detected anomalous activity between September 16 and 17. It began forensic triage and patched the application vulnerability. That did not end the incident. On September 23, Maileva saw unauthorized attempts against specific client accounts, apparently aimed at submitting and dispatching fraudulent mailings without the account holders’ consent. The threat had shifted from passive data theft to manipulation of the mail-submission queue, so Maileva suspended its platform.

The outage lasted six days and stopped document production for thousands of customers. Services came back progressively from September 28, with broader operations resuming on September 29. During the outage, neither Maileva nor Docaposte said publicly that tens of millions of records had been taken. The scale emerged on October 9, when a regional workplace health service in Quimper told its members that a third party had accessed Maileva’s mail-tracking infrastructure. La Poste’s confirmation to AFP came on November 14.

How a multi-tenant mail platform works, and where it can fail

A single flaw gave an outsider access to data from tens of thousands of separate customers because of how hybrid-mail platforms are built. Maileva sits between a customer’s ERP, HR, or billing system and the physical sorting facilities. Customers use a web portal or call RESTful APIs, including the document-production and lrc_copro endpoints, to automate printing, enveloping, franking, and registered delivery. The documents include payslips, invoices, shareholder notices, and formal legal reminders.

A typical integration authenticates against the API gateway with an OAuth 2.0 password flow (grant_type=password) plus a client_id and client_secret, and receives a short-lived Bearer token. The client then submits a multipart payload. It contains the document binary, usually a PDF, and structured JSON or XML metadata: the recipient’s postal address, duplex and color options, envelope window specification, carrier class, archive retention period, and a sender notification email. The backend parses the job, assigns a tracking identifier, queues it for the print-and-stuffing hardware, and logs the transaction in a central mail-tracking database.

Maileva described the cause as an application flaw in the production information system. It did not describe a breach of the network perimeter. The public reporting does not name the specific bug, but that statement places the weakness in how the web and API tier talks to the shared data stores. In multi-tenant B2B SaaS, a failure of that kind usually takes one of three forms.

Broken object-level and function-level authorization (BOLA and BFLA)

Multi-tenant platforms depend on logical isolation inside shared relational databases. Every query against the mail-tracking table should be scoped by an organization_id or tenant_id taken from the caller’s validated session token. If an endpoint that returns mailing status, dispatch manifests, or shipment history skips the ownership check on the object identifier, one low-privilege or stolen session is enough. The attacker iterates through sequential or guessable mailing references and collects metadata from all 70,000 customer organizations.

Injection into tracking and billing stores

Suppose a search or ingestion controller builds a query from unsanitized input such as a file-name filter, a date range, or recipient details. SQL injection or an ORM-layer injection then bypasses application authentication entirely. The web tier usually connects to the database as a shared, high-privilege service account that can read every tenant partition and linked schema. An injection flaw therefore hands over the whole mail-tracking table and any adjacent billing databases in one step.

Authentication and session manipulation

The September 23 events point here. Attackers tried to trigger mail dispatches from legitimate customer accounts. That suggests they either used their database access to collect session tokens, API keys, or password hashes, or exploited a weakness in token validation that allowed direct impersonation. Whichever it was, they had read access to historical tracking data and write access to the job-submission queue. The compromised component was close to the center of the platform’s orchestration engine.

Ten years of data in the live database

Retention made all of this worse. According to Docaposte’s internal figures, the compromised tracking database held about 39 million distinct mail references. People receive mail over time from several employers, hospitals, and landlords, so those references collapse to 22 million unique individuals once duplicates are removed.

The database also held much more than September 2026 queue data. Depending on each customer contract’s archiving clause, the production tracking tables kept dispatch logs going back up to ten years. Aged records were never moved to air-gapped or cold archival storage, so a decade of history sat within reach of the live application tier. One flaw could therefore reach all of it.

What the attackers took: recipient records and corporate billing data

The compromised environment connected two different data domains, and each carries its own risks.

Recipient names, addresses, sender emails, and file names

First names, last names, and postal addresses for 22 million people look mild next to leaked passwords or national ID numbers. The tracking database also exposed the sender’s email address and the literal file names of the uploaded correspondence, plus billing metadata from debt-recovery workflows. File names in enterprise pipelines are rarely opaque. ERP and medical billing software routinely generate names that encode document type, account number, invoice number, and date, for example Relance_Impaye_Hopital_20260912_ClientID.pdf or Bulletin_Paie_Sept2026.pdf.

The downstream notifications show how metadata turns a contact list into sensitive personal intelligence. Hôpital Foch in Suresnes disclosed that payment-reminder letters sent between September 9 and September 23 were caught in the intrusion. They went through its debt-collection provider, Kiwee, which subcontracts physical mail dispatch to Maileva. Clinical diagnoses and patient bank details were not in the mailing pipeline. The tracking entries did reveal patient identities, home addresses, hospital invoice numbers, treatment dates, and amounts owed.

Social housing providers Flandre Opale Habitat and Altéal notified tenants of possible exposure. Several diagnostic laboratories in the Inovie group, namely AXBIO, BioMedilab, and Biofusion, were affected through the same subcontracting chain. An attacker who knows where someone lives, which hospital treated them on a given date, and how much they still owe has everything needed for convincing spear-phishing and fake debt-collection schemes.

Corporate IBANs, invoice amounts, and accounting contacts

The second exposure concerns companies that contract directly with Maileva. The attacker moved into Maileva’s internal billing environment and took client companies’ International Bank Account Numbers (IBANs), the exact amounts of their Maileva invoices, and the names and contact details of their accounting staff. Maileva said that no individual consumers’ bank details were compromised.

This combination suits Business Email Compromise (BEC) and authorized push payment (APP) fraud. Corporate treasury teams often validate payment requests against known invoice amounts and billing cycles. An attacker holding the exact euro amount and the email address of the financial controller can send a spoofed or lookalike message saying Maileva or Docaposte has changed its settlement account, along with a forged invoice carrying a mule IBAN. Exposed corporate IBANs also create a direct debit risk. Where a debtor’s bank weakly verifies SEPA Direct Debit (Prélèvement SEPA) mandates, an attacker can attempt unauthorized pulls against the affected accounts. Finance teams need bank-side debit allowlisting to close that gap.

The subcontracting blind spot in third-party risk management

None of the 22 million people chose to open an account with Maileva. In many cases the data controller, such as Hôpital Foch, did not contract with Maileva at all. It hired an intermediary, Kiwee, and Kiwee routed the print jobs through Maileva’s APIs. That is a fourth-party relationship, and most third-party risk management (TPRM) programs do not map it.

Organizations tend to treat a mail-printing vendor like a postal carrier. In data-flow terms it is a cloud software processor that receives unencrypted document streams from the customer’s core systems. A hospital, laboratory, or municipal agency may run strict network segmentation, zero-trust identity controls, and endpoint detection. Once it sends a batch of unredacted PDFs and recipient metadata to a multi-tenant mail processor over an API, its security posture depends on that processor’s coding practices and database isolation.

Maileva in the wider pattern of French breaches

La Poste’s problems did not start with Maileva. In December 2025, days before Christmas, the pro-Russian hacktivist group Noname057(16) claimed a cyberattack that disrupted La Poste’s online banking portals, its main website, mobile applications, Digiposte, and France’s digital identity service. That attack was a distributed denial-of-service (DDoS) event and hit availability. The September 2026 Maileva intrusion was a quiet attack on confidentiality and integrity through a subsidiary’s application layer.

It fits a run of large data-harvesting operations in France over the past two years. These include the breaches at the healthcare payment processors Viamedis and Almerys (33 million people), the national employment agency France Travail (43 million people), the General Directorate of Public Finances (DGFiP), and the recent attack on the banking group Crédit Mutuel Arkéa. In each case the attackers skipped the hardened core systems and went after the web portals and B2B service providers that gather identity data across institutions.

GDPR and CNIL: what regulators will examine

After consolidating its forensic findings, Maileva notified the Commission Nationale de l’Informatique et des Libertés (CNIL) under Article 33 of the GDPR and filed a criminal complaint. The cybercrime section (Section J3) of the Paris Public Prosecutor’s Office opened a judicial investigation into unauthorized access to, and interference with, an automated data-processing system. French law covers this offense in Articles 323-1 to 323-3 of the Penal Code.

On the compliance side, CNIL’s review under GDPR Articles 28, 32, and 33 will likely turn on three questions:

1. Technical measures (Article 32). Did Maileva and Docaposte run a secure software development lifecycle, scan regularly for vulnerabilities with authenticated tools, and build tenant isolation suited to a repository of 39 million correspondence records?
2. Storage limitation (Article 5(1)(e)). Why did up to ten years of mail-tracking metadata stay queryable in the active production tier when it could have been purged or moved to offline storage after delivery?
3. Notification timing (Articles 33 and 34). How do detection on September 16 to 17, the shutdown on September 23, the client briefing on October 5, and public confirmation on November 14 fit the duty to notify regulators and affected individuals without undue delay?

Defensive lessons for engineers and finance teams

Enforce tenant isolation in the database engine

Application code that appends a WHERE tenant_id = ? clause is one bug away from failing. Row-level security (RLS) at the database layer gives a second barrier. A PostgreSQL example:

sql

ALTER TABLE mail_tracking ENABLE ROW LEVEL SECURITY;
ALTER TABLE mail_tracking FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON mail_tracking
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

The application sets app.tenant_id from the validated session at the start of each request. The application’s database role must not be a superuser, must not hold BYPASSRLS, and should not own the table, since owners skip RLS unless FORCE is set. With this in place, an injection bug or a missing ownership check in one endpoint cannot read across tenant boundaries.

Take finished mail out of the hot database

Once a letter has been printed, enveloped, and handed to the postal stream, its metadata and descriptive file names should leave the production database. Move them to an immutable archive that the live application tier cannot route to, and purge them when the contractual retention period ends. If the Maileva tracking tables had held only active jobs, the breach would have exposed far fewer than 39 million records.

Watch for slow collection

A week of unnoticed access suggests the attacker’s queries looked like normal traffic. Useful signals include per-tenant and per-credential query volume baselines, alerts on queries that touch many tenant partitions, and monitoring of new API credentials or job submissions that differ from a customer’s usual pattern.

Lock down supplier payment changes

Finance teams that received the Maileva billing notification should put out-of-band verification holds on every request to change a supplier’s IBAN. Verification means calling a known number, not replying to the email that made the request. They should also configure bank-level SEPA Direct Debit filters so that unauthorized pulls against their exposed account numbers are blocked.

Map your fourth parties

Ask each print, mail, and document-processing vendor which subcontractors touch your data and what they retain. If your recipients’ names, addresses, and document titles pass through a platform you have never assessed, your own breach notification obligations may depend on it.

FAQs

What happened in the Maileva data breach?
Attackers exploited an application-layer vulnerability in Maileva’s production system and took mail-tracking and billing data. La Poste confirmed on November 14, 2026 that 22 million people were affected.

What data was exposed in the Maileva breach?
Recipients’ first and last names, postal addresses, sender email addresses, and the file names of uploaded correspondence were exposed, along with billing metadata in debt-recovery workflows. On the corporate side, client companies’ IBANs, invoice amounts, and accounting contact details were taken. Maileva said no individual consumers’ bank details were compromised.

When did the Maileva breach happen?
Initial access was on September 9, 2026. Maileva detected it on September 16 to 17, suspended its platform on September 23, and restored services from September 28 to 29.

Who is at risk after the Maileva breach?
The 22 million recipients face phishing and fake payment-collection scams. Maileva’s corporate clients face BEC, invoice fraud, and unauthorized SEPA direct debit attempts.