The number of vulnerabilities detected in code continues to rise. According to Kaspersky’s threat analysis, 5,200 critical vulnerabilities were found in the first half of this year alone — nearly 50% more than during the same period last year. At the same time, the average gap between the publication of information about a vulnerability and the first attempts to exploit it is shrinking. The rapid development of AI systems plays a significant role in this process: while helping companies find weaknesses in their code, AI simultaneously shows hackers how to exploit them quicker.

It would seem that solving the problem of security gaps is very easy. All you need do is set up a scanner, check the infrastructure more often, and update vulnerable systems. But statistics from the Kaspersky Incident Response service show the opposite: a significant number of cyberattacks begin precisely by exploiting a flaw — and these are often already known flaws, not zero-day vulnerabilities.

Using a scanner does not give you an effective vulnerability management process. A scanner merely finds flaws (not always promptly), and then the IT team is tasked with prioritizing and fixing them. These processes can drag on for weeks, and in the meantime an attacker can easily gain access to the given infrastructure.

Where time is lost

The first delay can occur immediately after information about a vulnerability appears in databases. In addition to monitoring for breaches, the information security team is normally handling a dozen-or-so other tasks, so it relies entirely on the scanner for monitoring. If the scanner is configured to run weekly, a new vulnerability will appear in the report in a few days. In a company where scans are conducted quarterly, this obviously happens much later. Attackers, on the other hand, actively monitor news feeds and learn about new vulnerabilities immediately.

When the report finally reaches the security team, it contains far more than just one issue, raising the question of where to start. Critical vulnerabilities are addressed first, but attackers might exploit more than just those. Meanwhile, prioritization decisions are rarely based on data: often, they’re based on the order of the errors in the report, the name of the vulnerable system (they start with the one everyone’s talking about), or increased activity from its owner. Because of this, the risk of overlooking a serious threat is very high. Finally, the IT department takes on the vulnerability, and… it ends up back in the queue: they need to check the update’s compatibility and wait for a maintenance window.

After installing the update, the specialists close the ticket with a clear conscience and mark the status as completed. But would anyone verify that the patch was applied to all affected machines? Even the one that was turned off at the time of installation? Probably not, and then the company would assume the vulnerability was fixed, even though it’ll actually remain in the infrastructure for an indefinite period. This is the worst possible outcome: the risk remains — yet it’s no longer visible.

Put it all together, and what we get is months passing between disclosure and actual resolution. There’s no one in particular to blame here: every participant in the chain did what they’re supposed to. It’s just that this chain itself is made up of links with gaps between them.

A recipe for vulnerability management

To give attackers as few opportunities to gain access to corporate infrastructure as possible, it’s important to ensure that an organization has four key processes clearly established:

1.       Inventory

It’s impossible to verify the security of a system that no one knows exists. At the same time, virtually any large infrastructure will contain things like having had a server set up “for a week” three years ago, a network device left over from previous business owners, or a workstation that was forgotten during an office move. And each of these assets can pose a serious threat.

The goal of inventory management is to ensure complete transparency of the IT infrastructure. To achieve this, an up-to-date list of assets is compiled.

2.       Prioritization

When analyzing vulnerabilities, a security specialist shouldn’t rely solely on ratings from public databases such as the NVD, for these don’t always rely the real severity of the actual potential damage caused by exploiting a vulnerability. The specific structure of an organization’s infrastructure will have a significant impact. For example, the same vulnerability in a server located in an isolated segment, and in a system accessible from the internet, represents two very different risks.

Effective prioritization takes into account not only the publicly reported severity level but also the role of the vulnerable asset within the infrastructure, the likelihood of exploitation, and actual attack trends.

3.       Configuration settings

Overly permissive access settings, disabled security mechanisms, and default accounts are not technically vulnerabilities, but they often serve as entry points for cybercriminals. To prevent an attacker from exploiting inadequate configuration settings, security teams should follow several basic security best practices:

• delete default accounts;
• use strong passwords and MFA;
• disable unused services;
• apply the principle of least privilege.

4.       Confirmation

Blind spots are particularly common at the last stage of the vulnerability management process. Typically, once the IT department formally installs an update, the vulnerability is considered patched. However, before breathing a final sigh of relief, it’s important to at least verify that the patch has been successfully applied to all affected systems and has actually resolved the vulnerability.

