Once you have set up your vulnerability monitoring process, one of the steps following the subscription to news feeds is vulnerability triage.

This process is essential for making the information useful from an operational standpoint.

Let’s take CVE-2026-28858 as an example:

Without further context, it is very difficult to determine what the actual business risks are just by reading this summary.

Properly assessing a vulnerability requires several steps:

• Understanding its intrinsic characteristics—that is, what the vulnerability entails from a technical standpoint;
• Determining the environment in which the vulnerability occurs;
• Assessing the risk of exploitation of this vulnerability in light of its characteristics and the environment in which it occurs.

Technically, what is a vulnerability?

Let's start by defining a vulnerability. According to NIST (National Institute of Standards and Technology):

An error, flaw, or mistake in computer software that permits or causes an unintended behavior to occur. CVE is a common means of enumerating vulnerabilities.

A vulnerability is, therefore, primarily an error in software that causes unexpected behavior.

Let’s first find out which software is affected.

In the case of CVE-2026-28858, we quickly identify that the publisher of the vulnerable software is Apple and the software is the firmware present on iPhones and iPads with a version number prior to or equal to version 26.4.

This error can impact the system running the software, particularly in the context of malicious exploitation. It is generally assumed that a malicious actor will have motives that could harm one of the following:

• Confidentiality: the ability to control which information is disclosed and which is not
• Integrity: the assurance that the information held by the information system accurately reflects what it is intended to represent
• Availability: the assurance that the information storage and processing functions are operational
• Auditability: the ability to verify how information has been stored and used

The assessment of a vulnerability primarily incorporates the first three checkpoints, and this is precisely what is reflected in the well-known CVSS (Common Vulnerability Scoring System) score.

The assessment of the impact a vulnerability may have on these factors is generally performed by the vulnerability’s author. However, there may be situations where this context is not directly provided and where third parties perform the assessment instead.

In the case of our CVE-2026-28858, we do have an assessment that was performed by a third party. You can find it in the ADP section (for Authorized Data Provider, a third party participating in the CVE program that has the ability to add additional information to the reference database).

This assessment is based on the information inherent to the vulnerability. Generally, these are detailed in the description (in our case, we indicate a “buffer overflow,” a vulnerability category related to memory mismanagement). However, it may be necessary to consider them in context: the affected portion of the code, the execution context, additional classification information, the nature of the affected software, etc.

This step is the tedious one because, without expertise or additional context, it is not always easy to determine in practice what characteristics result from it. It is also important not to place blind trust in the information. The author of the vulnerability report is often the publisher, who may be opposed to certain forms of transparency.

As mentioned earlier, an ADP has added additional information for us:

• SSVC (Stakeholder-Specific Vulnerability Categorization), a vulnerability decision-making system. It indicates that no active exploitation has been reported, that the vulnerability can be exploited automatically by a threat actor, and that the final technical impact is severe
• The CWE (Common Weakness Enumeration) is a vulnerability categorization mechanism
• The base CVSS score, here 9.8 (critical)

In this case, this information is provided by CISA (the U.S. Cybersecurity and Infrastructure Security Agency).

Let’s take a moment to look at the CVSS score:

Alarming at first glance, isn't it?

The score is 9.8 out of 10, which is classified as critical. The vector provides information on the metrics used in the calculation—that is, the factors we mentioned earlier.

We won’t go into the details of the calculation in this article, but we will determine whether, in our context, this vulnerability is actually significant for us (or not).

Understanding the context of the vulnerability

As we have seen, this vulnerability affects the iOS and iPadOS operating systems, which are responsible for the proper functioning of iPhones and iPads.

By examining the CVSS vector (with an expert eye, though the First calculator can help identify these elements), we can see:

• The attack vector is the network: this indicates that this vulnerability is exploitable remotely.
• The complexity, required privileges, and lack of user interaction lower the barriers to exploitation.
• Exploiting the vulnerability does not directly grant access to a domain outside the targeted phone.
• The impacts on confidentiality, integrity, and availability are high.

