SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

FortiMail's exploited flaw has no fixed build in any of four branches, and CISA's deadline is 4 October

Fortinet says CVE-2026-104286 is being exploited in FortiMail, and its advisory lists fixes for three of four branches as upcoming and sends the fourth to a branch that is also affected. CISA's deadline is Sunday 4 October.

By Parminder Kumar Sharma · · 20 min read

Editorial illustration for the briefing: FortiMail's exploited flaw has no fixed build in any of four branches, and CISA's deadline is 4 October

Zero fixed builds in four branches, and a deadline that lands on a Sunday

Fortinet's advisory FG-IR-26-175 lists four FortiMail branches as affected by CVE-2026-104286, a flaw Fortinet says has been exploited in the wild. For three of them the fix is "upcoming": 8.0.2, 7.6.7 and 7.4.9. For the fourth, 7.2, the advisory says to upgrade to branch 7.4 or above, and the same table lists 7.4.0 to 7.4.8 as affected. The number of fixed builds an administrator can install today is zero, across 28 affected builds in four branches.

Fortinet's CVE record was published at 19:17 UTC on Thursday 1 October. At 11:34 BST on Saturday 3 October, 39 hours later, the advisory still says upcoming. CISA added the flaw to its Known Exploited Vulnerabilities catalogue the same day and set a due date of Sunday 4 October, three days on. The feed gives a date and no time: counted to the start of that Sunday there were 12.4 hours left at 11:34 BST, counted to the end of it 36.4. The required action is the wording CISA has put on all 46 entries added since 1 September, apply mitigations in accordance with vendor instructions, and here the vendor's instructions are workarounds because no fix exists.

What that arithmetic does not establish matters as much. It does not establish when exploitation began, so the figure several earlier briefings here lead with, days of exploitation before a fix, cannot be computed: no source gives a start date. It does not establish who is behind the attacks or how many appliances were taken; neither is stated. It does not establish that your appliance was entered, or that it was not. And it does not establish that fixes are close: "upcoming" carries no date in the advisory, in the CVE record or in any of the six news reports read for this briefing. For contrast, Check Point's management flaw arrived with a dated first attack and a 61 day gap. This one arrives with neither number.

The branch table, read line by line

This is the table from the live advisory page, read at 11:12 BST on 3 October and checked again at 11:34 BST. The last column is this briefing's own: it is derived from the advisory text and timeline, which name no release date for any fix.

Affected builds and fixes by branch, from Fortinet advisory FG-IR-26-175 as served on 3 October 2026. The last column is derived.

  1. Branch
    FortiMail 8.0
    Affected builds
    8.0.0 to 8.0.1
    Fix the advisory names
    Upgrade to upcoming 8.0.2 or above
    Installable fix today
    None, no date
  2. Branch
    FortiMail 7.6
    Affected builds
    7.6.0 to 7.6.6
    Fix the advisory names
    Upgrade to upcoming 7.6.7 or above
    Installable fix today
    None, no date
  3. Branch
    FortiMail 7.4
    Affected builds
    7.4.0 to 7.4.8
    Fix the advisory names
    Upgrade to upcoming 7.4.9 or above
    Installable fix today
    None, no date
  4. Branch
    FortiMail 7.2
    Affected builds
    7.2.0 to 7.2.9
    Fix the advisory names
    Upgrade to branch 7.4 or above
    Installable fix today
    None: names a branch, not a build

Two features of the table are easy to miss. The word "upcoming" appears in three of four rows, and the fourth has no build number at all. And the 7.2 instruction is a friendly name for a fix that does not exist yet. "Upgrade to branch 7.4 or above" reads like a fixed state, but every 7.4 build up to 7.4.8 is on the affected list. BleepingComputer and Field Effect both read the 7.2 row as a patch route, and Field Effect writes that 7.2.x has a patch available. On the advisory's own ranges, a 7.2 administrator who moves to the newest affected 7.4 build today swaps one affected build for another. The honest reading is that the 7.2 row says where to go once 7.4.9 exists.

Ladder diagram of four FortiMail branches in Fortinet advisory FG-IR-26-175. Each tile is an affected build: 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8, 7.2.0 to 7.2.9. Dashed boxes mark the upcoming fixes 8.0.2, 7.6.7 and 7.4.9; the 7.2 row names no build and an arrow leads up to the 7.4 row. A band states that no branch has an installable fixed build.
Drawn from the Fortinet advisory table as served on 3 October 2026; build ranges as listed by Fortinet, not tested.

