Security work keeps growing. Security teams do not.
That sounds obvious until you look at what a normal week has become.

• A scanner finds a vulnerability.
• Someone has to decide whether it matters.
• A cloud control flags a misconfiguration.
• Someone has to work out who owns the resource, whether a change can be made now, and how to prove the fix held.
• An audit request lands.
• Someone has to find the evidence, chase down the missing pieces, and make sure the same gap doesn't reappear next quarter.

None of those tasks is especially dramatic. That is precisely why they accumulate.

>Security teams have spent years getting better at finding problems, while the work that follows a finding has remained stubbornly human: triage, context gathering, ownership, approvals, remediation, retesting, evidence, and follow-through.

This is the part of security operations that rarely makes the keynote slide, but it is where a surprising amount of the week disappears.

At the same time, AI is moving from describing work to doing it.

That creates a more useful possibility than another copilot, and a more uncomfortable question than "can AI help?"

The real question is:

>How much meaningful security work can an organization safely hand to AI without handing away authority?

That is the problem governed defense is meant to solve.

A practical definition

Governed defense is an operating model in which AI security teammates execute defined security work inside customer-controlled scope, permissions, policies, approval gates, escalation rules, and audit trails. Offensive evidence establishes what is actually exploitable; defensive work uses that evidence to harden, remediate, and verify the outcome.

The work moves to the AI teammate. Authority stays with the organization.

At Secure.com, this is the operating model behind the phrase:

>Governed Defense, Powered by Offense.

It is not another name for compliance, nor a claim that a human must click "approve" on every routine step.

Governance is the architecture around execution: what the AI is allowed to do, where it can do it, when it must stop, who must approve consequential actions, and what evidence is retained afterward.

This is not a theory about what buyers might eventually care about. In our own conversations with security leaders, governance came up unprompted in the majority of them, before pricing, before feature comparisons, and usually before anyone asked about the AI itself.

Why advice-only AI does not solve the capacity problem

The first wave of enterprise AI was easy to understand because it behaved like an assistant.

• Ask a question, get a summary.
• Ask for a recommendation, get a draft.
• Ask for a playbook, get a list of steps.

Useful, certainly, but the human was still the execution layer.

Security exposes the limitation quickly. If an AI can tell an analyst that a host should be isolated, but the analyst still has to open the EDR console, verify the target, get approval, isolate the machine, update the case, collect the evidence, and confirm containment held, then the analyst has gained information but very little capacity.

The obvious response is autonomy. Let the system act.

That is where the conversation usually turns binary: either AI only advises, or AI is turned loose to make its own decisions. Serious security environments need a third option.

A governed AI teammate can own a defined piece of work end to end, but its authority is explicit rather than assumed. It proposes, explains, and executes on confirmation. It escalates when confidence is low. And every recommendation, approval, action, override, and outcome is recorded.

The goal is not autonomy for its own sake. The goal is to move work out of the human queue without letting accountability leave with it.

Governance Has to Be Designed In

Governance earns its place in the sentence only if a technical buyer can point to it. A trust badge is not enough.

Any vendor claiming governed execution should be able to answer six questions concretely:

1. Scope. Is the teammate assigned to a specific function, environment, tenant, asset group, repository, or workflow — and is that scope versioned so that a mid-engagement change cannot retroactively alter work already in flight? It should never begin with open-ended reach.

2. Context. Are its decisions grounded in the organization's own assets, identities, exposure, cases, and prior decisions, or in generic model output?

3. Permissions. Are read, recommend, and act privileges genuinely separable, so a team can widen authority gradually rather than all at once? And can the customer read, in plain language, what a given teammate is permitted to do and where that permission ends?

4. Approval. Which actions proceed, and which pause for a person? The honest default in security is that consequential action - isolate a host, force MFA, change a production configuration - is proposed and approved, not assumed. Approvals also have to reach the people who never log in to a security tool: a line manager, finance, and legal.

5. Evidence. Does the system record what it recommended, what a human approved, what changed, and what happened afterward, in a trail that cannot be quietly rewritten? This is the most checkable of the six. Ask to see the audit record for an action, including the intent captured before approval, not just the change after approval.

6. Feedback. Do overrides, false positives, and outcomes measurably change what gets surfaced next, inside the same function?

A vendor that can answer three of those is selling automation. Governed defense requires all six.

This framing is consistent with the broader direction of AI risk management. NIST's AI Risk Management Framework treats human-AI configurations as a spectrum and emphasizes that oversight should be defined by context and risk, designed, documented, and measured, rather than asserted as a principle.

CISA has made a similar point as agentic AI moves into operational environments, focusing on the oversight challenges that appear once AI systems can take actions rather than only generate text.

That is the line security teams are now crossing.

Why offense belongs inside the defensive loop

Governance explains how AI can act. It does not explain what the defense should act on first. That is where offense becomes useful.

Traditional offensive security often ends with a report.

The report may be excellent, the findings accurate, the remediation advice sound. But the operating model still creates a handoff: offense proves something can break, then defense inherits another backlog.

A more useful model treats offensive evidence as an input to defensive work rather than the end product.

A red-teaming function tests within an approved, versioned scope, validates which weaknesses are genuinely exploitable and how far an attacker could get, and provides the defensive side with evidence of what can actually be used against the environment. From there, the work moves into hardening, remediation, and retesting.

This changes prioritization from probabilistic to demonstrated. A validated exploit chain outranks any severity score, and blast-radius context gives a CISO a defensible sentence:

>This one fix breaks three paths to the crown jewels.

It also sets the bar for honesty on the offensive side:

>Continuous autonomous testing is only safe if the guardrails are structural rather than procedural.

Scope defined as a versioned manifest snapshotted at run start. Every host and port a tool touches is checked against that scope and blocked if it falls outside it, failing closed rather than open.

A kill switch that an operator can pull mid-run, with the safe default always being the more restricted state. And an audit record on every state-changing action, enforced in the build rather than left to discipline.

That is the difference between an autonomous attacker you can run against production and one you can only run in a lab.

Why this matters more now than it did two years ago

There is a reason this conversation feels more urgent. The offensive side is getting leverage.

Frontier models are becoming materially more capable in cybersecurity work, and the labs building them have become increasingly explicit that offensive capabilities are improving alongside defensive capabilities.

Standards bodies and AI labs alike are paying closer attention to how agentic systems are governed, precisely because those systems are no longer limited to producing advice.

The broader point does not depend on any single incident: machine-speed offense compresses the time defenders have to interpret, coordinate, and act.

>The response cannot simply be "more alerts, faster."

Detection that accelerates without execution just produces a faster queue. Defense needs its own leverage, but leverage an organization can explain to a CISO, an auditor, a regulator, and the people operating the systems.

Where AI Ownership Should Start

One of the easiest ways to make agentic security sound unrealistic is to describe the end state first: a fully autonomous security operation, an AI SOC that runs itself, a fleet of agents handling everything.

Most buyers do not want to start there, and they should not have to.

A more credible starting point is one function with a clear outcome and a clear authority model.

