Zoom on Windows: accept the fix against both bulletins
A deployment receipt does not complete installation validation. Record the client available to the user and the result that allows the change to be accepted.
Читати португальськоюBy Pentesty
Two records with different version boundaries
ZSB-26023, dated November 10, 2026, covers CVE-2026-108186: improper input validation in Workplace for Windows, CVSS 9.6, from 7.1.0 to before 7.1.8.
ZSB-26024, dated the same day, covers CVE-2026-108187: origin validation in Workplace for Windows, CVSS 8.1, in versions before 7.1.5.
Both describe network-based privilege escalation without attacker authentication, requiring user interaction (AV:N/PR:N/UI:R). Neither specifies the trigger or confirms active exploitation.
7.1.8 is the first common threshold for these ranges, not the verified latest version.
Turn prerequisites into test criteria
For each inventory row, map the installation to the product and range described in the bulletin. Record the vector, published prerequisites and unresolved questions separately. This allows another person to review exposure classification without reconstructing the research and prevents closing one platform using evidence for another.
Define a maintenance test that respects those conditions without inventing an invitation, link or exploit sequence. To verify delivery of the fix, the team should establish which software is in use and whether agreed functions work. Reproducing the vulnerability would be a separate exercise with its own authorization and criteria.
If suspicious activity appears during collection, record what was observed, when it happened and which data supports the hypothesis. Keep that investigation separate from update acceptance. Preserve evidence and refer the decision to the incident owner instead of turning a suspicion into an automatic conclusion.
Make the fixed version reach everyday use
Start by recording the workstation, owner, application path, observed version and collection time. Where installations exist in different locations or accounts, assess each copy separately. A package deployment record establishes one step; acceptance should observe the client available to the user after maintenance.
Select a sample that represents the environment and verify application launch, authentication and participation in an authorized test meeting. Compare the version shown by the application with the inspected executable. If they disagree, keep the workstation open until the installation in use is understood. The same principle of checking the application in use appears in our Chrome update analysis.
Request evidence that explains the exceptions
The responsible team can work with three straightforward deliverables. The first lists installations affected by each CVE. The second connects the update, observed version and functional result. The third records exceptions with an owner, reason, return date and next verification. Keeping them separate makes execution failures visible without confusing them with an absence of exposure.
- Prioritize clients inside the affected ranges and workstations whose owner or version remains unidentified.
- Use the official channel referenced by the bulletins and the organization’s approved distribution process, recording the package origin.
- Collect the version after maintenance and record the functional test outcome; retain error evidence and the result of any retry.
- Reassess exceptions when the vendor updates a bulletin or a new inventory identifies a different installation.
Close the change against a repeatable criterion
Define the evidence required for closure in advance: identified copies, a version outside both affected ranges and a recorded functional check. A workstation with missing information remains pending. If suspicious activity appears, open an investigation and preserve available records; application maintenance and investigation of a potential incident serve distinct purposes.
This gives support and security teams a question they can answer with evidence: which client was accepted, on which workstation, and on what basis? Our Notepad++ privilege boundary analysis complements this approach by checking the application and its execution context.
Frequently asked questions
How should one workstation be compared with two bulletins?
Keep one row per installation and record each comparison result. Where the boundaries differ, the acceptance record should explain why the selected version satisfies both.
How should exploitation prerequisites be recorded?
Transfer the relevant bulletin fields to the assessment record and distinguish published conditions from hypotheses. A test reviewer should be able to identify the source of each assumption.
Does an update close a suspected incident?
Define two outcomes: maintenance acceptance and the investigation conclusion. Each needs its own evidence and owner; a version record alone does not answer what happened before the change.
What evidence should accompany closure?
Record the workstation, installation, version after maintenance and functional outcome. Connect that evidence to both affected ranges and keep exceptions assigned to an owner and deadline.
Sources and references
Original Pentesty analysis, published November 11, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.