Silence matters too. The advisory does not mention FortiMail 7.0 or earlier, or FortiMail Cloud, and one Fortinet record, covered next, does list 7.0. Treat the silence as unconfirmed, not as safe.

Three Fortinet records, three answers

Fortinet publishes this flaw in at least four places: the advisory page, the CVE record it controls as its own CVE numbering authority, the CSAF file attached to the advisory, and an RSS item. They do not agree about which builds are affected or which are fixed. NVD carries the CVE record's data, so the disagreement shows up inside a single NVD entry.

What each Fortinet record says, read on 3 October 2026 from the advisory page, the CVE record at cve.org (last updated 2 October, 16:56 UTC), the NVD entry and the advisory's CSAF file.

  1. Record
    Advisory page
    Affected builds
    8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8, 7.2.0 to 7.2.9
    Fixed builds named
    Upcoming 8.0.2, 7.6.7 and 7.4.9; for 7.2, branch 7.4 or above
  2. Record
    CVE record, description text
    Affected builds
    The same four ranges
    Fixed builds named
    Not given
  3. Record
    CVE record, affected block (NVD shows it too)
    Affected builds
    8.0.0; 7.6.0 to 7.6.5; 7.4.0 to 7.4.6; 7.2.0 to 7.2.9; 7.0.0 to 7.0.9
    Fixed builds named
    Not given
  4. Record
    CVE record, solutions field
    Affected builds
    Not given
    Fixed builds named
    Upcoming 8.0.1, 7.6.6, 7.4.8 and 7.2.10, plus three FortiRecorder versions
  5. Record
    CSAF file
    Affected builds
    The same four ranges
    Fixed builds named
    Upcoming 8.0.2, 7.6.7 and 7.4.9, and the whole 7.4 branch listed as not affected

Count the builds, number by number within each range. The advisory's ranges cover 28 builds. The CVE record's affected block covers 34. They share 24. Four builds the advisory calls affected are missing from the record's block: 8.0.1, 7.6.6, 7.4.7 and 7.4.8. Three of those, 8.0.1, 7.6.6 and 7.4.8, are the newest builds in their branches' affected ranges, so they are the ones an administrator who patches promptly is most likely to be running. Ten builds the record lists, 7.0.0 to 7.0.9, appear nowhere in the advisory. A scanner fed from the CVE record rather than the advisory is wrong about 14 builds, and wrong in the dangerous direction for four of them. These counts are derived here, not stated by Fortinet.

The solutions field is stranger. It tells administrators to upgrade to upcoming versions 8.0.1, 7.6.6 and 7.4.8, which the advisory lists as affected, and to 7.2.10, which the advisory never mentions; the advisory sends 7.2 to another branch. The field also names FortiRecorder, a different Fortinet product that appears nowhere else in the advisory or the record. I read that as text left over from another advisory (inference), and I do not read it as saying FortiRecorder is affected. The CSAF file adds a smaller contradiction: it marks the whole 7.4 branch as not affected, while its own ranges include 7.4.0 to 7.4.8. A machine reading that file could conclude that the 7.2 instruction is a fix.

Which record is wrong is not stated. This briefing follows the advisory page, because it is the document Fortinet tells customers to act on, and it says so wherever the records diverge.

The label understates it, and the score is Fortinet's own

CISA's catalogue calls the flaw a path traversal, which sounds like reading files. Fortinet's description is that an unauthenticated attacker can write arbitrary files to the underlying system through crafted HTTP or HTTPS requests, and the advisory's Impact field reads "Execute unauthorized code or commands". The label names a bug class; the impact field names the outcome. Treat it as code execution on a mail gateway until shown otherwise.

The score is 9.8 under CVSS 3.1, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: reachable over the network, low complexity, no privileges, no user interaction, scope unchanged, and high impact on confidentiality, integrity and availability. Fortinet assigned it, acting as its own CVE numbering authority. NVD lists it as a secondary score from psirt@fortinet.com, and the NVD entry fetched on 3 October carries no score of NVD's own. CISA's contribution, published under the CISA-ADP identifier and not by any vendor, is a decision triple: exploitation active, automatable yes, technical impact total. That triple, not the 9.8, is what BOD 26-04's timelines turn on, together with whether the asset is publicly exposed.