Five tasks — one solution

Our solution, the Kaspersky Vulnerability Management module for Kaspersky Next Optimum helps information security specialists establish centralized management of vulnerabilities, assets, and configuration errors. The product solves five key tasks:

• It reduces the time between publication of vulnerability data and its detection in assets. The product automatically inventories the infrastructure — tracking even long-forgotten assets — and continuously scans it for vulnerabilities. Scanning is performed in two ways: agent-based and agentless. In the former, the solution runs on top of Kaspersky Endpoint Security, which allows for in-depth analysis of workstations and servers without transmitting service credentials over the network. In the latter, it analyzes ports and services where no agent is present. Both methods complement each other, enabling complete coverage of the company’s infrastructure.
• Checks configurations. Compliance with security standards is verified using predefined profiles.
• Prioritizes vulnerabilities. Priorities are assigned based on severity level, the characteristics of the specific asset, likelihood of exploitation, and other parameters.
• Promptly fixes errors. This involves remediation recommendations and centralized patch management integrated into the familiar administration infrastructure.
• Helps ensure that the vulnerability is fully patched. A remediation task is considered complete only after a follow-up verification.

The Kaspersky Vulnerability Management Module helps transform vulnerability management from a series of disjointed actions into a well-thought-out cycle. Details about licensing can be found on the Kaspersky Next Optimum for small and mid-sized businesses offering page and more about Vulnerability Management Module — on the module's home page.

Blogs

Blog

Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization

Flashpoint was awarded U.S. Patent No. 12,705,360 for its Ransomware Risk model, which rates how closely new vulnerabilities match those used in ransomware attacks.

SHARE THIS:

Flashpoint

October 1, 2026

Table Of Contents

Table of Contents

Under the Hood: How Flashpoint’s Patented Ransomware Vulnerability Model Works

Comprehensive Vulnerability Intelligence Integration

Protect Against Vulnerability and Ransomware Risk Using Flashpoint

Ransomware Risk FAQs (Frequently Asked Questions)

More

subscribe to our newsletter

Vulnerability and exposure management (VM) teams need critical metadata and context that clearly show which issues pose an immediate risk to their organization. While traditional VM frameworks tell defenders how severe a vulnerability may be, they do not provide visibility into how likely threat actors are to exploit it. This leaves security teams overwhelmed in patch backlogs without a clear strategy for prioritization.

Nowhere is this prioritization gap more dangerous than with ransomware. Ransomware-as-a-Service (RaaS) groups no longer choose targets at random. They look for specific technical conditions that make vulnerability exploitation easy, fast, and repeatable. With RaaS attacks rising by 45% period-over-period in H1 2026, organizations need a way to identify the specific traits that make a vulnerability attractive to ransomware operators before an attack occurs.

Flashpoint built the Ransomware Risk score into Flashpoint Vulnerability Intelligence to solve exactly this problem. Since 2022, it has rated newly discovered vulnerabilities based on how closely they resemble those known to be used in ransomware attacks. With the grant of the U.S. Patent No. 12,705,360 on August 11, 2026, the methodology behind the score is now formally patented. This milestone formalizes Flashpoint’s ability to cut through the noise with a proven, threat-informed signal that gives defenders the clarity they need to act on Day Zero.

“As vulnerability disclosures surge, prioritization is more important than ever for security teams. A severity score alone can’t tell you which vulnerabilities pose the greatest real-world risk of exploitation by ransomware actors.

Our patented Ransomware Risk model applies years of threat intelligence to that problem, giving customers an earlier signal and helping them prioritize based on how attackers actually operate.”

josh lefkowitz, co-founder and ceo at flashpoint

Under the Hood: How Flashpoint’s Patented Ransomware Vulnerability Model Works

The patented system evaluates newly disclosed vulnerabilities against the patterns shared by vulnerabilities ransomware groups have exploited. Rather than trying to predict what threat actors will do next, the model learns what past ransomware-exploited vulnerabilities have in common and compares each new flaw against those patterns.

The Four Step Process

Multi-Factor Fingerprinting

Every vulnerability ingested into Flashpoint Vulnerability Intelligence is profiled against more than 60 distinct technical factors. This “fingerprinting” links the vulnerability to key inputs including whether the flaw is remotely exploitable without authentication, whether it affects SCADA or Operational Technology (OT) systems, and its potential impact on data availability, which is central to extortion schemes.

