AI coding agents are part of the developer toolchain. Tools like Kiro and Claude Code generate features, tests, and code refactors from natural-language prompts. A single agent can open dozens of pull requests (PRs) across your repositories in an afternoon. That productivity comes with a trade-off: agents optimize for task completion at machine speed with no understanding of your organization’s risk.

Through protocols like the Model Context Protocol (MCP), agents also reach beyond the integrated development environment (IDE) to call APIs, query databases, and modify infrastructure and even entire environments, expanding the scope of resources your application security team defends.

This post lays out an application security (AppSec) control framework for AI coding agents. Two pillars organize the framework: author-time controls shape what the agent produces in the IDE; build-time controls verify and gate what reaches production. Your existing secure software development lifecycle (SDLC) controls still apply and are critical to a defense-in-depth security strategy. The framework shows where to layer additional guardrails so AppSec scales with agent-driven development. The framework is tool-agnostic and cloud-agnostic. Throughout, we use AWS services—Kiro in the IDE and AWS CodePipeline in the build—as a running example that you can adapt to your own toolchain.

Each of the following risks includes a treatment summary. The control framework section later in this post provides implementation details. The risks are ordered by severity with the highest impact risks first.

Agents read untrusted content, such as issue descriptions, web pages, MCP responses, and README files in third-party packages. Text from outside parties can redirect the agent to disclose secrets, open unauthorized PRs, or invoke tools without user consent. This risk, known as prompt injection, is the top risk in the OWASP Top 10 for LLM Applications. Any agent that reads content from outside parties is exposed, with or without MCP, so connecting tools widens the scope of impact.

Treatment: Treat non-developer input as untrusted. A large language model (LLM) can’t reliably separate instructions from data in a single context window, so architect for it: keep the agent that orchestrates trusted actions separate from the one exposed to untrusted content and grant the exposed agent only read-only, least-privilege access. Require human approval for irreversible actions. Use version-control steering files to prevent silent tampering.

Agents optimize for getting work done. Left unchecked, the code they generate can default to wildcard identity and access management policies, open security groups, and unencrypted storage, or embed sensitive values in code rather than referencing a secrets manager. Most coding agents now include safety mechanisms that make these outcomes less likely, but they remain imperfect, so you still need controls to account for the possibility.

Treatment: Security requirements in a steering document, plus policy-as-code scanning (Checkov, cfn-nag) in the IDE and pipeline. See Context as a security control.

Ungated code reaching production isn’t new, but AI agents amplify it. Machine-speed generation can propagate a flawed pattern across repositories before it’s identified.

Treatment: Branch protection rules requiring PR approval (a human-in-the-loop checkpoint), pre-commit hooks for security checks, and sandboxed agent runs that prevent direct pushes to protected branches. The right balance between human review and automated speed depends on the risk profile of the change. For many low-risk paths, automated checks alone might suffice, while higher-risk changes warrant a human checkpoint.

Agents don’t always distinguish current best practices from outdated patterns. They might recommend deprecated packages, reference library versions with new Common Vulnerabilities and Exposures (CVEs), and hallucinate package names that don’t exist, which can introduce risks of dependency confusion issues.

Treatment: Software Composition Analysis (SCA) in the pipeline (for example, Amazon Inspector code scanning or Dependabot) to flag vulnerable or unexpected dependencies. For additional control, resolve against a scoped registry like AWS CodeArtifact. Even without a fully curated registry, lockfile validation and allow-listing critical packages reduce exposure.

Through MCP and tool integrations, agents query databases, call APIs, and modify infrastructure. Without constraints on which tools and data an agent can reach, a single misconfigured integration provides unintended access to sensitive resources.

Treatment: Scope MCP servers to least-privilege tools and resources, enforce authn or authz on external connections, and audit tool invocations. The control point is the configuration file. Review it the same way you review AWS Identity and Access Management (IAM) policies.

Agents produce plausible-looking output. Code that compiles, passes linting, and looks reasonable can still be functionally wrong: misusing APIs, introducing subtle logic errors, or implementing security-sensitive operations incorrectly. Code that passes continuous integration (CI) but is wrong slips through review; code that fails to build is caught immediately.

Treatment: Layer deterministic verification (static application security testing (SAST), unit tests) with non-deterministic review (LLM-assisted screening against the specification). Neither catches everything alone.

Given a bug-fix prompt, an agent might also refactor surrounding code, disable an unreliable test, or reorganize imports. Unrequested changes introduce regressions and complicate review.

Treatment: A reviewed specification document that defines what must change and what must not, paired with a targeted review of the proposed changes. See Specifications as scope boundaries.

The preceding risks share a common thread: agents produce output faster than humans can review it, and they lack context to self-correct.

The following framework addresses this gap. It organizes controls into two pillars: author-time (pre-generation and post-generation of code) and build-time (in the pipeline, before code reaches production). Author-time controls shape what the agent produces. Build-time controls verify it. Neither is sufficient alone; together they reduce the volume and severity of issues that reach human reviewers.

Deterministic mitigations [D] produce the same result every time. Linters, SAST scanners, secrets detection, and policy-as-code match patterns against rules and define security invariants: no critical findings, no hardcoded secrets, and no wildcard IAM policies. Use them when the condition can be expressed as a rule. Organizations already have these and must continue enforcing them.

Non-deterministic mitigations [ND] use model judgment. They include steering documents, LLM-as-judge review, specification compliance checks, and scope-creep detection, and they evaluate intent rather than patterns. They catch novel issues that rules miss, but are probabilistic. Use them when evaluation requires context or reasoning across files. This is the new layer that AI-generated code demands, because agents produce code that can pass every deterministic check yet remain functionally wrong.

Human review [H] provides the final layer for the risk-based decisions neither tool type can make. Apply it where judgment is needed, not everywhere: routing every change to a person invites consent fatigue, where reviewers approve by reflex and the control loses its value. The default reflex is to route everything back to a human, but that isn’t always the right response—reserve human judgment for the decisions that genuinely need it.

The framework organizes controls into two pillars. Author-time controls (Pillar 1) shape what the agent produces in the IDE, before code is generated and just after. Build-time controls (Pillar 2) verify and gate that output in the pipeline, before it reaches production. The controls within each pillar are tagged deterministic [D], non-deterministic [ND], or human [H].

Author-time controls work inside the IDE, where the developer and agent still hold full context. They shape the prompt and the generated output before it ever reaches a pull request. The following controls apply at this stage.

Context as a security control [ND]

Control statement: Encode security invariants as natural-language constraints in a steering document that every developer environment consumes at session start. Addresses R002.
Many AI coding agent risks share one root cause: the agent lacks the security context an experienced developer carries implicitly. Your security team sets the policies, such as Amazon Simple Storage Service (Amazon S3) buckets require encryption, API gateways require mutual TLS, and credentials must come from AWS Secrets Manager. Developers don’t always have these requirements available when they’re building. They build what works, not what’s compliant. An AI agent amplifies this gap because it defaults to whatever pattern dominated its training data, with no awareness of your organization’s security posture.

A key mitigation is steering. Security teams write these invariants once as natural-language guidance in a steering document, then distribute them as shareable resources that developers consume in their IDE. The agent loads the file at session start and treats the contents as standing requirements:

• IAM policies must follow least-privilege principles; no wildcard Amazon Resource Names (ARNs).
• No hardcoded credentials in source code; use a secrets manager.
• Security groups must not allow unrestricted inbound access.

This shifts security left, before code generation begins. Steering biases generation toward secure defaults; it doesn’t guarantee them. Treat it as a strong default, paired with the following deterministic gates that block non-compliant code from merging. Security teams define the rules once and every developer environment inherits them automatically. Steering reduces the volume of issues that reach the pipeline, though it doesn’t replace downstream scanning.

How to write effective steering rules: Keep each rule specific and testable, scope it to a concrete risk class, keep the rule set concise so the agent can hold it in context, and iterate from the issues your scanners and reviewers surface.

Specifications as scope boundaries [ND]

Control statement: Require a reviewed specification before code generation begins. Define what must change and what must not. Addresses R007.

Spec-driven workflows turn vague prompts into reviewable specifications before code is generated. This creates a human checkpoint at the design phase, where security decisions are made:

• Requirements use testable notation that’s auditable before the agent writes a line of code. For example, the Easy Approach to Requirements Syntax (EARS): WHEN [condition] THE SYSTEM SHALL [behavior].
• Tasks are ordered in implementation steps, each mapped back to a requirement.

For bug fixes, specifications add a critical element: unchanged behavior documentation. This is an explicit list of behaviors that must continue working, giving the agent a written boundary against scope creep.

In this model, the specification becomes the primary artifact, code is a derivative of it. Human review effort concentrates on whether the specification solves the right problem with the right constraints, not on reading implementation diffs line by line.

Controlled tool access using MCP [D + ND]

Control statement: Scope each MCP server to the minimum set of tools the agent needs, and give it a dedicated, scoped-down credential rather than the developer’s own. Maintain an allowlist of reviewed MCP servers. Addresses R005.

MCP servers act as controlled gateways between the agent, the external tools, and data:

• Dependency management – An MCP server fronting your private package registry resolves dependencies against curated packages, not the public internet. This is a deterministic constraint on supply chain risk.
• Infrastructure tooling – Visibility into current resource configurations prevents templates that conflict with existing infrastructure.
• Scoped permissions – Each MCP server exposes a defined set of tools and resources. You choose exactly what the agent can access, supporting least-privilege at the integration layer. You supply that credential through the agent’s configuration (in Kiro, the env block of .kiro/settings/mcp.json). Avoid autoApprove: ["*"], which removes the human approval prompt on every tool call.

IDE code scanning [D]

Control statement: Run real-time static analysis in the IDE so security issues surface while the developer (and agent) still have full context. Addresses R002, R006.

Real-time diagnostics catch syntax errors, type mismatches, and configuration issues as the developer types. A malformed IAM policy is flagged before the agent builds further on it. Security-focused extensions (ESLint security plugins, Checkov, SAST) layer on top for immediate feedback while code is fresh in context.

Hooks: Automated guardrails at the point of action [D + ND]

Control statement: Attach deterministic checks to file-save events and non-deterministic verification to task-completion events. Addresses R002, R007.

• Shell command hooks [D] – Triggered on file save, these run a linter, formatter, or security scanner and produce the same result every time. They enforce hard rules.
• AI-powered hooks [ND] – Triggered on task completion. These prompt the agent to verify that the implementation matches the specification and check for any untested edge cases or files that were modified outside the task’s scope.

Build-time controls run in the pipeline after code is committed and before it reaches production. They verify and gate what the agent produced, catching what author-time controls did not. The following controls apply at this stage.

Layered security scanning [D]

Control statement: Run secrets detection, static analysis, dependency scanning, and infrastructure-as-code scanning in sequence. Fail the build on any critical finding. Addresses R002, R003, R004.

1. Secrets detection runs first because it’s cheapest and addresses a high-severity class of issue. It scans for hardcoded API keys, database connection strings, and credentials that AI agents might inadvertently include.
2. SAST scans source code for injection issues, insecure deserialization, and resource leaks. Custom rules can target AI-specific anti-patterns including overly broad exception handling, deprecated APIs, placeholder credentials, dynamic code execution through eval().
3. Software Composition Analysis (SCA) identifies known CVEs in dependencies. This is critical for AI-generated code, which might reference deprecated packages or hallucinate package names that open you to dependency confusion issues.
4. Infrastructure as code (IaC) scanning validates AWS CloudFormation, Terraform, and AWS Cloud Development Kit (AWS CDK) templates against security policies before deployment. Catches overly permissive IAM roles, unencrypted storage, and public-facing resources the agent created.

Each stage halts the pipeline on failure. Results export to a standard format (Static Analysis Results Interchange Format (SARIF)) for compliance auditing and flow downstream to human reviewers. The open source Automated Security Helper (ASH) bundles secrets, SAST, SCA, and IaC scanners behind one command that you can run locally and in AWS CodeBuild, emitting SARIF for the gates that follow.

Quality gates [D]

Control statement: Define pass/fail thresholds for each scan type. Block deployment on any critical or high-severity finding. Addresses R003.

Quality gates convert scan results into go/no-go decisions. Define thresholds for each severity: block on critical findings, require justification for highs, and track mediums. The gate is deterministic: if a threshold is breached, the pipeline stops. Exceptions require documented approval.

Differentiate blocking compared to advisory modes: hard failures on main, advisory on feature branches. Avoid gates becoming a friction that teams route around.

AI-assisted review [ND]

Control statement: Use an LLM reviewer to pre-screen every pull request for specification compliance, scope creep, and security anti-patterns before human review. Addresses R001, R006, R007.

• Specification compliance – Does the implementation match the requirements document?
• Scope verification – Were files modified outside the task’s stated scope?
• Security pattern review – Are there logic errors, misused APIs, or insecure patterns that pass SAST but violate intent?

This pre-screening focuses human reviewer attention on genuine risks rather than formatting or obvious issues. On AWS, AWS Security Agent (code review in preview at publication) checks pull requests against AWS-managed and custom security requirements. The reviewer screens and surfaces findings; the merge decision stays with a human.

A critical principle: the agent that wrote the code should not be the agent that reviews it. A separate session helps avoid self-confirmation bias, but a separate session alone doesn’t always avoid the generator’s blind spots, because two sessions of the same model can share them. Where practical, use a different model for review so the reviewer is less likely to inherit the same systematic weaknesses.

Human-in-the-loop review [ND + H]

Control statement: Require human approval on most pull requests, especially those touching security-sensitive or high-blast-radius code. Lower-risk changes might be eligible for agent-assisted or fully automated approval as tooling matures. Provide reviewers with scan results, LLM pre-screening output, and specification context to enable fast, informed decisions. Addresses R003.

Scale review depth to the risk of the change. Low-risk or boilerplate changes can take a lighter-touch review, while security-sensitive or novel-logic changes warrant mandatory deep review and a second reviewer.

Scanners catch known patterns but can’t judge whether code implements the intended business logic. Human review also serves to calibrate trust: teams build intuition about where agents excel (boilerplate, test writing) and where they’ve tended to struggle (novel business logic, security-sensitive operations), recognizing that this frontier shifts as models improve.