One more detail. Fortinet's CVE record appends temporal metrics to the vector, E:P/RL:O/RC:C. In CVSS 3.1, RL:O means an official fix is available and E:P means proof-of-concept code only. Neither fits an advisory with no fix and active exploitation. The base score does not depend on them; applying them as written would give 8.8 (derived here), a figure that flatters the risk and that nobody should use. I read the metrics as a template default rather than a judgement (inference), but they are what the record says.

Fortinet found the flaw, wrote the advisory, issued the CVE, set the score and sells the product. None of that is an accusation. It is the reason to cross-check Fortinet's records against each other and against CISA's, as the previous section does.

What Fortinet says about exploitation, quoted

The advisory's whole statement on exploitation is one sentence: "This has been reported to be exploited in the wild, customers are urged to apply the workaround below." Its metadata block adds Known Exploited: Yes, Discovered: Internal and Attack Type: Unauthenticated, and credits Gwendal Guégniaud of Fortinet's Product Security team.

Three things follow, and one does not. Exploitation is reported, in the passive voice, with no date, source or count. The word zero-day appears in the news coverage and not in the advisory; it is fair here because no fix existed at disclosure, but it is the press's label. "Discovered: Internal" does not say whether Fortinet found the flaw before or after attackers used it. And the CVE ID was reserved at 19:12:54 UTC on 1 October and published at 19:17:38, 4 minutes 44 seconds later, a gap consistent with an unplanned disclosure (inference; the record does not say).

Asked for more, Fortinet told BleepingComputer it was communicating "with relevant government organizations, including CISA, on the content of this advisory". BleepingComputer, The Register and Help Net Security each report that Fortinet has not said when attacks began, who is behind them or how many systems were compromised, and Cybersecurity Dive says it gave no start date. Nothing in the primary records says otherwise. watchTowr, a firm that sells exposure validation, told Cybersecurity Dive the flaw "is trivial to exploit". That is a commercial researcher's view and not a Fortinet statement.

CISA's entry is the only dated record: added Thursday 1 October, due Sunday 4 October, flagged for forensic triage, ransomware campaign use "Unknown". It is the first FortiMail entry in a catalogue that holds 31 Fortinet entries (derived from the KEV feed, version 2026.10.02). "Unknown" is the field's default state, an absence of a record rather than a record of absence. For how these clocks usually run, see the three day clock on old flaws.

The advisory page changed, and its history says it did not

Four news reports describe a Fortinet indicator list that the live advisory no longer contains. BleepingComputer prints a table of seven files with SHA-256 hashes, The Hacker News lists the same seven paths, and The Register and Help Net Security mention files. Neither the live page, read by curl and by a browser at about 10:12 UTC on 3 October, nor Fortinet's CSAF file contains them.

The Internet Archive explains the gap. It holds five captures of the advisory page, from 23:55 UTC on 1 October to 08:57 UTC on 2 October, with identical text. They show the seven files with MD5 and SHA-256 values, a second workaround that says to disable access to the management interface, no firewall option, and the IBE switch-off as a command only. The live page differs on each of those points: the file list is gone, the second workaround now says webmail interface, a firewall option has been added, and the graphical path to the IBE switch is given.

Before and after comparison of Fortinet advisory FG-IR-26-175. Archived captures from 1 to 2 October show seven file indicators with hashes, a workaround naming the management interface, no firewall option and a command-line-only IBE switch. The live page on 3 October has no file indicators, names the webmail interface, adds a firewall option and a graphical IBE path. Both show initial publication on 1 October only.
Drawn from five Internet Archive captures of the advisory and the live page read on 3 October 2026.

Meanwhile the page's own timeline still reads "2026-10-01: Initial publication", Fortinet's RSS item says "Revised on 2026-10-01", and the CSAF file gives a current release date of 2 October with a revision history that lists only version 1. When the page changed between 08:57 UTC on 2 October and about 10:12 UTC on 3 October, and why the file list left it, is not stated. A deliberate trim, a move elsewhere or a mistake would each fit; the record supports none of them. It does support a practical rule: copy an advisory when you read it, with the date, because the live page is not a reliable record of what it once said.

The wording change matters. The management interface and the webmail interface are not the same interface. This briefing follows the live page, notes that the news coverage repeats the earlier wording, and tells administrators to verify from outside that the web service is unreachable rather than trusting either phrase.

What to hunt for, from Fortinet's published indicators

Fortinet publishes four kinds of indicator. They are for hunting, not for proof of safety: a clean result tells you the attacker did not leave these particular marks, and says nothing about an attacker who used other infrastructure or cleaned up.

