Imagine a small scenario: A lunch group chat is discussing whether to add spice to their bento boxes when someone posts a news article: "Our company's email system has a vulnerability." The chat is silent for two seconds, then the most direct question pops up: "Is our system affected?" Someone replies: "I think it was around 7 PM."
Around 7 PM sounds like a dinner meeting time. Given the version range, the answer needs to be more precise: is it 7.6, 7.4, or 7.2? And what is the last number? At this point, put aside your panic and find the complete version number; that's more helpful than posting five exclamation marks in the group chat.
Vulnerability news can easily lead discussions to jump straight to "should we shut it all down?", but there are a few questions that need to be addressed in order. Which product, which device, which version is affected? What settings are currently in use? Who is responsible for confirming this? Only by filling in these gaps can a tense news story be transformed into a task that can be divided and completed.
According to an iThome report on October 3, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-104286 to the Fortinet email security gateway FortiMail on October 1 to its list of known exploitable vulnerabilities. [S1] Organizations using this product will need to translate this alert into specific device verification.
This audit can be divided into three steps: first, confirm the complete version; second, review the functionality and connectivity settings; and finally, decide on the appropriate action. Each step is documented so that subsequent announcements can quickly identify which devices require adjustments. If the same device has different administrators, designate one to compile the results to minimize duplication or omissions.
The complete version number is the first screening step.
The report lists the affected FortiMail versions as follows, including both version numbers: [S1]
- Versions 8.0.0 to 8.0.1
- Versions 7.6.0 to 7.6.6
- 7.4.0 to 7.4.8
- 7.2.0 to 7.2.9
When comparing versions, look at each branch separately, rather than combining four lines into a single continuous range. For example, 7.6.6 falls within the 7.6 branch range listed in the report; knowing only "7.6" is not enough to make a judgment. Version verification should also be done in conjunction with the latest official applicable range to confirm the branch and target version that need to be updated.
You can think of these four lines as designated floors in four buildings. For Building A, check the first and second floors; for Building B, check floors one through seven. Don't assume that because "seven" is a large number, all rooms below the seventh floor are considered part of the same area. The branches of the edition number and the last segment of numbers should be read together.
This analogy also helps to uncover a common misunderstanding: the difference in the last number doesn't mean it can be compared directly without considering the first two. Within the range listed in the report, the upper limit of the 7.6 branch differs from the upper limit of the 7.4 branch. [S1] The easiest way is to first find the line containing the same branch, then compare it to the complete version; don't let your eyes play a matching game among the four strings of numbers.
In practice, maintenance personnel can be asked to record the equipment name, product name, full version, and verification time. If there are multiple devices or backup machines, each one should be checked individually to avoid only looking at one. If the asset list only lists the version at the time of purchase, it is worth re-verifying; the actual operating status should be recorded during inventory checks to facilitate subsequent changes.
Mini-drama: The same phrase "有中" might be asking two different questions.
Suppose the group then displays this conversation:
"Found it, this one is version 7.6.6, so is there a chance it will be successful?"
"It falls within the affected area listed in the report."
"So it's been hacked?"
"Let's look at them separately. If the version matches the criteria, it needs to be addressed; if it has been compromised, we also need to check the relevant records."
The most confusing part here is that everyone uses the phrase "youzhong" (有中), but they're referring to different things. Some ask if the version is within the affected range, while others ask if the device has been compromised. Mixing these two questions together can make the person trying to confirm the status increasingly anxious, and might even mislead the person in charge into believing they've obtained evidence of an intrusion.
You could try making your group reply more specific: "The complete version has been confirmed and falls within the scope of the report; next, administrators will check the official guidelines and further verify for any anomalies." This is a hypothetical example of a response. By separating the known status from the next step, it's easier for everyone to know who should take over, and you don't have to rely on guesswork to interpret a vague "processing."
After the version is matched, what should be checked next?
According to the report, the vulnerability was caused by improper restrictions on restricted directories for specific path names, which could allow unauthenticated attackers to write arbitrary files to the underlying system through specially crafted requests. [S1] In simpler terms, the system should have restricted where files could be written, but there was a problem where the restrictions could be bypassed.
This also explains why simply answering "We have a password" is insufficient. The attack conditions described in the report do not require prior authentication. [S1] Administrators also need to verify whether the relevant interface can be accessed from the Internet and the current functional settings of the device. Version, settings, and connection methods must be considered together to discuss applicable solutions.
If the version falls within the scope, it indicates that further action is required; it does not prove that the device has been compromised. Version confirmation and anomaly investigation should be recorded separately: the former is used to arrange patching and mitigation, while the latter needs to be checked against device records and applicable guidelines. If anomalies are found, they should be handed over to cybersecurity personnel for further interpretation to avoid simply making configuration changes and closing the case.
Fun fact about tools: The same product can have several version lines.
The report lists the affected versions, including versions 8.0, 7.6, 7.4, and 7.2. [S1] An easily overlooked point is that simply knowing the product name or hearing "it's already the eighth version" doesn't provide a sufficiently precise unit of comparison. The complete version is the coordinate this list is looking for.
When reading the warning, you can use a highlighter to draw two lines: the first circle the product, and the second circle the version. The product must match, and the version number must also match. If the device name is just a code name given by the office, such as "Email Machine No. 1," it still needs to correspond to the actual product and version. Don't let a cute nickname replace the device's identity.
Another easily overlooked detail is the provisional recommendation mentioned in the report regarding Internet access to the IBE function and management interface. [S1] At this point, the question has expanded from "which version is installed" to "how it is currently used and which access points are open." This also explains why it's best to leave a column in the inventory sheet to set the verification status, so that version confirmation and subsequent actions can be linked.
Temporary mitigation should be assessed together with the service impact.
The report quoted Fortinet's advice at the time: before the patch is released, the IBE (Identification Encryption) function can be disabled, or internet access to the FortiMail management interface can be turned off. [S1] When planning the action, the latest official guidelines and patch status should be checked before deciding on temporary measures and update arrangements.
Before taking any action, identify who is using the relevant functions, which email processes may be affected, and how maintenance personnel will manage the equipment afterwards. Before disabling IBE, assess whether the operations of legitimate users will be affected; restricting external access also requires confirming that the retained management paths comply with organizational requirements.
A more prudent approach is to have management personnel verify the latest official guidelines, assess the service impact, arrange change and response methods, and then verify whether the settings have truly taken effect. The responsible person, the change time, and the verification results should also be recorded so that the next shift of maintenance personnel knows what measures have been taken and what tasks still need to be completed.
If we use a building as an analogy, temporarily restricting an entrance is like adjusting the traffic flow; subsequent repairs are another task that needs to be confirmed and completed. After adjusting the traffic flow, it's also necessary to know where normal users go, how management personnel enter and exit, and when to re-inspect. This analogy helps to organize the handling process; the actual approach is still determined by the person in charge based on official guidelines and on-site needs.
The worst possible ending is "The button is off, it should be fine now." A more complete handover report would include: whether the change is complete, the verification results, whether it affected normal operations, and who will be responsible for tracking updates next. These sentences don't use fancy jargon, but they significantly reduce the guesswork involved in the handover process.
Common misunderstanding: A few easy phrases are followed by an extra question.
"My password is very strong, so I shouldn't be worried, right?" This question comes back to the attack conditions. According to the report, this vulnerability involves unauthenticated attackers. [S1] Therefore, verifying password strength cannot replace version and configuration checks. Different protection measures answer different questions; don't think you've completed the entire checklist just because you checked one item.
"Emails are still being received normally, so it should be fine?" Whether a service is usable and whether a vulnerability needs to be addressed must be judged separately. Just like the lights in a room are still on, you can't decide which door lock needs repair based solely on that. After addressing the issue, it's essential to confirm normal email operations, but the fact that the service is functioning normally cannot replace necessary equipment checks.
"The list only has four lines; does reviewing one device represent all of them?" If an organization has multiple devices, each one needs to be checked individually. Devices may be managed by different people or have undergone changes at different times; inventory should be based on the actual condition of each device. There's no need to assume any particular device is inherently more dangerous; just avoid copying and pasting the answer from one device onto all devices.
"If there's a temporary measure, can we just remove it from the to-do list?" A better approach is to change the status to specific text, such as "Temporary action completed, pending confirmation of follow-up repair arrangements." Adding a few more words to the status bar lets people who come back a week later know where things are progressing, reducing the number of conversations like, "Hey, didn't we handle this last time?"
Weekend mini-practice: Using only pen and paper, understand the four lines of the edition number.
To practice checking version ranges, you can create a hypothetical list without logging into the device or scanning or adjusting any settings. Write down four hypothetical machines on a piece of paper: A is FortiMail 7.6.6, B is FortiMail 7.4.8, C is only written as FortiMail 7.2, and D is only named "Email Backup Machine".
The first round only involves data comparison. A and B can be compared to the complete range listed in the report; C is missing the last paragraph, and D hasn't even clearly stated the product and version number. Labeling C and D as "Data to be supplemented" will be more helpful for subsequent work than guessing an answer from memory. [S1]
The second round adds three columns: "Version Confirmed," "Setting Verification," and "Processing Status." Practice writing "Version Confirmed, the next two columns pending verification" for column A. Don't color the entire column green just because there's an answer in the first column. Finally, add a column for the person in charge, filling in fictitious groups A and B, so that each pending item has a next step.
The takeaway from this little exercise is simple: understand a version control table and learn to retain unfinished cells. When encountering real warnings, sharing this classification method with authorized administrators will allow for clearer questioning. This paper exercise is sufficient; verification and changes in the production environment should be handled by existing maintenance processes.
If you want to play around with this again, you can add three date sticky notes to this fictitious list. The first note should be the date the news was released, the second the date the device version was confirmed, and the third the scheduled return date to check the progress. Posting them separately makes it less likely that "I've seen the news" will be mistaken for "the device has been processed."
Now suppose someone takes over in a few days, but they're not in the original group and haven't seen the first twenty messages. Give them the list and ask if they can answer within half a minute: which fields are confirmed, which are still waiting for information, and who to contact. If they can answer, it means this record truly has a handover function and isn't only meaningful to the person who created it.
Finally, a quick summary: circle the words "probably," "should," and "I remember," and see if you can add a verification action after them. For example, change "I remember it was the 7 o'clock version" to "Pending confirmation of the complete version by administrators." Don't rush to write down uncertain parts with absolute certainty; just clearly stating the next step will move the list forward one step.
What information requires a reassessment?
The most useful new information going forward is the officially confirmed applicable and patched versions, necessary configuration requirements, and information to help identify anomalies. If a patch has already been provided, the update schedule should be reassessed; if the announcement adds details about the affected conditions, the original list of devices may also need to be adjusted.
As for "Is it all resolved?", it can be broken down into several verifiable questions: Have all devices been inventoried? Are the temporary measures effective? Is the service still usable? Are there any applicable patches available and verified through official methods? Recording each question will prevent mistaking "I have read the warning" for the risk being eliminated.
Postscript: Let the group have less guessing and more readily available answers.
Returning to the lunchbox group at the beginning, the most reassuring response would probably be that the equipment has been confirmed, someone is in charge of handling it, and it's clear which projects are still ongoing. People don't need to guess the license number while simultaneously trying to figure out the basis for the statement "it should be fine."
The numbers in cybersecurity information might seem a bit dry, but breaking them down into smaller issues like product, version, settings, and handling makes them easier to understand. When you encounter an alert, ask a precise question first, then leave a traceable answer. Knowing someone can handle the situation makes things much easier to accept.
source
- [S1] CISA has warned that the FortiMail vulnerability CVE-2026-104286 has been exploited. | iThome | Published: 2026-10-03 | Retrieved: 2026-10-04T00:01:46.436960+00:00