Place two approval gates: after security scans (reviewer focuses on correctness and business logic, with scan results as context) and before production deployment (final sign-off after integration testing). Treat human review as a secondary control, not a guarantee: reviewers are themselves non-deterministic and can miss issues, so human review layers on top of the deterministic gates rather than replacing them.

The framework is tool-agnostic, but AWS gives you building blocks for each pillar. The following services map directly to the controls described previously: Kiro for author-time guardrails, and CodeBuild and CodePipeline for build-time gates.

Kiro maps to Pillar 1: It puts the author-time controls in the IDE, where the developer and agent still share full context. Each feature in the following list implements one of those controls, configured in-repo under .kiro/ so the guardrails are version-controlled and shared across the team rather than set per developer.

• Steering documents – Markdown files in .kiro/steering/ load into the agent’s context at session start. Conditional inclusion using fileMatch (for example, ["**/*.tf"]) loads IaC-specific rules only when relevant.
• Specification-driven workflows – Three-phase specifications (requirements in EARS, design, and tasks) with review checkpoints. Bug-fix specifications capture unchanged behavior explicitly.
• Agent hooks – Triggered on file save, tool invocation, or task completion. Shell hooks run deterministic checks (linters, tests); Ask Kiro hooks run AI prompts for non-deterministic review. For example, a security pre-commit scanner hook can flag hardcoded credentials when the agent finishes a task.
• Property-based testing – Guided by a specification or hook, Kiro can generate property-based tests (for example, using the hypothesis library) that exercise hundreds of randomized inputs, probing edge cases a hand-written test suite would miss.
• MCP integrations – Connect Kiro to private package registries, internal docs, issue trackers, and infrastructure tooling, creating the controlled tool access pattern.

For enterprise environments, Kiro supports AWS IAM Identity Center for single sign-on and provides IP indemnity coverage for subscribers. Check the Kiro documentation for current Region availability.

CodeBuild runs each scanning tool (checking for secrets, SAST, SCA, and IaC) as a build action. A non-zero exit code fails the action, and the stage halts or rolls back according to its OnFailure setting. Findings export as SARIF to Amazon S3 for compliance, and CodePipeline action variables pass results to downstream approval actions.

• CodeBuild exit codes halt the pipeline on scan failures
• AWS Lambda invoke actions evaluate scan results against configurable thresholds and return pass/fail decisions
• Manual approval actions halt the pipeline, send Amazon Simple Notification Service (Amazon SNS) notifications, and link to review artifacts; decisions and reviewer identity are logged for audit

The following table consolidates the framework into a single view that includes each stage of the SDLC and the deterministic [D] and non-deterministic [ND] controls that apply there. Every stage carries both, a reminder that neither control type is sufficient on its own.

This post laid out a framework for adopting AI coding agents at machine speed without letting unreviewed risk reach production. It layers guardrails at two points:

• Author-time controls – Steering, specs, and scoped tools shape what the agent generates in the IDE.
• Build-time controls – Scanning, quality gates, and layered review verify it before it reaches production.

No single layer is enough: deterministic gates enforce hard rules, non-deterministic review catches what they miss, and human judgment is reserved for the decisions that need it. Together, they let AppSec scale with agent-driven development.

Where to start this week:

1. Start with steering and specs – Encode security requirements as steering and use specifications for new features. Highest impact, lowest effort. For a ready-made starting set, the open source Project CodeGuard (a Coalition for Secure AI project under OASIS Open, of which Amazon is a contributing member) publishes reusable steering rules for common risk classes—hardcoded credentials, IaC misconfiguration, supply chain, and MCP security—that you can adapt to your AWS environment.
2. Add deterministic pipeline gates – Integrate SAST, SCA, and secrets detection. Table-stakes regardless of AI usage.
3. Calibrate and iterate – Review what controls catch, adjust steering for recurring issues, and expand agent autonomy as trust builds.
4. Accountability – Developers remain accountable for the security of what they ship. AI agents accelerate development; they don’t transfer ownership.

More information:

• Kiro documentation
• AWS CodePipeline User Guide
• AWS Agentic AI Security Scoping Matrix

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

Threat actor names can sound simple. LockBit. Fancy Bear. BlackCat. Scattered Spider. Anonymous Sudan. Each name gives the impression of a clear group with a defined identity.  In threat intelligence, however, the name is rarely the whole story.  Some names are chosen by attackers. Others are assigned by researchers, security vendors, governments, or public databases. One name may represent a ransomware brand, a hacktivist identity, a research label, a campaign, a malware family, or an activity cluster observed across different incidents.  For security professionals, this distinction is important. Confusing attacker created identities with researcher assigned labels can lead teams to […]

The post The Branding and Attribution Behind Cybercrime appeared first on Check Point Blog.

Key Takeaways Microsoft continues to be the single most impersonated brand in Q2 2026, appearing in 23% of all brand phishing attempts, far ahead of any other company The top five impersonated brands, Microsoft, LinkedIn, Google, Apple, and Amazon, together account for more than half of all brand phishing attempts tracked this quarter Open AI’s ChatGPT entered the top ten most impersonated brands for the first time, signaling that AI tools are now firmly on criminals’ radar Technology was the most targeted industry overall, followed by Social Networks and Banking Real world cases this quarter ranged from fake payment failure […]

The post Which Brands Are Impersonated Most? Inside the Q2 2026 Brand Phishing Report appeared first on Check Point Blog.

Blogs

Blog

The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery

We outline Flashpoint’s practical, repeatable framework for prioritizing vulnerabilities based on real-world risk, exploitability, and business impact.

SHARE THIS:

Flashpoint

July 23, 2026

Table Of Contents

Table of Contents

Flashpoint’s Method for Threat-Informed Vulnerability Prioritization

Prioritize Vulnerabilities More Effectively and Faster Using Flashpoint

Frequently Asked Questions (FAQ)

More

Your Guide to
Proactive Vulnerability
Management

Download Now

Organizations are gaining new ways to identify vulnerabilities at scale, thanks to new generations of powerful AI models. However, security teams still face the same fundamental question: which vulnerabilities actually matter?

Vulnerability management teams have increasingly struggled to keep pace with growing disclosure volumes. From January 1, 2026 to June 30, 2026, Flashpoint tracked 21,667 vulnerabilities, an 8% period-over-period increase, with one-in-five containing publicly available exploit code at time of disclosure. At the same time, the gap between disclosure and exploitation continues to shrink, with some vulnerabilities weaponized in as little as 24 hours.

Flashpoint’s Method for Threat-Informed Vulnerability Prioritization

Recent developments such as Anthropic’s Mythos model have highlighted the growing potential for AI-assisted vulnerability discovery. As advances in code analysis enable researchers and organizations to identify software flaws at unprecedented speed and scale, the volume of discovered vulnerabilities is set to potentially increase significantly across software ecosystems.

That’s why we created this guide, The Flashpoint Method for Threat-Informed Vulnerability Prioritization, a practical, intelligence-driven framework designed to help vulnerability and exposure management teams cut through the AI-driven noise and focus on the vulnerabilities that matter most. By incorporating real-world exploitation activity, threat actor behavior, asset exposure, business context, and remediation considerations, organizations can make faster, more informed decisions and reduce risk more effectively.

Download to gain:

1. A clear, threat-informed prioritization framework: How to assess which vulnerabilities demand immediate attention, and why — moving beyond static severity scores alone.
2. Core and expanded prioritization checklists: Criteria spanning asset criticality, active exploitation, CVSS severity and ransomware risk, social risk and community chatter, business context, compensating controls, zero-day status, KEV inclusion, EPSS scoring, ease of remediation, and vulnerability age.
3. How to operationalize prioritization at AI scale: Insight into how Flashpoint’s vulnerability intelligence platform and analyst expertise help teams keep pace as AI-assisted discovery accelerates disclosure volume.

Prioritize Vulnerabilities More Effectively and Faster Using Flashpoint

While increased visibility into vulnerabilities is ultimately a positive for defenders, it amplifies a challenge security teams already face—separating which vulnerabilities represent meaningful risk to your environment and require immediate action.

Download The Flashpoint Method for Threat-Informed Vulnerability Prioritization to learn how Flashpoint’s vulnerability intelligence helps organizations triage, prioritize, and remediate risk more effectively.

Frequently Asked Questions (FAQ)

What is threat-informed vulnerability prioritization?

Threat-informed vulnerability prioritization is the process of evaluating vulnerabilities based on real-world risk rather than severity scores alone. It incorporates factors such as active exploitation, exploit availability, threat actor activity, asset exposure, business context, and remediation considerations to determine which vulnerabilities require immediate attention.

Why is vulnerability prioritization important?

Organizations face thousands of newly disclosed vulnerabilities each year, while security teams have limited time and resources to remediate them. Effective vulnerability prioritization helps organizations focus on the vulnerabilities most likely to be exploited and most likely to impact their environment.

How is AI changing vulnerability management?

AI-assisted code analysis is enabling researchers and organizations to identify software flaws faster and at greater scale. While increased visibility into vulnerabilities benefits defenders, it also increases the volume of vulnerabilities that security teams must evaluate, making effective prioritization even more important.

Why isn’t CVSS enough for vulnerability prioritization?

CVSS provides a standardized measure of technical severity, but it does not account for whether a vulnerability is actively being exploited, relevant to your environment, or likely to impact your business. Effective prioritization combines severity with threat intelligence and organizational context to assess real-world risk.

How does Flashpoint help organizations prioritize vulnerabilities?

Flashpoint combines analyst-driven vulnerability intelligence with real-world exploitation data, threat actor insights, asset exposure, and business context to help organizations identify the vulnerabilities that pose the greatest operational risk. This intelligence supports faster, more informed remediation decisions and operationalizes threat-informed vulnerability management at AI scale.

The post The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery appeared first on Flashpoint.

Some security teams are reducing critical exposure within hours, while others are leaving similar issues open for days. The 2026 Exposure Gap Report shows that many organizations can identify, validate, and prioritize exposure, but the real challenge begins when teams need to turn those insights into remediation.  Across environments, organizations are often working with similar types of exposure, yet their outcomes vary significantly. The difference depends on how quickly validated findings move into remediation and how consistently teams can repeat that process at scale.  Remediation Speed Varies Significantly  According to the report, Utilities organizations resolve exposure in about 12.6 hours […]

The post What the 2026 Exposure Gap Report Reveals About Remediation appeared first on Check Point Blog.

Developed together with Usman Chaudhary @ Google for Public Sector (his post)

Let’s call it what some in the industry are calling it: the vulnerability apocalypse. For years, finding vulnerabilities was slow, expensive, specialized work. LLMs made it cheap — in its first weeks, one frontier model surfaced more than 23,000 issues across a thousand open-source projects, including a 27-year-old flaw in OpenBSD found for under $20,000 in compute. And when finding bugs gets cheap, attackers find more of them — and likely exploit more of them, faster than defenders can patch. This isn’t hypothetical: Google’s threat intelligence team has already reported the first zero-day exploit built with AI, caught being used in the wild. The deluge is real, and it’s here.

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit…

Since Mythos, AI-powered defenses have emerged just as fast: autonomous agents that find and fix vulnerabilities in source code, tools that rewrite code to eliminate whole classes of bugs, frontier models utilized by defenders.

But here’s what gets lost in the arms race: the fundamentals are more important now than they have ever been. When you can’t out-find or out-patch the machines, what saves you is the boring, durable work done well — knowing your environment, limiting how far a break-in can spread, fixing root causes. AI raises the ceiling on both attack and defense; it doesn’t change what good defense is made of. And defending against AI-speed attacks doesn’t always require AI — sometimes it just requires the fundamentals, done well at scale.

One new note to add. Recent incidents like this made some people state that “basics don’t matter, machines will find a way.” To me it means that basics do matter, but consistency and scale are MUCH more critical. After all, and this is a silly example, no machine can find a buffer overflow if you code in Rust. And, yes, sadly, this means you need to be “near perfect”, but hey good news — with the same machines you can. So this is not a boring “do the basics please” post, this is a reminder that you need to scale them with AI.

Why the urgency is real (and different this time)

Why act now, if you’ve heard “do the fundamentals” for twenty years? Because the gap between discovery and exploitation is effectively gone — according to some sources, high-severity flaws are now exploited within hours, sometimes before a public proof-of-concept exists, and the damage is material, widespread, and accelerating.

A program that assumes days or weeks to respond was built for a world that no longer exists. The fundamentals — visibility, segmentation, process — are what absorb the shock when patching inevitably falls behind. And this holds whether AI capabilities jump or improve gradually: the actions needed today are largely the same.

AI made finding vulnerabilities cheap. The attackers noticed. The answer isn’t panic — it’s the fundamentals done well at scale.

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It?

Start by reverse-engineering the impossible

Before any playbook, one exercise — because it does more to find your real gaps than any framework will.

Imagine you could patch any vulnerability within 15 minutes of its release, as if by magic. Now work backwards: what would have had to be true? You’d need to know instantly what you run and where it’s exposed. You’d need testing so automated that a fix ships safely in minutes. You’d need no legacy that resists change, and an architecture built to absorb it. You’d need to have already eliminated whole classes of bugs, so there were fewer to patch at all.

You will never hit 15 minutes across the environment — legacy systems guarantee it. But the gap between that fantasy and your reality is the most honest map you will ever get of where your program breaks. Every item in the playbook below is something that this exercise surfaces.

The Playbook: Fundamentals at AI Scale and Speed

Each of these is written as what to do and how to actually get it done — because the advice-to-adoption gap is where most programs die.

The four moves: SEE → DECIDE → CONTAIN → RUN

1. SEE — know your environment, and keep watching

• The play: Map your environment (configuration graph) — what you run, what’s exposed to the internet, and how far one compromise can spread. Then keep watching: observability across your own environment, and threat intelligence for the outside view, so you know the moment a bug in vendor software starts being exploited in the wild.
• The advantage: The graph pays for itself immediately — dead code, unused open-source packages, and forgotten internet-facing servers you can simply remove — and it’s the asset list every other move depends on. Threat intel buys you early warning: you hear a vendor bug is being exploited when it’s announced, not when it hits you, so a compensating control can be in place before an attacker arrives.
• If you skip it: You defend blind — the breach starts at the asset you didn’t know you owned, and you learn about it from someone else.