Indicator types in advisory FG-IR-26-175, from the live page and the five archived captures. Addresses are written as Fortinet defangs them.

  1. Type
    IP addresses
    What Fortinet lists
    79[.]141.169.187 and 45[.]129.0.192
    Where it appears
    Live page and archive
  2. Type
    Files added or modified
    What Fortinet lists
    Seven paths, each with an MD5 and a SHA-256 (paths below)
    Where it appears
    Archive only
  3. Type
    System event logs
    What Fortinet lists
    A cron entry running a shell command as root that mentions /migadmin; an admin logout reported from (null); a configuration event adding an archive account named archive234
    Where it appears
    Live page and archive
  4. Type
    Encryption logs
    What Fortinet lists
    An IBE decryption exception reporting invalid Base64 at position 0, and a line reporting that an internal user failed to log in
    Where it appears
    Live page and archive

The seven file paths in the archived advisory. The MD5 and SHA-256 values are in the archived capture of 1 October, 23:55 UTC.

  1. Path
    /data/lib/liblog.so
    Status in the advisory
    Added
  2. Path
    /data/bin/webconsole
    Status in the advisory
    Added
  3. Path
    /data/bin/mailservice
    Status in the advisory
    Added
  4. Path
    /data/etc/ld.so.preload
    Status in the advisory
    Added
  5. Path
    /bin/smit
    Status in the advisory
    Modified
  6. Path
    /data/etc/httpd.conf
    Status in the advisory
    Modified
  7. Path
    /data/migadmin.tar.gz
    Status in the advisory
    Modified

Fortinet does not say what these files do or in what order they appeared. By name and location the list holds a shared library, a preload file, two files in a program directory, a changed file in the system binary directory, a changed web server configuration and a changed archive. That is a larger footprint than the phrase "arbitrary file write" suggests, and another reason the label understates the flaw.

The archive account indicator is the most revealing, and it needs careful reading. The first listed attacker address, 79[.]141.169.187, is also the remote address in the configuration event that adds archive234, with a remote directory of /uploads. Fortinet's own documentation says an archive account can use a remote destination, an FTP or SFTP server, for the mail it archives. So the indicator is consistent with an account created to ship mail off the appliance. Fortinet does not say that happened, how much mail moved, or whether any did. BleepingComputer draws the same inference and calls it a possibility. It is an inference here too.

Hunt in this order, from outside the appliance wherever you can. Search firewall, proxy and mail logs for the two addresses as far back as they go. List every archive account and look for one you did not create, above all one with a remote destination. Search the event log for the system patterns and the IBE decryption exception. Compare the seven paths and, from the archived capture, their hashes. Then ask the uncomfortable question about retention: most of these indicators live in logs and files on the appliance, which is the machine an intruder with root can edit. Anything you did not already ship elsewhere is evidence you hold on trust.

Two workarounds that are not the same workaround

Fortinet offers three options. Switch the IBE service off, by the GUI or with one command. Or disable internet access to the webmail interface, or limit it to a trusted private network. Or, if a web application firewall sits in front of the appliance, block POST requests to the IBE path that carry a directory traversal sequence. The advisory does not say they are equivalent, and they are not.

IBE is FortiMail's identity-based encryption service: a recipient gets a notification and reads the encrypted message on the FortiMail itself. Fortinet's administration guide says "External IBE users can only access their secure messages via the link in the IBE notification email". For an organisation that sends secure mail to external recipients, restricting internet access to the web interface therefore cuts those recipients off, because they can no longer reach the appliance: the same secure mail service the first workaround switches off. Either way there is a cost, and the advisory is silent on it. That is my reading of the documentation, not Fortinet's statement.

Three further gaps. The advisory does not say whether an appliance that already had IBE off was ever reachable, only that turning it off is a workaround. It does not say whether a workaround removes anything already planted; The Register states that it will not. And no Fortinet virtual patch is listed, because the Virtual Patch field says No.

Stated and not stated

