In 2024, researchers from the University of Illinois found that GPT-4, when provided with a common vulnerabilities and exposures (CVE) description, could autonomously exploit 87% of a curated 15-vulnerability one-day dataset. Without the description, it could only exploit 7%. This provided a “margin of safety” for the industry because while AI could exploit known vulnerabilities, it could not discover them.

However, on April 7, Anthropic announced that Claude Mythos Preview had closed that margin, with the model autonomously discovering thousands of zero-day vulnerabilities across major operating systems and browsers. Separately, Mythos scored 83.1% on the CyberGym vulnerability reproduction benchmark. In one campaign targeting OpenBSD across 1,000 scaffold runs, the total compute cost was less than $20,000.

Exploitation timelines are collapsing. Langflow’s CVE-2026-33017 (CVSS 9.8) was exploited 20 hours after disclosure with no public proof-of-concept. Marimo’s CVE-2026-39987 (CVSS 9.3) was hit in 9 hours and 41 minutes.

The defensive infrastructure most organizations rely on wasn’t designed for this. Rapid7’s 2026 threat landscape report states that the median time from CVE publication to CISA’s known exploited vulnerabilities (KEV) listing is five days. Google’s M-Trends 2026 report found that exploitation is happening before a patch is even released. When the Langflow advisory was published, the first exploit arrived in 20 hours. When the Marimo advisory was published, it took under 10 hours.

The assumption that your patch window is safe because exploitation takes time is no longer true. Here are your building blocks.

Replace CVSS-only prioritization with a three-layer filter

Most vulnerability management programs still prioritize by CVSS score alone. CVSS quantifies a vulnerability’s “theoretical” severity without considering whether a vulnerability is being exploited in the wild or how quickly someone could weaponize it. A CVSS 8.8 vulnerability with a history of active exploitation (like Docker’s CVE-2026-34040) gets lower priority than a CVSS 9.8 vulnerability that may never be exploited in the wild.

A recent study validated against 28,377 real-world vulnerabilities offers a concrete replacement: A three-layer decision tree incorporating CISA KEV status, Exploit Prediction Scoring System (EPSS) scores, and CVSS, thus forming a singular prioritization filter.

Three-Layer Vulnerability Prioritization Filter

Layer	Data source	Threshold	Action	SLA
1. Active exploitation	CISA KEV catalog	Listed	Immediate patching	Hours
2. Predicted exploitation	EPSS via FIRST.org	Score ≥ 0.088	Escalate to Tier 0 pipeline	24 hours
3. Severity baseline	CVSS via NVD	Score ≥ 7.0	Typical remediation	Per policy

Validated result: 18x efficiency gain, 85.6% coverage of exploited vulnerabilities, ~95% reduction in urgent remediation workload. All three data sources are open and free.

The described integration is entirely automatable. It’s possible to build a script to query the CISA KEV API, the EPSS API from FIRST.org, and the NVD, and have that script run against your asset inventory for every published CVE. The human in this process should remain in the loop as an approver, but not as the trigger.

Close the agent authorization gap

Creating exploits quickly not only changes how patches are prioritized, but how controls are configured for all the agent-driven systems that now possess privileged credentials. Your authorization policies have not been assessed against the behavior of AI agents, and that is now a measurable risk. CVE-2026-34040 showed that Docker’s authorization plugin architecture silently bypasses every plugin when the request body exceeds 1MB. Common AuthZ plugins (OPA, Casbin, Prisma Cloud) are unaware of this type of bypass, which occurs in Docker’s middleware before the request reaches the plugin.

When Cyera demonstrated this vulnerability, they showed that an AI agent debugging infrastructure could infer the bypass path while completing a legitimate task, without any instruction to exploit anything.

The Internet Engineering Task Force (IETF) is working on authorization models for agents. The document draft-klrc-aiagent-auth-01, published in March by participants from AWS, Zscaler, Ping Identity, and OpenAI, proposes the use of the current Secure Production Identity Framework for Everyone (SPIFFE) and OAuth 2.0 for AI agents to obtain dynamically provisioned and short-lived credentials.

Separately, the IETF Agent Identity Protocol draft (draft-prakash-aip-00) reports that out of about 2,000 surveyed model context protocol (MCP) servers, none had authentication.

But these standards are months to years away from implementation. For now, security teams must proactively incorporate agent-level test scenarios for all authorization boundaries, such as oversized requests, burst frequency, and multi-step escalation of privileged requests.

Map your credential blast radius

In a survey conducted by CSA/Zenity and published on April 16, 53% of organizations said they had already seen cases where AI agents exceeded their intended permissions, and 47% experienced a security incident involving an agent.

