Overview

On May 6, 2026, Palo Alto Networks published a security advisory for CVE-2026-0300, a critical unauthenticated buffer overflow vulnerability affecting PAN-OS PA-Series and VM-Series firewall appliances. Prisma Access, Cloud NGFW, and Panorama appliances are not affected by this vulnerability. The vulnerability carries a CVSSv4 score of 9.3 and has been confirmed as exploited in the wild by the vendor.

CVE-2026-0300 is a buffer overflow (CWE-787) in the User-ID™ Authentication Portal (also known as Captive Portal), a non-default PAN-OS feature used to map IP addresses to usernames. An unauthenticated remote attacker can exploit this vulnerability by sending specially crafted packets to a device with the Authentication Portal enabled, achieving arbitrary code execution with root privileges on the affected firewall. No authentication or user interaction is required.

Palo Alto Networks has confirmed limited exploitation in the wild targeting Authentication Portals exposed to either untrusted IP addresses or the public internet. No patches are currently available; fixed versions are expected to begin rolling out on May 13, 2026, with additional releases through May 28, 2026.

PAN-OS is among the most widely deployed enterprise firewall operating systems in the world. Shodan identifies approximately 225,000 internet-facing PAN-OS instances, representing a significant attack surface. Rapid7 strongly urges all organizations running affected PAN-OS versions with the User-ID Authentication Portal enabled to apply the available workarounds immediately and prioritize patching as soon as fixed versions become available.

Update #1: On May 6, 2026, CVE-2026-0300 was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. Palo Alto Networks Unit 42 also published a threat brief attributing observed exploitation to CL-STA-1132, a likely state-sponsored threat cluster that deployed open-source tunneling tools and conducted Active Directory enumeration following initial compromise.

Mitigation guidance

Organizations running PA-Series and VM-Series firewalls with the User-ID™ Authentication Portal enabled should apply the available workarounds immediately and prioritize patching as soon as fixed versions are released. Check the official documentation to establish whether the affected User-ID™ Authentication Portal is currently enabled.

According to the Palo Alto Networks advisory, the following versions are affected by CVE-2026-0300:

Until patches are available, Palo Alto Networks recommends one of the following workarounds:

• Restrict User-ID™ Authentication Portal access to only trusted internal zones. Refer to Step 6 of the Live Community article and the Knowledgebase article for instructions on restricting access.

• Disable User-ID™ Authentication Portal entirely if it is not required (Device > User Identification > Authentication Portal Settings > uncheck Enable Authentication Portal).

Please refer to the vendor advisory for the latest guidance.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0300 with authenticated vulnerability checks available in the May 6th, 2026 content release.

Updates

• May 6, 2026: Initial publication.

• May 7, 2026: Updated overview to note the addition to CISA KEV and the Unit 42 threat brief attributing exploitation to CL-STA-1132.

The machine emulator has been abused in at least two different campaigns distributing ransomware and remote access tools.

The post Hackers Abuse QEMU for Defense Evasion appeared first on SecurityWeek.

Security leaders rarely struggle to produce data. The challenge is turning that data into something the board can use to make decisions.

Walk into a board meeting with a slide showing 1,200 critical vulnerabilities and 44 internet-facing assets, and you will likely see polite acknowledgment rather than meaningful discussion. The question that follows tends to cut through quickly: what does this mean for the business?

Boards allocate capital based on financial exposure, not vulnerability counts. A list of findings describes workload, but directors are responsible for revenue protection, liability, and risk to the balance sheet. When security reporting remains technical, it sits outside the way investment decisions are made elsewhere in the organization. The issue is less about communication and more about framing the problem in terms the business already understands.

From severity to risk

CVSS measures theoretical severity, but it does not measure business risk. A high score indicates that a flaw could be dangerous, yet it does not tell you whether the vulnerability is reachable in your environment, whether exploit code exists, or whether it is likely to affect revenue in the near term. It answers a useful engineering question, but it does not answer the question the board is asking.

That question is about likelihood and impact. Most enterprise risk frameworks define risk in those terms, and that is how financial decisions are made. The gap becomes clear when two vulnerabilities appear similar on a dashboard but carry very different consequences. A high-CVSS issue on a segmented lab system may present little business risk, while a moderately severe vulnerability on an internet-facing production system with active exploit activity can expose regulated data and revenue streams.

What is often missing in that comparison is threat context. Understanding how attackers behave, which vulnerabilities they are exploiting, and where access paths actually exist changes how risk is interpreted. Active Risk in InsightVM brings those elements together by combining exploit telemetry, attacker behavior, and asset context to estimate the likelihood that a vulnerability will be used. When that likelihood is paired with business impact, the conversation shifts toward exposure rather than severity.

From CVSS scores to financial exposure

Prioritization alone does not translate into board-level decisions. Knowing what is most likely to be exploited is necessary, but it is not sufficient when the goal is to justify investment.

FAIR provides a way to bridge that gap. The model defines risk as a combination of how often a loss event is likely to occur and how much that event would cost. In practical terms:

Annualized Loss Exposure (ALE) = Loss Event Frequency × Probable Loss Magnitude

Active Risk informs the likelihood side of that equation by grounding it in observed attacker behavior and exploit activity. FAIR converts that likelihood into financial terms, allowing security teams to describe exposure in a way that aligns with how capital is allocated.

Instead of reporting that a set of vulnerabilities is “high risk,” the discussion becomes more concrete. A team might say that a group of issues represents several million dollars in annualized exposure across systems tied to revenue. That is a number that can be evaluated alongside other business risks, rather than interpreted as a technical signal.

