How 2 Palo Alto CVEs Scored Low But Ruined 13,000 Devices

Imagine a security team staring at a dashboard of glowing red alerts, only to dismiss several of them because the numerical severity scores look manageable. They follow the protocol, prioritizing the high-score threats while pushing the medium-score items to a later maintenance window. Suddenly, the network is compromised. This is not a hypothetical nightmare; it is the exact scenario that unfolded during Operation Lunar Peek in November 2024. In this massive breach, attackers successfully gained unauthenticated remote administrative access and eventually root control over more than 13,000 Palo Alto Networks management interfaces. The tragedy of this event lies in the math: two specific palo alto vulnerabilities were treated as isolated, manageable risks, when in reality, they functioned as a single, devastating key to the kingdom.

palo alto vulnerabilities

The Mathematical Illusion of Security Scores

In the world of cybersecurity, we rely heavily on the Common Vulnerability Scoring System, or CVSS, to tell us what to fix first. It is a standardized way to assign a number to a flaw, theoretically helping organizations allocate their limited time and resources. However, the Palo Alto incident exposed a fundamental flaw in this logic. When looking at the two primary vulnerabilities involved, the numbers provided different answers depending on which version of the scoring system was applied.

For CVE-2024-0012, the CVSS v4.0 score sat at a 9.3, while the older CVSS v3.1 version rated it at a 9.8. Meanwhile, the second flaw, CVE-2024-9474, received a 6.9 under the v4.0 standard and a 7.2 under v3.1. To a distracted administrator, a 6.9 looks like a “medium” priority item. It does not scream “emergency.” It does not trigger the immediate, all-hands-on-deck response that a 9.8 might. The problem is that these scores are calculated in a vacuum. They describe the characteristics of a single hole in the fence, but they fail to describe what happens when an intruder uses two holes to walk straight through the front door.

The discrepancy between scoring versions alone creates a fog of war. If one department uses v4.0 and another uses v3.1, they are literally speaking different languages. This lack of consensus means that the perceived risk of palo alto vulnerabilities can fluctuate wildly based on which spreadsheet a manager happens to be reading. This isn’t just a technical nuance; it is a systemic failure that allows attackers to operate in the gaps between different scoring methodologies.

The Failure of Isolated Triage

The core issue is that CVSS was designed to score individual vulnerabilities, not attack chains. An adversary does not view a network as a collection of separate CVEs; they view it as a series of steps toward an objective. When a security team looks at a dashboard, they often see a list of independent line items. They see a “high” and a “medium.” They prioritize the high and queue the medium for next week. This approach treats cybersecurity like a grocery list rather than a chess match.

In the case of the Palo Alto breach, the triage logic consumed the scores as isolated events. The Service Level Agreement (SLA) dashboards and the high-level reports sent to the board reflected this isolation. If a vulnerability is scored as a 6.9, it might fall below the threshold for an immediate emergency patch. But when that 6.9 is the final step in a chain that begins with a 9.3, the “medium” vulnerability effectively inherits the “critical” status of the first. The math fails to account for the compound interest of digital destruction.

Security leaders are beginning to realize that relying solely on base scores is a dangerous gamble. Peter Chronis, a veteran security leader with experience at major Fortune 100 companies, found success by moving away from CVSS-first prioritization. By shifting the focus toward how vulnerabilities actually interact and their real-world impact, he was able to reduce actionable critical and high-risk vulnerabilities by a staggering 90%. The lesson is clear: the score is a starting point, not a destination.

Five Triage Failure Classes CVSS Cannot Catch

To understand why organizations keep falling victim to these breaches, we must examine the specific ways in which traditional scoring models fail to represent reality. There are five distinct categories where the current methodology leaves the door wide open for sophisticated actors.

1. Chained CVEs That Look Safe Until They Aren’t

The Operation Lunar Peek event is the perfect case study for this failure class. The two vulnerabilities functioned as a two-stage rocket. The first, CVE-2024-0012, was an authentication bypass. This allowed an attacker to slip past the initial security checks. The second, CVE-2024-9474, was a privilege escalation flaw. On its own, the second flaw appeared to require administrative access to exploit. If an attacker couldn’t log in, they couldn’t use the escalation flaw, making it look like a low-priority “medium” risk.

However, the authentication bypass upstream completely eliminated the prerequisite for the escalation. The attacker used the first flaw to get in, and the second to become the “root” user with total control. Because the scores were calculated separately, neither one communicated the cumulative effect. The “medium” flaw became a “critical” weapon the moment it was paired with its partner. This is the essence of the “chaining” tactic: using a series of seemingly minor gaps to create a massive breach.

2. Nation-State Adversaries Who Weaponize Patches Within Days

The speed of modern exploitation has outpaced the speed of traditional patch management. We no longer live in an era where “Patch Tuesday” provides a comfortable window of safety. According to the CrowdStrike 2026 Global Threat Report, there has been a 42% increase in zero-day exploits being used before they are even publicly disclosed. Once a vulnerability is known, the clock starts ticking with terrifying intensity.

Data shows that China-nexus adversaries are often able to weaponize newly patched vulnerabilities within just two to six days of disclosure. This creates a race where the defender is almost always running behind. If an organization treats a new CVE as a routine queue item to be handled during the next scheduled maintenance cycle, they may find that the “window of opportunity” for the attacker has already closed—and the attacker has already moved on to the next target. The average breakout time for an intrusion is now approximately 29 minutes, with some recorded as fast as 27 seconds. In that timeframe, a “medium” priority patch is useless.