Coordinate Mapping

The model turns each multi-factor fingerprint into a set of values that place it as a single point on a map, so vulnerabilities with similar profiles land close together.

Identifying the Ransomware Neighborhood (Cluster Check)

Flashpoint overlays historical threat data onto the map to establish neighborhoods where vulnerabilities previously exploited in real-world ransomware attacks aggregate.

Similarity and Likelihood Rating

When a new vulnerability is ingested, its coordinates are checked against these neighborhoods. The scoring system calculates its spatial proximity to known ransomware vectors and assigns a clear rating: Low, Medium, High, or Critical.

This four-step method, developed by Flashpoint’s Ben Haynes and Jacob Kouns, is the basis of U.S. Patent No. 12,705,360.

What It Means for Vulnerability Management Teams

By translating complex structural attributes into a single risk score, the patented model delivers four key operational advantages:

1. Prioritize Beyond CVSS: Leveraging the Ransomware Risk model, security teams can confidently prioritize 1.0 to 6.9 CVSS issues if its structural profile lands it in a “High” or “Critical” ransomware cluster.
2. Act on Day Zero: Because the Flashpoint model rates all vulnerabilities on disclosure, security teams gain actionable guidance immediately, eliminating the need to wait weeks for external exploitation reports.
3. Effectively Communicate Risk: CISOs can present clear, business-centric risk statements rather than abstract numerical scores.
4. Adaptive Ratings: Scores update in near real time as vulnerability details change, and the model keeps adjusting as new vulnerabilities join the set it compares against.

Comprehensive Vulnerability Intelligence Integration

Flashpoint’s Ransomware Risk model is built to enhance, not replace the vulnerability management frameworks organizations already rely on. In fact, it provides even greater value for security teams as our Ransomware Risk model provides clarity for every vulnerability detailed by Flashpoint Vulnerability Intelligence, including over 105,000 issues missed by CVE and NVD.

Within Flashpoint Ignite, security teams have a complete view of vulnerability risk, seeing the score alongside CVSS (v3 and v4), EPSS, Social Risk, and exploit maturity.

Protect Against Vulnerability and Ransomware Risk Using Flashpoint

Vulnerability management requires more than cataloging. It demands threat-informed prioritization that aligns security operations with real-world business risk. Flashpoint’s patented Ransomware Risk model eliminates guesswork by surfacing the flaws that match the profile of known ransomware targets, allowing security teams to patch what matters most, first. 

By combining proprietary knowledge of vulnerability architecture and ransomware attacks, Flashpoint bridges the gap between theoretical and active exposure. Request a demo today to see how our Ransomware Risk model provides the definitive signal needed to stay ahead of extortion groups.

Ransomware Risk FAQs (Frequently Asked Questions)

What is the Ransomware Risk score? 

The Ransomware Risk score is a rating in Flashpoint Vulnerability Intelligence that shows how closely a vulnerability resembles those known to be used in ransomware attacks. Each vulnerability is rated Low, Medium, High, or Critical, so security teams can see which ones to patch first to reduce their ransomware exposure.

How is Ransomware Risk different from CVSS and EPSS?

CVSS measures how severe a vulnerability could be, and EPSS estimates how likely it is to be exploited in general. Ransomware Risk adds a ransomware-specific signal that works alongside both, showing how closely a vulnerability matches those ransomware groups have used. In Flashpoint Ignite, all three scores appear together.

What does Flashpoint’s ransomware patent cover?

U.S. Patent No. 12,705,360, granted August 11, 2026, covers Flashpoint’s method for rating how likely a vulnerability is to be used in a ransomware event. Each vulnerability is profiled on more than 60 factors, compared with vulnerabilities used in past ransomware attacks, and rated by similarity. The patent formalizes the model behind the Ransomware Risk score, live since 2022.

How often are Ransomware Risk scores updated?

Ransomware Risk scores update in near real time, so new vulnerabilities are rated as soon as they’re disclosed. The model also keeps adjusting as new vulnerabilities join the body it compares against, so ratings reflect the ransomware landscape as it stands today.

The post Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization appeared first on Flashpoint.

In Part 2 of the Patch Sound Barrier series, I shared a thought experiment from a talk in May 2026: imagine any vulnerability in your environment can be patched within 15 minutes of release. Now reverse-engineer that reality. What had to be true?

