For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it. 

In V12, default settings are changing, GitHub said in its changelog, noting, “it turns an npm install behavior that runs automatically today into one you explicitly opt into.” 

Specifically, the post said, “allowScripts defaults to off: npm install will no longer execute preinstall, install or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds; a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. Prepare scripts from git, file, and link dependencies are blocked the same way.”

Analysts, consultants, and users generally applauded the change, but said that it would only narrow the exposure to supply chain attacks instead of eliminating it. 

Attacks likely to move elsewhere

Sonu Kapoor, maintainer for CVE Lite CLI in the OWASP Incubator Project, said that this change is likely to force the supply chain attacks that leveraged the automatic execution to move elsewhere.

“This does not eliminate npm supply chain risk, it removes a major automatic execution path,” Kapoor said. “Attackers can still move to other paths: malicious package code that runs at application runtime, compromised maintainer accounts, dependency confusion, typo-squatting, poisoned GitHub Actions workflows, malicious transitive dependencies, or stolen publishing tokens. This closes one very dangerous door, but it does not secure the whole house.”

Still, attacks leveraging the setting have been regularly used in supply chain attacks. 

However Alan Parkinson, director of secure medical device firm Threat Detective, said more sophisticated attackers have already moved beyond this hole. 

“The install script attack vector has been known for years,” Parkinson said. “Most security teams marked it as low risk and moved on to higher risk threats. What raised its profile wasn’t the technical exploitability changing, it was a run of high-profile victims and some threat actors openly chasing notoriety.”

He added, “the pre and post install scripts was never a clever attack vector to begin with. Running code from an install hook is crude and noisy, which is why it caused such visible damage. The more capable actors are already moving to other methods, so v12 mainly shuts the door on less sophisticated threat actors.”

Although GitHub declined an interview, Zach Steindler, a GitHub principal engineer, answered InfoWorld’s questions by email. He said the volume and pace of supply chain attacks forced the default settings change. 

“We’ve seen attackers target these capabilities to quickly propagate attacks from one compromised package to many. Years of security and usability research have shown that it’s not enough to make secure functionality available; the secure path has to be the default in order for it to be widely adopted,” Steindler said.

He added, “we believe that these changes are a great way to provide high impact secure defaults while still providing the option for some users to fall back on functionality they might need in some circumstances.”

Change overdue

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that GitHub was the last of the repositories to make the setting default change. “Rivals moved first: Yarn, pnpm and Bun all block third party install scripts by default in their own ways,” Gogia said. “Npm is not inventing a new doctrine. It is finally adopting one.”

Steindler didn’t dispute Gogia’s comment. 

“It’s not easy being the stewards of the largest package repository in the world. Community consensus on what security capabilities should be standard, and when it’s okay to make breaking changes shifts over time. From our continual conversations with the community, it was clear it was time to make this change,” Steindler said.

“The recent attacks are alarming,” he noted, “but stewarding these package repositories is a multi-decade effort, not just a moment in time. As attacks evolve, so will our defensive security capabilities. We’re in this for the long haul.”

Gogia said that the change, although overdue, is a good one. 

“Npm is removing one of the most comfortable hiding places for software supply chain risk: code that executes the moment a developer types install,” Gogia said. “With npm v12, execution becomes something that must be approved, recorded in the project, and committed for review. That is not a design adjustment. It is a change in control philosophy.”

Bad defaults become infrastructure

Gogia had his own take on why GitHub waited so long.

“Npm waited because its risky default acquired a constituency. As far back as 2016, npm’s own position was that the convenience of install scripts outweighed the worm risk, with an opt-out flag for the cautious. The trade-off was a documented product decision, not an oversight,” he said.

“The trouble with bad defaults is that they become infrastructure,” he added. “Native module builds, browser installers such as Playwright and Cypress, Electron download flows and Husky hooks all grew around automatic execution. Turning it off became less a technical adjustment and more a constitutional reform.”

Liability changed hands

The real pressure for the change, however, came from regulators.

“The deeper answer is that the liability changed hands. Once regulation such as the EU Cyber Resilience Act and securities disclosure rules placed supply chain failure on corporate balance sheets, a documented unsafe default became indefensible,” Gogia said. 

Kapoor agreed that long-used procedures enabled this security hole to survive longer than it should have. 

“The reason this likely was not done long ago is compatibility,” he said. “Install scripts are not only used by attackers. Many legitimate packages use them to compile native modules, download platform-specific binaries, generate files, or complete setup steps. Changing the default breaks assumptions that have existed in the npm ecosystem for years. That is why these security changes often arrive slowly. The safer default is obvious from a security perspective, but painful from an ecosystem compatibility perspective.”

In addition, he noted, “the bigger point is that package managers are moving from implicit trust to explicit trust. That is the right direction. Developers should have to approve which dependencies are allowed to execute code during install. But approval cannot become a blind checkbox. Teams need visibility into which package wants to run a script, whether it is direct or transitive, why it is there, and whether it belongs in the project at all.”