Even with this information in hand, decision-making is still based on vague factors at this stage.

As noted earlier, CISA indicates that there are no known exploits for the vulnerability. We would therefore like to take this into account in the remainder of our analysis, along with other temporal factors:

• Is the vulnerability being actively exploited? Is there any publicly known exploit code? What are the circumstances of the discovery: an internal audit or a report of a zero-day exploit (a vulnerability exploited before the vendor is aware of it)?
• Do we have options to mitigate the risk or apply a patch?
• Is the information we have reliable?

Asking these questions means acknowledging the reality and severity of the threat posed by adversaries. This is a crucial step in the decision-making process.

So far, we have information that can be considered reasonably reliable: Apple has a good track record of transparency regarding its vulnerabilities, and CISA takes an independent approach to vendors while serving as a reference source.

We can therefore take it a step further and consult the vendor’s advisory referenced for the vulnerability to get a more complete picture.

Apple lists a set of vulnerabilities fixed in their March 24, 2026, security update cycle.

We find our CVE in the section dedicated to telephony and learn that a fix is indeed available, as Apple details the measures they have implemented to address the vulnerability. Through the credited individuals, we also learn that the vulnerability was reported by an embedded technology security lab at the Korea Advanced Institute of Science and Technology (KAIST).

This information suggests that the vulnerability was discovered in an academic setting and, as such, has likely not been exploited previously.

When searching for our vulnerability's ID number, the results do not indicate any known exploits or potential exploit code. When consulting the entry in the EPSS (Exploit Prediction Scoring System), we find a score of 0.00049 (as of the date of this article). This indicates that the probability of this vulnerability being exploited in the next 30 days is estimated at 0.049%. This is very low.

In our CVSS calculator, we can therefore enter the results of our findings:

• There is no public exploit code.
• The vulnerability was reported by an academic institution, not by incident response teams.
• There are no reports of active exploitation.
• A patch is available.
• The body of evidence gives us a high level of confidence.

The score is still high, but we’ve deducted a point to account for the actual severity of the threat. If our prioritization were based solely on this score, we would still move from the “Critical” category to the “High” category.

Now let’s determine how an exploit would affect us.

Exploitation environment

The vulnerability affects a system located in a specific environment. In our case, we assume this refers to our fleet of iPhones deployed to provide telephony tools to our sales team.

As a matter of policy, and because we have data control mechanisms in place, we know that these phones do not contain any trade secrets belonging to our organization. Similarly, these phones are connected to a restricted office network that is separate from more critical networks (production, engineering). They also operate in a restricted mode that limits the devices’ ability to connect to unknown networks.

However, our sales representatives interact with buyers from client companies who have a significant need for responsiveness. They may also need to discuss sensitive contracts currently being signed. We consider this information to be moderately sensitive.

To determine whether we should prioritize applying this patch, we must therefore assess the environmental component of the CVSS score and take these factors into account.

We are therefore updating the CVSS score with our new metrics:

Taking all contextual factors into account, our CVSS score is now set at 6.8 out of 10. This represents a medium severity level, even though we initially assessed the vulnerability as critical.

Conclusion

We have assessed a vulnerability in isolation. As you have likely noticed, it is not the only one included in the update released by Apple on March 24, 2026.

We should therefore repeat this process as many times as there are vulnerabilities reported in this bulletin, and only for the iPhone fleet. There are no actively exploited vulnerabilities in this update, and it seems sensible to apply the patches based on our standard procedure. There is therefore no need to call in the on-call team.

However, in February, an actively exploited vulnerability (CVE-2026-20700, if you’d like to try the exercise again) might have warranted swift action.

VulnPilot, our vulnerability intelligence tool, collects, aggregates, and performs this analysis for you for each vulnerability that could affect your IT infrastructure. The result is a priority score that takes into account all the factors we’ve discussed in this article today:

What’s more, these vulnerabilities are automatically grouped into action plans. These plans provide even greater clarity by offering a series of actions that allow you to address multiple vulnerabilities without having to analyze them individually.