Usman and I revisited this exercise in our “basics at AI scale” post. Readers asked: “How do I actually run this exercise with my team?”

So here’s how. Two ground rules first:

• This is not a 15-minute patch SLA. If you take this post and write “all vulnerabilities remediated within 15 minutes” into a policy, I will find you… I utterly hated “30 days flat” policies as an analyst and “15 minutes flat” is the same mistake with more zeros. The number is a probe, not a target.
• You will never get there across your whole environment. Legacy systems guarantee it. The point is the gap between the fantasy and your reality, because that gap is the most honest map of your program you will ever get. The Patch Sound Barrier is real; this exercise tells you where yours is and what it is made of.

Why 15 minutes, and not “fast”

“Fast” allows cheating. Some consider 90 days “fast” because they started at an annual cadence. “Patch faster” is generic advice everyone agrees with, but rarely acts on (or: barely acts on). An aggressive, specific number forces you to identify which pipeline steps physically cannot fit.

The Cloudflare quote from Part 2 summarizes this: demanding faster patching without redesigning the process leads to skipped steps. If regression testing takes a day, a two-hour SLA just skips testing. This exercise targets pipeline design, not raw speed. A 15-minute window leaves room only for automated steps. Everything else itemizes your sound barrier.

The 15 minutes, minute by minute

Assume a patch drops at T+0. At each stage, ask:

1. What must be true for this stage to fit the timeframe?
2. What is current reality, and what is the gap?

Details:

and

A 15-minute timeline leaves zero room for manual deliberation. In this model, humans define policies, build automation, and handle (rare!) exceptions. They do not manually approve or execute patches.

The five things the exercise refuses to let you skip

1. Inventory as a live graph. If identifying affected systems takes hours, downstream automation cannot compensate. First move: measure how long it takes to locate a specific library or version today. That duration is your baseline gap. Most organizations are shocked. Log4j much?
2. Rapid automated testing. Manual testing blocks rapid remediation. First move: time how long it takes to get from “patch available” to “confident it won’t break prod” on core systems, then work out what it would take to make that 5 minutes.
3. Replaceable infrastructure. Rapid patching relies on redeploying updated templates rather than patching running instances. First move: determine your “replaceability ratio”: the percentage of systems that can be automatically rebuilt from source fast enough to fit the deploy window.
4. Pipeline-level governance. Per-change approval gates prevent rapid execution. Approve the policy and the pipeline, not each patch. First move: transition low-risk change classes to pre-approved automated pipelines.
5. Rehearsed rollback. Teams patch slowly because they fear breaking prod, and they fear it because they’ve never practiced un-breaking it. First move: execute and time an intentional rollback on a non-critical production system.

The cheat code: change the verb from “patched” to “non-exploitable”

For legacy systems, OT networks, or appliances you can’t modify, 15-minute patching is fiction. So change the verb: make the vulnerability non-exploitable or harmless within 15 minutes. That’s the Part 1 move: assume you can’t patch, then decide what you’ll do instead.

The difference (reminder for most, new for some...):

• Patching eliminates the flaw. It requires vendor fixes, testing, deployment, and mutable target systems, factors largely outside your immediate operational control.
• Mitigation reduces exposure risk. It relies on controls you own (network segmentation, identity policies, access gateways … at times an ax) without modifying target code, so actions can be pre-engineered and pre-approved easier.

The 15-minute mitigation exercise tests four capabilities:

1. Can you isolate network paths immediately via automated policy?
2. Can you revoke or scope down credentials in minutes?
3. Do you know the blast radius well enough to isolate a component without breaking the business?
4. Can you push a protection rule via API in minutes? (See API or Die.)

Your patch clock partly belongs to the vendor (partially). Your mitigation clock is all yours. For legacy, that’s the only 15-minute clock that matters.

But a segmentation diagram is not segmentation, and a kill switch nobody has pulled is a hypothesis. As I argued in Survival of the Basics, a mitigation counts only if it is a tested, operational control.

How to actually run this with your team

Book 90 minutes, a whiteboard, and the right people: platform/infra, an app owner, whoever runs change management, and QA. Security alone will find the gaps, but won’t own any of them.