2. DECIDE — spend your limited capacity where it matters

• The play: Prioritize by real exploitability, not raw severity — a “medium” on an internet-facing service one hop from customer data beats a “critical” on an isolated internal box (recently chains of Lows and Mediums were used in real compromises as well). Run two lanes: your own code you can fix, refactor, or rewrite; vendor code you can’t touch, so that lane is compensating controls and faster detection.
• The advantage: Your finite capacity goes to the few findings that could actually hurt you — and every flaw gets a response you can execute: a fix where you can, a shield where you can’t.
• If you skip it: Busy but not safer — capacity burned on findings no attacker could reach while the one exploitable path stays open, and months of exposure waiting on a vendor patch you could have mitigated in days.

3. CONTAIN — make sure one bug can’t become a breach

• The play: Segmentation splits the environment so a foothold in one place can’t reach the rest. Zero trust and least privilege make every person, service, and AI agent prove each request — and grant only the access it needs. When you can’t patch fast, mitigate: block the exploit path or take the exposed component offline. And when the same bug class keeps returning from the same code, fix the root cause — rewrite memory-unsafe components in a memory-safe language instead of patching the same flaw forever.
• The advantage: One exploited bug stays a contained incident instead of a company-wide breach — and containment keeps working even when patching can’t keep up.
• If you skip it: One bug becomes the whole environment — the first agentic ransomware ran its entire chain through doors these basics would have closed — and unfixed root causes bring the same bug class back every quarter.

4. RUN — make it continuous, and govern what runs it

• The play: Make scanning and fixing continuous and automatic, not quarterly — with the process defined before you accelerate: human-in-the-loop approval before fixes ship, a tested rollback path for when one goes wrong, and every AI agent wrapped in identity, least privilege, and human review from day one.
• The advantage: Machine-speed remediation that’s safe to run — and the whole playbook becomes a daily operating discipline instead of a one-time project.
• If you skip it: Quarterly scans mean months of exposure between runs; automation without approvals and rollback breaks production at machine speed; and an ungoverned agent becomes your newest insider threat.

None of these are new controls. What’s new is the bar. AI changed the speed and scale of the attacks, so the fundamentals have to run faster than they used to and cover everything with no exceptions.

The hard part isn’t technical

Every move above lands on someone else’s roadmap. Many are already on them, some for years. Segmentation changes how infrastructure operates; a continuous fix pipeline changes how developers ship; rewriting memory-unsafe components costs engineering quarters. Expect pushback — not because those teams don’t care about security, but because you’re asking to spend their time against their goals.

Three things buy the political capital: bring evidence, not mandates — the configuration graph and real exploitability data argue better than any policy memo; co-own the fix — show the risk and the trade-off, then let engineering own the how, because a rewrite they choose ships and a rewrite they’re ordered into stalls; and give leadership one number tying the work to risk reduced, so the effort defends itself at budget time.

Mandates breed quiet workarounds. Shared evidence and shared credit create movement.

The frontier agrees:

Anthropic, having surfaced the scale of the problem with Mythos, has focused on the fix: an automated pipeline that investigates, validates, and patches code vulnerabilities — delivered through Claude Code — with human review before anything ships.

Google frames it as AI threat defense: using AI across the whole vulnerability management lifecycle — finding, fixing, detecting, responding — wrapped in a framework and human review. The emphasis is on managing the end-to-end process, not any single tool.

OpenAI focuses on cyber-focused models — such as the GPT-5.6 series (including the Sol model) — which are designed to assist defenders with vulnerability identification, red teaming, and security validation, shifting the approach toward high-reasoning, specialized models capable of handling complex security tasks.

Different bets, same conclusion: none of them claims AI fixes vulnerability management for you — every one wraps the capability in process and human review.

The real reckoning

The vulnerability deluge is real, whatever you call it: AI made finding bugs cheap, and cheap discovery means more exploitation and more damage. But the reckoning isn’t that AI broke defense — it’s that the fundamentals matter more than they ever have. Use AI to find, to fix, and to move faster than you thought possible. But map your environment, limit how far a break-in can spread, fix the root causes, and keep a human on the decisions that matter.

Get the fundamentals right — that was always the strategy; now it’s the only one. Which of these is your program most under-invested in? That’s the conversation worth having…

P.S. This came out a bit too high-level, but this is admittedly for the high level audience…

Further reading and sources:

• “Breaking the Patch Sound Barrier” series
• Security incident disclosure — July 2026 (boring title award winner!)
• Google Secure AI Framework (SAIF)
• Google Threat Intelligence Group on the first AI-developed zero-day observed in the wild (2026).
• CoSAI Shared Responsibility for AI Security
• Anthropic — the post-Mythos code-patching pipeline via Claude Code
• Zero risk isn’t the job: a CISO’s guide to agentic AI
• First Take: OpenAI’s Hugging Face Hack — CISOs Must Focus on Fundamentals and Ignore the Hype (Gartner access required)

Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most breaches don’t start with a vulnerability nobody knew about. They start with one nobody patched in time. Vulnerability exploitation is now the single biggest way attackers get into a network. It has overtaken stolen credentials for the first time in the 19-year history of Verizon’s Data Breach Investigations Report, with 31% of breaches now […]

The post How to scale your patches without scaling your team (the patch wave) appeared first on Heimdal Security Blog.

Claude Mythos, an AI model from Anthropic, has found 23,019 software vulnerabilities in the past month. Fewer than 1% of them have been patched. That gap is the story. Finding a vulnerability used to be the hard part, the thing that limited how fast software got fixed. AI just closed that gap to almost nothing. […]

The post AI didn’t break patching. It showed us patching was already broken. appeared first on Heimdal Security Blog.

Risk is concentrating. The 2026 Exposure Gap Report shows vulnerabilities claiming a larger share of critical exposure, and that shift has real implications for how security teams prioritize their response. Two findings are central to this change. Vulnerabilities now represent a much larger share of critical exposure, and only a small percentage of vulnerability alerts are validated as exploitable. Together, these findings show why prioritization depends on context, validation, and a clear understanding of which exposures require action. Exposure Is Shifting Toward Vulnerabilities Vulnerabilities now account for 42.6% of critical exposure, up from 18.7% in 2025. This increase shows that […]

The post Under Pressure: Insights from the 2026 Exposure Gap Report appeared first on Check Point Blog.

The National Cyber Security Centre (NCSC) is warning organisations to prepare for an unprecedented wave of vulnerability disclosures, driven by AI-accelerated exploitation of technical debt. This commentary sets out how Check Point Exposure Management helps government, public sector, and CNI organisations get ahead of it.  The NCSC’s CTO, Ollie Whitehouse, published a clear and urgent warning in May 2026: AI is enabling threat actors to exploit long-standing technical debt at a scale and speed the industry has not seen before. A “patch wave” – a surge of vulnerability disclosures requiring rapid, large-scale remediation – is expected. For organisations operating critical […]

The post The NCSC Patch Wave Is Coming. Do You Know Where Your Risk Lives? appeared first on Check Point Blog.

Blogs

Blog

Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM

In this post, we explore how Flashpoint’s External Attack Surface Management (EASM) capability helps organizations continuously discover internet-facing assets, identify exposure to critical vulnerabilities, and prioritize remediation efforts based on real-world risk.