When AI builder tools such as Flowise (CVE-2025-59528, CVSS 10.0), Langflow, or n8n become compromised, the blast radius extends far beyond the host. These tools contain API keys to frontier models, database credentials, vector store tokens, and OAuth tokens to business systems. A compromised AI builder host is not just a single-system breach. It is a credential harvest that unlocks authenticated access to every connected service.

Without credential dependency maps for each AI tool host, incident response for agent compromise is guesswork. For every instance, document each credential, the extent of its access, and the relevant credential rotation process. Also begin migrating static API keys to short-lived tokens where downstream services allow.

Five actions for this quarter

1. Deploy the three-layer KEV-EPSS-CVSS filter

Substitute CVSS-only prioritization according to the table above. Automate the collection of data from all three APIs as part of a scheduled script against your asset inventory. Desired outcome: 18 times more efficient, 85.6% coverage of exploited vulnerabilities, 95% reduction in urgent remediation workload.

2. Implement event-driven patching for Tier 0 services.

Determine which services fall under the critical exposure tier: Services exposed directly to internet users, AI builder hosts, and container orchestration control plane. Trigger event-driven patching on a CVE publication instead of waiting for the next maintenance window for this tier.

Goal: deploy patch to canary within four hours of a CVE being declared critical. Use the CISA KEV and EPSS feeds to trigger event-driven patching. In situations where it is impossible to meet the goal of four-hour patching because of legacy dependencies, change-freeze windows, or rollback risk, immediately apply compensating controls such as removing internet exposure to the vulnerable service, rotating credentials for the vulnerable service, disabling affected functionality of the service (if applicable), and identifying an exception owner for the exposure until a patch can be deployed.

It is not acceptable to allow unbounded exposures for extended periods while awaiting a maintenance window.

3. Test authorization boundaries at agent scale.

Create test cases for every API that AI agents may communicate with via AuthZ policies. Specifically, include test cases for requests exceeding 1MB, 5MB, and 10MB body sizes. This includes test cases for burst rate > 100 requests per second and test cases for unusual parameter combinations (privileged flags, host mounts, capability additions). Additionally, patch to Docker Engine 29.3.1 to fix CVE-2026-34040.

4. Credential blast radius mapping for all AI builder hosts.

Document each credential for each Langflow, Flowise, n8n, and custom AI pipeline instance. Classify each credential by its lifespan (static key vs. short-lived token). Identify what each credential can access. Set up alerts for anomalous IP or identity for any credential access.

5. Shadow AI discovery scan for this week.

According to CSA data, there is a greater than 50% chance that your agents have exceeded their expected boundaries. Check your Security Information and Event Management (SIEM) and network monitoring tools for communications to the default ports of the AI builder: Langflow 7860, Flowise 3000, and n8n 5678. Any unauthorized instances are an unmonitored attack surface.

The takeaway

AI agents are emerging, and the standards bodies are responding. The IETF has multiple drafts related to agent authentication and authorization. The Coalition for Secure AI has published its MCP Security taxonomy and Secure-by-Design principles.

But these standards move at standards-body speed, and the exploit window is now measured in hours. Organizations that implement the three-layer filter and event-driven patching this quarter will have a measurable reduction in exposure. Those who wait will be running calendar-based patch cycles against an adversary that operates in less than 20 hours. 

Nik Kale is a principal engineer specializing in enterprise AI platforms and security

Security | VentureBeat – ​Read More

Malware over the past decades has become one of the most critical threats to various sectors and entities, ranging from normal endpoint devices to critical infrastructure and other organizations. Even most, if not all, of the final stages of each compromise rely on malware. Computer security researchers and malware analysts have developed different toolkits to understand malware samples and dissect them in order to understand their intent, functionalities, capabilities, stealth mechanisms, malware infrastructure, and more.

But the main question is: is malware analysis just about tools and premium kits for dissecting and inspecting malware? This is the mistake that most junior and even some other analysts fall into.

First, we need to understand what a tool or software actually is. In basic terms and definition, a tool or software is something programmed to make human daily tasks easier. For example, Microsoft Office Writer allows writing hundreds of pages that were once limited to classic paper, now with different page setup sizes for writing various articles and documents.

What lies behind the tool is the external or internal set of data used to parse and understand the structure. You can imagine that ransomware does not know what an extension is unless the malware author has already configured it to recognize it or inserted it into a list of extension datasets. Without those pre-hardcoded or configured lists of extensions, ransomware does not actually know what or which files to encrypt.

Tools work with the same mechanism and follow the same approach, only with different configurations.

Malware analysis, by nature, is a challenging and complex field to adapt to. Most tools were developed years ago; some are outdated, while others are still being updated and improved. However, we should not forget that most of them work based on signature detection to recognize things such as packers.