A practical example

Consider two vulnerabilities identified during a scan. The first is a CVSS 9.8 issue on a segmented guest Wi-Fi router. It is severe from a technical standpoint, but it has no access to sensitive data, no path into production systems, and no evidence of active exploitation.

The second is a vulnerability with a moderate CVSS score on an internet-facing customer database. Public exploit code exists, and the system stores regulated data tied directly to revenue and compliance obligations.

On a scanner dashboard, the first may appear more urgent. When viewed through a financial lens, the second carries greater risk.

Assume an annual probability of exploitation of 20 percent for the database scenario. If the potential impact includes $750,000 in incident response, $1.2 million from several days of business interruption, $600,000 in legal and regulatory costs, and $1 million in customer churn and reputational damage, the total loss for a single event is $3.55 million.

Applying the FAIR model results in approximately $710,000 in annualized exposure. That figure reflects the risk carried by that single vulnerability on a production system.

By contrast, even if the Wi-Fi router vulnerability had a 5 percent probability of exploitation and a $50,000 impact, the resulting exposure would be around $2,500. Both findings may appear critical in a technical report, but only one represents a material financial concern.

This is where Active Risk and FAIR work together. One identifies where attackers are likely to act, and the other expresses the consequence in financial terms. The combination changes how vulnerabilities are evaluated and how priorities are set.

Visualizing exposure across your environment

Once risk is expressed in financial terms, the next step is to understand how that exposure is distributed. Boards tend to think in terms of portfolios rather than individual issues, and the same principle applies to cybersecurity.

In most environments, exposure is not evenly spread. A relatively small number of systems and vulnerabilities account for a large portion of potential loss. Internet-facing services, systems tied to revenue, and assets with known exploit activity often sit at the higher end of that distribution.

This creates a practical way to focus effort. Rather than attempting to address every vulnerability equally, teams can identify where exposure is concentrated and reduce risk in those areas first. In many cases, addressing a small number of issues can significantly reduce overall exposure, particularly when those issues sit on systems that are both reachable and business-critical.

A before-and-after view helps make this visible. If an organization reduces modeled exposure from several million dollars to a substantially lower figure through targeted remediation, the result can be explained in terms of reduced downside risk rather than increased patching activity. Over time, tracking that change shows whether investments are producing measurable outcomes.

Making risk actionable

By the time exposure is expressed in financial terms, the discussion in the boardroom has already shifted. The focus moves away from counts and severity toward risk, trade-offs, and acceptable levels of exposure.

One of the first issues that arises in that context is the assumption that risk should be driven to zero. In practice, eliminating all exposure is neither achievable nor economically sensible. Reducing risk always involves trade-offs, and those trade-offs become clearer when expressed in financial terms.

If an organization has already reduced exposure significantly, but further reduction requires a disproportionate increase in cost, the decision becomes one of balance. The question is no longer why risk still exists, but whether the remaining exposure aligns with the organization’s tolerance.

The same logic applies when discussing budget. Requests framed in operational terms, such as additional headcount or tooling, are difficult to evaluate in isolation. When those requests are tied to measurable reductions in exposure, the relationship between cost and benefit becomes clearer.

For example, if additional resources reduce several million dollars of modeled exposure at a fraction of that cost, the investment can be assessed alongside other initiatives using the same financial lens. At that point, the discussion is no longer about capacity. It is about risk reduction.

Putting security in business terms

Reducing exposure also affects how the organization is perceived externally. Cyber insurance underwriting, for example, increasingly considers factors such as attack surface, exploit availability, and remediation speed. Demonstrating that exposure is measured and reduced over time can influence how risk is priced.

The same applies during customer due diligence. Being able to explain where risk exists, how it is prioritized, and how it has been reduced provides evidence of maturity. It shows that security is being managed deliberately rather than reactively.

Aligning to risk tolerance

Productive board discussions tend to end with agreement on acceptable levels of exposure. Without a financial view, every issue can appear urgent. With it, prioritization becomes more grounded.

Leadership can evaluate whether the level of risk being carried is consistent with business objectives, and whether further investment is warranted. That shifts vulnerability management from a process focused on volume to one focused on where exposure is concentrated and how it can be reduced most effectively.

Clear exposure, clearer decisions

Vulnerability management has often been treated as an operational activity centered on patching and scanning. When combined with threat context and financial modeling, it becomes part of enterprise risk management.

Instead of reporting how many vulnerabilities exist, security leaders can describe how much exposure the organization carries. Instead of focusing on activity, they can show how targeted actions reduce risk over time. That framing aligns cybersecurity with the same decision-making process used across the rest of the business.

When exposure is clear, decisions become clearer. Leadership can determine where to accept risk, where to transfer it, and where to invest in reduction. The conversation with the board moves away from technical detail and toward measurable impact, which is where security becomes part of strategy rather than an isolated function.

As a tester, I do all my work inside a Virtual Machine (VM). Recently, I found myself in a situation where I needed to get a VM on a Windows […]

The post QEMU, MSYS2, and Emacs: Open-Source Solutions to Run Virtual Machines on Windows appeared first on Black Hills Information Security, Inc..

Carrie Roberts // A fun story from an adventure in social engineering not too long ago. Thought I’d pass on some things I learned and ways to be more prepared in the […]

The post Social Engineering – Sometimes It’s Too Easy appeared first on Black Hills Information Security, Inc..

Brian B. King // If working with several customers at once, or in succession, it would be easy to lose track of whose data you’re looking at, or to include […]

The post Pentesting with Linked Clones appeared first on Black Hills Information Security, Inc..