SHARE THIS:

Flashpoint

June 5, 2026

Table Of Contents

Table of Contents

Understanding the Exposure Gap

Connecting Asset Discovery to Vulnerability Intelligence

Prioritizing What Actually Requires Action

Building a Continuously Monitored, De-Risked Perimeter

Frequently Asked Questions (FAQ)

More

subscribe to our newsletter

The volume of vulnerability disclosures is higher than ever, yet most security teams are still struggling to act.

From vulnerability scanners to public sources and AI-accelerated discovery, organizations are often drowning in findings, but lack the context to prioritize what affects their perimeter and is actively being exploited. 

Compounding this challenge is the growing issue of unknown and forgotten assets. Up to 95% of a company’s assets change each year, creating critical external blind spots and leaving them vulnerable to attacks on unmonitored infrastructure.

As attack surfaces expand due to cloud adoption, shadow IT, acquisitions, and distributed environments, many organizations struggle to maintain control over what assets they own, what software is running on those assets, and therefore, where exposures exist. You can’t patch what you don’t know is there.

These are the challenges Flashpoint External Attack Surface Management (EASM) is designed to address. With the introduction of EASM in Flashpoint Ignite, organizations can continuously discover internet-facing assets, map them to Flashpoint Vulnerability Intelligence, and prioritize remediation efforts based on actual risk rather than vulnerability volume and severity alone.

“The most effective vulnerability management programs are built on more than vulnerability awareness alone,” said Josh Lefkowitz, Co-Founder and CEO of Flashpoint. “Organizations need to understand where exposure exists within their environment and focus remediation efforts where they will have the greatest impact. Flashpoint EASM helps connect vulnerability intelligence directly to exposed assets, giving security teams a clear path from identification to remediation.”

Understanding the Exposure Gap

For many organizations, vulnerability intelligence is no longer the limiting factor.

Security teams have access to more vulnerability data than ever before. They can track newly disclosed vulnerabilities, monitor exploit activity, review KEV catalogs, and identify emerging threats often within hours of disclosure. And Flashpoint customers get the added advantage of learning about vulnerabilities up to 2 weeks faster than NVD, as well as the growing 105K+ vulnerabilities that never make it to public sources.

But understanding whether those vulnerabilities affect assets the organization actually owns remains a challenge. And that challenge exists because asset visibility and vulnerability intelligence often live in separate workflows.

• Asset inventories become outdated. 
• Cloud infrastructure changes constantly. 
• New internet-facing services appear without centralized oversight. 
• Acquisitions introduce unfamiliar infrastructure. 
• Shadow IT creates blind spots that security teams may not discover until after exposure is identified.

As environments become more dynamic, validating exposure often requires analysts to pivot between scanners, spreadsheets, asset inventories, cloud consoles, and vulnerability intelligence sources.

As a result, organizations must face a growing disconnect between understanding which vulnerabilities are out there vs. whether the organization is actually at risk.

Connecting Asset Discovery to Vulnerability Intelligence

Flashpoint EASM begins by discovering internet-facing assets associated with an organization, giving security teams an attacker’s-eye view of their external perimeter. Using seed domains and IP addresses, it initiates ongoing discovery across the external environment, uncovering infrastructure that often evades internal tracking, including:

• Shadow IT and untracked cloud resources
• Forgotten infrastructure and legacy internet-facing assets
• Newly exposed services and subdomains

Once assets are validated, they are surfaced within Ignite and automatically correlated with Flashpoint Vulnerability Intelligence, including pre-NVD findings, KEV intelligence, and proprietary vulnerability coverage beyond public sources. Teams receive alerts when new assets are discovered and when newly identified vulnerabilities affect monitored assets. For a full walkthrough of the workflow, see the Flashpoint EASM product update.

Prioritizing What Actually Requires Action

Not every vulnerability on your attack surface demands the same response. Flashpoint EASM helps teams cut through the noise by combining asset exposure with intelligence on what attackers are actively exploiting, so remediation efforts focus on the vulnerabilities that create meaningful risk.

Rather than focusing on vulnerability severity alone, security teams can now prioritize based on actual exploit activity targeting their attack surface. Flashpoint EASM provides the clarity needed to make that shift.

Building a Continuously Monitored, De-Risked Perimeter

As attack surfaces continue to evolve, organizations need full attack surface visibility, intelligence on what attackers are exploiting, and an efficient path to remediation.

By connecting Flashpoint Vulnerability Intelligence directly to their exposed assets, organizations can move from reactive investigation to having confidence that their external perimeter is continuously monitored and de-risked.

Learn more about Flashpoint External Attack Surface Management and request a demo.

Frequently Asked Questions (FAQ)

What is External Attack Surface Management (EASM)?

External Attack Surface Management (EASM) helps organizations discover, monitor, and assess internet-facing assets that could be exposed to attackers.

This includes domains, subdomains, IP addresses, cloud infrastructure, internet-accessible services, and other externally exposed assets that may introduce security risk.

By continuously monitoring these assets, organizations can better understand their external attack surface and identify exposures that require remediation.

How is Flashpoint EASM different from traditional asset inventories?

Traditional asset inventories, CMDBs, and internal scanners often depend on manual updates and may not reflect the full scope of an organization’s internet-facing environment.

Flashpoint EASM continuously discovers external assets and maps them to Flashpoint Vulnerability Intelligence, helping organizations identify exposures that may otherwise remain difficult to track through static inventories alone.

Why is attack surface visibility important?

As organizations adopt cloud services, acquire new businesses, deploy new applications, and support distributed environments, external attack surfaces change constantly.

Without continuous visibility, security teams may struggle to identify unknown assets, shadow IT, forgotten infrastructure, or newly exposed services that increase organizational risk.

How does Flashpoint EASM help prioritize remediation?

Knowing a vulnerability is severe is only half the picture. Flashpoint EASM correlates discovered assets with our proprietary vulnerability intelligence, including KEV data and pre-NVD findings, so teams can prioritize based on the severity of vulnerabilities present on their actual attack surface.

What vulnerability intelligence is included?

Flashpoint EASM integrates directly with Flashpoint Vulnerability Intelligence, including:

• Proprietary vulnerability coverage beyond public sources
• Pre-NVD vulnerability findings
• Known Exploited Vulnerability (KEV) intelligence
• Vulnerability enrichment and contextual risk information

This allows organizations to understand both exposure and vulnerability relevance within a single workflow.

Does Flashpoint EASM support continuous monitoring?

Yes. Once assets are discovered and validated, Flashpoint EASM continuously monitors the external attack surface for newly identified assets, vulnerable software, exposed services, and relevant vulnerability findings.

Teams can receive alerts when new exposure risks are identified.

How does Flashpoint EASM reduce alert fatigue?

Traditional vulnerability programs generate large volumes of findings without clarity on whether those assets are actually owned or exposed. Flashpoint EASM’s triage inbox lets teams accept true assets and reject noise, ensuring alerts are scoped only to infrastructure the organization actually owns.

Who should use Flashpoint EASM?

Flashpoint EASM is designed for security teams responsible for:

• Vulnerability management
• Attack surface management
• Exposure management
• Threat intelligence
• Security operations
• Risk management