1. Select three specific target systems: modern (containerized service), median (standard application server), and legacy (high-risk core system).
2. Map the clock for each system: document stage durations and identify the gaps.
3. Identify the primary bottleneck stage.
4. Define a single corrective move for that bottleneck: one bottleneck, fixed end to end (same logic as Baby ASO).
5. Apply the mitigation model to legacy targets: establish rapid containment controls where patching is impossible.
6. Track stage durations quarterly: progress shows up as shorter stages on your critical systems.

No time for a workshop? Pick a widely used component (a core library or agent) and time how long your team takes to find every active instance with high confidence. That’s your T+0 to T+1 baseline.

So, will you get to 15 minutes?

Containerized microservices can get there (yes, really, but provided some moons are aligned just right). Standard application servers can perhaps go from weeks to hours. Legacy systems need rapid mitigation (segmentation, credential scoping, containment) rather than patching.

What do you think? Is this totally crazy or what?

Related posts and resources:

• The original “patch sound barrier” post (2013)
• Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?
• Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? (this defines the “vulnerability apocalypse” term)
• Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management (with Usman Chaudhary, July 2026)
• Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers?
• Stop Building a 2003 SOC with AI, Part 3 (“API or Die”)
• Baby ASO: A Minimal Viable Transformation for Your SOC

The 15-Minute Patch, Reverse-Engineered: What Had to Be True? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

- AI, supply-chain exposure, quantum computing and geopolitical conflict are testing security programs. Preparing for disruption must become part of day-to-day operations.

The post Four Cyber Threats Harboring Big Plans for the Future appeared first on SecurityWeek.

Cyber Asset Attack Surface Management (CAASM) solved a significant problem. Security teams can now say with confidence what they own.  But, two things separate a CAASM tool that stops there from one that actually moves the needle on risk. The first is what the inventory itself carries. The second is what it connects to. 1. An inventory needs to do more than list what exists A list of assets is just the beginning. The tools worth building on now attach criticality and connection data to every asset from day one, so a security team isn’t just looking at a spreadsheet […]

The post Two Things Every Cyber Asset Attack Surface Management (CAASM) Tool Needs to Get Right appeared first on Check Point Blog.

Check Point uncovers thousands of fake support accounts, with hundreds more appearing every day A delayed flight. Missing luggage. A refund that never arrived.  For frustrated customers, social media has become a direct route to customer support. They tag the company, explain the problem, and wait for a response.  However, threat actors are watching those same conversations.  A Check Point Exposure Management investigation uncovered a coordinated social engineering campaign in which scammers monitor public complaints, impersonate customer support accounts, and approach customers seeking help. Researchers engaged directly with the scammers and followed the attack from the first social media interaction […]

The post Scammers Are Watching Airline Complaints and Posing as Customer Support appeared first on Check Point Blog.

We analyzed ongoing conversations with prospective customers to find out what buyers ask most. Below are those questions, covering how Check Point Exposure Management helps teams validate risk, cut noise, coordinate remediation, and report progress. Part 1 covered how security leaders think about asset discovery, cloud visibility, threat intelligence, credential exposure, and integrations. Once teams know what’s exposed, the conversation shifts to prioritization and response. 1. How do you prioritize which exposures matter? Security teams often manage thousands of vulnerabilities across applications, endpoints, cloud resources, and internet facing infrastructure. A severity score alone does not provide enough context to determine […]

The post The Top Exposure Management Questions Security Leaders Ask: Insights from Customer Conversations (Part 2) appeared first on Check Point Blog.

Security teams are starting to actively use AI for security work, including vulnerability triage, penetration testing, threat modeling, incident response, and code review. The promise is speed, but a security tool that moves fast and raises too many false alarms doesn’t save time. Engineers spend time on false alarms, on-call is noisier, and teams distrust findings that matter.

Today, we’re releasing Deception Benchmark, the first benchmark designed to measure that trust problem directly. It tests whether a model can distinguish real vulnerabilities from code that looks risky but is actually safe. The benchmark includes 14,822 samples across 16 languages and more than 70 Common Weakness Enumeration (CWE) categories. We evaluated 12 models from five providers and are releasing the dataset and whitepaper to the community. Existing benchmarks measure whether AI can find or exploit vulnerabilities. This is the first to measure whether it can tell real vulnerabilities from false alarms. Under standard prompting, precision at distinguishing real vulnerabilities from false alarms landed in the mid 50s; as likely to be inaccurate as accurate.