What the record establishes and what it leaves open, read from the Fortinet advisory (live and archived), the CVE and NVD records, the CISA KEV entry and six news reports on 3 October 2026.

  1. Question
    Is it exploited?
    Stated on the record
    Yes: the advisory says Known Exploited; CISA lists it; CISA-ADP rates exploitation active
    Not stated
    When it began, by whom, against how many, or how Fortinet learned of it
  2. Question
    Which builds?
    Stated on the record
    28 builds: 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8, 7.2.0 to 7.2.9
    Not stated
    Whether 7.0 or earlier is affected; whether FortiMail Cloud is; why the CVE record disagrees
  3. Question
    Is there a fix?
    Stated on the record
    Upcoming 8.0.2, 7.6.7 and 7.4.9; 7.2 to move to branch 7.4 or above
    Not stated
    Any release date; any fixed 7.2 build; what "or above" means before 7.4.9 exists
  4. Question
    What does the flaw do?
    Stated on the record
    Unauthenticated arbitrary file writes by crafted HTTP or HTTPS requests; impact is code or command execution
    Not stated
    Which files are written; whether IBE must be on for the flaw to be reachable
  5. Question
    What did attackers do?
    Stated on the record
    Indicators list added and changed files, a root cron entry and an archive account with a remote destination
    Not stated
    Their aims; whether mail was copied or taken; any data loss
  6. Question
    What is the workaround?
    Stated on the record
    IBE off, or restricted web access, or a firewall rule
    Not stated
    The cost of IBE off; whether appliances with IBE already off were reachable; why the wording changed
  7. Question
    Who and how many?
    Stated on the record
    Nothing
    Not stated
    Actor, campaign name, victim count, number of exposed appliances
  8. Question
    Is there a UK alert?
    Stated on the record
    NCSC general edge device guidance of 27 August
    Not stated
    A FortiMail-specific NCSC alert: none found in its feed at 11:34 BST on 3 October

The UK position

Nothing in the sources puts a UK regulator on this flaw, so the UK angle is thin and sourced narrowly. I read the NCSC's all-content feed at 11:34 BST on 3 October. Its newest item is dated 28 September and concerns Citrix NetScaler; there is no FortiMail item. That describes one feed at one moment, not the NCSC's position. The NCSC's 27 August advisory on edge devices, written around operational technology, asks organisations outside operational technology to keep an inventory of internet-facing systems and to monitor for unexpected configuration changes or outbound connections, and asks every organisation to register for its free Early Warning service. An unexpected archive account with a remote destination is exactly that kind of configuration change.

BOD 26-04 and the 4 October date bind only US federal civilian agencies, and CISA says it encourages all organisations to prioritise catalogue entries anyway. For a UK organisation the date is a signal of CISA's confidence, not a deadline. The legal clock that does apply is the ICO's: for certain personal data breaches the UK GDPR expects a report "within 72 hours of becoming aware of the breach, where feasible", according to the ICO guide. A mail gateway handles personal data in transit, so a confirmed compromise is likely to start that clock (my inference).

What to do, in the order worth doing it

Take this with you

UK organisations running FortiMail

  • Find every FortiMail you run, appliance or virtual machine, and write down its exact build. The advisory covers 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8 and 7.2.0 to 7.2.9. For anything older, ask Fortinet in writing, because the advisory is silent.
  • Record whether the IBE service is on and whether the web interface is reachable from the internet, tested from outside your own network and not read from a settings screen. Do this before you change anything.
  • Preserve evidence first: copy the logs and configuration off the appliance and snapshot it if it is a virtual machine. CISA's own triage guidance says to collect evidence before remediating where possible.
  • Apply a workaround today. If you send no secure mail to external recipients, switch the IBE service off. If you do, decide knowingly, because restricting access cuts those recipients off. A firewall rule on the IBE path is the advisory's third option.
  • Do not treat the 7.2 instruction as a fix, and do not move to an affected 7.4 build and mark the risk closed. Watch for 8.0.2, 7.6.7 and 7.4.9, and compare the advisory, the CVE record and your scanner's data when they appear.
  • Hunt for the published indicators: the two addresses in firewall, proxy and mail logs; the seven file paths and their hashes; the event log patterns and the IBE decryption exception; and any archive account you did not create, above all one with a remote destination.
  • Check outbound connections from the appliance to unfamiliar FTP or SFTP servers and any copying or forwarding of mail you did not configure, as far back as your logs go.
  • If anything matches, treat the appliance as compromised: isolate it, keep the evidence, rebuild from known-good media instead of cleaning it, and assume everything it held or could reach is exposed. Fortinet does not say that a workaround or an upgrade removes planted files.
  • Rotate every credential the appliance held or could see: administrator accounts, any directory or API credentials, relay credentials, certificates and private keys, and the credentials of any remote archive destination.
  • Review mail flow end to end: recipient and delivery policies, archive accounts, forwarding, downstream transport rules and the DNS records that route mail to the appliance. Then decide whether a personal data breach has occurred, with the 72 hour ICO clock in mind.