Kapoor added that this change matters because install-time execution often happens in privileged environments with access to tokens, secrets, internal registries, build artifacts, or deployment paths. “Even if the script does not compromise production directly, it may be able to steal enough context to support the next stage of an attack,” he said.

Value in the pain

Cybersecurity consultant Brian Levine, executive director of FormerGov, agreed that the closing of this security hole is a very good thing. 

“It seems like virtually every major supply chain attack of the last decade has had the same original sin: code that ran automatically because the ecosystem let it. Npm finally closing that door by default is overdue, but it’s genuinely significant. This is the package manager for hundreds of billions of downloads a month,” Levine said.

“When npm changes its defaults, it changes the security posture of practically every enterprise dev environment on the planet. It may have been the last large code repository to still allow this kind of automated execution.”

Levine added that this change might not merely stop a security hole, but the new process may meaningfully improve security. 

“There’s actually something valuable buried in this migration pain. Having developers explicitly approve which packages can run code and commit that list to source control is a form of software supply chain governance that many organizations never had,” Levine said. “It creates an auditable record which is meaningful, especially for regulated industries.”

A widely used JavaScript implementation of Google’s Protocol Buffers format is placing too much trust in untrusted data, exposing affected applications to remote code execution and other attacks.

Researchers at Cyera have disclosed six vulnerabilities affecting “protobuf.js,” all stemming from the library’s handling of schema and metadata. Attackers could exploit an input validation oversight to insert malicious data and influence an application’s behavior.

Protocol Buffers is a technology for packaging data in a compact, structured format to streamline the exchange of information between different applications. The protobuf.js library reportedly receives more than 50 million weekly downloads. It is commonly pulled into applications indirectly through dependencies such as gRPC tooling, Google Cloud libraries, and other frameworks, making it difficult for organizations to track.

Researchers disclosed six CVEs covering remote code execution, denial-of-service (DoS) conditions, prototype pollution, prototype injection, and code-generation issues.

“While exploitation of these vulnerabilities generally requires specific conditions, those conditions are increasingly common in data and AI ecosystems that routinely exchange data, schemas, and configuration files across services, repositories, cloud platforms, and third-party integrations,” Cyera researchers Assaf Morag and Vladimir Tokarev said in a blog post.

Patches are available for both protobuf.js and protonufjs-cli, the project’s command-line code generation tools.

Metadata capable of writing code

The most significant of the bugs is a code-generation flaw tracked as CVE-2026-44291.

According to Cyera, protobuf.js dynamically generates encoder and decoder functions and compiles them using JavaScript’s Function () constructor. Under specific conditions, an attacker can manipulate schema-derived information so that data intended to describe a message instead becomes executable code.

The researchers demonstrated an attack chain in which prototype pollution is used to trick protobuf.js into accepting attacker-controlled values as legitimate protobuf types. Those values are then incorporated into the generated code and executed within the Node.js process.

The impact extends beyond runtime applications. A separate code-injection issue, tracked as CVE-2026-44295, affects the pbjs command-line tool, where crafted schema names can be embedded into generated JavaScript files and executed when those files are later imported.

While successful exploitation requires specific preconditions, such as the ability to influence protobuf schemas or descriptors, researchers noted that modern software increasingly exchanges schemas, descriptors, and configuration files across repositories, cloud environments, APIs, and third-party integrations, making those assumptions less restrictive than they once were.

The remaining vulnerabilities are less severe. Researchers identified a prototype injection (CVE-2026-44292) flaw that can alter application behavior by tampering with inherited object properties, as well as denial-of-services (DoS) bugs (CVE-2026-44289, CVE-2026-44290, and CVE-2026-44294) that can crash or exhaust application resources using maliciously crafted inputs.

Patching advised as supply chain risk looms

The researchers noted that protobuf.js is often consumed as a transitive dependency, meaning organizations may be exposed without realizing the library is present in their software stack. As schemas move through automated development pipelines and software supply chains, components traditionally viewed as passive data can become a pathway for attacks.

“Development teams routinely accept code contributions, integrate third-party components, and automatically process files through CI/CD pipelines,” they explained. “We found that under certain conditions, a malicious protobuf schema could be introduced into this workflow and ultimately executed within trusted build environments.”

A compromise at this stage could have downstream impacts on products, customers, and business operations, they added.

The vulnerabilities affect protobuf.js versions 7.5.5 and earlier, along with versions 8.0.0 and 8.0.1, as well as vulnerable releases of protobuf.js-cli. Patches are available in protobuf.js 7.5.6 and 8.0.2, while protobuf.js-cli users are advised to upgrade to versions 1.2.1 or 2.0.2.

The article originally appeared on CSO.

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher.

The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds.

First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL.

Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.”

Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.”

For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces.

The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog.

“The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote.

The exploit

Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token.

This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.”

In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.”

This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.”

This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian.

Short notice

Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands.

[Related content: When responsible disclosure becomes unpaid labor]

An ethical question

Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it?

These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch.

For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident.

An imbalance of power

Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.”

The spokesperson added that the issue Askar reported “has been mitigated for our services and no customer action is required.”

[Related content: Is the vulnerability disclosure process glitched?]

There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.”

However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.”

This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.”