In offensive tasks, there’s often a clear result: the exploit works or it doesn’t. Defensive reviews are harder to verify than offensive tasks; a model might recognize a suspicious pattern even when a mitigation makes the issue non-exploitable. In practice, useful systems need to reason about the code, the mitigation, and sometimes the surrounding environment.

The community has made progress on security evaluations. CyberGym tests agents on more than 1,500 realistic tasks. Meta’s CyberSecEval and CyberSecEval 2 measure exploit generation. CYBENCH evaluates capture the flag (CTF) challenges. SEC-Bench and VulnBench push toward authentic security workflows.

Recent work reinforces both the progress and the gap. ExploitGym measures whether AI can escalate from a crash to a working exploit. Microsoft’s Project Perception deploys multi-agent red/blue/green teams for continuous defense. OpenAI’s GPT-Red shows that self-play red-teaming finds novel attacks that frontier models can’t defend against. Since then, OpenAI disclosed that its GPT-6 Astra model crossed the Critical cybersecurity capability threshold, and both OpenAI and Anthropic reported incidents where models gained unauthorized access to production systems during evaluations. The offensive side is moving fast. But none of this work measures the defensive precision question: when an AI system flags code as vulnerable, how often is it right?

14,822 samples, 16 languages, and more than 70 CWE categories. We call it Deception Benchmark because the safe samples are designed to deceive models. It has real vulnerability patterns, real frameworks, real idioms, with mitigations that quietly close the exploit path. The goal is to classify code as vulnerable or safe, with no hints.

Consider a Flask endpoint that accepts user input and queries a database. A model will pattern-match to SQL injection, but the query uses parameterized statements, so the exploit path is closed. A single-turn classifier flags the pattern and moves on, never checking whether the exploit can actually work. Production tools rely on multi-step loops and agentic workflows to compensate, but that scaffolding masks whether the model itself understands the code. This benchmark strips the scaffolding away and asks the model to make the call in a single pass, so what it measures is understanding, not how many tries a harness takes to get there.

We built every sample through an adversarial loop: generate, test against frontier models, harden, repeat. If a model gets it right easily, the sample doesn’t survive. The result is a benchmark calibrated to the frontier, not below it. Building it this way is expensive. Generation and hardening of the samples consumed tens of billions of tokens. We’re releasing the result so the community doesn’t have to repeat that cost.

This benchmark generates two challenge types. Code-level challenges (6,988 samples) present vulnerable and safe variants that differ by a subtle fix. Both look suspicious, only one is exploitable. Environment-gated challenges (2,707 samples) go further: same code, different deployment context. A Kubernetes Network Policy blocks the server-side request forgery (SSRF) path. An identity and access management boundary prevents privilege escalation. The pattern is visible in the source. The infrastructure makes it unexploitable. The model has to figure out which scenario applies.

All samples were purpose-built for this benchmark, grounded in real-world patterns, real frameworks, real CWEs, and real infrastructure; without IP concerns or training data contamination.

Generating reliable labels at this scale is difficult: a single pass—by people or by models—leaves errors that skew scores. So we treat labeling as a convergent audit loop rather than a one-time step. Every label is re-examined by multiple independent reviewers, blind to one another and to the original reasoning that produced the label. Disagreements escalate to direct adjudication, where the original reasoning is evaluated against the challenge. Unresolved cases go to human review. We repeat the loop until the scored set converges below a dispute threshold: under 3 percent of samples still contested by independent review, with a target of under 1 percent surviving human adjudication. One choice makes this defensible: we never relabel a disputed sample. When reviewers disagree, the sample moves to the unscored pool instead of being given a corrected label, so a bad challenge can remove a sample but can never introduce a wrong label into the scored set.

A human review of 100 randomly drawn scored samples found no label errors. We describe the full process in the whitepaper.

The benchmark is roughly balanced: half vulnerable, half safe, so a random classifier scores 50 percent. We report two error rates separately, because they fail in opposite directions. The false positive rate (FPR) is how often the model flags safe code as vulnerable. These are the false alarms that waste an engineer’s time. The false negative rate (FNR) is how often it misses a real vulnerability and calls it safe. Accuracy alone hides this: a model that labels everything vulnerable catches every bug (0 percent FNR) but flags all safe code (100 percent FPR) and still scores about 50 percent. We consider FPR below 10 percent and FNR below 10 percent the minimum bar for production use.