• A SOC Teammate can own triage, enrichment, case assembly, execution of approved playbooks, and escalation to a human when judgment is required.
• A CSPM Teammate can own cloud posture analysis, attack-path context, framework mapping, remediation workflow, and verification that the fix held.
• An AppSec Teammate can prioritize by exploitability rather than finding count, route work to the owner who can actually fix it, support the fix, and validate the result.
• Red Teaming can test an approved environment, validate what is genuinely exploitable, and retest after remediation- the proof unit that closes the loop and turns the other three from opinion into evidence.

Each of those functions creates value on its own.

The point is not to make the first purchase depend on a future ecosystem. Start with the work consuming the most human time, govern it properly, prove the result, and expand only when the first function has earned trust.

The real outcome is capacity, not "more AI"

This brings the argument back to where it started.

>Security teams are not short on intelligence.

They are short on the hours required to carry every repetitive step that modern security work creates.

The commercial value of governed defense should therefore be measured by:

• work completed
• queues reduced
• handoffs eliminated
• remediation followed through on
• and hours returned to people who have better things to do than reconcile consoles or chase evidence.

That framing matters, because "AI replaces analysts" is both unhelpful and inaccurate. Judgment becomes more valuable as AI takes on more execution.

Risk acceptance, architecture, exceptions, incident command, business trade-offs, and consequential approvals still belong to accountable people. The opportunity is to stop spending those people on work that never needed their judgment in the first place.

The shift is from visibility to accountable execution

For a long time, security software was mostly rewarded for seeing more.

More telemetry, more detections, more findings, more context. That made sense when visibility was scarce.

The bottleneck has moved. Teams can usually see the work.

What they cannot do indefinitely is carry every handoff, investigation, approval, remediation step, evidence request, and retest themselves while the volume keeps growing.

Agentic AI gives security a chance to change that operating model, but only if action and control are designed together. Advice-only systems leave the workload with people. Ungoverned autonomy creates an accountability problem.

Governed defense sits between those extremes:

>AI does meaningful work inside boundaries the organization sets, reviews, and can defend.

Offense then gives the system a way to keep learning what matters. Attack evidence informs hardening. Hardening is verified. The result feeds the next cycle.

>The goal is not an autonomous security department. It is a security team that can finally scale its capacity without causing chaos.

At Secure.com, the short version is simple: the work moves; control stays.

That is what we mean by Governed Defense, Powered by Offense. See how it works

When someone asks what tools a red team needs, throwing out a list of Nmap, Burp Suite, Metasploit, BloodHound, and Cobalt Strike isn't particularly useful. Those are all relevant tools, but a real red team stack depends on what you're testing, what stage of the intrusion you're emulating, and what the exercise is supposed to prove.

A web app assessment, an assumed-breach Active Directory exercise, and an adversary emulation against a SOC are three very different jobs.

So rather than ranking tools, here's how I'd think about the red team toolkit by function.

1. Reconnaissance and attack-surface discovery

Common tools: Nmap, Masscan, Amass, Nuclei

Before exploitation comes enumeration. You need to understand what is exposed, which services are running, where the interesting applications reside, and which parts of the attack surface warrant manual attention.

Nmap is still one of the basic pieces of kit for host discovery, service enumeration, version detection, and network mapping. Masscan is useful when the address space is large and speed matters, while Amass is useful for external asset and subdomain discovery.

Nuclei sits somewhere between reconnaissance and vulnerability discovery. Its template-driven approach makes it useful for quickly checking large numbers of targets for known exposures and misconfigurations, although I wouldn't treat a Nuclei hit as proof of exploitability on its own.

The output from this phase should narrow the attack surface, not become a giant list of scanner findings.

2. Web application and API testing

Common tools: Burp Suite, OWASP ZAP, ffuf

For web work, Burp Suite remains difficult to avoid. Proxying requests, manipulating sessions, replaying traffic, testing authentication flows, and manually investigating application logic are bread-and-butter activities for app-focused operators.

OWASP ZAP is a useful open-source alternative, particularly when automated scanning needs to be incorporated into a repeatable workflow.

ffuf is also worth having around for content discovery, endpoint enumeration, and fuzzing.

This is one area where operator judgment matters far more than the scanner. Automated tooling can find a suspicious endpoint. Understanding that two individually unremarkable weaknesses can be chained together to enable account takeover is where the actual assessment starts to get interesting.

3. Exploitation

Common tools: Metasploit Framework, custom exploit tooling

Metasploit is still useful because it provides a mature framework for exploit development, validation, payload handling, and post-exploitation.

That doesn't mean every red team engagement should become search → use → exploit.

Good operators frequently modify public exploits, build their own tooling, or reproduce techniques manually because the objective is not simply to demonstrate that a CVE exists. The useful question is whether that weakness can be turned into an attack path in this particular environment.

That distinction matters when you're talking about a red team assessment rather than a vulnerability scan.

4. Active Directory and identity attack paths

Common tools: BloodHound, Impacket, NetExec

Identity is where many internal engagements become interesting.

BloodHound is valuable because it turns Active Directory relationships into attack paths. Instead of looking at users, groups, sessions, and privileges independently, you can see how apparently minor permissions combine into a route toward a high-value identity or system.

Impacket provides a collection of Python implementations of network protocols widely used for Windows and Active Directory assessments.

NetExec is useful for enumeration and authorized testing across Windows/AD environments.

For modern red teams, understanding identity relationships is often more valuable than finding another unpatched endpoint. Attackers increasingly get somewhere interesting by abusing legitimate access rather than dropping an exotic exploit.

5. Command and control and adversary emulation

Common tools: Cobalt Strike, Sliver, MITRE CALDERA

Once the objective shifts to emulating an actual intrusion rather than finding vulnerabilities, you need tooling that supports post-compromise activity and adversary behavior.

Cobalt Strike is probably the best-known commercial platform in this category.

Sliver is an open-source C2 framework that is increasingly common in offensive security labs and authorized assessments.

MITRE CALDERA takes a somewhat different approach. It is an automated adversary-emulation platform built around the ATT&CK framework and can be useful when teams want repeatable execution of known adversary behaviors rather than purely manual operations.

This is also where MITRE ATT&CK itself becomes part of the toolkit. It isn't an exploitation tool, but it provides red and blue teams with a shared taxonomy for planning exercises based on real adversary tactics, techniques, and procedures.

6. Automated pentesting and continuous offensive validation

Platforms worth evaluating: Horizon3.ai NodeZero, Pentera, Secure.com

This is the newer part of the red team stack and shouldn't be confused with vulnerability scanning.

Platforms such as Horizon3.ai and NodeZero focus on autonomous pentesting and attack-path validation, in which the system attempts to demonstrate how weaknesses can be chained rather than simply listing vulnerabilities.

Pentera focuses on automated security validation and adversary emulation across internal networks, identity, cloud, and external attack surfaces, with retesting to validate remediation.