It is particularly valuable for organizations seeking to connect vulnerability intelligence to real-world asset exposure and remediation priorities.

How does Flashpoint EASM work with Flashpoint Vulnerability Intelligence?

Flashpoint EASM extends the value of Flashpoint Vulnerability Intelligence by helping organizations understand where vulnerable assets exist within their external environment.

Rather than viewing vulnerability intelligence and attack surface visibility separately, organizations can use both capabilities together to identify exposure, prioritize remediation, and reduce risk more effectively.

The post Connecting Vulnerability Intelligence to Real-World Exposure With Flashpoint EASM appeared first on Flashpoint.

The FIFA World Cup 2026 kicks off on June 11. Across 16 cities in the US, Canada, and Mexico, billions of people will be watching, traveling, betting, and spending. Threat actors have been watching too, and for far longer. Check Point Research and Check Point Exposure Management spent the past year tracking the cyber threat landscape building around this tournament. What emerged is a coordinated pre-positioning effort across three sectors that sit at the center of the World Cup economy: finance, travel and hospitality, and gambling. The infrastructure is already built, with most of them already live. Financial Sector: Fraud […]

The post Fraud, Ransomware, and Fake Apps Are Already Targeting FIFA 2026 appeared first on Check Point Blog.

As the U.S. approaches the 2026 elections in November, the greatest threat to voting integrity will likely not be from hackers targeting voting machines or altering ballots, but from a growing war over reality itself.   Voter influence operations are increasingly focused on manipulating the information environment surrounding voters, flooding social media and search results with misleading narratives and fake content, and impersonated news sources designed to erode trust in what people see and hear online. Sophisticated operators have already cloned major media brands like Reuters, The Washington Post, and Fox News using look-alike domains that can fool even attentive readers at a glance. In this new era of AI-powered disinformation, the […]

The post The 2026 U.S. Midterms Have a Cyber Problem, But it’s Not at the Ballot Box appeared first on Check Point Blog.

So, you read my previous blog post about breaking the patch sound barrier, but it left you wanting more? Well, this is that “more.”

Here are three useful ideas to advance the conversation.

1. Defining the “Vulnerability Apocalypse”

People love to throw around terms like vulnerability apocalypse, but what does it actually mean? What is the crisp definition? Here:

Anton’s Vulnerability Apocalypse (VulnPocalypse) is …

… a rapid step increase in:

1. The number of software vulnerabilities (including zero-days i.e. vulnerabilities not known to defenders),

2. Speed of exploit development,

3. Volume of exploitation based on them,

4. Resulting incident damage.

With some help from the fine folks on Twitter and LinkedIn — and Gemini, naturally — the above is what I got.

Note that for a situation to truly qualify as “an apocalypse”, all four of these factors must be present simultaneously:

1. Massive Volume: A staggering influx of new vulnerabilities.
2. Rapid Exploit Development: Attackers weaponizing flaws nearly immediately.
3. Evident Exploitation: AI and automated tools scanning and exploiting at scale.
4. Severe Incident Damage: Widespread, material business impact resulting directly from these compromises.

The key? The fourth factor: incident damage. If you have a massive spike in vulnerabilities, but it doesn’t result in actual, widespread related damage, it isn’t an apocalypse — it’s just a high-volume vuln Tuesday.

How do we track that this is indeed coming? This is Part 3 of this saga, coming soon!

2. The Polarization of “Patch Faster”

Ever since advanced models capable of hunting down vulnerabilities emerged, the traditional advice of “just patch faster” has become incredibly polarizing.

Ultimately, my take aligns closely with a recent Cloudflare post: “Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch.”

So, yes, do patch faster. And, no, patch faster won’t save you.

What will? This!

3. A Thought Experiment: The 15-Minute Magic Wand

Let me leave you with a useful thought experiment I recently used in a presentation.

Imagine you wake up tomorrow morning and, by pure force of magic, any vulnerability in your systems, applications, and operating systems can be patched within 15 minutes of patch release. The dream has come true!

Now for the fun part: Reverse engineer that reality.

What fundamental changes had to happen in your environment to make that 15-minute window physically possible?

If you actually run through this exercise, you will discover a goldmine of hidden opportunities. You’ll identify exactly where you can boost asset discovery, streamline software updates, automate testing, eliminate legacy roadblocks, and modernize your architecture. Fun!

Will it actually get your entire enterprise to a 15-minute patch cycle? No, probably not — and definitely not for every legacy application. But it will give you a concrete, actionable roadmap for modernizing your IT.

Let’s hope this was both fun and useful.

Related blog:

• 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? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blogs

Blog

The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation

In this post we break down the technical mechanics of TeamPCP’s recent campaign, the impact on the developer ecosystem, and the urgent steps needed to secure software supply chains.

SHARE THIS:

Flashpoint

May 28, 2026

Table Of Contents

Table of Contents

What is Mini Shai-Hulud?

How Mini Shai-Hulud Works

Four Waves of Supply Chain Attacks

Recommended Immediate Actions

Track TeamPCP and Defend against Mini Shai-Hulud Using Flashpoint

More

subscribe to our newsletter

The developer ecosystem recently faced one of its most significant architectural threats to date, with the threat actor group TeamPCP unleashing Mini Shai-Hulud—a self propagating worm and multi-ecosystem threat. Potentially affecting millions of developers and thousands of companies, Mini Shai-Hulud has fundamentally compromised the trust layer of modern CI/CD pipelines.

The operational tempo of Mini Shai-Hulud has accelerated with every campaign. What began as opportunistic credential theft has now evolved into a high-speed, automated operation that can compromise hundreds of packages in under thirty minutes. From the exfiltration of approximately 3,800 internal GitHub repositories to the poisoning of critical libraries like TanStack and AntV, TeamPCP’s campaign has been incredibly effective in exploiting developer tooling and identity infrastructure.

What is Mini Shai-Hulud?

Mini Shai-Hulud is deployed as a 498 KB obfuscated script executed using the Bun JavaScript runtime. The deliberate choice of Bun, rather than Node.js, is a tactical evasion technique as most endpoint detection and response (EDR) platforms and security information and event management (SIEM) solutions have behavioral rules tuned to Node.js execution patterns.

How Mini Shai-Hulud Works

The worm propagates by stealing npm and GitHub authentication (OIDC) tokens from developer environments, then using those credentials to publish malicious versions of packages the compromised user maintains. To accomplish this, the worm scrapes runner process memory to extract short-lived identity tokens, which it then exchanges for per-package npm trusted-publisher tokens without requiring any long-lived npm secrets.

Credential Exfiltration and Command-and-Control

Mini Shai-Hulud targets credentials across 130 file paths, including npm tokens, GitHub personal access tokens, AWS, GCP, and Azure configuration files, Kubernetes kubeconfig files, Docker credentials, HashiCorp Vault tokens, 1Password and Bitwarden CLI vaults, SSH private keys, and Bitcoin wallet files. 

Exfiltration occurs across multiple channels: the Session Protocol network, the GitHub Git Data API using dynamically created Dune-themed repositories on victim accounts, HTTPS to the threat actor-controlled domain, and an api for GitHub Actions workflow exfiltration.