Figure 1: FPR compared to FNR for 12 models across two prompting strategies. No model reaches the generous bar.

Among the general-purpose frontier models tested, no configuration achieves both FPR and FNR less than 10 percent on this benchmark.

Every model has the same failure mode. With direct prompting, they catch up to 95 percent of real vulnerabilities but also flag 41–99 percent of safe code. Precision runs from 52 percent to 71 percent, clustered in the mid-50s; effectively as likely to be inaccurate as accurate. The models see a vulnerability pattern and stop reasoning. Proof-of-exploit prompting cuts false positives by 17–74 points but misses 7–44 percent of real vulnerabilities. The environment-gated challenges are worse: models flag the code and ignore the Kubernetes Network Policy next to it. No tested configuration keeps both false positives and false negatives below 10 percent.

These results reflect general-purpose models in single-turn prompting. Purpose-built systems with multi-step validation and tool use are a different operating point that we didn’t measure, and if a harness can close the gap between pattern recognition and genuine understanding, this benchmark is the place to demonstrate it. Two cautions before assuming it already does. Agentic verification is proven mostly on offensive tasks, where success can be confirmed: the exploit fires or it doesn’t. Judging that code is safe has no such oracle. Extra iterations re-sample the same judgment rather than confirm a negative, and a harness still inherits the base model’s understanding. If the model can’t separate an effective mitigation from an ineffective one in a single pass, more passes won’t add the missing knowledge. That’s what this benchmark measures: the model’s intrinsic ability to understand code, tested at the single-turn baseline where no scaffolding can mask the gap.

For security teams evaluating AI tools today: ask your vendors how their system performs on tasks like this, not just whether it finds vulnerabilities, but how often it’s wrong. Pair any AI-assisted review with human verification on high-risk code paths, and use Deception Benchmark to hold your tools accountable.

We built Deception Benchmark to simplify measuring this problem in a reproducible way. The public release includes the samples and evaluation workflow. We don’t release the labels, so submissions can be scored consistently over time without turning the benchmark into a memorization exercise.

Of the 14,822 samples, 9,695 are scored; the remaining 5,127 are held out and unscored, mixed in with the rest of the benchmark. The goal is straightforward: make it more difficult to optimize the benchmark compared to improving the underlying system. We describe that design in more detail in the whitepaper.

Deception Benchmark is available on GitHub, along with the whitepaper and submission instructions for verified scoring. If you’re building security tooling, you can download the dataset, run your system against the benchmark, and submit predictions for scored evaluation.

If you have feedback about this post, submit comments in the Comments section below.

Blogs

Blog

Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing

Threat actors are no longer just using automation to execute tasks, they are leveraging prepackaged, safeguard-free AI, weaponizing stolen session data, and directly targeting defenders’ security stacks.

SHARE THIS:

Flashpoint

September 1, 2026

Table Of Contents

Table of Contents

The Death of Signal: Threat Actors are Shifting to “Private AI”

Weaponizing the Defender’s Own Tooling

The Structural Failure of CVE/NVD and the Importance of KEV

Ransomware Evolution: From Encryption to Cloud Extortion

Protect Your Organization Using Flashpoint

More

subscribe to our newsletter

In our latest webinar, Flashpoint Vice President of Intelligence, Ian Gray, briefed security leaders on the evolving threat environment, providing critical insights from the Flashpoint Global Threat Intelligence Report (GTIR): 2026 Midyear Edition.

The threat landscape has developed at a striking pace with Flashpoint tracking over 22 million illicit AI discussions, 7.4 million compromised hosts yielding 1.7 billion stolen credentials, and over 21,600 disclosed vulnerabilities in just six months. Beyond these staggering numbers, the on-demand session detailed something even more alarming: a fundamental shift in adversary operational tradecraft.

Here are the five critical shifts every cyber threat intelligence (CTI), Vulnerability Management, and SOC team needs to know.

The Death of Signal: Threat Actors are Shifting to “Private AI”

The public discussion surrounding criminal artificial intelligence (AI) has reached a critical inflection point. Early in the AI boom, Flashpoint observed threat actors collaboratively experiment across underground forums, jailbreaking commercial frontier models or advertising surface-level tools like WormGPT and DarkGPT.