Secure.com takes a broader approach to AI Teammate. Its Red AI Teammate covers external exposure, continuous pentesting, adversary emulation, exploit validation, and detection validation, while running on the same Security OS as defensive teammates. The interesting part of that model is the offense-to-defense workflow: an offensive finding can become defensive work and then be retested rather than ending its life in a PDF.

These platforms aren't necessarily replacements for experienced red team operators. They make the most sense for repeatable attack paths, continuous validation, and for work you want to run more frequently than a manual engagement can economically allow.

So what are the essential tools used by red teams?

If I had to build a practical red team toolkit rather than collect every offensive-security tool on GitHub, I'd want coverage across these functions:

Function	Examples
Network discovery	Nmap, Masscan
External reconnaissance	Amass
Vulnerability discovery	Nuclei
Web/API testing	Burp Suite, OWASP ZAP
Fuzzing/content discovery	ffuf
Exploitation	Metasploit, custom tooling
AD/identity analysis	BloodHound
Windows/AD operations	Impacket, NetExec
C2	Cobalt Strike, Sliver
Adversary emulation	MITRE CALDERA
ATT&CK mapping	MITRE ATT&CK
Automated pentesting/validation	Horizon3.ai NodeZero, Pentera, Secure.com

The exact stack matters less than whether it supports the exercise's objective.

What is the main purpose of red teaming in cybersecurity?

A proper red team isn't trying to produce the longest vulnerability report.

The main purpose of red teaming is to simulate realistic adversary behavior and determine whether an organization can prevent, detect, and respond to an attacker pursuing a defined objective.

That objective might be to obtain domain-level privileges, access a sensitive application, access regulated data, compromise a critical cloud workload, or demonstrate whether an attacker can move from an initial foothold to a high-value asset.

This is one reason I wouldn't use "penetration test" and "red team exercise" interchangeably.

A penetration test generally focuses on finding and validating vulnerabilities within an agreed scope. A red team exercise is typically more objective-driven and evaluates how the wider security program performs against realistic adversary behavior, including whether defenders notice what is happening.

What happens during a red team exercise?

The exact methodology varies, but a mature engagement usually starts with an objective, threat model, scope, and rules of engagement.

The red team then develops an attack path that includes reconnaissance, initial access, privilege escalation, credential access, lateral movement, persistence, and other relevant techniques. Those actions can be mapped to MITRE ATT&CK so the organization has a common record of the TTPs exercised.

The important output isn't simply "we got Domain Admin."

You want to know:

• Which attack paths worked?
• Which controls stopped something?
• Which activities generated telemetry?
• Which techniques generated useful detections?
• What did the SOC miss?
• How far could the operator move?
• What needs remediation?
• Can the defensive improvement hold up on retest?

Those questions turn an offensive exercise into security evidence.

What should a red team assessment include?

At minimum, I'd expect the final assessment to document the objective and scope, attack path, techniques used, affected assets and identities, evidence of successful exploitation, detection and response observations, business impact, remediation priorities, and what should be retested.

One of the biggest mistakes is treating the final report as the end of the engagement.

If a red team demonstrates an exploitable path on Monday, the organization remediates it on Friday, and nobody attempts the path again, you know a change was made. You don't actually know whether the attack path was closed.

Retesting is what turns remediation from an assumption into evidence.

How do red teams and blue teams collaborate during cybersecurity exercises?

This is where purple teaming becomes useful.

During a collaborative exercise, the red team executes a known adversary technique while the blue team observes the telemetry, detections, and response behavior. Both sides compare what the attacker actually did with what the defensive stack actually saw.

If the technique wasn't detected, the blue team investigates why. Maybe the telemetry wasn't collected. Maybe the SIEM had the data but no useful analytics. Maybe an alert fired without enough context for an analyst to recognize the behavior.

The defensive team fixes the gap, then red executes the technique again.

That creates a much healthier loop:

Execute technique → observe telemetry → identify detection gap → tune defense → retest

MITRE ATT&CK works particularly well as the common language here because both sides can discuss the exact technique being employed rather than vaguely saying that "the EDR missed the attack."

This is ultimately where I think red teaming delivers the most value. Finding a path into the environment matters, but converting what the attacker learned into a better defensive control, then proving that control works, is what actually improves the security program.

What would you add to the stack?

Traditional pentesting assumes deterministic software with fixed boundaries, you send input X, you get output Y. Agentic AI breaks that assumption entirely: the same prompt can produce different outputs on consecutive runs, and the system reasons in natural language rather than following fixed code paths.

Testing an AI agent means covering four attack layers a normal web app doesn't have (planning, tool calls, memory, non-determinism), and real engagement data shows most agents fail at least one of them. Full breakdown of the methodology, the tooling landscape, and what actually changes below.

Why your existing pentest methodology doesn't cover this

Worth stating the core problem plainly before anything else: traditional penetration testing evaluates known software against known attack vectors, operating on the assumption of fixed software with defined boundaries. Agentic AI is none of those things.

An agent plans its own next action, calls tools with real privileges, persists memory across sessions, and can be manipulated through plain English rather than a crafted payload. The question isn't whether your current methodology covers this, it doesn't, the question is what actually replaces it.

First, get the terminology straight, because these four things aren't the same discipline

This is where a lot of confusion starts, and it matters for scoping any engagement correctly:

• Traditional penetration testing asks "can we gain unauthorized access?" within a bounded, usually announced scope, testing infrastructure, APIs, and applications for known weaknesses.
• Traditional red teaming asks "can we achieve this objective?" with fewer method constraints, simulating a real adversary across systems, people, and process, testing detection and response, not just technical flaws.
• AI penetration testing tests the technical system surrounding the model, prompts, the retrieval layer, APIs, and agent architecture, for exploitable defects, the same discipline as traditional pentesting applied to new terrain.
• AI red teaming tests the model or agent itself for harmful behavior under adversarial prompting, jailbreaks, and manipulation, a fundamentally different skill set than infrastructure testing.

The reason this distinction isn't academic: an AI penetration tester's techniques won't catch a jailbreak, and an AI red teamer's techniques won't catch broken authorization. Attackers don't respect that boundary, the most serious real-world incidents combine a weakness in model behavior with a flaw in the code wrapped around it, and that combination lives specifically wherever agents are wired to take action.

The four-layer attack surface a web app pentest never touches

One red team firm's framework, built from real 2026 engagements, breaks agent testing into four layers:

1. Planning layer. The layer that interprets natural language and decides what action to take next. This is where goal hijack lives, an attacker plants instructions in content the agent processes (an email, a document, a tool's output) that redirects what the agent believes it's supposed to be doing.
2. Tool layer. Where the agent calls external systems with real, often broad, privileges. This is the layer GitLost and the OpenAI/Hugging Face incidents both exploited, an agent with more access than the task in front of it actually requires.
3. Memory layer. Context that persists across sessions or users. Poisoned early, false information gets treated as established fact in every later decision, and the injection can be split across multiple sessions specifically so earlier pushback falls out of context before the poisoned fact gets acted on.
4. Non-determinism. The same input can produce different outputs run to run, which means testing requires statistical sampling across many variations, not a single pass. A vulnerability that doesn't trigger on attempt one may trigger on attempt eleven.

The same firm's Q1-Q2 2026 engagement data across 12 AI agent assessments is worth sitting with directly: 8 of 12 agents were vulnerable to indirect prompt injection via tool output, 7 of 12 had over-privileged agent tokens with broader access than any individual human user on the same system, 9 of 12 had no rate limiting on the agent endpoint at all, and 4 of 12 had memory poisoning that crossed user boundaries entirely.

That's not a handful of edge cases, that's the majority of tested agents failing at least one fundamental control.

Why point-in-time testing specifically fails here

A regular pentest report from six months ago tells you something useful about six months ago. For agentic systems, the attack surface changes every time the underlying model, system prompt, or tool integration changes, not on a fixed quarterly or annual schedule.

Continuous testing, re-running adversarial checks after every meaningful configuration change, catches regressions that a point-in-time engagement structurally cannot. This is the same logic driving the shift toward continuous red teaming in infrastructure security generally: a red team report from last spring says almost nothing about the risk sitting in your environment today, and the same principle applies with even more force to a system whose behavior can drift with every model update.

The tooling landscape, and where the boundaries actually sit

• Open-source scanners for baseline model behavior: Garak (NVIDIA) produces baseline scores across prompt injection, jailbreaks, and sensitive data leakage. PyRIT (Microsoft's Python Risk Identification Tool) supports structured adversarial probing. Both are useful for the planning-layer and model-behavior side of testing, neither covers the infrastructure or tool-permission side on its own.
• Dedicated AI red-teaming platforms: Firms like Noma Security and HackerOne's AI Red Teaming offering focus specifically on adversarial testing of the model and agent behavior itself, jailbreaks, manipulation, and the kind of goal-hijack testing the planning layer requires.
• The infrastructure and tool-permission side: This is where agent-adjacent testing overlaps with traditional attack-path analysis. Secure.com's Infrastructure Security Teammate runs continuous, automated attack-path testing mapped to MITRE ATT&CK across cloud, IAM, and application layers, relevant specifically to the tool layer of agent testing, since an agent's real-world risk is bounded by exactly the privileges and access paths a continuous infrastructure red team would already be mapping. Worth being precise about scope here: this class of tool tests what an agent can reach and do once it has a foothold, it isn't a substitute for model-level adversarial testing (jailbreaks, prompt injection against the model itself), which requires the LLM-specific tooling above. A complete program needs both.

A basic methodology to actually run this

• Map all four layers before testing anything. Identify every memory write path (explicit tool calls, automatic derivation from conversation, RAG ingestion), every tool the agent can invoke and the privilege level each grants, and every point where untrusted content reaches the planning layer.
• Test goal hijack with realistic, not obvious, injections. The GitLost disclosure showed a single reframing word ("additionally") was enough to defeat a guardrail, subtle phrasing matters more than obviously malicious-looking prompts.
• Test cross-session and cross-user memory isolation specifically. Craft an adversarial input in one session, switch to a different user context, and check whether the poisoned content loads into the new session.
• Run statistical sampling, not single-pass tests. Given non-determinism, a finding that doesn't reproduce on the first attempt isn't cleared, run the same adversarial input multiple times before ruling a path safe.
• Test the seam between the model and the infrastructure around it, not just each in isolation. A guardrail that holds when the model is tested alone can fail once it's reachable through a misconfigured endpoint the infrastructure side never flagged, this is the gap both disciplines miss when run separately.

The Cybersecify data (8 of 12 agents vulnerable to indirect prompt injection, 9 of 12 with no rate limiting at all) suggests most organizations deploying agents right now haven't actually had either kind of testing done yet, model or infrastructure.

TLDR

JetBrains disclosed CVE-2026-63077 on July 28, a critical, unauthenticated remote code execution flaw affecting every on-premises version of TeamCity, JetBrains' widely used CI/CD server.

An attacker with no credentials at all can bypass authentication through the agent polling protocol and run arbitrary OS commands with the privileges of the TeamCity server process. JetBrains has patched it and released a plugin for anyone on older versions who can't upgrade immediately, and there's no evidence of active exploitation yet.

What's worth knowing before deciding how urgently to treat that last point: the last two times TeamCity had a vulnerability in this exact severity class, unauthenticated, HTTP(S)-reachable, full server compromise, two separate North Korean state-backed groups and Russia's APT29 were exploiting it within days of disclosure.

What the vulnerability actually does

CVE-2026-63077 carries a CVSS score of 9.8. The root cause is insecure deserialization of untrusted data in TeamCity's agent polling protocol, the channel build agents use to check in with the server for jobs and configuration updates.

An attacker with no valid session, no username, and no prior access can send a crafted payload to that endpoint and execute operating system commands directly. Depending on what the TeamCity server process has permission to touch, that can mean exposure of stored credentials and build configurations, or direct modification of server state, including the artifacts and deployment steps a build pipeline produces.

Why this specific severity class has a track record worth taking seriously

In September 2023, JetBrains patched CVE-2023-42793, an unauthenticated authentication bypass in TeamCity. Within days, Microsoft observed two North Korean state-sponsored groups it tracks as Diamond Sleet and Onyx Sleet exploiting it to drop backdoors and implants.

By December, APT29, the Russian group behind the 2020 SolarWinds compromise, was also actively exploiting the same flaw. CISA and international partners issued a joint advisory on it. In February 2024, JetBrains disclosed CVE-2024-23917, another unauthenticated bypass in the same severity class, and Arctic Wolf's assessment at the time was blunt: threat actors were likely to turn their attention to it quickly given what a compromised TeamCity server enables.

A month later, JetBrains patched a further pair of authentication bypass flaws in March 2024. That's three separate critical, unauthenticated compromise vulnerabilities in this product across roughly 18 months, two years before this one, and the first of those three was weaponized by two different nation-state actor groups within the same week it was disclosed.

Why an unexploited CVE today doesn't mean a quiet one tomorrow

JetBrains is explicit that there's no evidence of in-the-wild exploitation of CVE-2026-63077 as of disclosure. That's meaningfully different from a flaw with active attacks already underway, and it's worth not overstating the current state of things.

But the 2023 pattern shows the gap between disclosure and weaponization for this exact vulnerability class in this exact product can be measured in days, not weeks, particularly once a proof-of-concept becomes public.

Shadowserver was tracking thousands of internet-exposed TeamCity servers during the 2024 disclosure. A meaningful number of instances typically remain unpatched well past the point attackers start looking.

What this means for teams running TeamCity today

The direct fix is straightforward: upgrade to 2025.11.7 or 2026.1.3, or apply JetBrains' security patch plugin if an immediate upgrade isn't feasible; it covers versions back to 2017.1.

Beyond the patch itself, this is worth treating as a prompt to check whether your TeamCity server's agent polling port is reachable from anywhere it doesn't need to be, restricting it to trusted internal build agent ranges is JetBrains' own interim guidance, and internet-facing admin or polling endpoints on CI/CD infrastructure are exactly the kind of exposure that's easy to lose track of once a server's been running quietly for a year or two.

That last point is the broader lesson we keep coming back to: a build server that was locked down at deployment time doesn't stay that way on its own, and a point-in-time review has no way of catching a newly exposed polling endpoint that appeared six months after the last assessment.

We've written about why annual testing cadences miss exactly this kind of drift and what continuously re-checking exposure against a changing environment actually looks like in practice; both are directly relevant to the kind of internet-facing CI/CD infrastructure this vulnerability targets.

FAQs

1. Does the absence of confirmed in-the-wild exploitation mean this vulnerability is lower priority than the 2023 and 2024 TeamCity flaws were at disclosure?
Not based on the historical pattern. CVE-2023-42793 also had no confirmed exploitation at the moment of disclosure, and nation-state actors were actively using it within the same week once a proof-of-concept became available. The absence of confirmed exploitation today describes the current moment, not a reliable predictor of the next several days.

2. Is patching the CVE itself sufficient, or does the underlying exposure pattern need separate attention?
Patching closes this specific vulnerability. It doesn't address whether the server's agent polling port or other administrative interfaces are reachable from a broader network segment than necessary, which is the condition that turns any future TeamCity vulnerability, this one or the next one, into an immediately exploitable exposure rather than a theoretical one.

3. Why does TeamCity specifically keep producing this exact severity class of vulnerability?
Multiple distinct root causes have produced the same practical outcome, unauthenticated full server compromise, across 2023, 2024, and now 2026: an alternate authentication path issue, then another authentication bypass, now insecure deserialization in a different protocol entirely. That suggests the risk isn't tied to one specific code defect so much as the general hazard of a CI/CD server exposing multiple authentication-adjacent surfaces to the network, each one a fresh opportunity for a distinct implementation flaw.

4. Does restricting the agent polling port to trusted IP ranges fully mitigate the risk if patching is delayed?
It meaningfully reduces exposure but isn't equivalent to patching. Network-level restriction depends on those trusted ranges staying accurate and on no compromised internal host being able to reach the port, whereas the patch removes the underlying deserialization flaw regardless of network position.

Qualys disclosed RefluXFS on July 22, a race condition in the Linux kernel's XFS reflink handling that's been present since kernel 4.11 in 2017.

An unprivileged local user can overwrite root-owned files at the block layer, and the overwrite survives reboot while leaving every piece of metadata (ownership, permissions, timestamps, the setuid bit) completely untouched. No mitigation exists short of patching. Qualys estimates over 16 million systems are potentially exposed.

What happened

RefluXFS is a race condition in XFS's copy-on-write reflink handling, tracked as CVE-2026-64600. Qualys demonstrated it against /etc/passwd and setuid-root binaries on a default RHEL 10.2 install, stripping the root password entirely in under 10 seconds in testing.

Here's the mechanism in plain terms. An attacker clones a root-owned file using FICLONE, which only needs read access to the source file. XFS reflinks work via copy-on-write, meaning both the original and the clone initially point to the same physical disk blocks.

The kernel checks whether a block is shared while holding a lock, then briefly releases that lock to reserve transaction space. During that exact gap, a second concurrent write can complete its own copy-on-write operation and remap the clone to a different block.

When the first operation resumes, it's still holding the old, now-stale block reference, and writes directly into it using O_DIRECT, which bypasses the page cache entirely and skips the revalidation check that would normally catch this. The result: an attacker's write lands inside a root-owned file, at the disk block layer, with no ownership change, no permission change, and no log entry generated in testing.

Why the usual defenses don't help here

This is worth understanding precisely because it explains why patching is genuinely the only option. Memory protections like KASLR and SMEP protect against memory corruption, this is a block-layer disk write, not memory corruption, so they never come into play.

SELinux in Enforcing mode, seccomp, and kernel lockdown all failed to stop it in Qualys' testing, since none of them restrict the specific combination of write and ioctl permissions the exploit needs, permissions an ordinary profile grants by default. Container boundaries and user-namespace restrictions don't help either, since the flaw operates below the layer those mechanisms isolate.

Who's exposed

Three conditions all need to be true: the system runs Linux 4.11 or later without the fix, the XFS filesystem was created with reflink=1, and the target file and an attacker-writable directory sit on the same XFS filesystem.

That combination is the default on RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, and CloudLinux 8, 9, and 10, Fedora Server 31+, and Amazon Linux 2023 (plus Amazon Linux 2 images from December 2022 onward). Debian, Ubuntu, SLES, and openSUSE aren't affected by default since they don't typically use XFS as the root filesystem, only exposed if an admin specifically chose XFS with reflink enabled.

Check your own systems with: xfs_info / | grep reflink= (also worth running against any other mounted XFS volume where a protected file and an attacker-writable directory coexist).

The AI angle, reported plainly

Qualys says it pointed Claude Mythos Preview, a restricted-access Anthropic model, at the kernel and asked it to hunt for a Dirty COW-style race condition. The model located the race, wrote a working exploit, and drafted the initial advisory, which Qualys engineers then independently verified before coordinating disclosure.

Worth noting this isn't happening in a vacuum: Linux maintainers have raised real concerns this year about AI-assisted bug hunting producing low-quality noise, and curl's maintainer shut down its own bug bounty program in January after a wave of AI-generated reports collapsed the validity rate below 5%. RefluXFS is a case where the model's output held up under human verification, but that's a distinct claim from AI bug hunting being reliable at scale across the board, and the two shouldn't be conflated.

Patch status

The fix merged upstream on July 16. Red Hat's errata began landing as early as July 14, several days before coordinated disclosure, so anyone who patched on Red Hat's normal cycle was already covered before this vulnerability had a public name.

Debian's tracker shows the fix in trixie-security as kernel 6.12.96-1, with trixie's base kernel and forky still listed as vulnerable as of this writing. Installing the update alone isn't enough, since the running kernel stays in memory until reboot.

What to actually do

• Check xfs_info output on every XFS volume, root filesystem and otherwise, for reflink=1
• Confirm your specific RHEL/Fedora/Amazon Linux stream has an applicable advisory, coverage is stream-specific, don't assume patched-in-general covers your exact release
• Patch, then reboot, don't treat package installation alone as remediation
• Prioritize multi-tenant and CI/CD systems first, anywhere untrusted local code execution is possible, since that's the realistic path to triggering this

TLDR

Prioritization is the real bottleneck in red teaming, not test volume. A mid-market SaaS company found 127 attack paths in a single week once it moved from an annual pentest to continuous testing, and none of those paths showed up in the prior year's report.

The part that actually separates a useful red team exercise from a pile of low-priority findings is scoring targets by business impact before testing even starts, then chaining individual weaknesses the way a real attacker would, instead of listing bugs by CVSS severity.

Why A Single Weakness Rarely Matters On Its Own

A leaked credential by itself is a low-severity finding. That same credential paired with an over-permissioned service account and a misconfigured trust relationship can be a direct route to a customer database. The chain is what gets flagged urgent, not any one link in it. This is why crown jewel scoring has to happen before testing starts.

A test server nobody uses matters less than the system holding customer records, so attack paths get prioritized by what they actually reach, not just whether they're technically exploitable.

The Parts That Show Up Most in Prioritization

A few attack simulations recur constantly at this stage: privilege escalation chains, lateral movement, cloud identity and entitlement abuse (over-permissioned IAM roles are one of the most common ways attackers expand access), insider misuse, and third-party or supply chain paths.

None of this replaces human judgment. It just means testers spend their time on the chains worth their attention instead of manually tracing every possible path by hand.

Why This Breaks Down Without Continuous Discovery

Prioritization only works if the asset inventory feeding it is current. An annual pentest only covers what existed on scope-definition day; everything spun up after that stays untested until next year.

That's the actual mechanism behind the 127-path number: continuous discovery surfaced attack paths a point-in-time scope could never have caught, because most of those assets didn't exist when the last pentest was scoped. We wrote up the full mechanics of this, including how findings get deduplicated and mapped to MITRE ATT&CK, in our breakdown of how AI red team workflows actually run.

FAQs

1. Does attack path prioritization replace CVSS severity scoring, or sit on top of it?
It sits on top. CVSS still describes how exploitable a single finding is, but it says nothing about what that finding connects to. A high-CVSS bug on an isolated test server can rank below a chain of medium-severity issues that reaches a crown jewel.

2. How do you score a crown jewel before a test has even run?
By business impact rather than technical exposure, usually a CIA-style rating (confidentiality, integrity, availability) applied to the asset itself. A production database holding customer records gets scored high regardless of how hardened it currently looks.

3. What's the actual failure mode of point-in-time pentest scoping?
It's not that the test misses vulnerabilities in what it covers. It's that anything provisioned after the scope was locked in- new cloud instances, forgotten subdomains, shadow SaaS- never gets tested until the next annual cycle.

TLDR

A hacker breached Suno, the $5.4B AI music generation platform, using the Shai-Hulud npm supply chain worm, the same worm family behind the Mini Shai-Hulud campaign we mapped in our supply chain attack surface breakdown.

The leaked source code confirms Suno used commercial proxy services to bypass YouTube's bot detection while scraping over 380,000 hours of audio, and the breach also exposed customer payment data that Suno never disclosed to affected users.

This one incident sits at the intersection of a live supply chain threat, an active copyright case, and an unreported data breach, which is a combination worth breaking down piece by piece.

What Happened: Shai-Hulud NPM Worm to SUNO Breach

The hacker, using the handle ellie.191, gained access through Shai-Hulud, a self-replicating npm supply chain worm that Unit 42 first identified in September 2025. The worm compromises a developer's npm install pipeline, harvests GitHub tokens and cloud credentials from the infected environment, then replays those credentials against the target's own repositories and infrastructure.

That path gave ellie.191 access to Suno's private GitHub repositories and cloud services, pulling source code from 2023 and 2024 along with the full customer database. Suno has confirmed the breach dates to November 2025, roughly two months after Unit 42's public disclosure of the worm.

The gap between disclosure and patching is the part that should concern anyone running a dependency-heavy engineering org, since it means the exploited entry point was already known and documented before it was used against Suno.

What The Leaked Source Code Actually Exposed

The dataset files inside the leaked code list exact scraping tallies by platform: 152,162 hours of tagged YouTube Music, 113,879 hours of untagged YouTube Music, 62,117 hours from Pond5, 19,514 hours from IMSLP, 17,615 hours from Genius, 12,287 hours from Deezer, plus smaller pulls from Jamendo, Freesound, and MuseScore.

The documented total exceeds 380,000 hours, close to 43 years of continuous audio, and a separate pipeline targeted roughly one million hours of podcast audio through PodcastIndex.

The code also names the tool used to acquire it: Bright Data's commercial proxy network, used to rotate IP addresses and get past YouTube's bot detection systems specifically.

Why This Is A DMCA Problem, Not Just A Data Breach

That proxy detail matters beyond the copyright fight already underway. DMCA Section 1201 makes bypassing a technological measure that controls access to copyrighted work independently actionable, with no fair use defense available regardless of how a court eventually rules on the underlying training question.

The RIAA already raised this circumvention theory in its amended complaint against Suno, and the leaked code now names the specific proxy tool used to do it.

Practically, this means Suno could win the fair use argument in Massachusetts federal court, where dispositive motions are now scheduled for April 2027, and still face a separate, unresolved liability track for how the data was acquired in the first place.

Where SUNO's Breach Notification Falls Short

Alongside the source code, the intrusion reached emails, phone numbers, and Stripe payment details for hundreds of thousands of Suno users. Suno has called the incident limited and has not notified any affected user, citing the fact that it doesn't retain full card numbers as grounds for no sensitive personal information being compromised.

Massachusetts law, where Suno is headquartered, requires notification to any resident whose email or phone number is accessed by an unauthorized party. Several affected users confirmed to journalists they received no notification of any kind.

This is worth flagging for any GRC or incident response team benchmarking their own breach notification thresholds, since "limited scope" is a self-determined legal conclusion, not a fixed regulatory bar.

The Broader Shai-Hulud Pattern: Why This Keeps Happening

Suno is a downstream casualty of a worm that's still active and mutating. Shai-Hulud's source code was later dumped publicly on GitHub, and copycat actors have already weaponized the leaked, non-obfuscated code in fresh campaigns.

We broke down the mechanics of this exact campaign, including the OIDC token extraction and CI/CD cache poisoning techniques that made it possible for malicious packages to carry valid SLSA provenance, in our supply chain attack surface map.

The pattern holds across both posts: the entry point is trusted infrastructure the organization already relies on, not a new vulnerability in its own code.

Where This Actually Breaks Down

Suno's breach shows what happens after a supply chain worm succeeds, not just how the worm itself spreads. Most organizations think about npm compromise as a code integrity problem.

Suno's case shows it's just as often a data exposure problem, since the same compromised credentials that let an attacker publish malicious packages also let them read whatever source code and customer data sits behind those credentials.

We think about this as the execution gap between detecting that a dependency was compromised and verifying what that compromise actually reached. Most teams can tell you a package was flagged.

Far fewer can tell you, with confidence, what that access touched before it was cut off. That's the harder question, and it's the one this breach answers for Suno, whether the company intended to answer it or not.

TLDR: Nearly every "Top AI SOC Platforms" list online right now is published by one of the vendors it ranks, and unsurprisingly, that vendor comes out on top.

This post skips the rankings entirely and gives you the actual evaluation framework: what category a platform falls into, the questions that separate real automation from a chat assistant bolted onto a SIEM, and the red flags that show up in a POC before they show up in your bill.

Why every "best AI SOC" list you find is a trap

Search "best AI SOC platforms 2026" right now and you'll find a dozen near-identical articles, each from a different vendor, each ranking that same vendor first, using a scoring methodology the vendor itself designed.

One such guide openly admits its own bias in the methodology, noting that every "best of" list has a bias baked into its scoring and the honest move is to show it rather than hide it. That's the exception, not the rule. This guide takes a different approach: no rankings, just the criteria, so you can score any vendor on your own shortlist yourself.

What an AI SOC platform actually is

For anyone still sorting out the terminology: an AI SOC platform is a security operations tool where AI agents carry out the core SOC functions (detection, triage, investigation, and response) by reasoning over correlated security data, under human oversight, rather than following a fixed script.

That's the distinction from SOAR (which runs pre-written playbooks and can't handle anything it wasn't scripted for) and from a basic "AI copilot" (which summarizes alerts but doesn't act on them).

Gartner's 2025 Hype Cycle places AI SOC agents at the early "Innovation Trigger" stage, with market penetration still in the 1 to 5% range. Translation: this is genuinely early, vendor claims are running well ahead of production maturity industry-wide, and due diligence matters more here than in a mature category.

The four market categories, and why lumping them together ruins your comparison

Before you evaluate any single vendor, sort your shortlist into categories, because comparing across categories produces meaningless results.

One practitioner-written comparison frames this distinction well: lumping a chat assistant bolted onto a SIEM in with autonomous agents that run detection, triage, and response end to end is how buyers end up comparing a feature against a platform.

• SIEM/XDR-bundled AI (CrowdStrike Charlotte AI, SentinelOne Purple AI, Palo Alto Cortex XSIAM). Strong if you're already deep in that ecosystem, but value is tightly coupled to that vendor's platform, and pricing typically bundles per-endpoint plus data ingest costs, creating real lock-in.
• SOAR-turned-agentic (Torq, D3 Morpheus, Stellar Cyber). Started as automation/playbook platforms and layered agentic reasoning on top of a mature workflow engine. Generally strong at response execution since that's the legacy strength, the open question is how much of the "agent" layer is genuinely reasoning versus dressed-up scripting.
• Pure-play AI-native investigation (Dropzone AI, Radiant Security, Prophet Security, Exaforce). Built AI-first around one job: take an alert, investigate it, return a verdict. Often the deepest investigation capability, but check whether response/action closes the loop or just hands you a recommendation.
• Hybrid AI plus human-in-the-loop platforms (Secure.com's SOC Teammate, UnderDefense MAXI, Mate Security). Pair AI-driven triage and investigation with explicit human oversight controls or managed analyst backup for edge cases the AI escalates rather than closes. Secure.com frames this as a deliberate architectural choice rather than a feature, building an immutable decision trail into the product rather than treating explainability as a compliance add-on. Worth it if your team wants governance and an audit trail built into the product architecture rather than bolted on as a compliance feature.

The evaluation criteria that actually separate leaders from marketing decks

1. Investigation depth: L1 speed or L2/L3 depth? Ask the vendor to walk one real incident end to end. One evaluation framework specifically recommends watching whether context carries across each step of the incident or gets re-gathered at every stage, since many platforms automate Tier 1 triage and stop there, which speeds up the queue without actually deepening the investigation.
2. Auditable, evidence-backed verdicts. Ask to see the full evidence trail behind a verdict, every log line, correlation, and inference, and confirm your analysts can reproduce the finding from the same data. A verdict you cannot audit is an opinion, not a defensible finding you can act on or explain to an auditor later.
3. Detection coverage beyond the SIEM. Real incidents cross cloud, SaaS, identity, and code, and a lot of that telemetry never reaches the SIEM because ingestion costs too much. List the sources your stack currently leaves dark (high-volume cloud audit logs, GitHub, Google Workspace are common gaps) and have the vendor demonstrate a detection and investigation across exactly those sources, not a curated demo dataset.
4. Integration breadth and lock-in risk. How many tools does it connect to natively, and what happens when a vendor on your stack pushes an API change? One comparison guide explicitly weights vendor neutrality as heavily as investigation depth, on the logic that a capable AI locked into one vendor's ecosystem is worth less to a multi-vendor SOC than a slightly narrower tool that runs across the whole stack. Secure.com's own integration approach leans the same direction, positioning itself as an added reasoning layer on top of an existing SIEM/EDR/SOAR stack rather than requiring a rip-and-replace.
5. Pricing model and transparency. Five pricing models exist across this market: flat-rate subscription, per-endpoint, per-alert, per-token, and enterprise custom contracts. One vendor comparison found only one of nine platforms surveyed publishes per-asset pricing openly, with the rest requiring a "contact sales" conversation before a buyer can even compare options, which stalls procurement before a real comparison can start. Per-alert and per-token pricing can also produce real bill shock if your alert volume spikes during an actual incident, which is exactly when you don't want a cost conversation.
6. Governance and staged autonomy. Can your team define exactly which actions the system can take autonomously versus which require human sign-off, and can that scope expand gradually as trust builds, rather than an all-or-nothing autonomy switch on day one?

Red flags to walk away from during a POC

• The vendor can't produce a single end-to-end incident walkthrough on request, only a curated demo
• "Full automation" claims with no visibility into what specifically gets auto-closed versus escalated
• No clear answer on what happens to your data, integrations, or historical case data if you switch vendors later
• Pricing that can't be estimated without a live sales call, even roughly
• No reference customer willing to discuss what actually changed in their first quarter of use, not just the sales pitch metrics

A structured way to actually run the POC

Don't evaluate on vendor demos alone. Define your baseline numbers before the POC starts (current false-positive rate, mean time to investigate, mean time to respond) and score the vendor against measurable movement on those same numbers over a real 30 to 90 day window against your own alert stream, not a synthetic dataset.

Ask reference customers specifically what moved for them in their first 90 days, not what the vendor's case study says moved.

FAQ

1. Does an AI SOC platform replace a SIEM or SOAR? No. It sits on top as a reasoning and coordination layer. As one breakdown of the shift from SOAR puts it, your SIEM keeps collecting logs, your SOAR keeps running the playbooks it already has, the AI SOC layer adds context-aware judgment and investigation depth on top of what you already run. Anyone pitching full replacement of your existing stack on day one is a red flag, not a selling point.

2. How much should staged autonomy actually widen over time in a mature deployment? Most teams start conservatively (auto-triage and enrichment only) and expand toward autonomous containment actions (host isolation, credential revocation) only after several months of validated, audited decisions build internal confidence.

If a vendor pushes you toward broad autonomy from week one, ask specifically how disputed or reversed decisions get logged and reviewed, since that governance trail matters more at scale than the initial automation percentage.

3. What's the single biggest procurement mistake teams make in this category? Comparing platforms across categories (a SIEM-bundled copilot against a pure-play investigation agent) as if they're interchangeable, then being surprised when the "AI SOC" they bought doesn't do what a different category of tool would have done. Sort your shortlist by category first, then compare within category.

French security firm Lexfo stumbled onto an active Microsoft 365 phishing operation because the attacker left a Python web server (python3 -m http.server 8080) running with directory listing enabled, basically an open filing cabinet of their own attack infrastructure, sitting on a public port.

The exposed directory held phishing configs, credential-harvesting logs, RMM installers, combolists, and even the operator's Telegram session files.

That one lapse let researchers pivot through the operator's own GitHub history and identify not just him, but two other phishing operators he'd sourced tooling from — three separate campaigns, one investigation.

Why this is worth understanding even if you never touch the specific IOCs

All three ran forks of Evilginx, an open-source adversary-in-the-middle (AiTM) proxy. For anyone unfamiliar: an AiTM phishing kit doesn't just steal a password, it sits between the victim and the real login page in real time, relaying the actual authentication flow (including the MFA prompt) while capturing the resulting session cookie.

That's why traditional "just use MFA" advice doesn't fully close this gap, the victim completes MFA against the real service, and the attacker steals the live session token that comes out the other end.

Here's the part that actually matters for defenders: the three campaigns used two mechanically different bypass techniques, and each needs a different fix.

Technique 1: classic AiTM proxying (two of the three operators). Standard Evilginx relay-the-login approach. This is stopped cold by phishing-resistant MFA, FIDO2 keys or passkeys, because those bind the authentication to the real domain's origin, and a proxy sitting in between breaks that binding.

Technique 2: device code phishing (the third operator, "black-queen"). This is the one worth sitting with, because calling it "MFA bypass" undersells it, nothing is technically bypassed. Microsoft's OAuth device code flow is a legitimate sign-in method built for input-constrained devices (think: signing into a streaming app on a TV using a code shown on screen).

The attacker generates a real device code, wraps it in a fake Microsoft Authenticator-themed page, and tells the victim to enter that code at the genuine microsoft.com/devicelogin. The victim then signs in on Microsoft's actual page and clears MFA themselves — for real. The attacker's backend is just polling in the background and grabs the resulting token the instant it's issued.

The reason a passkey or FIDO2 key doesn't save you here: the victim authorizes on genuine Microsoft infrastructure. Origin-binding, the exact mechanism that stops Evilginx, passes cleanly, because the origin really is Microsoft. Microsoft first documented this technique in a Russia-aligned campaign back in February 2025, and it's since spread well past state-backed use.

Scale and persistence

This wasn't a smash-and-grab. The device-code operator ("saroula01") ran quietly for over a year, logging 218 distinct captured accounts across a dozen countries, roughly 94% of them corporate mailboxes. Stolen tokens were set to auto-refresh, some refreshed as many as 25 times, meaning the framework kept sessions alive indefinitely without the victim ever noticing anything was wrong.

Worth flagging separately: the report found signs of AI-assisted development across all three operations, one operator's forked repo included leftover commit history showing an AI coding session used to build a detection-evasion feature. None of the three built their own frameworks from scratch; they cloned public repos and modified the glue code around them. The barrier to running a working campaign here is startlingly low.

What to actually do about it

• Phishing-resistant MFA (FIDO2/passkeys) stops the AiTM path but not device code abuse: don't assume rolling out passkeys closes this out completely.
• Block the device code flow via Conditional Access wherever you don't have a genuine input-constrained-device use case (Teams room devices and some CLI tools are the real exceptions). Microsoft's own guidance recommends this directly.
• Layer Continuous Access Evaluation and IP-based Conditional Access so a token used from outside your normal ranges gets re-checked rather than riding out its full lifetime.
• Hunt Entra sign-in logs for refresh-token grants from Microsoft's desktop client ID (d3590ed6-52b3-4102-aeff-aad2292ab01c) where that client isn't in normal use for your org, cross-referenced against unfamiliar source IPs. Also check the Original transfer method field on sign-ins, a session that started via device code stays tagged that way on later refreshes even when the live protocol doesn't show it.

Nebula Security disclosed GhostLock this week, a Linux kernel vulnerability that's been sitting in the code since 2011 (kernel version 2.6.39), meaning it's shipped by default in essentially every mainstream distro for 15 years.

Any logged-in local user, no special permissions and no network access required, can trigger it using nothing more than ordinary threading calls. Nebula turned it into a working root exploit with a 97% success rate in testing, and critically, it also escapes containers, a compromised container can break out to the host kernel.

For context on severity language: this is scored 7.8/10, not a perfect 10, specifically because it needs local access to start. Don't let that score fool you though — the practical risk here is closer to critical for a huge chunk of real-world infrastructure, for reasons the CVSS number doesn't fully capture (more on that below).

The technical root cause

This is a use-after-free bug, a class of memory-safety flaw where the kernel keeps a pointer to a chunk of memory after that memory has already been freed and reused for something else, letting an attacker manipulate what ends up there.

Specifically, it lives in the kernel's rtmutex (real-time mutex) subsystem, which manages priority inheritance for locks, a mechanism meant to stop an important task from getting stuck waiting behind a trivial one.

The technical breakdown from Threat-Modeling.com explains it well: a cleanup function called remove_waiter() was written assuming the thread cleaning up a lock is always the same thread waiting on it.

A feature called Requeue-PI broke that assumption years ago, letting one thread clean up on behalf of another, but the cleanup code was never updated to account for it. The result: the kernel clears the wrong task's pointer, creating the use-after-free condition an attacker can exploit for privilege escalation.

Why this one is worse than a typical local-only bug

Two things push GhostLock past "patch when convenient":

1. It's chainable. Nebula demonstrated it as the second half of an attack chain they call IonStack, paired with a Firefox sandbox-escape flaw (CVE-2026-10702), they showed a full chain from a single malicious link click to full root control, tested against Firefox on Android. As covered by Undercode News, that's what turns a "local only" bug into something that matters for remote compromise, it doesn't need to start local if something else gets you a foothold first.
2. Patch status is messy. The original April 2026 fix introduced a separate crash bug (CVE-2026-53166), and the cleanup for that was still settling upstream as of early July. Availability is uneven, Ubuntu had patched its newest release, but as of early July still listed 24.04, 22.04, and 20.04 LTS as vulnerable or in-progress. Don't assume "patched" until you've confirmed the actual fixed package version for your specific distro and release.

Worth noting: this was found using Nebula's AI-driven bug hunting platform, VEGA, part of a broader pattern this year of automated tools surfacing decade-plus-old kernel bugs that human review passed over repeatedly.

What to actually do

• Check your distro's specific security advisory and confirm the fixed package version, not just that a patch exists, the messy rollout means "updated" doesn't always mean "actually fixed" right now.
• Prioritize shared and multi-tenant systems first: cloud servers, container hosts, CI/CD runners, anywhere an attacker is most likely to find the local foothold this bug needs.
• RANDOMIZE_KSTACK_OFFSET and STATIC_USERMODE_HELPER build options make exploitation harder, but they're mitigations, not fixes, don't treat them as a substitute for patching.
• No confirmed in-the-wild exploitation yet, but working exploit code is already public. Historical precedent (Dirty COW, PwnKit) suggests weaponization typically follows within days to weeks of a public PoC, not months, plan your patch timeline accordingly rather than waiting for a scheduled window.

GhostLock is at least the second kernel privilege-escalation bug this year credited partly to automated/AI-assisted bug hunting (the other being Bad Epoll, CVE-2026-46242).