The worm uses a dead-drop command-and-control (C2) architecture via GitHub’s public commit search API. An installed daemon (kitty-monitor, deployed as a systemd service on Linux or a LaunchAgent on macOS) polls GitHub for commits containing the string “firedalazer,” parses RSA-PSS-signed command payloads from matching commits, and executes them. This technique leverages GitHub as a trusted relay, making C2 traffic difficult to block without disrupting legitimate GitHub usage.

The worm then uses a persistence mechanism as a dead-man’s switch: a GitHub personal access token named “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner” is created on compromised developer machines. If an operator revokes this token without first disabling the persistence mechanism, the worm destroys all home directory data on the compromised device.

AI Agent Hijacking

Beyond standard persistence mechanisms, Mini Shai-Hulud targets AI coding agents. The SafeDep analysis documents that the worm modifies Claude Code’s settings .json to insert a SessionStart hook, enabling the worm to be reinstated with full LLM API privileges even if the infected npm packages are later removed, or the npm cache is cleared. A similar technique targets Visual Studio Code’s tasks.json file using the “runOn”: “folderOpen” trigger, and Codex configuration files are also targeted.

These AI agent hijacking techniques represent a novel attack surface: by persisting within trusted AI tool configurations, the malware can exfiltrate all code and secrets processed by those tools during future development sessions.

Four Waves of Supply Chain Attacks

Flashpoint has observed at least four documented waves of TeamPCP npm and PyPI supply chain attacks in 2026, leveraging Mini Shai-Hulud to compromise developer tooling ecosystems and steal credentials, cloud keys, and source code across tens of thousands of organizations. 

The following timeline tracks the escalation of TeamPCP and the Mini Shai-Hulud waves throughout 2026:

Wave 1: Initial SAP Packages (April 2026)

The first documented wave of Mini Shai-Hulud attacks targeted a small number of SAP-ecosystem npm packages in April 2026. While TeamPCP had already proven their CI/CD attack capabilities in March 2026 by compromising Aqua Security’s Trivy scanner and Checkmarx KICS via GitHub Actions, this initial wave served primarily as a proof-of-concept for the self-propagation mechanism and a reconnaissance phase for TeamPCP’s access broker network. Further, these attacks demonstrated the group’s ability to compromise widely used security tooling—a development that significantly undermines defenders’ ability to trust automated CI/CD pipeline scanning results.

Wave 2: TanStack, Mistral AI, and Guardrails AI (May 2026)

Leveraging a GitHub Actions cache-poisoning technique, TeamPCP published malicious versions of 42 TanStack packages across 84 releases, impacting a project with over 518 million cumulative downloads. 

The attack also compromised Mistral AI and Guardrails AI, extending the attack surface to the AI developer tools ecosystem. Forged commit authorship was used to blend the attacker’s commits into AI-assisted development environments where Claude Code is commonly deployed.

TeamPCP simultaneously listed Mistral AI source code for sale on BreachForums, claiming possession of approximately 5 GB of data across 450 internal Mistral repositories.

Wave 3: AntV Ecosystem (May 2026)

Targeting AntV enterprise data visualization ecosystem, TeamPCP compromised the atool npm account, which held publishing rights across a broad catalog of AntV packages. In 22 minutes, 637 malicious versions were published across 323 packages—a scale and speed that overwhelmed standard security monitoring pipelines.

Each infected package contained the Mini Shai-Hulud worm, which, upon execution, created up to 2,500 compromised repositories on victim accounts within hours.

Wave 4: Co-Ownership of BreachForums and GitHub Breach

In the most recent wave, TeamPCP announced its assumption of co-ownership of BreachForums, the largest English-language cybercriminal forum currently active. This development significantly elevates TeamPCP’s standing and operational reach. As co-owners, the group stated it would manage platform operations, handle dispute resolution, staff and vet moderation personnel, and host monetary contests for the community. The announcement positions TeamPCP as both an active threat actor and a platform-level infrastructure operator, with the ability to shape forum policies, curate the availability of criminal tooling, and influence the broader access broker and ransomware ecosystem.

Additionally, by poisoning a GitHub employee’s development environment, TeamPCP exfiltrated approximately 3,800 internal GitHub repositories. Within the stolen data were highly sensitive codebases such as:

• copilot-api and copilot-token-service
• actions-runtime
• billing-platform
• enterprise-crypto
• authentication
• codeql-core
• detection-engineering
• csirt
• azure-config

Recommended Immediate Actions

Critically, the theft of internal source code from one of the world’s most widely used code hosting platforms creates incredible downstream risk for organizations that depend on GitHub Copilot and GitHub Actions for their own software development pipelines. Organizations running AI coding agents such as Claude Code and VS Code with extensions in their CI/CD pipelines face heightened exposure. Security teams should treat AI agent configuration files as sensitive assets subject to integrity monitoring and change-control policies.

If your organization uses npm, PyPi, or AI-assisted development tools, Flashpoint recommends the following immediate steps:

1. Audit and remove: Immediately audit CI/CD environments and remove all infected versions of AntV, TanStack, Mistral AI, and Bitwarden CLI packages.
2. Rotate credentials: Rotate all cloud credentials (AWS, GCP, Azure) and npm tokens.
3. Disable persistence first: Before revoking suspicious GitHub tokens, ensure the kitty-monitor daemon is disabled to avoid triggering the “dead-man’s switch” wiper.
4. Lock down IDEs: Restrict the installation of VS Code extensions to an approved allow-list and monitor for unauthorized changes to settings.json or tasks.json.
5. Block C2 infrastructure: Block all traffic to identified TeamPCP C2 domains.

Track TeamPCP and Defend against Mini Shai-Hulud Using Flashpoint

Flashpoint assesses with high confidence that TeamPCP will continue to scale its supply-chain attacks against npm, PyPI, and developer tooling ecosystems. The group’s shift from direct execution to orchestrating a broader ecosystem via BreachForums signals a maturation into a platform-layer criminal operation. While TeamPCP has hinted that the group may be approaching “retirement” due to law enforcement pressure, this should be treated with caution. Whether a misdirection or a genuine exit plan, the open-sourcing of Shai-Hulud means the tradecraft is available to the wider cybercriminal community.

Organizations should reference the OpenSSF npm Best Practices guidance for a practical baseline in hardening their package consumption posture. Flashpoint customers can gain access to known Indicators of Compromise (IOCs) and MITRE ATT&CK Mapping for Mini Shai-Hulud by logging into Flashpoint Ignite. To learn more about how Flashpoint tracks threat actor groups like TeamPCP and protects the software supply chain, request a demo.

The post The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation appeared first on Flashpoint.

Attackers are now agentic. AI agents run reconnaissance, test exploits, and weaponize vulnerabilities at machine speed – collapsing the mean time from CVE disclosure to confirmed exploitation from 2.3 years in 2018 to roughly 10 hours in 2026, with 72.7% of exploited CVEs in 2026 hitting as zero days, up from 16.1% in 2018.   Every year, the major breach reports tell the same story. Misconfigurations. Unpatched systems. Identity sprawl. Flat networks. The root causes barely change, and yet organizations continue to get breached, not because they lack visibility into these problems, but because closing them at scale is genuinely hard. Too many […]

The post The Autonomous Security Platform Built for Attacker Speed appeared first on Check Point Blog.