For example, if a packer is unknown, or if a malware author reverse-engineers the packer and modifies section names such as UPX1 or UPX0 into random names, the tools may be unable to recognize which packer was used to pack the malware sample.

That is where mindset plays a critical role in the analysis stage, because in malware analysis, most, if not all, tools are fundamentally the same.

Examples include: Pestudio, Detect It Easy, Strings, HxD, IDA, Ghidra, Process Hacker, Autoruns, Procmon, API Monitor, x64dbg, and so on.

In general terms, these tools are effective and sufficient to understand malware behavior, functionalities, and capabilities. But the most important aspect is how to use those tools and what exactly you need from them.

Nowadays, you may not see malware of interest like in past decades that attracted security firms and the industry to analyze and publish long PDF reports for the community. Malware has mostly become a business today, such as MaaS (Malware as a Service).

In addition, it is now quite rare to see malware with an interesting initial delivery vector.

Last but not least, one trap that many analysts fall into is becoming bored during malware analysis, and I do not blame them at all. This is because what is common nowadays are infostealers, weaponized Office documents exploiting CVE-2017-0199 or CVE-2017-11882, or PDF documents asking users to click a link to update their software.

Until this point, everything is fine.

What is not fine is when analysts do not have clear goals before analyzing malware. There are several questions an analyst should ask before even touching the malware sample:

1- Why should I analyze this malware?

2- What is my goal in analyzing this malware?

3- What do I need to look for inside this malware?

4- What tools are effective for this stage of analysis?

Malware analysis is not about having different virtual environments for different purposes and maintaining large analysis toolkits. In reality, you may not need all of those tools to inspect malware.

Having many tools in your arsenal is good, but one of the main issues that causes analysts to fail is tool switching.

For example, switching from x64dbg to OllyDbg raises the question: if you already have x64dbg, why do you need OllyDbg? If the answer is plugins, x64dbg also supports plugins.

If you have Strings, why do you need BinText?

If you have Ghidra or Iaito/Radare2, why do you need Cutter or Binary Ninja?

If you already have a pattern-matching tool, why do you need a separate URL revealer?

However, we should not ignore that each tool has its own advantages and disadvantages.

An analyst should adjust their mindset to inspect and dissect malware samples effectively.

What I have seen from many junior analysts nowadays, and what I also did at the beginning of my journey, is performing a quick review of the sample by dragging and dropping it into different tools and then immediately jumping into dynamic analysis.

Dynamic analysis often shows what malware is doing, at least in most non-sophisticated cases. However, there are still valuable indicators that may be missed during static analysis.

You may ask: “If the malware is packed or obfuscated, why not just jump directly into dynamic and network analysis?”

The answer is that dynamic analysis is not a “bibbidi-bobbidi-boo” solution that reveals everything.

There are still static analysis approaches you can follow:

1- Unpack the malware if the packer can be unpacked using a public open-source tool.

2- If the malware is obfuscated, connect small indicators and patterns together until they provide meaningful context.

3- Dump stack strings using FLOSS if the malware does not provide strings of interest.

4- Look for Windows API functions related to registry, networking, or file activities.

You can validate these approaches through advanced static analysis.

This can be useful when the malware does not act as a dropper, downloader, stager, or loader in most cases. Samples often have different structures, different hash values, different import address tables, and clearer plaintext strings. They may appear different, but they are still connected.

Another mindset analysts should build is: never trust, always verify. Do not assume. Look for evidence and avoid cognitive bias. Focus on facts.

You should never forget that malware analysis is a cat-and-mouse game. Malware authors do their best to misdirect analysts because once you are misdirected, your analysis may no longer provide meaningful results.

Some common misdirection techniques include:

1- Junk code

2- Dead code

3- Junk strings

4- Unusable Windows API functions

Finally, you must understand that as a malware analyst, whether junior or senior, malware analysis is not something you can fully learn in a few weeks, through one course, or by reading one book.

Malware analysis is a field of experience.

I believe it is one of the fields that requires more hands-on experience than many others, because malware authors continuously develop new techniques, new methodologies, and new approaches every day.

The more samples you analyze, the more experience you gain. Day by day, you will begin to feel the difference in your analysis process.

The last thing I want to say to junior analysts is that you may not immediately see or feel your progress. Usually, it takes months or even years to clearly notice how much you have grown in this field.

You can compare it to growing your hair longer; most visible changes only become noticeable after several months.

However, try to focus on the binary platform you want to specialize in, for example:

• Windows malware analysis
• Linux malware analysis
• macOS malware analysis
• Android malware analysis
• iOS malware analysis

Each of these has its own approaches and methodologies.

The tools you use for Windows malware analysis may not be effective for Android malware analysis, and the same applies across other platforms.

Secjuice – ​Read More