3. Stockpiled CVEs That Nation-State Actors Hold for Years

While some attackers move fast, others are incredibly patient. Sophisticated nation-state actors often engage in “vulnerability stockpiling.” They find a flaw, verify its utility, and then sit on it for months or even years. They wait for the perfect moment to strike, often during high-stakes periods like political transitions or major economic shifts. This allows them to bypass many of the standard detection mechanisms that look for sudden spikes in exploitation activity.

A notable example is the Salt Typhoon group, which targeted senior U.S. political communications. They did not rely on a single, flashy zero-day. Instead, they chained together older, known vulnerabilities—CVE-2023-20198 and CVE-2023-20273—on internet-facing devices. By using “old” flaws that many organizations had neglected to patch, they gained access to the most sensitive communications in the country. These stockpiled vulnerabilities are like dormant landmines; they may not be active today, but they are waiting for the right footstep.

4. Identity Gaps That Never Enter the Scoring System

One of the most significant blind spots in modern cybersecurity is the “identity gap.” Most CVE scores focus on software flaws—bugs in code, memory leaks, or logic errors. However, a massive portion of modern breaches occurs not because of a software bug, but because of an identity failure. If an attacker steals a set of credentials through social engineering, there is no CVE assigned to that event. There is no “score” for a stolen password or a bypassed multi-factor authentication (MFA) prompt.

You may also enjoy reading: John Ternus Wants to Make Apple TV More Competitive: 5 Key Takeaways.

In many ways, identity is the new perimeter. If an attacker can impersonate a legitimate administrator, they don’t need to exploit a vulnerability to escalate privileges; they already have them. Because these methods do not trigger traditional vulnerability management tools, they often go unmeasured and unmanaged. A company might have a perfect patch management record for their palo alto vulnerabilities, yet still be completely compromised because they failed to secure the human element of their identity infrastructure.

5. The Exploding Volume of Disclosed Flaws

The sheer scale of the vulnerability landscape is becoming unmanageable. In 2025, over 48,000 CVEs were disclosed, representing a 20.6% increase from the previous year. Projections for 2026 suggest this number could climb above 70,000. This is an exponential growth curve that human security teams simply cannot keep up with using manual triage methods. The infrastructure used to score and enrich these vulnerabilities is buckling under the weight.

NIST has reported that CVE submissions have grown by 263% since 2020. As the volume grows, the quality of the data often suffers. When thousands of new flaws are reported every month, the “noise” makes it incredibly difficult to find the “signal”—the specific vulnerabilities that actually pose a threat to your specific environment. This volume creates a sense of “alert fatigue,” where security professionals become desensitized to warnings, leading to the very complacency that attackers exploit.

Practical Strategies for Moving Beyond CVSS

If the traditional scoring system is flawed, how should a modern organization protect itself? The goal is not to ignore CVSS, but to supplement it with context-aware intelligence. You cannot fix every vulnerability, so you must become surgical in your prioritization.

Implement EPSS and SSVC Models

Instead of looking only at the base severity score, organizations should integrate the Exploit Prediction Scoring System (EPSS). While CVSS tells you how bad a bug is, EPSS tells you how likely it is to be exploited in the wild. A vulnerability with a CVSS of 7.0 that has a high EPSS score is often a much more urgent threat than a 9.8 that has never been seen in an active attack. Additionally, using the Stakeholder-Specific Vulnerability Categorization (SSVC) model allows you to use a decision-tree approach. This helps you categorize flaws based on whether they are being actively exploited, the importance of the affected asset, and the availability of a patch.

Adopt an Asset-Centric Security Model

A vulnerability is only as dangerous as the asset it lives on. A critical flaw on an isolated, non-networked testing machine is a much lower priority than a medium flaw on your primary internet-facing gateway. You must maintain a real-time, accurate inventory of your hardware and software. When a new vulnerability is announced, your first question should not be “How high is the score?” but rather “Is this running on a critical path to our crown jewels?” By mapping vulnerabilities to business impact, you can prioritize the 1% of flaws that actually matter.

Prioritize “Chaining Potential” in Triage

During your triage process, train your analysts to look for relationships between vulnerabilities. If you see an authentication bypass and a privilege escalation flaw in the same product or ecosystem, they must be treated as a single, high-priority incident. Do not allow them to be separated into different workstreams. Security orchestration and automation (SOAR) tools can be configured to flag these patterns, helping to bridge the gap that manual human review often misses.

Focus on Identity and Behavior, Not Just Patches

Since many breaches bypass the CVE model entirely through identity theft, your defense must include robust Identity and Access Management (IAM). This includes implementing “Least Privilege” access, where users only have the bare minimum permissions necessary for their jobs. Furthermore, move toward behavioral analytics. Instead of just looking for “bad code,” look for “bad behavior.” If an administrative account suddenly starts accessing databases it has never touched before, or logs in from an unusual geographic location, that should trigger an immediate response, regardless of whether a vulnerability was exploited.

The era of relying on a single number to define your security posture is over. The Palo Alto incident serves as a stark reminder that attackers are creative, fast, and highly organized. They do not play by the rules of the scoring systems we have built. To survive in this landscape, we must stop looking at vulnerabilities as isolated mathematical problems and start seeing them as parts of a dynamic, evolving battlefield.

Add Comment