Today, adversaries are shifting from public forums to running fine-tuned, open-source models locally on private servers, which greatly hampers traditional signature-based detection. Flashpoint analysts are now seeing attackers generate unique, highly tailored malware variants, flawless phishing lures, and custom exploit scripts at extremely low costs—completely offline and shielded from public monitoring.

“A few months ago, a lot of this was collaborative… public outsourcing. Now what we’re seeing is scarier: pre-packaged cybercrime models run locally on private infrastructure. Malicious code, exploit scripts, and targeted phishing are all being generated inside closed environments.”

Ian Gray, VP of Intelligence, Flashpoint

Weaponizing the Defender’s Own Tooling

Another eye-opening tactical insight shared during the session was how threat actors are repurposing defender infrastructure for automated initial access and extortion. In the webinar, we pointed to recent campaigns where adversaries specifically targeted misconfigurations and zero-day vulnerabilities inside open-source vulnerability scanners, secrets-detection tools, Kubernetes clusters, and Infrastructure-as-Code(IaC) environments.

What this means for defenders is that the attack surface is no longer bounded by traditional enterprise network boundaries: it extends directly into CI/CD pipelines, security orchestration tooling, and third-party SaaS integrations. Security teams are finding themselves in a race against attackers who use automated scanning scripts to weaponize vulnerabilities in the security tools themselves.

The Global Infostealer Threat and Identity-First Attacks

Flashpoint tracked 7.4 million hosts compromised by infostealers in H1 2026—a 27% increase period-over-period—harvesting 1.7 billion credentials and identity information.

While the top infostealer strains remain familiar, law enforcement operations have created vacuums that competitors rapidly fill.

Threat actors are leveraging drive-by downloads, watering holes, and pirated software packages to plant stealers. Once a machine is compromised, the logs capture corporate SSO credentials, active browser cookies, VPN keys, and SaaS session tokens. This enables adversaries to simply log in without having to leverage complex technical exploits.

The Structural Failure of CVE/NVD and the Importance of KEV

The Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) have failed to keep pace with the velocity of AI-assisted vulnerability discovery. As such, vulnerability management teams are facing significant operational delays.

Metric	Flashpoint GTIR Midyear H1 2026 Data	Operational Impact
Total Disclosures	21,667	Remediation volume exceeds defender bandwidth.
Exploit Availability	19% (4,015 CVEs)	Functional code is ready before patches are deployed.
Public Catalog Lag	Growing Backlog (NVD/KEV)	Delay in official scoring leaves teams blind to active risk.

Therefore, waiting for NVD enrichment before prioritizing a patch is a dangerous strategy. To compensate, security teams require Vulnerability Intelligence (VI) that provides primary-source confirmation of weaponization, exploit availability, and actionable mitigation guidance long before public databases update.

Ransomware Evolution: From Encryption to Cloud Extortion

Ransomware-as-a-Service (RaaS) activity surged by 45% period-over-period, reaching 6,256 verified victim postings on data leak sites. However, total on-chain payout revenue dropped by 8% to $820 million, with victim pay-rates hitting a record low of 28%.

Faced with declining payouts and resilient enterprise backups, extortion syndicates are adapting. Rather than relying exclusively on technical file-encrypting malware, groups are executing pure data extortion campaigns—frequently targeting cloud platforms or extracting data through third-party vendor access.

Protect Your Organization Using Flashpoint

Defending against machine-speed attacks requires moving beyond reactive, post-incident telemetry. Flashpoint arms security, CTI, and vulnerability management teams with the primary-source intelligence required to preempt adversary operations:

• Unrivaled Deep & Dark Web Visibility: Flashpoint’s Primary Source Collection actively monitors closed criminal communities, illicit Telegram channels, and private forums, giving you early warning when threat actors build custom AI toolkits or trade credentials targeting your organization.
• Comprehensive Vulnerability Intelligence (VI): Flashpoint tracks zero-days and vulnerability disclosures independently, delivering immediate exploit availability data and threat-informed prioritization so you patch what actually matters.
• Continuous Compromised Credential Monitoring: Instantly surface exposed enterprise credentials, active session tokens, and stealer logs tied to your domain or third-party supply chain before they lead to an account takeover (ATO).

Request a demo, or watch the full on-demand webinar to explore the data shaping today’s risk landscape.

The post Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing appeared first on Flashpoint.