A company can install the latest available software and still face a dangerous interval: a security fix is visible to attackers before the supplier has delivered it as an update. Faster patching inside the company does not remove that earlier gap.
AI makes this supplier-side interval more dangerous. For Norwegian businesses, the buying decision must therefore include how a software provider turns a discovered weakness into protection on customers' systems. A promise to find more bugs is incomplete without a credible route for shipping the fixes safely.
What the new Firefox research shows
On 29 October 2026, Epoch AI reported that GLM 5.3 built file-stealing webpages against six Firefox releases in offline Ubuntu 26.04 tests. A browser visit was sufficient. The model combined public fixes with a separate unpublished flaw. Researchers supplied resources and target versions. This was not an observed attack campaign. They achieved no equivalent Chrome result and had not established whether attacks succeed on Firefox 159.0. They report the unpublished flaw fixed in 159.0.
Mozilla released Firefox 159.0 on 27 October. Its security advisory lists the corrected vulnerabilities. Check the supplier's current advisory for your product, platform and release channel, including any supported enterprise version. Do not assume a version number for one channel identifies the right update for every installation.
The study strengthens the case for acting on available updates. It also exposes a limitation in the reassuring phrase “we are fully updated”: that describes the customer's installation, not everything a supplier has discovered or is preparing to release.
Two intervals, two different owners
There are two delays to examine. First, a fix becomes visible before it is available as a supported update. Second, an available update waits to be installed and activated at the customer. Google's Chrome security team described both release and restart delays in July.
The supplier controls its development and release process. Management controls the company's rollout arrangements and the agreement with its IT provider. An outsourced provider may be responsible for installation without controlling when the software manufacturer makes a correction available.
Do not merge these responsibilities into one service-level promise. A ticket answered quickly does not establish when a supported update will arrive. Equally, a supplier's rapid release is of little benefit to a machine that remains on the previous version.
Ask for an example of a completed security update through the relevant product and customer channel. Which stages does the manufacturer control, which does the operating provider control, and where does the company need to act? The purpose is to find an accountable handover, not to demand that a small Norwegian IT provider guarantee another company's engineering timetable.
Mozilla is changing how fixes are released
In its 29 October response, Mozilla describes weekly releases and withholding regression tests until fixes ship. It also plans to separate when fixes for different security layers become exposed, so attackers cannot obtain every ingredient of an attack chain from overlapping release gaps. Implementation will take coordination. This is a planned engineering response, not a guarantee that the risk has disappeared.
The principle is useful beyond the technical details: protection should not depend on every barrier remaining perfect at the same time. A well-designed system makes one failure insufficient for a serious compromise. Maintaining that independence through a release matters as well as designing it into the product.
Think of repairing one of two protective doors while the other remains closed. That is an illustration of the principle, not a literal model of browser security. The software supplier must demonstrate which barriers apply and how they remain useful while changes are delivered.
This is work for the supplier's engineers. It is not a reason for customers to postpone available updates or choose their own sequence of individual fixes.
Ask for evidence, rather than a claim that AI makes the product secure
For important software, put three questions into the next supplier review:
- How do you reduce the interval before a supported fix reaches our release channel? Ask how security work passes testing and how urgent corrections reach supported versions. The supplier need not disclose exploitable details to answer a process question.
- What limits the damage if one protection fails? Ask which separate boundary protects important data or administrative functions, and what testing supports the answer. A second feature is not necessarily an independent barrier.
- How will we know our update is active? Agree what the operating provider reports about installed versions, required restarts, failed installations and exceptions outside its normal scope.
These are proposed procurement questions, not a certification scheme or a new legal requirement. Make the depth proportionate. A small AS can start with the browser and one critical business application through its existing provider. A company buying a custom platform should examine the developer's release process and dependencies more closely.
An honest limitation is useful evidence. A provider may explain that it cannot measure a particular upstream interval, while demonstrating a reliable customer rollout. Record both. A general assurance that “we use the strongest AI” answers neither question.
A Norwegian example: the update is ready, the restart is not
Consider a hypothetical Norwegian engineering consultancy. Employees use browser-based customer portals and a specialist estimating tool. The external IT provider reports that updates download automatically, but staff routinely keep browser sessions open for days to avoid interrupting unfinished work.
Management should ask the provider to demonstrate that the corrected version is running, rather than accept download completion as the result. Agree a restart routine with employees, test the important customer workflow and follow up machines that are offline or excluded. Plan around actual work so people can save what they need and resume it safely.
NSM recommends fast, centrally managed and largely automatic security updates, particularly for operating systems and software handling external content, including browsers. Reliable routine updating remains the foundation.
For the specialist tool, the operating provider should identify who supplies security corrections, which version is supported and how urgent updates are tested without waiting for a long general change project. If a supported fix is unavailable, use the separate guide to response before a patch exists to prepare proportionate containment and continuity decisions.
The example separates work the company can verify from a manufacturer-side dependency. Management needs visibility into both.
What the board should ask management to bring back
Where software dependence is material, the board should ask management to identify a small number of important products, the providers responsible for corrections and rollout, and the evidence supporting their arrangements. Management should explain unresolved dependencies and the resources needed to improve them. The board should challenge the exposure and priorities, without choosing release branches or scheduling restarts.
AI is also a reason to invest in defensive engineering. Buyers should welcome suppliers that find weaknesses and explain how fixes reach customers. Rejecting a product merely because it discloses more corrected bugs rewards silence over useful work. Judge the handling, the remaining exposure and the evidence, rather than the count alone.
Use the board cyber-reporting guide to make that distinction visible. The next useful question is: Which part of the journey from a security finding to protection on our systems is still an assumption, and who will verify it?
Sources checked on 31 October 2026. The consultancy and door analogy are hypothetical. Supplier questions and management recommendations are the author's analysis. The cited research does not establish widespread compromise, a universal attack deadline or that any browser is permanently secure. The illustration is AI-generated.