Belnet’s Breach Reached Beyond Email

Detection on 2026-09-24 preceded remediation at 08:10 the next morning. Belgium’s Centre for Cybersecurity assists; authorities were informed. The actor, message count and actual file downloads remain unconfirmed.

FileSender and FedSender links from that window could expose files. Password-protected or authenticated transfers are excluded if passwords were absent from upload comments. On 2026-09-29, Belnet disabled affected transfers and remaining links, triggering notifications. Senders must recreate needed transfers; recipients must ask them. The service cannot resend them.

Update, 1 November 2026: FortiMail guidance

Fortinet identifies FortiMail and CVE-2026-104286: unauthenticated web requests can place attacker-chosen files. Exploitation is reported. Its current fixes are 8.0.2 for branch 8.0, 7.6.7 for 7.6, and 7.4.9 for 7.4, or later supported releases. The advisory page describes 7.2.10 as upcoming, while Fortinet’s CSAF document directs the 7.2 branch to 7.4 or above. An upcoming label does not establish an available build. Confirm the supported route with Fortinet before selecting a 7.2 remedy. The advisory page directs all 7.0 releases to migrate to a fixed release. Belnet does not identify its installed version.

The vendor remediated its hosted service on 2026-10-05; customers need no action. Temporary options include disabling IBE, restricting webmail’s internet access, or filtering traversal POSTs to /ibe at a WAF. Containment does not establish that an already compromised appliance is clean.

The structured CVE record was updated on 28 October. It now lists the corrected 8.0, 7.6 and 7.4 thresholds shown above. The unresolved 7.2 difference is between Fortinet’s current publications. The CVE record enumerates 7.0.0 through 7.0.9 as affected, while the advisory page describes all 7.0 versions. Do not treat an omitted version as an assurance that an unsupported branch is safe.

Review the correspondence as well as the service

NCSC incident questions support reviewing specific correspondence. Examine contracts, support bundles and recovery links separately; these are examples for review, not an established theft inventory. Successful delivery cannot establish whether another copy exists.

Restrict an exposure list to the sending team, date, recipient, delivery method, information category and responsible owner. Prioritise credentials and sensitive attachments; preserve an audit trail without replicating everything in another widely accessible spreadsheet.

Actions for senders and operators

The ICO’s response guide separates fact gathering, containment, assessment and protective advice. Apply that structure to the sender’s remaining risk: restore the service, revoke exposed secrets, notify appropriate people and watch for believable follow-up requests. Returning the mail gateway to service cannot recover copies already taken. These are practical response principles, not a statement of Belgian notification law.

• Search the full window. Check messages to Belnet-owned domains, automated notices, forwarded attachments and FileSender/FedSender transfers.
• Classify the material. Record credentials, recovery links, personal data, contracts, financial instructions, research material and protected operational information. Treat these as categories to check, not confirmed stolen contents.
• Rotate live secrets. Replace passwords, API keys, tokens and private links exposed in clear text or attachments. A successful delivery receipt does not establish confidentiality.
• Warn participants about thread hijacking. Verify changed payment instructions, credential requests and unexpected follow-ups through an independent channel.
• Preserve evidence. Retain relevant messages, headers, transfer identifiers and notifications to match subsequent findings to the actual exposure.
• Request scoped guidance. Ask the provider whether your addresses, domains or shared services were affected; review affected guest accounts and remove unnecessary accounts.
• Verify the running build. Check current branch guidance; patch deployment alone does not establish recovery.

BlackTree’s Roundcube review separates closing a known flaw from examining earlier exposure. The same distinction matters here: mail holds identity, history and authority, and restoring communication does not resolve the consequences of copied data.

Sources and timing

• Incident notice, updated 2026-10-02 at 11:00 local time; current dateline 2026-10-01.
• Vendor advisory FG-IR-26-175, published 2026-10-01; updated 2026-10-07.
• CNA original, updated 2026-10-28; checked against the advisory page and the separately dated CSAF publication.
• Incident identification guidance, published 2019-06-10; reviewed 2020-10-08.
• Breach-response guidance, reviewed here in its current form; its legal guidance is under review.