The question that exposes the gap

Every defensive step above assumes you can tell, afterwards, what happened on the appliance. The indicators Fortinet publishes are logs, files and configuration entries on the very machine an unauthenticated writer could reach. The advisory page that listed them has already lost a section without saying so, and the fixes have no date.

So the question is not whether you can apply a workaround this weekend. It is this: if your FortiMail had been entered on Thursday, which record, held somewhere the appliance could not reach, would show it on Monday, and who in your organisation would be looking at it?

Key facts

Sources

  1. PrimaryFortinet advisory FG-IR-26-175, live page read by curl and by a browser on 3 October: affected builds, upcoming fixes, workarounds, indicators, Impact and Virtual Patch fieldsFortinet PSIRTaccessed 2026-10-03
  2. PrimaryEarliest of five archived captures of the Fortinet advisory (1 October 23:55 UTC to 2 October 08:57 UTC), used for the seven-file indicator list, MD5 and SHA-256 values and the earlier workaround wordingInternet Archiveaccessed 2026-10-03
  3. PrimaryCSAF file for the advisory: affected ranges, the not-affected list that includes branch 7.4, release dates and revision historyFortinet PSIRTaccessed 2026-10-03
  4. PrimaryFortinet advisory RSS feed, used for the item reading Revised on 2026-10-01Fortinet PSIRTaccessed 2026-10-03
  5. PrimaryCVE record JSON: reserved and published times, affected block, solutions field, CVSS vector with temporal metrics, CISA-ADP SSVC valuesCVE Program, Fortinet as CNAaccessed 2026-10-03
  6. PrimaryNVD record: description, Fortinet-assigned CVSS 3.1 metric typed secondary, CWE, configuration ranges and the CISA KEV fieldsNIST NVDaccessed 2026-10-03
  7. PrimaryKnown Exploited Vulnerabilities JSON feed, version 2026.10.02: dateAdded, dueDate, requiredAction, forensicTriage, ransomware field, CWEs, and the count of Fortinet entriesCISAaccessed 2026-10-03
  8. PrimaryCISA alert of 1 October 2026 adding CVE-2026-104286 to the KEV catalogue, and its statement that BOD 26-04 applies only to federal agenciesCISAaccessed 2026-10-03
  9. PrimaryBOD 26-04 implementation guidance, used for the forensic triage steps, including collecting evidence before remediatingCISAaccessed 2026-10-03
  10. PrimaryFortiMail 8.0.0 administration guide on IBE: external recipients read secure messages through a link to the FortiMail itselfFortinetaccessed 2026-10-03
  11. PrimaryFortiMail 7.6.3 administration guide on archive accounts: a remote destination is an FTP or SFTP serverFortinetaccessed 2026-10-03
  12. PrimaryNCSC all-content RSS feed read on 3 October: newest item 28 September, no FortiMail itemNCSCaccessed 2026-10-03
  13. PrimaryNCSC advisory of 27 August 2026 on internet-exposed systems and edge devices, used for the inventory, configuration change monitoring and Early Warning adviceNCSCaccessed 2026-10-03
  14. PrimaryICO guide to personal data breaches, used for the 72 hour reporting expectationICOaccessed 2026-10-03
  15. Reported byReport of 1 October with the seven-file hash table, Fortinet's statement and the archive account reading; read with a browser because curl returns 403BleepingComputeraccessed 2026-10-03
  16. Reported byReport of 2 October listing the same seven file paths and the management interface wordingThe Hacker Newsaccessed 2026-10-03
  17. Reported byReport of 2 October whose subhead says some admins are still waiting for patchesThe Registeraccessed 2026-10-03
  18. Reported byReport of 2 October with the watchTowr comment and Fortinet's government statementCybersecurity Diveaccessed 2026-10-03
  19. Reported byAnalysis of 2 October that reads the 7.2 row as a patch routeField Effectaccessed 2026-10-03
  20. Reported byReport of 2 October confirming the upcoming fix versions and what Fortinet did not discloseHelp Net Securityaccessed 2026-10-03
  21. Reported byVendor FAQ published 1 October (a firm that sells exposure validation): fixed versions not yet available, management interface wordingwatchTowraccessed 2026-10-03

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.