Security, Decoded: Insights from Suzu Labs

The AI Governance Gap: Verizon's 2026 DBIR Shows Attackers Scaling AI While Employees Leak Data Through It

Jacob Krell — Thu, 28 May 2026 18:39:14 GMT

On May 20, 2026, Verizon published the 2026 Data Breach Investigations Report with a dedicated AI section built on original research conducted with Anthropic. The study examined 793 threat actors and found the median actor used AI across 15 MITRE ATT&CK techniques. AI assisted text in phishing emails doubled year over year. The report highlighted VoidLink, a malware framework an AI agent assembled in six days, and PromptLock, described as the first AI powered ransomware to dynamically generate cross platform encryption scripts through local large language models. Verizon framed these developments as a point of no return for automated threat development.

The same report documents a parallel crisis on the defensive perimeter of the enterprise. Sixty seven percent of employees access AI from non corporate accounts on corporate devices. Source code is the number one data type uploaded to unauthorized AI services. Regular AI users tripled from 15 percent to 45 percent in a single year. Shadow AI now ranks as the third most common non malicious insider action in DLP datasets, with detections up fourfold.

Attackers are operationalizing AI at scale. Employees are exporting sensitive data into AI platforms at scale. This post will walk through that dual failure, explain why both sides share the same root cause, and make the case that AI governance should be treated like ordinary access control rather than a novel category requiring novel frameworks.

The AI Governance Gap

The structural pattern is straightforward. AI is integrated into offensive campaigns faster than most security programs can detect or respond to AI augmented tradecraft. At the same time, employees are creating new data loss paths through ungoverned AI usage that most organizations cannot even inventory. Both failures trace to the same gap. Organizations have not extended their existing governance structures to cover AI as an enablement technology.

On the offensive side, the DBIR data shows AI accelerating known techniques rather than inventing a new attack taxonomy. Less than 2.5 percent of AI assisted techniques involved rare or novel methods. Exploitation accounted for 32 percent of AI assisted activity. Phishing accounted for 44 percent. The median threat actor spread AI assistance across 15 ATT&CK techniques. That is operational integration, not experimentation at the margins.

On the internal side, the risk profile is different but equally concrete. Shadow AI is structurally worse than the shadow IT wave of a decade ago. Shadow IT brought unapproved systems into the environment. Data mostly stayed inside those systems until an integration or misconfiguration exposed it. Shadow AI sends data out by design. Every prompt that includes source code, customer records, or internal research documentation is a potential data loss event routed to an external platform the security team may never have approved.

At this point one is likely wondering why organizations keep treating AI governance as a special case. The answer is habit and headline anxiety. AI feels unprecedented, so boards ask for AI specific task forces, novel policy templates, and moratoriums that security teams cannot enforce. The result is either a ban that employees route around, or no policy at all while usage explodes. Neither outcome produces governance.

The practical position is simpler. AI governance should look like access control for any other high impact enablement technology. Start with an inventory of who uses which AI platforms, for what purposes, and with what data. Apply least privilege based on role and need. Enshrine boundaries in an acceptable use policy. Monitor for anomalies the same way organizations monitor privileged database access or SaaS exfiltration. Treat AI like just another enablement technology, because that is what it is in governance terms.

It is important to consider that restriction without structure fails on both sides of the gap. Organizations that block security teams from frontier AI capabilities do not eliminate the offensive use case. They forfeit the defensive one. Attackers face no compliance review, no procurement cycle, and no internal debate about whether to adopt AI assisted phishing, exploitation, or malware development. Defenders who voluntarily stay on manual timelines widen a gap that the DBIR now measures in median technique counts and doubled phishing quality.

Governance is the right answer. Governance for AI looks exactly like governance for production databases, code repositories, and privileged SaaS integrations. Inventory, least privilege, policy, monitoring. The organizations overcomplicating this problem are waiting for a novel framework while their data leaves through chat windows that their DLP stack was never configured to watch.

The Dual AI Governance Failure

Dimension	Offensive Side (AI in attacks)	Internal Side (Shadow AI)
Scale	Median 15 techniques per actor	67% using non corporate AI accounts
Growth	AI phishing text doubled	Regular AI users 3x (15% to 45%)
Data type	Exploitation (32%) and phishing (44%)	Source code (#1), technical docs (3.2%)
Novelty	<2.5% novel techniques	4x increase in DLP detections
Governance status	Limited detection for AI augmented TTPs	Limited visibility into AI tool usage

The Evidence Beyond the Headlines

The DBIR is the anchor for May 2026. It is not the only proof that the gap is already costing organizations money and time.

AI offensive capability was already proven

OpenAI classified GPT-5.3-Codex as high cyber capability under its Preparedness Framework when the model shipped in February 2026. Anthropic had already classified unreleased frontier models on the same axis before the Mythos leak compressed public attention. Capability at the model layer was documented by vendors themselves before Verizon quantified how threat actors operationalize it.

Google Threat Intelligence Group confirmed in May 2026 what many researchers had been tracking as a theoretical risk. Threat actors used AI to help develop a zero day exploit that bypassed two factor authentication through a semantic logic flaw in a widely deployed administration tool. That is a finished offensive outcome beyond what lab benchmarks alone would imply.

Amazon Threat Intelligence documented a single financially motivated actor with low to medium baseline skill using commercial AI services to compromise more than 600 FortiGate devices across 55 countries in 38 days, as published on the AWS Security Blog in February 2026. The actor used AI across planning, tooling, and lateral movement. The volume of custom tooling would typically imply a well resourced development team. The DBIR median of 15 AI assisted techniques per actor rhymes with that campaign at scale.

DARPA's AI Cyber Challenge produced Cyber Reasoning Systems whose agents found 18 real vulnerabilities in production software during the 2025 final competition, including six zero days, at an average cost of $152 per finding. Anthropic's Frontier Red Team reported in February 2026 that Claude Opus 4.6 discovered more than 500 high severity zero days in production open source codebases using out of the box capabilities. The UK AI Security Institute and Palo Alto Networks published benchmarks in May 2026 showing frontier models approaching autonomous enterprise intrusion capability in controlled testing, including multi stage paths through credential theft, privilege escalation, lateral movement, and persistence.

That pattern matches the DBIR's novelty statistic. AI compresses time to execute known tradecraft. It does not require a new MITRE category to damage an organization that still cannot see AI assisted phishing or AI generated malware frameworks arriving on the same calendar quarter.

VoidLink and PromptLock belong in that same bucket as escalation signals. A malware framework built by an AI agent in six days. Ransomware that generates cross platform encryption logic locally. Both are warnings that automated threat development has crossed from proof of concept to production tempo. Verizon's framing of a point of no return for automated threat development is consistent with what independent offensive research already demonstrated in 2025 and early 2026.

Shadow AI as a data loss vector

The internal statistics in the 2026 DBIR read like an adoption curve security teams have seen before, with worse data flow physics.

Forty five percent of users are now regular AI users, up from 15 percent in the prior year. Sixty seven percent access AI from non corporate accounts on corporate devices. Shadow AI ranks third among non malicious insider actions in DLP datasets and detections rose fourfold. Source code leads uploaded data types. Research and technical documentation accounted for 3.2 percent of DLP violations involving external AI. Fifteen percent of users run unauthorized AI browser extensions that collect browsing context.

The historical parallel to shadow IT is useful for executives who lived through the SaaS sprawl decade. Shadow IT was a governance gap where teams adopted tools without approval. Shadow AI is the same governance gap with outbound data gravity. The deeper risk is that proprietary logic leaves the trust boundary in a paste buffer every time an employee submits a prompt containing work product.

Shadow AI Data Exposure Model

The DBIR provides the percentages. It does not model what those percentages mean for a specific organization. We did.

For a representative organization with 1,000 employees, the DBIR figures produce the following exposure model.

Step	Calculation	Result
Total employees	Baseline	1,000
Regular AI users (45%)	1,000 x 0.45	450
Using non corporate accounts (67%)	450 x 0.67	~302
Daily AI prompts per user (industry midpoint)	302 x 7	~2,114
Prompts containing sensitive work data (~30%)	2,114 x 0.30	~634 per day
Monthly (22 working days)	634 x 22	~13,950
Annual (250 working days)	634 x 250	~158,500

*Assumptions: 45% regular AI users and 67% non corporate account usage from Verizon 2026 DBIR. Seven prompts per day is a conservative industry midpoint for regular AI users (enterprise AI usage surveys consistently report knowledge workers averaging 5 to 15 AI interactions per working day). Thirty percent sensitive data rate is a conservative estimate based on DLP research showing roughly a third of AI prompts in enterprise settings contain proprietary or work sensitive content.

Approximately 634 prompts containing sensitive work data leave the trust boundary every working day through ungoverned AI channels in a 1,000 person organization. Over a year, that approaches 158,500. Those prompts are routed to platforms the security team may not have approved, may not monitor, and may not even know exist.

Source code is the number one data type according to the DBIR. For a software company or any organization with significant development activity, a meaningful share of those 158,500 annual prompts contain proprietary logic, internal architecture details, or unreleased product code. The data loss is silent because no file was downloaded, no USB drive was inserted, and no email was sent to a personal address. The data left through a chat window.

This model scales linearly. A 5,000 person organization faces approximately 3,170 sensitive prompts per day through ungoverned channels. A 10,000 person organization faces approximately 6,340. The exposure is proportional and it compounds every day that governance is absent.

AI Offensive Capability Timeline

No single publication has assembled the complete progression from lab demonstration to operational deployment of AI offensive capabilities. The milestones are scattered across vendor reports, government publications, and threat intelligence disclosures. The pace is worth tracing.

When	Milestone	Source
Q3 2024	DARPA AIxCC semifinal: AI agents find vulns at 37% success rate	DARPA
Q1 2025	AIxCC final: 18 real vulns, 6 zero days, $152/finding, 77% rate	DARPA
Q1 2025	Claude Opus 4.6 finds 500+ high severity zero days in production OSS	Anthropic Frontier Red Team
Q1 2025	GPT-5.3-Codex classified as "High Cyber Capability"	OpenAI Preparedness Framework
Q1 2025	Single actor compromises 600+ FortiGate devices across 55 countries in 38 days using AI	Amazon Threat Intelligence
Q2 2025	First confirmed AI developed zero day exploit (2FA bypass)	Google GTIG
Q2 2025	DBIR measures median AI usage across 793 threat actors (15 techniques)	Verizon / Anthropic
Q3 2025	VoidLink: malware framework built by AI agent in 6 days	Verizon DBIR
Q4 2025	PromptLock: first AI powered ransomware using local LLMs	Verizon DBIR

The progression from controlled lab environment to confirmed field deployment spans approximately 12 months. Every milestone was confirmed by a different independent source. DARPA documented the competition results. Amazon documented the FortiGate campaign. Google GTIG confirmed the zero day. Anthropic documented both the defensive capability and the offensive misuse. The DBIR synthesized 793 actors with Anthropic. The convergence of independent sources on the same finding, that AI is operationally integrated into attack campaigns, is what makes the case structural rather than anecdotal.

AI as a defensive force multiplier

The offensive numbers are only half of the budget conversation. IBM's 2025 Cost of a Data Breach Report found organizations with extensive AI in security operations saved $1.9 million per breach on average. AI enabled organizations identified breaches in 148 days and contained them in 42 days. Organizations without that capability averaged 168 days to identify and 64 days to contain. That gap is dwell time translated directly into cost.

The SANS 2025 Threat Hunting Survey found 61 percent of organizations cite skilled staffing shortages as the primary barrier to threat hunting. AI assisted correlation, hypothesis generation, and triage automation are how smaller teams approximate the pace the DBIR documents on the offensive side. Restriction without governance removes that path while leaving attacker access untouched.

What Organizations Should Do Now

The following recommendations mirror the same sequence security teams already use for SaaS, privileged access, and data exfiltration controls. AI is another surface. The controls are not mysterious.

Build an AI usage inventory. Catalog which employees use which AI platforms, for what purposes, and with what categories of data. The same asset management discipline applied to SaaS subscriptions and code repository access applies here. You cannot scope least privilege for a surface you cannot see.

Apply least privilege to AI access. Not every employee needs frontier model access. Not every use case requires uploading source code or customer data. Scope platform choice, model tier, and data submission rights by role the same way organizations scope access to production databases and CI/CD secrets.

Establish an AI acceptable use policy. Enshrine approved platforms, permitted data types, and review requirements in policy. Structured enablement replaces shadow usage with governed usage and explicit boundaries security can monitor. Employees are already using AI. Policy gives security teams something enforceable.

Deploy DLP for AI platforms. Monitor what data flows to AI services the same way organizations monitor uploads to personal cloud storage or unknown SaaS tenants. Source code and internal documentation leaving the organization through an AI prompt is a data loss event even when the employee had good intentions.

Enable security teams with frontier AI capabilities. The offensive side is not waiting for procurement approval. Invest in AI assisted threat hunting, detection engineering, and incident response workflows with audit trails and tool boundaries. Organizations that restrict defenders while attackers operationalize AI across 15 techniques are choosing the worst asymmetry available.

Extend zero trust principles to AI agents. As tools gain autonomy, each agent interaction should be scoped, audited, and revocable. Treat agent credentials like privileged access requests with time bounds and default deny postures. Authorization layers provide the actual control boundary. Prompt level instructions alone do not.

The Gap Closes Through Ordinary Governance

The 2026 DBIR will be remembered for exploitation overtaking credentials as the top initial access vector. The AI chapter deserves equal weight. Median threat actors already spread AI across 15 techniques. Phishing quality doubled. Malware frameworks compress from weeks to days. Inside the same enterprises, nearly half the workforce uses AI regularly and two thirds route it through non corporate accounts on managed devices.

The organizations that move fastest will treat AI governance as an extension of access control they already operate. They will inventory usage, scope privilege, write policy, monitor exfiltration, and arm defenders with the same class of tools attackers already treat as routine. The organizations that ban AI without structure will discover their source code on an unauthorized platform. The organizations that ignore AI governance entirely will discover the same outcome without ever having written a policy.

Sources

Verizon, "2026 Data Breach Investigations Report," May 20, 2026, https://www.verizon.com/business/resources/reports/dbir/
SecurityWeek, "Verizon DBIR 2026: Vulnerability Exploitation Overtakes Credential Theft as Top Breach Vector," May 20, 2026, https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
Anthropic and Verizon DBIR collaboration (AI threat actor research, 793 actor sample), as reported in the 2026 DBIR
OpenAI, "GPT-5.3-Codex System Card," February 5, 2026, https://openai.com/index/gpt-5-3-codex-system-card/
Anthropic, "Claude Code Security" and Frontier Red Team research, February 2026, https://www.anthropic.com/research/claude-code-security
Amazon Web Services Security Blog, "AI-Augmented Threat Actor Accesses FortiGate Devices at Scale," February 2026, https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/
DARPA, "AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense," 2025, https://www.darpa.mil/news/2025/aixcc-results
Google Threat Intelligence Group, "AI Vulnerability Exploitation and Initial Access," May 2026, https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
UK AI Security Institute, "How Fast Is Autonomous AI Cyber Capability Advancing," May 2026, https://www.aisi.gov.uk/blog/how-fast-is-autonomous-ai-cyber-capability-advancing
Palo Alto Networks, "Defenders Guide: Frontier AI Impact on Cybersecurity," May 2026 update, https://www.paloaltonetworks.com/blog/2026/05/defenders-guide-frontier-ai-impact-cybersecurity-may-2026-update/
IBM, "2025 Cost of a Data Breach Report," 2025, https://www.ibm.com/reports/data-breach
SANS Institute, "2025 Threat Hunting Survey: Advancements in Threat Hunting Amid AI and Cloud Challenges," 2025, https://www.sans.org/white-papers/sans-2025-threat-hunting-survey-advancements-threat-hunting-amid-ai-cloud-challenges
Suzu Labs, "Claude Mythos and the Cybersecurity Risk That Was Already Here," March 27, 2026, https://suzulabs.com/suzu-labs-blog/claude-mythos-and-the-cybersecurity-risk-that-was-already-here

The Remediation Paradox: Verizon's 2026 DBIR Shows Exploitation Winning While Defenders Patch Slower

Jacob Krell — Thu, 21 May 2026 22:19:30 GMT

On May 20, 2026, Verizon published the [2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/). The headline number is hard to miss. For the first time in the report's history, vulnerability exploitation overtook credential theft as the number one initial access vector in confirmed breaches. Exploitation rose to 31 percent of initial access cases. Credential abuse, long the dominant entry path, fell to 13 percent and lost the top spot entirely.

The DBIR analyzed more than 22,000 confirmed breaches, roughly double the prior edition's 12,195. The dataset is larger, the signal is clearer, and the direction is the same story security leaders have been watching accelerate for three years. Attackers are getting in through flaws in software and infrastructure faster than organizations are closing them.

At this point one is likely wondering whether the industry is finally catching up. The same report answers that question with a second headline that gets far less attention. Median patch time increased from 32 days to 43 days. The share of CISA Known Exploited Vulnerabilities fully remediated dropped from 38 percent to 26 percent. The top threat vector is rising. The primary industry response is slowing. That mismatch has a name and a structural explanation. This post will walk through both and make the case that patching alone cannot close a gap that is widening on both sides simultaneously.

The Remediation Paradox

The 2026 DBIR does more than confirm that exploitation is up. It documents a structural mismatch between how fast attackers operate and how fast defenders remediate. We call this The Remediation Paradox. The number one initial access vector is getting harder to defend against precisely because the gap between disclosure and compromise has inverted, while organizational remediation velocity is moving in the wrong direction at the same time.

Patching faster remains necessary. It cannot close a gap that is widening faster than any single organization can patch, no matter how mature its vulnerability management program. Mandiant's M-Trends 2026 report puts estimated mean time to exploit at negative seven days. Exploitation now routinely occurs before a patch exists. When the decisive window sits entirely on the detection side of the timeline, a strategy built around closing every hole before an actor arrives is optimizing for a condition that the data says no longer holds.

It is important to note that security teams are working harder than ever. Most organizations are patching more advisories, running more scanners, and buying more tools. The paradox is that the industry's collective answer to the DBIR still sounds like the answer from a decade ago. Patch faster. Scan more. Close the backlog.

That recommendation addresses real exposure. It stops short of the capabilities the threat model now demands, in a way that aligns uncomfortably well with what the security vendor market sells. Patching platforms, vulnerability scanners, and compliance oriented remediation workflows are mature product categories with clear ROI narratives. Detection engineering, threat hunting, and adversary focused monitoring are harder to productize and harder to sell at scale. Every vendor summary of the 2026 DBIR will emphasize accelerated patching because that is what most vendors are built to deliver. The analysis tracks the business model. Organizations hear the same prescription because the industry sells the same prescription.

For sake of clarity, naming that incentive dynamic is not an attack on vendors. Vulnerability management vendors solve a real problem. The gap is what gets left out of the bundle. When exploitation leads initial access and mean time to exploit is negative, the decisive organizational capability becomes time to detection, not time to patch. Programs that spend prevention heavy budgets on scanning and scheduling while threat hunting remains understaffed are responding to yesterday's breach pattern with tomorrow's invoice line items.

In this way, The Remediation Paradox is a velocity problem dressed up as a tooling problem. Attackers compress the exploitation window with automation, prior compromise markets, and third party blast radius. Defenders expand patch timelines and celebrate scanner coverage. Both trends appear in the same annual report. Both trends cannot continue without breach costs continuing to set records.

The Evidence Stack

The DBIR is the anchor. It is not the full picture. Multiple independent research streams converged on the same conclusion before May 20, and they keep converging after it.

Mean time to exploit and breakout speed

Mandiant's M-Trends series tracks estimated mean time to exploit across years. In 2018, defenders had roughly 63 days between disclosure and in the wild exploitation. In 2024, the metric crossed zero. M-Trends 2026 places it at negative seven days.

Year	Estimated Mean Time to Exploit (Mandiant)
2018	63 days
2024	Crosses zero
2025	-7 days

CrowdStrike's 2026 Global Threat Report documents the operational speed on the other side of initial access. The fastest observed eCrime breakout time was 27 seconds. The average sat at 29 minutes. Eighty two percent of detections were malware free, meaning defenders cannot rely on traditional malware signals to catch the intrusion in progress.

Prior compromise was the most frequently confirmed initial infection vector for ransomware in 2025 at 30 percent, according to Mandiant M-Trends 2026. That figure matters for remediation strategy. A ransomware event in 2026 is often the bill arriving for a foothold sold or planted months earlier. Patching the edge device on the day of encryption does not unwind the broker sale that already happened.

The Crossover: Exploitation Overtakes Credentials

Third party compounding

Exploitation is only one entry path. The DBIR also shows third party involvement reaching 48 percent of breaches, a 60 percent year over year increase from 30 percent in the prior edition.

The Identity Theft Resource Center's 2025 Annual Data Breach Report found that supply chain attacks doubled between 2021 and 2025, and that approximately 30 percent of all breaches involve at least one third party. The numbers differ in scope and methodology, but the direction is identical. Breach harm increasingly originates outside the perimeter of the organization that signs the incident response retainer.

It is important to consider that third party risk is not only frequency but remediation quality. The DBIR reports that only 23 percent of third party organizations had fully remediated missing MFA on cloud accounts. A vendor questionnaire that checks policy language without checking control implementation is measuring paper, not exposure.

The governance gap described in recent supply chain analysis still applies. One compromised supplier, one poisoned extension, one unpatched SaaS integration, and dozens of downstream organizations inherit the blast radius. The acceleration in third party involvement tracks the same structural load bearing dynamic seen in vendor consolidation.

Ransomware economics and the pivot to data

Ransomware appeared in 48 percent of breaches in the 2026 DBIR, up from 44 percent. Prevalence is rising. Payment economics are moving the other way.

According to the DBIR, median ransom payout fell to $140,000 from $150,000, and 69 percent of victims did not pay. Ninety six percent of ransomware victims were small and medium businesses. Half of ransomware victims had an infostealer leak within 95 days before the attack.

Those figures sit together uncomfortably only if ransomware is treated as a single business model. A clearer read treats operators as rational economic actors seeking maximum margin. Where segmentation, backup resilience, and blast radius reduction have worked, encryption alone produces a declining payout. The industry preaching of immutable backups and tested restore paths has changed the math on the availability side of the extortion. The declining median payout is partly a testament to that defensive progress.

Where data is worth more than downtime, operators pivot. Exfiltration, leak sites, and regulatory pressure replace or supplement encryption. Both dynamics are real at once. Ransomware involvement can rise while payouts fall because the campaign type is splitting. One path monetizes disruption. The other monetizes confidentiality at scale.

Breach cost and the AI defensive gap

IBM's 2025 Cost of a Data Breach Report provides the financial mirror. The US average breach cost reached $10.22 million, a 9.2 percent increase and a new record for the region. Organizations using AI powered security saved an estimated $1.9 million per breach. AI enabled organizations identified breaches in 148 days and contained them in 42 days. Organizations without AI powered security took 168 days to identify and 64 days to contain.

Twenty six fewer days to identification and twenty two fewer days to containment translate directly to outcome. That gap is the difference between finding the actor internally and learning about the compromise from a partner, regulator, or criminal announcement.

DBIR year over year key metrics

Metric	2025 DBIR	2026 DBIR	Change
Vulnerability exploitation (initial access)	20%	31%	+55%
Credential abuse (initial access)	#1 vector	13%	Displaced
Ransomware involvement	44%	48%	+4 pts
Third party involvement	30%	48%	+60%
Median patch time	32 days	43 days	+34%
KEV remediation rate	38%	26%	-32%
Confirmed breaches analyzed	12,195	22,000+	+80%

Source: Verizon DBIR 2025 and 2026 editions.

The Remediation Scissors

Mandiant's M-Trends series tracks estimated mean time to exploit across years. Verizon's DBIR tracks median time for organizations to fully patch known exploited vulnerabilities. Plotting both lines on the same chart produces what we call The Remediation Scissors, two trend lines moving in opposite directions that crossed between 2022 and 2024 and have been diverging since.

Year	Mean Time to Exploit (Mandiant)	Median Patch Time (Verizon DBIR)	Defender Buffer
2018	63 days	~30 days (industry baseline)	+33 days
2020	44 days	~30 days (industry baseline)	+14 days
2022	32 days	~30 days (industry baseline)	+2 days
2024	-1 day	32 days (2025 DBIR)	-33 days
2025	-7 days	43 days (2026 DBIR)	-50 days

*Sources: Mandiant "Analysis of Time-to-Exploit Trends" (2018-2019 average: 63 days, 2020-Q1 2021 average: 44 days, 2021-2022 average: 32 days), Mandiant M-Trends 2025 and 2026 (2024: -1 day, 2025: -7 days), Verizon DBIR 2025 and 2026 (median patch time). Patch time values before 2024 are industry baseline estimates. Defender buffer = MTTE minus median patch time.

In 2018, defenders had a 33 day buffer. Exploitation typically followed disclosure by 63 days. Patching typically completed in about 30 days. That left roughly a month of margin. By 2022, the buffer had compressed to just two days. The scissors were closing. Then they collapsed. Between 2022 and 2024, the defender buffer crashed from +2 days to -33 days as exploitation timelines crossed zero and went negative. By 2025, the gap had widened to negative 50 days. Exploitation now precedes patch availability by a week, and the median organization still takes 43 days to deploy the patch once it exists.

The scissors will not close through patching improvements alone. The exploitation line is driven by AI acceleration, prior compromise markets, and zero day availability. It is moving at a pace that no remediation program can match at scale. The only way to shorten the negative buffer is to add detection capability on top of remediation capability.

The KEV Exposure Gap

The DBIR provides two related numbers that most coverage reports independently. Organizations face a median of 16 KEV vulnerabilities requiring remediation. Only 26 percent of KEVs are fully remediated. Applied together, those figures produce a concrete and uncomfortable number.

The median organization has approximately 12 unpatched known exploited vulnerabilities at any given time (16 KEVs assigned, 26 percent remediated, 12 remaining).

Every vulnerability in the CISA KEV catalog has confirmed in the wild exploitation. Twelve of them are sitting unpatched in the median organization right now while the DBIR reports exploitation as the leading initial access vector at 31 percent. The exposure is measured, not hypothetical. It is the gap between what CISA says is being exploited and what the average organization has actually fixed.

In the prior DBIR period, the equivalent calculation produced roughly 7 unpatched KEVs (38 percent remediation on a median of 11). The number has nearly doubled in a single year. The backlog is growing faster than remediation programs are clearing it.

What Security Leaders Should Do Now

The Remediation Paradox does not argue for abandoning patching. It argues for designing the security program around the assumption that prevention has already failed somewhere in the environment, because the data says it routinely has.

Rebalance investment toward detection and threat hunting. The mean time to exploit collapse made the case before the DBIR arrived. The 2026 edition confirms it with exploitation leading initial access. The decisive control is time to detection. Budget, headcount, and executive attention should follow that fact. Weekly structured hunts, compromise assessments that start from adversary presence rather than alert queues, and behavioral analytics aimed at malware free intrusion chains belong in the same priority conversation as the next scanner renewal.

Treat patching as necessary but insufficient. Continue patching. Do not slow down. Prioritize Known Exploited Vulnerabilities and internet facing exposure. In doing so, pair every remediation SLA with a detection hypothesis. If the patch ships on day forty three and exploitation can precede availability, the organization still needs visibility into whether the flaw was used on day two.

Extend third party risk management beyond questionnaires. With 48 percent of breaches involving a third party, vendor risk programs must cover software supply chain exposure, developer tooling, and the remediation velocity of critical suppliers. Contractual notification timelines matter. So does evidence that partners actually fixed missing MFA on cloud accounts, not merely promised to.

Monitor infostealer markets as ransomware early warning. Half of ransomware victims in the DBIR data had a stealer leak within 95 days before the attack. Credential monitoring in dark web and infostealer markets is now an early warning layer for ransomware exposure, not a niche threat intelligence exercise. When employee or service account credentials appear in a stealer log, the clock to ransomware is measurable.

Deploy AI assisted defensive tooling. Organizations that restrict their security teams from AI capabilities do not reduce the offensive use case. They forfeit the defensive one. IBM's breach cost data quantifies the gap in dollars and days. AI assisted correlation, triage, and hunt hypothesis generation are how smaller teams approximate the pace CrowdStrike documents on the offensive side.

The Gap Is Still Widening

The 2026 DBIR lands in an environment where exploitation leads, patching slows, third party involvement jumps, and breach costs set US records. The question for 2026 and beyond is narrower than whether organizations will be affected. They will. The question is whether they learn about compromise from their own detection stack or from someone else's notification.

As such, the industry conversation needs to move past the remediation paradox's comfortable prescription. Faster scanning alone does not answer malware free breakout measured in minutes, prior compromise sold before ransomware deployment, or third party MFA gaps that persist after assessment. Detection centric strategy is the structural response the data has been pointing toward since mean time to exploit crossed zero.

At a Glance

What happened. Verizon released the 2026 DBIR on May 20, 2026. Vulnerability exploitation became the leading initial access vector at 31 percent, displacing credential abuse at 13 percent, while median patch time rose to 43 days and KEV full remediation fell to 26 percent.

Why it matters. The top threat vector and the industry's primary remediation response are diverging. That mismatch is The Remediation Paradox. Patching remains necessary but cannot close a gap where exploitation often precedes patch availability and vendor dominated analysis still disproportionately emphasizes the tools vendors sell.

The trend. Mean time to exploit sits at negative seven days (Mandiant M-Trends 2026). Third party involvement hit 48 percent of breaches. Ransomware prevalence rose to 48 percent while median payouts fell, reflecting both industrialized cybercrime and improved backup and segmentation discipline.

What to do. Rebalance toward threat hunting and detection. Keep patching aggressive but assume breach somewhere in the estate. Extend third party governance to real control verification. Treat infostealer monitoring as ransomware early warning. Deploy AI assisted defensive tooling and close the identification and containment gap IBM documents.

Who is affected. Any organization relying on prevention heavy vulnerability programs without proportional detection investment. Small and medium businesses bear 96 percent of ransomware victim share in the DBIR data. Enterprises with dense third party and software supply chain dependency inherit compounded blast radius.

Sources

- Verizon, "2026 Data Breach Investigations Report," May 20, 2026, https://www.verizon.com/business/resources/reports/dbir/

- Verizon, "2025 Data Breach Investigations Report," 2025, https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf

- Mandiant, "M-Trends 2026: Data, Insights, and Strategies From the Frontlines," Google Cloud, March 2026, https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

- Mandiant, "Analysis of Time-to-Exploit Trends: 2021-2022," Google Cloud Blog, https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2021-2022/

- CrowdStrike, "2026 Global Threat Report," February 2026, https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/

- Identity Theft Resource Center, "2025 Annual Data Breach Report," January 2026, https://www.idtheftcenter.org/wp-content/uploads/2026/01/2025-ITRC-Annual-Data-Breach-Report.pdf

- IBM, "2025 Cost of a Data Breach Report," 2025, https://www.ibm.com/reports/data-breach

- SecurityWeek, "Verizon DBIR 2026: Vulnerability Exploitation Overtakes Credential Theft as Top Breach Vector," May 2026, https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/

The Extension Blind Spot: How One VS Code Plugin Gave Attackers GitHub's Source Code

Jacob Krell — Wed, 20 May 2026 21:01:35 GMT

GitHub's 3,800 Repositories Stolen Through a Single IDE Extension

On May 19, 2026, a single VS Code extension on a single employee's device gave attackers access to 3,800 of GitHub's internal repositories. GitHub confirmed the breach the following morning, disclosed that it had rotated critical credentials and cryptographic keys overnight, and identified the financially motivated hacking group TeamPCP as responsible. The stolen source code appeared on cybercrime forums within hours, with TeamPCP demanding between $50,000 and $95,000 depending on the listing.

This is the platform that hosts the world's software supply chain. The platform that publishes guidance on secure software delivery, maintains the GitHub Actions ecosystem, and stores the source code for millions of organizations. It was compromised through an IDE extension.

The GitHub breach did not happen in isolation. It is the fifth successful supply chain compromise attributed to TeamPCP (tracked by Google Threat Intelligence as UNC6780) since March 2026. The pattern across all five is consistent. Target developer tooling that handles credentials. Harvest everything reachable. Use those credentials to spread.

Target	Date	Vector	Blast Radius
Aqua Security Trivy	March 2026	Compromised GitHub Actions tags (CVE-2026-33634)	10,000+ CI/CD workflows
Checkmarx KICS	March 2026	Malicious VS Code plugins on OpenVSX	36,000+ extension downloads
LiteLLM (PyPI)	March 2026	Compromised maintainer credentials	95M monthly downloads, ~500K machines
TanStack + Mistral AI	May 2026	Legitimate release pipeline abused, valid SLSA provenance	84+ npm packages
GitHub	May 19, 2026	Poisoned VS Code extension on employee device	3,800 internal repositories

TeamPCP has also partnered with the Lapsus$ extortion group for monetization, and the collaboration explains the shift from credential harvesting to direct data sales. The convergence between supply chain attackers and high profile extortion groups is creating a compounding effect across the cloud native ecosystem. The campaign is not slowing down. TeamPCP has publicly stated it will continue, claiming upcoming operations aimed at stealing terabytes of trade secrets with its partners.

The Extension Blind Spot

The deeper story here is not that GitHub got breached. Breaches happen to the best resourced organizations on the planet. The deeper story is what this breach reveals about the state of supply chain risk in 2026. The attack surface has expanded into layers that most organizations have not yet governed, and threat actors have noticed before defenders have.

The day before GitHub disclosed its breach, a separate and apparently unrelated incident hit the Nx Console VS Code extension. Nx Console has 2.2 million installations. According to StepSecurity, the compromised version deployed a multi stage credential stealer capable of harvesting tokens from GitHub, npm, AWS, HashiCorp Vault, Kubernetes, and 1Password. It exfiltrated data through three independent channels.

The malicious version was live for approximately 11 minutes before being pulled. Eleven minutes sounds fast until you consider how many machines auto update extensions in that window.

Two VS Code extension compromises in two days. One hit 2.2 million potential victims. The other hit GitHub itself. Both exploited the same structural reality. VS Code extensions have full, unrestricted access to everything on the developer's machine.

This is the extension blind spot. Most organizations today have extensive governance over their production environments. Servers run EDR agents. Cloud workloads operate under IAM policies scoped to least privilege. SaaS applications require SSO and MFA. Even developer laptops have endpoint protection deployed. But the code running inside the IDE sits entirely outside that governance. There is no permission model. No approval workflow. No inventory of installed extensions. No monitoring of what those extensions access.

The same organization that requires three approvals for a new SaaS subscription allows any developer to install arbitrary code execution environments in their IDE with no oversight whatsoever.

This started as a gap. The threat landscape moved faster than governance could adapt, and extension security was simply not on the radar. That explanation held in 2024. It does not hold in May 2026. TeamPCP has now compromised five organizations through developer tooling in three months. The Shai Hulud worm family has been tracked since September 2025. The IDEsaster vulnerability class demonstrated in March 2026 that every major AI IDE was vulnerable to extension layer exploitation. The evidence is overwhelming and public. At this point, the absence of extension governance is a choice.

The extension blind spot is a symptom of a broader condition. Supply chain risk has expanded into the developer tooling layer, the build pipeline, the package registry, and the IDE itself. Organizations that have not extended their supply chain risk management programs to cover these surfaces are exposed in ways that traditional vendor risk assessments will never catch.

Why This Keeps Working

The Marketplace Nobody Governs

The VS Code marketplace hosts approximately 60,000 extensions from around 45,000 different publishers. According to research from Koi Security, only 1,800 of those extensions are verified. The marketplace has accumulated 3.3 billion combined installs. The average developer has approximately 40 extensions installed in their IDE.

The scale matters because it defines the attack surface. An attacker who compromises a single popular extension can reach millions of developers in a single move. The verification rate (roughly 3% of all extensions) means 97% of what developers install has no formal vetting beyond the marketplace's automated checks.

Academic Research Confirms the Structural Weakness

Peer reviewed research has consistently documented the problem. A 2024 study published at NDSS analyzed 25,402 VS Code extensions and discovered 21 extensions with verified code injection exploits impacting over 6 million installations. A separate analysis of 52,880 extensions found 5.6% exhibited suspicious behavior. A third study examining 27,261 extensions found 8.5% (2,325 extensions) exposed to credential related data leakage through commands, user input, and configurations.

The contrast with browser extensions makes this gap concrete. When you install a Chrome extension, you see a permission prompt. "This extension can read and change all your data on all websites." Chrome uses a declarative permission system where extensions must declare what they need upfront, and users explicitly grant access. Manifest V3 further restricted extensions from executing remote code entirely.

VS Code has none of this. No permission prompt. No declarative capability system. No restriction on remote code execution. An extension claiming to format JSON has identical technical capabilities to one managing cloud infrastructure. The workspace trust model is binary, and most developers grant full trust to avoid disruption.

The browser industry solved this problem a decade ago. The IDE industry has not even started.

VS Code extensions run in a dedicated Node.js Extension Host process with unrestricted access to the file system, network, and can spawn child processes with the same privileges as the VS Code application itself. In practical terms, installing a VS Code extension is equivalent to running an arbitrary Node.js application with the developer's full user permissions.

This extends beyond VS Code. Cursor, Windsurf, Kiro, and other AI powered IDEs are built on the same VS Code foundation. They inherit the same extension trust model. The AI development boom has multiplied the number of developer tools with this exact vulnerability class. According to Lyrie Research, 73 sleeper malicious extensions have already been deployed across Open VSX, and two unpatched Cursor sandbox escapes enable code execution from extensions in 2026.

The Supply Chain Attack Trend Is Accelerating

The broader industry data supports what TeamPCP's campaign makes viscerally obvious. Third party involvement in breaches has gone from 9% in 2022 to 48% in 2025 according to Verizon's DBIR series. That is a fivefold increase in three years. Vulnerability exploitation has followed the same trajectory, rising from 5% of breaches in 2022 to 34% in 2025, overtaking credential theft as the leading breach vector. The median time for full patching increased to 43 days.

Developer tooling attacks are the natural evolution of this trend. SolarWinds (2020) compromised a build pipeline to distribute backdoored updates to 18,000 organizations. Codecov (2021) modified a bash uploader script to exfiltrate credentials for two months undetected, affecting GoDaddy, IBM, HPE, and Atlassian. Supply chain attacks jumped over 300% in 2021 alone according to Sonatype's State of the Software Supply Chain report.

The difference in 2026 is the attack surface has shifted further upstream. The targets are no longer just build systems and package registries. They are the developer's IDE itself, the tool used to write the code before it ever reaches a pipeline. TeamPCP understood this before the industry did.

EDR Cannot See It

EDR tools operate at the process and file system level. They detect known malware signatures, suspicious process trees, and anomalous network behavior. But a VS Code extension making authenticated API calls to GitHub using the developer's own credentials looks identical to normal IDE behavior. The malicious activity is indistinguishable from legitimate operation because it is using the same interfaces, the same credentials, and the same access patterns as a legitimate extension.

Most security teams still have zero visibility into what extensions are installed on their developers' machines. That is the blind spot these attacks keep walking through.

What Defenders Should Do

The organizations that will avoid becoming the next entry on TeamPCP's list are the ones that extend their existing security governance to cover the developer tooling layer. The gap exists because this layer grew outside traditional security boundaries. Closing it requires deliberate action.

Implement extension allow listing. VS Code's `AllowedExtensions` policy (available since v1.96) lets organizations control exactly which extensions can install. Deploy it via Microsoft Intune, Active Directory Group Policy, or any MDM solution. The configuration is granular: allow by publisher (`"microsoft": true`), by specific extension (`"esbenp.prettier-vscode": true`), or pin to specific versions (`"dbaeumer.vscode-eslint": ["3.0.0"]`). When enforced, unapproved extensions cannot install and become disabled if already present. This is the single highest impact control available today.

Build an extension inventory. Security teams cannot govern what they cannot see. Organizations need visibility into what extensions are installed across their developer fleet, when they were last updated, and who published them. Treat this inventory with the same rigor applied to software asset management for production systems.

Isolate credentials from the developer desktop. The fundamental problem is that developer workstations hold persistent credentials to sensitive systems. Short lived credentials, hardware bound tokens, and just in time access models reduce the blast radius when a workstation is compromised. A stolen OAuth token that expires in fifteen minutes is worth significantly less than a long lived personal access token with repository admin scope.

Segment developer access by project scope. A developer working on a frontend feature should not have credentials to infrastructure repositories loaded in the same IDE session. Scoped access models limit what any single compromised extension can reach.

Treat developer workstations as part of the attack surface. The same assume breach posture organizations apply to servers and cloud workloads needs to extend to developer machines. Monitor for anomalous extension behavior. Alert on unusual outbound connections from IDE processes. Include developer workstations in threat hunting hypotheses.

Apply zero trust to the tooling layer. We have written previously that zero trust should extend to the dependency graph. The same principle applies to the IDE itself. Every extension, every plugin, every integration running inside a developer's IDE is executing with implicit trust that is rarely evaluated. That trust should be earned, monitored, and revocable.

Supply Chain Risk Is No Longer Optional to Manage

The GitHub breach is a data point on a trend line that has gone from 9% third party involvement in breaches in 2022 to 48% in 2025. TeamPCP alone has hit five organizations in three months. The question for security leaders is no longer whether supply chain risk is material. It is whether their organization has done anything structured to measure and manage it.

Most organizations run vendor risk assessments for their SaaS providers and cloud vendors. Far fewer extend that same rigor to the software supply chain, the development tooling, or the extensions running on every developer workstation. The governance gap is not theoretical anymore. It is the active attack surface that the most effective threat actors of 2026 exploit repeatedly and successfully.

The extension blind spot is the most visible symptom. The underlying condition is supply chain risk that has outgrown the governance structures most organizations built to manage it.

At a Glance

What happened. On May 19, 2026, TeamPCP compromised a GitHub employee's device through a poisoned VS Code extension and exfiltrated 3,800 internal repositories. This is their fifth successful supply chain attack in three months.

Why it matters. VS Code extensions have full, unrestricted access to everything on a developer's machine. No sandbox, no permission model, no approval workflow. 97% of the 60,000 extensions in the marketplace are unverified. The browser industry solved this a decade ago. The IDE industry has not started.

The trend. Third party involvement in breaches went from 9% to 48% in three years according to Verizon's DBIR series. Supply chain attacks are shifting upstream from build systems and package registries into the IDE itself, the tool used to write code before it ever reaches a pipeline.

What to do. Deploy VS Code's `AllowedExtensions` policy via Intune or GPO. Build an extension inventory. Isolate credentials with short lived tokens. Include developer workstations in threat hunting. Extend third party risk assessments to cover developer tooling and open source dependencies.

Who is affected. Any organization using VS Code, Cursor, Windsurf, or other VS Code based IDEs. The extension trust model is inherited across all of them.

Sources:

- SecurityWeek, "GitHub Confirms Hack Impacting 3,800 Internal Repositories," May 20, 2026

- HackRead, "GitHub Breach: TeamPCP Steals 3,800 Repositories via VS Code Extension," May 20, 2026

- SecurityWeek, "From Trivy to Broad OSS Compromise: TeamPCP Hits Docker Hub, VS Code, PyPI," May 2026

- StepSecurity, "Nx Console VS Code Extension Compromised," May 2026

- The Record, "GitHub confirms being hacked by TeamPCP, says customer data unaffected," May 20, 2026

- Aikido Security, research on VS Code extension attack surface, May 2026

- Verizon, "Data Breach Investigations Report," 2023, 2024, 2025, 2026 editions

- Koi Security, "Exposing Malicious Extensions: Shocking Statistics from the VS Code Marketplace," 2026

- NDSS 2024, "Developers Are Victims Too: A Comprehensive Analysis of The VS Code Extension Ecosystem"

- Lyrie Research, "The Compromised Workbench: Definitive 2026 Defensive Playbook Against IDE Extension Supply Chain Attacks," 2026

- Sonatype, "State of the Software Supply Chain Report," 2021

The Cost of a Click: Why Passive Cookie Consent Is Your Biggest Compliance Liability

Hannah Perez — Wed, 20 May 2026 18:41:57 GMT

If you think a basic pop-up banner that reads "By continuing to browse this site, you accept cookies" protects your business, you are sitting on a regulatory time bomb.

Historically, cookie compliance was treated as a legal afterthought, a superficial check-the-box marketing chore handled by a generic WordPress or HubSpot plugin. But the landscape has shifted dramatically. Today, passive or forced consent isn't just bad UX; it’s a direct trigger for multi-million dollar class-action lawsuits, regulatory audits, and severe brand damage.

Over the years, I’ve watched organizations struggle with this shift firsthand. Companies that assumed their data tracking was "under the radar" have faced real-world, ruinous litigation simply because their website didn’t give users explicit, granular control over how their data was harvested and shared.

With global regulations tightening, cookie consent has evolved from a simple legal requirement into the front line of Privacy Engineering. If you own, manage, or build for a website, this isn't a problem you can afford to defer.

The Massive Gaps in Traditional Cookie Compliance

Most businesses have glaring compliance gaps because they rely on the illusion of privacy rather than actual data governance. A standard compliance audit frequently exposes three fatal flaws:

"All-or-Nothing" Forced Consent: Forcing users to accept all trackers to view a webpage violates the core tenets of modern privacy frameworks. Under strict standards like the GDPR and evolving U.S. state laws (such as CPRA in California, VCDPA in Virginia, and CPA in Colorado), consent must be freely given, specific, and informed.
Implicit Consent Schemes: Banners that assume a user agrees just because they scrolled down the page are completely non-compliant. If a user hasn't explicitly clicked an "Accept All" or opted into specific categories, firing tracking scripts automatically is an illegal data collection practice.
The "Dark Pattern" Trap: Designing a banner where the "Accept All" button is bright and prominent, while the "Reject All" button is buried deep inside a complex sub-menu, is legally defined as a dark pattern. Regulators and plaintiffs' attorneys are actively targeting companies that manipulate user behavior this way.

The Regulatory Reality Check

The cost of getting this wrong is no longer just a theoretical fine from a distant European regulatory body. The legal risk has landed squarely on domestic soil, driven by a surge in private rights of action and aggressive enforcement of consumer privacy acts.

The Scope: If your website tracks visitors across state lines, collecting telemetry, behavioral patterns, or ad-targeting metrics, you fall under a patchwork of strict data tracking laws.
The Gaps: Traditional legal teams can tell you what the law requires, but they cannot audit your source code or configure your technical stack to enforce it. Meanwhile, development teams often implement third-party marketing tags without realizing those tags are dropping unauthorized, non-compliant tracking cookies.

This disconnect between legal requirements and technical execution is exactly where lawsuits thrive.

Entering the Era of Privacy Engineering

To protect your enterprise, cookie compliance can no longer be handled at the surface level. It requires Privacy Engineering; the practice of embedding data protection and consumer choice directly into your website's technical architecture from the ground up.

Suzu Labs is proud to announce our newest service line: Privacy Engineering. As practitioners who approach cybersecurity and data governance from an offensive and analytical perspective, we don't just hand you a policy document and walk away. We bridge the gap between compliance theory and technical reality.

Our Privacy Engineering service tackles your website’s compliance vulnerabilities through comprehensive technical alignment:

Dynamic Cookie & Tracker Discovery: We deep-scan your entire web ecosystem to identify hidden, obsolete, or rogue scripts that are dropping trackers without authorization.
Granular Preference Engineering: We architect advanced, compliant consent mechanisms that give users precise, verifiable control over specific categories of tracking (such as essential, analytical, functional, and targeting cookies).
Automated Enforcements (Signals like GPC): We configure your environment to automatically recognize and respect browser-level privacy controls, like Global Privacy Control (GPC) signals, ensuring compliance without degrading user experience.
Comprehensive Framework Mapping: Whether your compliance benchmark is GDPR, CCPA/CPRA, or emerging state-level data restrictions, we map your front-end tracking data directly to your backend compliance posture before an auditor, or an attorney, does.

Protect Your Business Today

A website is often a company's largest marketing asset, but without strict privacy safeguards, it can quickly become its greatest financial liability. True compliance isn't achieved by downloading a plugin; it is built through rigorous engineering.

Ensure your website is legally bulletproof and technically sound. Contact Suzu Labs to learn how our Privacy Engineering team can map your compliance gaps, safeguard your tracking infrastructure, and protect your company from preventable legal exposure.

Discover Suzu Labs Privacy Engineering

Sources:

1. General Data Protection Regulation (GDPR)

Under the European Union’s GDPR, consent must be explicitly structured as freely given, specific, informed, and unambiguous. Academic field studies tracking the evolution of web tracking confirm that "all-or-nothing" or forced consent interfaces directly violate these core tenets because they eliminate a user's free choice.

Nguyen, T. T., Backes, M., & Stock, B. (2022). Freely Given Consent? Studying Consent Notice of Third-Party Tracking and Its Violations of GDPR in Android Apps. Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2369-2383. https://doi.org/10.1145/3548606.3560564
Utz, C., Degeling, M., Fahl, S., Schaub, F., & Holz, T. (2019). (Un)informed Consent: Studying GDPR Consent Notices in the Field. arXiv preprint. Distributed via the Federal Trade Commission (FTC) PrivacyCon. https://doi.org/10.1145/3319535.3354212

2. California Consumer Privacy Act / California Privacy Rights Act (CCPA/CPRA)

The CPRA builds fundamentally upon California's existing privacy architecture by explicitly banning the deployment of dark patterns—user interfaces designed or manipulated to undermine user autonomy or force consent. Legal and technical analyses show that hiding a "Reject All" option or forcing total tracking acceptance to access a site directly infringes upon these statutory rules.

Habib, H., Li, M., Young, E., & Cranor, L. (2022). “Okay, whatever”: An Evaluation of Cookie Consent Interfaces. CHI Conference on Human Factors in Computing Systems, 1-27. https://doi.org/10.1145/3491102.3501985
Li, D. (2022). The FTC and the CPRA's Regulation of Dark Patterns in Cookie Consent Notices. The University of Chicago Business Law Review, 1(1), 561-590.
Gunawan, J. (2025). Dark Patterns as Disloyal Design. Scholarly Commons at Boston University School of Law, 1-54.

3. Evolving U.S. State Laws (VCDPA in Virginia & CPA in Colorado)

As the United States remains without a single comprehensive federal data privacy standard, state-level regulations like the Virginia Consumer Data Protection Act (VCDPA) and the Colorado Privacy Act (CPA) have stepped in to establish distinct regulatory frameworks. These state laws mirror foundational tenets of the GDPR and CPRA by mandating clear consumer notification, banning deceptive choice architectures, and requiring structured affirmative opt-ins or clear paths to opt out of behavioral telemetry.

Taetzsch, E. S. (2024). Why the United States Needs a Comprehensive Federal Data Privacy Law. Journal of Legislation (University of Notre Dame), 50(1), 1-32.
Law, P. (2021). The iOS 14.5 Update: A Game Changer in Federal Privacy Law. Richmond Journal of Law and Technology, 28(2), 254-290.

Five Years of US Privacy Breach Data Tell a Story Security Leaders Cannot Ignore

Jacob Krell — Tue, 19 May 2026 17:33:49 GMT

In April 2026 alone, the ShinyHunters extortion group breached ADT (5.5 million customers), Amtrak (2.1 million confirmed records), and McGraw-Hill (13.5 million student and educator accounts). All three attacks followed the same pattern. An employee credential was compromised through social engineering or infostealer malware, which gave the attackers access to the organization's Salesforce environment, from which they exfiltrated millions of records without triggering a single network based detection. No vulnerability was exploited. No malware was deployed on a server. Three household name organizations lost tens of millions of records in a single month through identity based access to cloud platforms.

These are not anomalies. They are the latest data points in a five year acceleration that the numbers now make impossible to dismiss. In 2025, the Identity Theft Resource Center tracked 3,322 data compromises across the United States, a new all time record and a 79 percent increase over 2021. Three consecutive years have now exceeded 3,000 annual compromises. The era of occasional, isolated data breaches is over. What organizations face today is a sustained, structural acceleration in privacy risk that shows no sign of reversing.

The Volume Is Not Going Down

All US Industries (ITRC Annual Data Breach Reports)

Year	Total Compromises	Year Over Year Change
2021	1,859	Baseline
2022	1,798	-3%
2023	3,202	+78%
2024	3,152	-2%
2025	3,322	+5% (New Record)

The jump between 2022 and 2023 is worth pausing on. In a single year, the number of US data compromises increased by 78 percent. That was not a temporary spike. The figure has held above 3,000 for three consecutive years and set a new record in 2025. Over the full five year window, volume increased 79 percent.

Healthcare Only (HHS OCR Breach Portal)

Year	Large Breaches (500+ Individuals)	Year Over Year Change
2021	715	Baseline
2022	719	+1%
2023	746	+4%
2024	742	-1%
2025	710	-4%

Healthcare breaches have plateaued in the 700 to 750 range since 2021. That plateau should not be confused with stability. It represents two large healthcare breaches every single day, a rate that doubled from one per day in 2018. The sector has simply reached a sustained high and stayed there.

The Scale of Each Breach Is Exploding

Volume alone does not capture the full picture. The number of individuals affected per breach is where the acceleration becomes most dramatic.

Healthcare Records Exposed (HHS OCR)

Year	Individuals Affected	Average Breach Size
2021	~45.9 Million	~64,000
2022	~51.9 Million	~72,000
2023	~133 Million	~183,500
2024	~289 Million	~389,000
2025	~61.6 Million	~86,700

Between 2021 and 2024, the number of individuals affected by healthcare breaches alone increased more than sixfold. In 2024, 289 million individuals had their protected health information exposed or impermissibly disclosed. That is roughly 85 percent of the entire US population in a single year, from a single industry.

The 2025 figure appears to represent a return to 2021 levels, but this requires important context. The 2024 total was dominated by the Change Healthcare ransomware attack, which alone affected 192.7 million individuals, the largest healthcare breach in history. When the BlackCat/ALPHV ransomware group hit Change Healthcare on February 21, 2024, the downstream disruption was immediate and nationwide. Pharmacies could not process prescriptions electronically. Hospitals could not verify insurance eligibility. Providers went weeks without reimbursement. UnitedHealth Group, Change Healthcare's parent company, reported over $3.09 billion in direct response costs through Q3 2024.

Remove that single event and 2024 still exceeded 96 million individuals. The underlying trend has not reversed. 2024 was an outlier of catastrophic scale, and 2025 returned to a baseline that would itself have been considered extreme just four years earlier.

All US Industries (ITRC Victim Notices)

Year	Victim Notices Issues
2021	351.8 Million
2022	425.2 Million
2023	420.4 Million
2024	1.37 Billion
2025	278.8 Million

The cross industry picture mirrors healthcare. In 2024, 83 percent of all 1.37 billion victim notices came from just five mega breaches, each affecting over 100 million individuals. The concentration of harm into fewer, larger incidents is itself a structural shift.

Physical Theft Is Dead. Hacking Owns the Curve.

The nature of breaches has changed as dramatically as their volume. A decade ago, physical loss and theft of devices containing unencrypted data was a leading cause of healthcare breaches. That era is over.

According to HHS OCR data, the shift has been rapid and decisive.

- In 2019, hacking and IT incidents accounted for 49 percent of all large healthcare breaches.

- By 2023, that figure reached 79.7 percent.

- In 2025, hacking and IT incidents exceeded 80 percent of all reported breaches.

OCR has documented a 239 percent increase in hacking related breaches between January 2018 and September 2023, and a 278 percent increase in ransomware attacks over the same period. Loss and theft incidents, once the dominant breach category, now occur at a rate of less than one per month and typically involve paper records rather than electronic devices.

Within the hacking category, the tactics are also evolving. According to the ITRC, phishing, smishing, and business email compromise remained the number one root cause of data breaches in 2025, increasing slightly to 466 incidents from 458 in 2024. Ransomware, by contrast, declined for a second consecutive year, falling from 194 incidents in 2024 to 143 in 2025. Attackers are increasingly choosing to steal data and threaten to release it rather than encrypting it.

The economics have shifted. Encryption triggers immediate detection, incident response, and often law enforcement involvement. Quiet exfiltration can go undetected for months. The Cl0p ransomware group demonstrated this model at scale in 2023 when it exploited a vulnerability in MOVEit Transfer file sharing software, exfiltrating data from over 2,600 organizations without encrypting a single file. Many victims did not learn they were compromised until Cl0p posted their names on a leak site weeks later.

The ITRC also identified an emerging threat it calls "Previously Compromised Data" or PCD. Attackers are using AI to repackage records stolen in older breaches to launch new attacks, including account takeover and fraudulent account creation. Data stolen years ago is not inert. It continues to have value and continues to produce harm indefinitely.

This shift matters for how organizations think about privacy protection. The controls that mattered ten years ago, encrypting laptops, tracking portable media, securing filing cabinets, are no longer where the risk lives. The risk lives in network infrastructure, cloud environments, identity systems, and the third party vendors who manage them.

Third Party Breaches Are Growing Faster Than Direct Ones

Perhaps the most consequential trend in the data is the rise of breaches that originate not within an organization, but within its vendor ecosystem.

The ITRC's 2025 report found that supply chain attacks doubled between 2021 and 2025. Approximately 30 percent of all breaches now involve at least one third party. The number of entities affected by supply chain attacks nearly doubled in a single year, from 660 in 2024 to 1,251 in 2025, despite the number of initial attacks remaining flat.

In healthcare specifically, HHS OCR data shows that 35.8 percent of all 2025 breaches occurred at business associates rather than covered entities. Business associate breaches consistently expose more records per incident because a single vendor often processes data for dozens or hundreds of healthcare organizations simultaneously. In 2023, business associates accounted for 23 percent of breach reports but 58 percent of all exposed records (77.3 million out of 133 million total).

The underlying mechanism is vendor consolidation, and it functions like a structural load bearing wall in a building. As industries migrate to shared platforms, clearinghouses, and cloud infrastructure, the number of organizations that depend on any single vendor grows while the number of independent security boundaries shrinks. Remove that one wall and the entire floor collapses.

Change Healthcare operated as a clearinghouse processing 15 billion healthcare transactions annually. When it was breached, the downstream impact affected nearly every healthcare organization in the country. A single point of compromise produced 192.7 million victim records. The same dynamic plays out at smaller scales constantly. A billing vendor breach exposes records from hundreds of practices. An EHR platform compromise affects every provider using that system. The blast radius of a vendor breach is a function of how many organizations that vendor serves, and industry consolidation is pushing that number higher every year.

Professional services firms, the lawyers, accountants, and consultants that serve as trusted intermediaries for multiple organizations, saw the most aggressive growth in attacks over the five year period. The ITRC documented a 162 percent increase in compromises targeting professional services, from 182 in 2021 to 478 in 2025. These firms are increasingly used as stepping stones to compromise their multiple clients.

The Transparency Crisis Compounds the Problem

At this point one is likely wondering whether there is at least a silver lining in collective learning, whether organizations are sharing enough about what went wrong to help others defend. The opposite is happening. Organizations are disclosing less about breaches, not more.

According to the ITRC, the decline is steep.

- In 2020, nearly 100 percent of breached organizations disclosed how the breach occurred.

- By 2024, only 35 percent did.

- In 2025, that figure collapsed to 30 percent.

Seven out of ten breach notifications in 2025 contained no information about the attack vector. The individuals who received those notices, and the other organizations trying to learn from those incidents, were given no actionable information about what went wrong or how to prevent it.

This is a collective intelligence failure. When organizations withhold root cause information to mitigate legal or reputational exposure, they prevent the broader ecosystem from learning. Every organization that reads a breach notice and finds no attack vector information is an organization that cannot assess whether it faces the same risk. The ITRC has called repeatedly for a federal breach notification standard that would mandate disclosure of attack vector, root cause, and remediation steps. No such federal standard exists. State notification laws vary widely in what they require, and most do not mandate root cause disclosure. The privacy landscape is getting worse in part because the feedback loop that should be making it better has broken down.

The Regulatory Surface Area Has Exploded

Breaches are accelerating. At the same time, the number of regulatory frameworks organizations must comply with has multiplied at an extraordinary pace.

Period	States With Comprehensive Privacy Laws In Effect
2020	1 (California CCPA)
End of 2023	5 (added Virginia, Colorado, Connecticut, Utah)
End of 2024	8 (added Texas, Oregon, Montana)
April 2026	20 (added Iowa, Delaware, Nebraska, New Hampshire, New Jersey, Tennessee, Minnesota, Maryland, Indiana, Kentucky, Rhode Island, Vermont)

In 2020, one state had a comprehensive consumer privacy law in effect. By April 2026, twenty do. Twelve new laws took effect between January 2025 and mid 2026 alone. Alabama has passed both chambers and awaits a governor's signature. Pennsylvania, Louisiana, and Massachusetts have bills in active sessions. Each law has its own applicability thresholds, consumer rights, breach notification requirements, and enforcement mechanisms. There is no federal privacy law to preempt this patchwork.

This regulatory acceleration is happening alongside the breach acceleration documented above. More breaches trigger more notifications, which trigger more investigations, which trigger more enforcement actions, which produce more regulation. The cycle is self reinforcing. The organization that suffers a breach in 2026 does not answer to one regulator. It may answer to five or ten at once.

A US Breach Now Costs $10.22 Million and the Number Is Still Climbing

IBM's 2025 Cost of a Data Breach Report quantifies what this environment costs organizations.

The US average cost of a data breach reached $10.22 million in 2025, a 9.2 percent increase over 2024 and a new all time record for any region. Globally, breach costs fell for the first time in five years to $4.44 million, driven by faster detection through AI powered defenses. The US moved in the opposite direction, with higher regulatory fines and escalation costs driving the increase. The gap between US breach costs and the global average has never been wider.

Healthcare remains the most expensive industry for breaches for the 14th consecutive year, at $7.42 million per incident. Healthcare breaches also took the longest to identify and contain, at an average of 279 days, more than five weeks longer than the global average of 241 days. Every additional day an attacker dwells in a healthcare environment is another day of data exfiltration, another set of records exposed, another expansion of the eventual notification scope.

The consumer economic impact is equally concrete. According to the ITRC's 2025 survey, 80 percent of consumers received at least one breach notice in the past 12 months. Of those affected, 36 percent lost more than $10,000 to cybercriminals and over 20 percent of those who contacted the ITRC directly lost more than $100,000. These are people who had credentials stolen in one breach, repackaged by attackers using AI, and used to drain bank accounts months or years later. The ITRC also found that 81 percent of small businesses reported a cyberattack in the past year, and nearly 40 percent raised prices to cover remediation costs. The ITRC calls this the "cyber tax." Consumers pay for institutional security failures through higher prices whether they were personally affected or not.

Five Years of Compounding Risk Leave Security Leaders With Shrinking Margin

These trends are not independent. They compound. More breaches trigger more notifications, which trigger more enforcement under more state laws, which increases the financial and operational consequences of each incident. The organization that suffers a breach in 2026 faces a fundamentally different regulatory, legal, and economic environment than one that suffered the same breach in 2021.

It is important to consider that breach exposure is not a matter of if but simply a matter of when. The math makes this clear. With 3,322 compromises across approximately 6.5 million US employer firms (per Census Bureau data), roughly one in every 1,960 organizations appeared in a public breach report in 2025. That is the base rate before accounting for unreported incidents, third party exposure, and the fact that supply chain breaches now cascade across hundreds of downstream entities per event. Factor in that 30 percent of all breaches involve a third party, and the probability of an organization being affected, directly or through a vendor, rises substantially. Over a five year window at current rates, the cumulative exposure is closer to one in 400.

For security leaders, this data has practical implications. The complexity of the privacy landscape has grown faster than most organizations' capacity to manage it, and the window for proactive investment is closing. We advise organizations to act on four priorities immediately.

Map your third party data exposure. Thirty percent of breaches now originate at vendors, and supply chain breach cascades doubled in a single year. We recommend that every critical vendor relationship have contractual breach notification timelines and evidence of current security assessments.

Audit identity and SaaS access controls. The ShinyHunters campaign that opened this analysis exploited employee credentials to access cloud platforms without triggering network detections. Conditional access policies, phishing resistant MFA, and SaaS session monitoring are now baseline requirements.

Staff a dedicated privacy function. Twenty state privacy laws, each with different breach notification timelines and consumer rights requirements, cannot be managed with part time attention from a CISO or general counsel. We see consistently that the organizations weathering this environment have someone whose job is to know where personal data resides and what obligations attach to it.

Treat breach response as a when, not an if. At one in 400 cumulative five year exposure, the question is readiness. Tabletop exercises, pre negotiated incident response retainers, and documented notification workflows should be in place before the incident arrives. The cost of building that capability after a breach has been publicly reported is measured in both dollars and trust.

Sources:

- Identity Theft Resource Center, "2025 Annual Data Breach Report," January 2026

- Identity Theft Resource Center, "2024 Annual Data Breach Report," January 2025

- U.S. Department of Health and Human Services, Office for Civil Rights, Breach Portal (data through February 2026)

- HIPAA Journal, "Healthcare Data Breach Statistics," updated February 27, 2026

- HIPAA Journal, "2025 Healthcare Data Breach Report," January 2026

- IBM, "2025 Cost of a Data Breach Report"

- HIPAA Journal, "Average Cost of a Healthcare Data Breach Falls to $7.42 Million," August 2025

- BlueRadius Cyber, "HIPAA Breach Report 2026: OCR Data, Ransomware Trends," April 2026

- MultiState, "20 State Privacy Laws in Effect in 2026," February 2026

- DapriPro, "State Privacy Law Tracker: New Regulations Taking Effect in 2026"

- IAPP, "US State Privacy Legislation Tracker 2026"

- Federal Trade Commission, Privacy and Security Enforcement Actions

- PrivacyLawMap, "Privacy Enforcement Actions and Penalties Tracker," April 2026

Mean Time to Exploit Has Gone Negative. Security Strategy Has to Change.

Jacob Krell — Tue, 05 May 2026 17:12:17 GMT

Mandiant's M-Trends 2026 report puts estimated mean time to exploit at negative seven days. That number should reset how security leaders think about vulnerability management. It means exploitation is now routinely occurring before a patch is available.

In 2018, that same window was 63 days. Defenders had roughly two months between disclosure and exploitation to identify, prioritize, test, and deploy a fix. In 2024, the metric crossed zero. Now it sits at negative seven. The window did not just shrink. It inverted.

The question that should follow immediately: how quickly can we find the adversary that is already here?

The Numbers Behind the Collapse

The Mandiant figure is not an outlier. Multiple independent sources have converged on the same conclusion.

Source: Mandiant M-Trends reports 2019-2026.

CrowdStrike’s 2026 Global Threat Report documents a sharp rise in pre-disclosure exploitation, reporting a 42 percent increase in zero-day vulnerabilities exploited before public disclosure. Google's Threat Intelligence Group tracked 90 zero day vulnerabilities exploited in the wild during 2025, with 48 percent targeting enterprise technologies, an all time high. The Verizon 2025 DBIR found vulnerability exploitation now accounts for 20 percent of all breaches, a 34 percent year over year increase.

AI is reducing the skill and time required to turn advisories into working exploit logic. Even when AI does not produce a finished exploit, it accelerates vulnerability comprehension, payload adaptation, and target specific testing. LiteLLM's CVE-2026-42208 was actively exploited within 36 hours of advisory publication earlier this year. On May 1, 2026, Reuters reported that CISA is considering cutting the default KEV remediation window from two weeks to three days in direct response to AI compression of exploitation timelines.

The threat is fast. That is proven. The question now is what that speed means for defensive strategy.

Why Prevention Heavy Budgets No Longer Match the Threat Model

The traditional vulnerability management model assumes a positive gap between disclosure and exploitation. That gap is where patching lives. Identify, prioritize, test, schedule, deploy, verify. That sequence assumes time. When estimated mean time to exploit is negative seven days, the entire sequence executes after the adversary is already inside.

If exploitation can precede patch availability, then patching cannot be the decisive control for that class of vulnerability. It remains necessary, but it cannot be sufficient. The decisive control becomes time to detection. The organization that finds the actor in hours survives. The organization that finds the actor from a ransom note does not.

Organizations spending the majority of their security budget on preventive controls are optimizing for a threat model that expired sometime in 2023. CrowdStrike's 2026 report found 82 percent of detections are now malware free. The fastest observed eCrime breakout time was 27 seconds, with the average at 29 minutes. Mandiant's M-Trends 2026 report found the initial access broker handoff to a ransomware affiliate has collapsed to 22 seconds.

Mandiant’s M-Trends 2026 report found prior compromise was the most frequently confirmed initial infection vector for ransomware in 2025 at 30 percent, double the prior year. Ransomware operators are purchasing footholds that already exist. No patch deployed at the time of the ransomware event would have prevented the initial compromise because it was already in the past.

Prevention still matters. It gets right sized for a threat landscape where it can no longer carry the entire defensive load alone.

Assume Breach and Detection as the Decisive Controls

The security industry has talked about "assume breach" for over a decade. For most of that time it remained aspirational. The data now says something different. Assume breach has become descriptive of the current reality.

Mandiant's M-Trends 2026 report found global median dwell time at 14 days, up from 11 in the prior period. For cyber espionage incidents, median dwell time reaches 122 days. Organizations detected malicious activity internally only 52 percent of the time, up from 43 percent the prior year. For every breach an organization finds on its own, there is roughly another one it only learns about when someone else tells it.

If dwell time is measured in weeks or months and nearly half of compromises are found externally, a significant percentage of organizations are compromised right now and do not know it.

The control that determines business impact is detection speed. The mechanism that compresses dwell time is threat hunting: proactive, hypothesis driven searching for adversary presence that does not wait for an alert to trigger.

The financial case is quantified. IBM’s 2025 Cost of a Data Breach Report found that organizations using security AI and automation extensively saved $1.9 million per breach and reduced breach identification and containment time by 80 days. Organizations with extensive use identified and contained breaches in 204 days, compared with 284 days for organizations with no use. That gap translates directly to reduced blast radius and lower cost.

Mitiga’s 2026 cloud resilience research recommends rebalancing security investment toward 50 percent prevention, 30 percent detection, and 20 percent response. The exact ratio matters less than the direction. The same AI capabilities compressing the offensive timeline are available on the defensive side today. AI assisted threat hunting allows security teams to generate hypotheses at machine speed, correlate anomalies across millions of log entries, and automate triage down to the investigations that warrant human attention.

The SANS 2025 Threat Hunting Survey found that 61 percent of organizations cite skilled staffing shortages as their primary barrier to threat hunting. The investment case includes solving the capacity problem, not just purchasing platforms. Organizations need dedicated headcount, structured methodology, and AI tooling that allows smaller teams to operate at the pace the threat demands.

What Security Leaders Should Do Now

Rebalance investment toward detection and response. Shift budget toward threat hunting teams, behavioral analytics, and incident response readiness.

Stand up or expand threat hunting programs. Weekly structured hunts targeting identity based lateral movement, administrative tool misuse, and edge device compromise. Compromise assessments that start from the assumption the adversary is present.

Deploy AI assisted defensive tooling. Hypothesis generation, log correlation, anomaly detection, and triage automation at machine speed. Organizations that restrict their security teams from AI capabilities do not reduce the offensive use case. They forfeit the defensive one.

Operate under the assumption that prevention has already failed somewhere in the environment. Design detection and response capabilities around that assumption and the dwell time numbers will follow.

The organizations that survive this shift will not be the ones that patch perfectly. No one patches perfectly at negative seven day speed. They will be the ones that assume exposure, hunt continuously, compress dwell time, and use AI to scale defensive judgment before attackers use it to scale exploitation.

The patch window has inverted. Security strategy has to invert with it.

Sources:

Mandiant, Google Cloud, M-Trends 2026: Data, Insights, and Strategies From the Frontlines, March 2026.
CrowdStrike, 2026 Global Threat Report, February 2026.
CrowdStrike, 2026 Global Threat Report Executive Summary, February 2026.
Google Threat Intelligence Group, Look What You Made Us Patch: 2025 Zero-Days in Review, March 2026.
Verizon, 2025 Data Breach Investigations Report, April 2025.
Reuters, U.S. officials weigh cutting deadlines to fix digital flaws amid worries over AI-powered hacking, sources say, May 1, 2026.
IBM, Cost of a Data Breach Report 2025, 2025.
IBM / hosted PDF copy, Cost of a Data Breach Report 2025: The AI Oversight Gap, 2025.
SANS Institute, 2025 Threat Hunting Survey: Advancements in Threat Hunting Amid AI and Cloud Challenges, March 2025.
Intel 471, SANS 2025 Threat Hunting Survey Report, 2025.
Mitiga, A Mindset Shift for Cloud Security Resilience: Assume Breach, 2026.

When AI Billing Breaks Trust: What the Claude Code Backlash Says About AI Governance

Hannah Perez — Thu, 30 Apr 2026 16:56:56 GMT

When AI Billing Breaks Trust: Lessons from the Claude Code Backlash

AI adoption is accelerating, but trust is still fragile.

Recently, users of Claude Code raised concerns about how usage is being billed, specifically around when subscription usage ends and paid “extra usage” begins.

Public reports across GitHub and community forums describe scenarios where users still had included usage available, but were instead charged for exceeding usage at the API billing rates.

To clarify, Anthropic sold users a block of usage. Users who were below their caps were charged extra for exceeding it (which they didn't). And rather than fixing the glitch Anthropic clarified that it was their policy to not fix "incorrectly routed" billings. That they expected users to simply pay up for usage they didn't owe.

There's a technical term for intentionally over-billing, despite being aware that generated bills were erroneous or incorrect. It's called fraud.

These reports are not proof of systemic failure. But they highlight a growing gap between user expectations and system behavior.

And then things got more interesting.

When Context Changes Cost

In a widely shared thread on Reddit, one developer claimed that simply having the string “HERMES.md” in their git commit history triggered Claude Code to route usage to paid billing, resulting in roughly $200 in unexpected charges.

Why does that matter?

Because Claude Code is designed to ingest project context—including recent commits—into its working prompt.

And “HERMES.md” isn’t a random string, it’s a legitimate convention used in AI agent systems to define project-level context and behavior.

Users who were using paid API licenses for their Hermes configurations were using Claude Code to assist in the setup. A perfectly valid use case that did not violate terms of service. Rather than using the context to determine if a particular usage exceeded allowable use cases (such as is the case for other safety training), they took the lazy way out. A literal check for a specific filename, and nothing more.

Some community speculation suggests this may have interacted with internal safety or abuse-detection mechanisms that influence how requests are classified—and potentially how they’re billed.

To be clear: this behavior has not been publicly confirmed by Anthropic.

But that’s exactly the point.

The Real Risk: Invisible Decision-Making

If a system can:

Interpret your development environment
Classify your activity
Change how your usage is handled
And impact billing as a result

…without clear visibility or explanation;

you no longer fully control the system.

This Isn’t Just a Billing Issue

This is part of a broader pattern:

Changing pricing models
Shifting feature access (e.g., third-party tools moving to separate billing)
Revised cost expectations for real-world usage

Individually, these are product decisions.

Together, they point to a deeper issue:

AI systems are now making operational decisions that directly impact cost, risk, and trust.

What This Means for AI Adoption

As AI becomes embedded into engineering and business workflows, companies need more than capability.

They need:

Clear usage governance
Visibility into how decisions are made
Validation of system behavior under real conditions
Defined escalation paths when something goes wrong

Because billing surprises are rarely the root problem.

They’re the symptom.

Where Suzu Labs Comes In

At Suzu Labs, we help organizations validate, not just adopt, AI systems.

Our AI Assessment and Advisory services identify:

Hidden behaviors in AI tooling
Gaps between expected and actual system operation
Risks in billing, access, and control logic

We test how these systems behave in the real world, so you’re not learning the hard way.

Because in AI, trust isn’t given.

It’s verified.

Sources:

GitHub issue (Claude Code routing to paid “extra usage” despite available subscription usage):
https://github.com/anthropics/claude-code/issues/45249
GitHub issue (~$60 unexpected extra usage charges + denied dispute):
https://github.com/anthropics/claude-code/issues/45497
Anthropic official documentation on Claude Code usage + billing behavior:
https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Reddit thread reporting “HERMES.md” commit string allegedly triggering ~$200 in extra usage charges (community-reported behavior):
https://www.reddit.com/r/ClaudeAI/comments/1svdm1w/psa_the_string_hermesmd_in_your_git_commit/
GitHub discussion referencing HERMES.md as a legitimate AI agent configuration convention:
https://github.com/NousResearch/hermes-agent/issues/502
The Verge article on Anthropic shifting third-party tool access (e.g., OpenClaw) to separate billing:
https://www.theverge.com/ai-artificial-intelligence/907074/anthropic-openclaw-claude-subscription-ban
Business Insider report on revised Claude Code token cost estimates:
https://www.businessinsider.com/anthropic-claude-code-token-estimates-2026-4

From Army Ranger to Ethical Hacker: What Cybersecurity Can Learn from the Battlefield

Suzu Labs — Wed, 29 Apr 2026 17:07:42 GMT

Cybersecurity doesn’t start with tools, it starts with mindset.

In this episode featuring Aaron Colclough, we get a rare look at how military discipline, real-world threat thinking, and hands-on experience shape some of the best cybersecurity professionals today. His journey from Army Ranger to ethical hacker highlights a reality many organizations overlook: true security isn’t theoretical, it’s practiced.

The Path from Military to Cybersecurity

Aaron’s story isn’t a straight line, it’s a transition rooted in adaptability.

Coming from a military background, he didn’t just learn cybersecurity through textbooks. He approached it the same way he approached missions:

Understand the objective
Identify weaknesses
Execute with precision

That mindset translated seamlessly into cybersecurity, where attackers don’t follow rules—and defenders can’t afford to either.

Why Hands-On Experience Matters More Than Certifications

One of the biggest takeaways from the conversation is simple:

You don’t learn security by reading about it—you learn by doing it.

Aaron emphasizes that real growth in cybersecurity comes from:

Breaking things (safely)
Testing systems like an attacker would
Learning from failure, not avoiding it

This is where many organizations fall short. They rely heavily on compliance checklists and certifications, but those don’t simulate real-world attacks.

Thinking Like an Attacker (Without Being One)

The shift from defender to attacker mindset is where real security begins.

Aaron highlights that ethical hackers succeed because they:

Question assumptions
Look for unintended entry points
Exploit what others overlook

It’s not about being malicious—it’s about understanding how malicious actors think so you can stop them.

The Problem with “Check-the-Box” Security

A major theme throughout the episode is the gap between perceived security and actual security.

Many companies believe they’re protected because they:

Passed an audit
Installed security tools
Met compliance requirements

But none of those guarantee resilience.

Real attackers don’t care about compliance—they care about opportunity.

Translating Military Discipline into Cyber Defense

Aaron’s background as an Army Ranger plays a huge role in how he approaches cybersecurity:

Discipline: Consistency beats occasional effort
Preparation: You train before the attack, not during it
Adaptability: No plan survives first contact

This translates directly into stronger security programs—ones that are tested, not assumed.

What Businesses Should Take Away

If there’s one thing this episode makes clear, it’s this:

Security is not a tool—it’s a practice.

Organizations should:

Invest in real-world testing (not just audits)
Think like attackers, not just defenders
Prioritize hands-on validation over assumptions

Because at the end of the day, the question isn’t:
“Are we secure?”
It’s:
“Have we actually tested that?”

Final Thoughts

Aaron’s journey reinforces something the cybersecurity industry is slowly realizing:

The best defenders are the ones who understand offense.

Whether it’s through adversarial simulation, penetration testing, or continuous validation, organizations need to move beyond surface-level security and start embracing real-world testing.

Because attackers already are.

Watch the full podcast here: Army Ranger Turned Professional Hacker with Aaron Colclough

When Elite Cyber Teams Can't Crack Web Security

Jacob Krell — Thu, 23 Apr 2026 17:11:00 GMT

HTB's 2025 benchmark tested 796 security teams. Only 21% passed web security challenges.

The Security Illusion

Security certifications line your walls. Compliance audits come back clean. Your team assures leadership that web applications are secure. Everything looks good on paper.

Then comes the test. Hack The Box's 2025 Global Cyber Skills Benchmark put 796 corporate security teams through real-world scenarios mirroring actual attacker methodologies. These weren't fresh graduates or understaffed IT departments. These were elite corporate teams with dedicated security professionals, competing for significant prize money, motivated to demonstrate their capabilities. The result reveals an uncomfortable truth about the gap between security theater and security capability: only 21.1% could successfully identify and mitigate common web vulnerabilities under test conditions.

This performance gap matters because it exposes a systemic failure in how organizations build and measure security capability. We've created an industry where passing compliance audits and earning certifications has become divorced from the ability to defend against real attacks. The implication? Most organizations are operating under a dangerous illusion of security, validated by credentials that don't correlate with defensive capability when it counts.

The Numbers Tell a Troubling Story

The benchmark brought together 4,549 security professionals from companies across the globe. These were corporate teams competing for $50,000 in prizes, facing 66 challenges across 16 technical categories.

21.1% Web security challenge solve rate
18.7% Secure coding challenge solve rate
21.3% Cloud security challenge solve rate

Web applications have become the primary attack surface for modern businesses. Industry data consistently shows that application-layer vulnerabilities account for the majority of successful breaches, yet the benchmark reveals that even motivated security professionals struggle to identify these flaws under test conditions. The secure coding score of 18.7% is particularly revealing. Education's 0% performance in this category exposes a fundamental problem: we're training tomorrow's developers without embedding security as a core competency. The result is a continuous cycle where vulnerabilities are architected into systems from inception, only to be discovered in production when attackers find them first.

Industry Breakdown: Regulatory Compliance Doesn't Equal Defensive Capability

The performance patterns across industries reveal an uncomfortable disconnect between investment, regulation, and actual security capability:

Healthcare (15.6%): Despite HIPAA compliance requirements and significant security spending, healthcare organizations demonstrate below-average defensive capability. The complexity of legacy systems integrated with modern applications creates attack surfaces that compliance frameworks don't adequately address. When patient data breaches occur, it's rarely because organizations lacked compliance documentation.

Finance (19.2% web, 10.1% blockchain): Financial institutions operate under the heaviest regulatory scrutiny in business, yet barely outperform the overall average. The blockchain score is particularly telling. Organizations have invested heavily in emerging technology without building corresponding security expertise. Regulation creates minimum baselines; it doesn't build capability.

Retail (20.3%): Slightly above average, but consider the implications. One in five retail security professionals can identify common web vulnerabilities. The other four can't reliably protect the payment systems and customer data that represent the business's trust foundation.

Education (7.8% web, 0% secure coding): The institutions training tomorrow's technology workforce demonstrate the weakest performance. This isn't just ironic; it's structurally problematic. We're perpetuating skill gaps at the source.

Energy & Utilities (6.7%): Critical infrastructure operators demonstrate the lowest web security capability. These organizations protect systems where security failures have physical-world consequences beyond data breaches, yet show the weakest performance in defending web-accessible interfaces to operational technology.

The pattern is clear: traditional security approaches based on compliance, tool acquisition, and certification don't translate to defensive capability when tested against realistic attack scenarios. Organizations across every sector are investing in security without building the practical skills needed to apply it effectively.

Why Performance Doesn't Match Investment

The Certification Paradox

Security certifications have become currency in hiring and advancement, yet they predict nothing about an individual's ability to identify and mitigate actual vulnerabilities. The disconnect is structural: certifications test knowledge retention and theoretical understanding through multiple-choice formats. The HTB benchmark tested applied skill under conditions mirroring how real attacks unfold. Attackers don't present multiple-choice questions. They probe, experiment, iterate, and exploit. Organizations have built hiring, training, and advancement structures around credentials that validate the wrong things.

This creates a perverse incentive structure. Security professionals optimize for certification acquisition because that's what employers reward. Employers rely on certifications because they need some basis for evaluating candidates. Everyone operates rationally within a system that produces teams capable of passing exams but struggling with the practical application of security principles under realistic conditions.

The "Shift Left" Illusion

The 18.7% secure coding solve rate exposes a gap between security rhetoric and reality. Every organization claims to practice DevSecOps and shift security left in the development lifecycle. The benchmark results suggest most of this is aspirational rather than operational. Secure coding isn't a tool you integrate into your pipeline. It's a competency that must be developed in your development team. Most organizations have implemented security automation without building security capability.

The result is predictable: automated tools identify vulnerabilities, but developers lack the expertise to properly evaluate false positives, understand attack vectors, or architect resilient solutions. Security becomes a checkbox in the CI/CD pipeline rather than a practice embedded in how teams think and work. Vulnerabilities introduced during development are exponentially more expensive to remediate in production, and they represent systemic risk because they reflect fundamental gaps in how teams approach building software.

The OWASP Top 10 Isn't Secret Knowledge

The OWASP Top 10 has been publicly available and widely referenced for nearly two decades. These aren't zero-day vulnerabilities requiring sophisticated exploitation techniques. They're well-documented, frequently discussed, common vulnerability patterns. The benchmark essentially asked: can your security team identify and mitigate the most predictable, well-known vulnerabilities that attackers routinely exploit? For most organizations, the answer is no.

This failure has direct business implications. Retail teams scoring 20.3% means one in five can identify vulnerabilities in payment processing flows or customer data handling. The other four can't, which means security reviews likely miss exploitable flaws. Financial institutions at 19.2% means online banking platforms, mobile apps, and transaction systems undergo security assessments by teams that miss common vulnerabilities four times out of five. Healthcare at 15.6% means patient portals, electronic health records integrations, and medical device interfaces likely contain exploitable vulnerabilities that internal security reviews don't catch.

Organizations invest in security tools, hire security professionals, conduct security reviews, and maintain compliance. Yet when tested on the ability to identify common, well-documented vulnerabilities under realistic conditions, most teams fail. The problem isn't lack of investment. It's misallocation of investment into credentials, tools, and processes that don't build the practical skills required to defend against actual attacks.

What High Performers Do Differently

The benchmark data reveals that top-performing organizations approach security fundamentally differently from their peers. The gap isn't about budget, tools, or headcount. It's about how they build and validate capability. Organizations in the top quartile share common characteristics that distinguish them from the average performers struggling with basic vulnerability identification.

They Measure What Matters

Top performers moved beyond using certifications and compliance as proxy measures for security capability. They implemented performance-based validation that tests whether their teams can actually identify and mitigate vulnerabilities under realistic conditions. This shift from credential-based to capability-based assessment changes how organizations invest in security talent development. When you measure practical skill application instead of certification completion, you optimize for different outcomes.

The concept of Continuous Threat Exposure Management (CTEM) reflects this philosophy. Rather than treating security validation as a periodic event (annual penetration tests, quarterly scans), high performers maintain continuous assessment cycles that validate defensive capability against evolving attack techniques. This creates feedback loops where teams learn from realistic scenarios and develop practical pattern recognition that translates to improved defensive performance.

They Build Security Capability Where It Matters Most

The secure coding performance gap reveals where most organizations fail: at the source. Top performers recognized that security team training doesn't fix vulnerabilities introduced during development. They invested in building security competency within development teams themselves. This isn't about tools or automation. It's about developing developers who understand security as a core aspect of their craft, not an external constraint imposed by the security team.

This requires fundamentally different approaches to developer education. Instead of one-time security awareness training, high performers provide regular, hands-on practice with security scenarios relevant to the applications teams actually build. Security becomes part of the development feedback loop rather than a gate at the end of the process. Code reviews explicitly evaluate security implications. Architecture discussions include threat modeling. Security expertise diffuses throughout the development organization rather than remaining concentrated in a separate security team.

Moving from Insight to Action

The HTB 2025 Global Cyber Skills Benchmark accomplished something rare: it measured actual defensive capability under realistic conditions rather than accepting credentials and compliance as proxies. The results reveal an uncomfortable gap between how organizations think about security and the practical reality of their defensive capabilities. This gap matters because attackers don't care about your compliance posture or your team's certifications. They care about whether your defenses can detect and respond to exploitation attempts.

Rethinking How You Build Security Capability

Start measuring practical ability instead of credentials. The correlation between certifications and defensive capability is weak at best. Organizations need assessment methods that test whether teams can identify and mitigate real vulnerabilities under realistic conditions. This doesn't mean abandoning certifications entirely, but it does mean recognizing them as baseline knowledge indicators rather than capability predictors. Build evaluation and advancement criteria around demonstrated skill application.

Invest in capability development, not just tool acquisition. Security tools are valuable, but they're only as effective as the teams operating them. High performers in the benchmark didn't succeed because they had better tools. They succeeded because their teams had developed pattern recognition and practical skills through continuous practice against realistic scenarios. Shift training budgets from certification bootcamps to hands-on practice environments where teams can safely fail, learn, and develop intuition about security.

Build security competency where vulnerabilities are introduced. The 18.7% secure coding score shows that most organizations haven't successfully diffused security expertise into their development teams. Security can't remain the exclusive domain of a separate security team. Development teams need embedded security competency. This requires changing how developers are educated, how code is reviewed, how architecture is evaluated, and how success is measured. Make security capability part of what it means to be a developer, not an external constraint developers work around.

The Strategic Imperative

Web applications have become the primary interface between businesses and their customers, partners, and operations. Application security isn't an IT concern; it's a business continuity issue with direct implications for revenue, reputation, and regulatory exposure. Organizations that continue operating under the illusion that compliance equals security will continue experiencing the gap between their security theater and their actual defensive capability.

The benchmark data suggests most organizations are operating in this gap. The difference between high performers and average organizations isn't resources or budget. It's a fundamental difference in how they approach building and validating security capability. Moving from average to high performance requires acknowledging that traditional approaches (certifications, compliance, tool acquisition) don't build the practical skills required to defend against real attacks.

The opportunity is significant. Organizations that invest in building genuine defensive capability rather than just accumulating security credentials will develop competitive advantages. They'll ship more secure products, respond more effectively to incidents, make better architecture decisions, and reduce the business risk that comes from having security teams that can't reliably identify common vulnerabilities.

The choice is whether to continue optimizing for compliance and certifications while accepting the capability gap, or to embrace the harder work of building practical security skills throughout your organization. Attackers are betting most organizations will choose the former. The benchmark data suggests they're probably right.

Ready to Test Your Real Security Posture?

Suzu Labs specializes in web application security assessments and penetration testing that go beyond compliance. We measure real defensive capability through performance-based validation.

Sources:

1. https://www.hackthebox.com/business/reports/cyber-skills-benchmark-2025

The Invisible Threat: Business Logic Flaws in Modern Applications and Why Scanners Miss Them

Jacob Krell — Wed, 22 Apr 2026 18:53:50 GMT

In today's security landscape, some of the most dangerous vulnerabilities aren't flagged by automated scanners at all. These are the business logic flaws: subtle mistakes in an application's design or workflow that malicious actors can exploit by doing the unexpected. As a result, companies can be blindsided by breaches even when their vulnerability scan reports come back clean.

In this whitepaper, we'll explore how business logic flaws hide in plain sight, why automated tools (even those using AI) struggle to detect them, and why human-led penetration testing remains essential for rooting them out. Along the way, we'll delve into real-world examples (from web apps to Active Directory domains), highlight the author's perspective as an OSWE and OSEP certified expert, and show how engaging a skilled human tester can make all the difference in securing your organization.

What Are Business Logic Flaws?

Every application operates according to certain business rules or logic: the expected steps and checks that define how users and systems should interact. A business logic flaw is a weakness in those rules or their implementation. Unlike typical security bugs (like SQL injection or cross-site scripting) which result from coding errors, logic flaws arise when the application works as it was programmed, but in an unintended way.

In other words, the application doesn't prevent a sequence of actions or inputs that violate the intended business rules. This can enable an attacker to manipulate normal features to achieve a malicious outcome.

Examples of Logic Flaws

E-commerce Coupon Abuse: Imagine an e-commerce site that is supposed to enforce one coupon per purchase. If a crafty user finds a way to apply multiple discount codes at checkout, that's a logic flaw. The system's workflow failed to enforce a business rule.

Banking Authorization Bypass: A banking application might assume users request transfers through the official UI. If an attacker discovers they can send a crafted request that approves a transfer without proper authorization because the backend blindly trusts a parameter, that's a business logic vulnerability.

In all these cases, the system doesn't crash or show a glaring error; everything appears "normal," except that the attacker has bypassed a crucial control.

Key Characteristics of Business Logic Flaws

They often involve abusing legitimate application functionality in an unintended order or context
These flaws are specific to an application's unique logic and workflow (so each one is often one-of-a-kind)
There may be no obvious error or malfunction; the application may even return a "successful" message, making the attack blend in with normal operations
Exploiting them usually requires understanding how the business process is supposed to work, and how it can be tricked

Because logic flaws are tied to business processes, a deep understanding of the application (and sometimes the industry or domain) is needed to identify them. A developer or user might not notice anything wrong during everyday use, and that's exactly why attackers love these flaws: they can persist undetected for years, quietly exposing data or allowing fraud without ever triggering an alarm.

Why Automated Scanners and AI Tools Miss These Flaws

Automated security scanners, whether static code analyzers, dynamic application scanners, or even the new AI-powered testing tools, excel at finding known technical vulnerabilities. They look for patterns and signatures: SQL injection payloads that return errors, cross-site scripting that echoes back `<script>` tags, missing security headers, etc.

What they don't understand is context and intent.

A scanner can tell you if input is not sanitized, but it cannot easily tell if allowing a $1.00 purchase of a $100 item is a security problem; after all, $1.00 is a perfectly valid price from the system's perspective. In short, scanners test the code behavior, not the business logic. If the code is functioning as written (even if the logic is flawed), the tool often considers it "okay."

The Scanner's Perspective

Consider a web vulnerability scanner going through an e-commerce checkout flow. It will try common attacks like SQL injection in text fields or test if it can bypass authentication by tampering cookies. But will it:

Try to apply two coupons and realize the combined discount is unintended?
Attempt to perform steps out of order, like completing a purchase without adding an item to the cart?

Unlikely. As long as the application returns 200 OK responses and doesn't expose something overtly dangerous in a single request, the scanner moves on. From the scanner's limited point of view, "no errors" means "no problem," which is exactly how logic flaws slip by.

Why Automated Tools and AI Miss Logic Flaws

Lack of Business Context: Scanners don't truly understand what the application is supposed to do. If an online form is meant to only allow past dates for scheduling (e.g., backdating an approval), a scanner won't know the difference between a past date or future date field being accepted. Only a human would notice "hey, you shouldn't be able to schedule this in the past" if that breaks a rule.

No Alarm Trigger: Many logic attacks don't produce errors or log entries. They are valid operations in the eyes of the software, just arranged maliciously. Since automated tools often look for error signatures (stack traces, abnormal responses, crashes), a well-executed logic exploit flies under the radar.

Explosive Combinatorics: Business workflows often involve multiple steps and conditional paths. Testing every conceivable combination or sequence of actions is beyond the capability of today's automated scanners. Attackers, however, might find that one specific sequence out of a million leads to a breach. Humans excel at intuition to focus on suspicious or "out-of-bound" sequences, whereas tools are typically linear and breadth-first in their approach.

Creative Manipulation: AI-based scanners can be trained on known vulnerability patterns, but they still lack true creativity. A human tester can conceive of novel attack strategies on the fly, like abusing an app's password reset function to also change someone else's email, or using a normal feature in an unintended way. These kinds of ideas don't come from a signature or training set; they come from an attacker's mindset and experience.

To put it plainly, automated scanners test for known weaknesses, while logic flaws are often unknown unknowns. In fact, one industry expert noted that logic vulnerabilities are "difficult to detect using automated vulnerability scanners," which is why they're a favorite target for bug bounty hunters and manual testers.

It's telling that many bug bounty programs (which rely on external human hackers) report lots of business logic issues, things that the company's internal scans never caught. Even advanced machine learning tools struggle here: they might churn through code and point out suspicious patterns, but they "lack deep understanding of business logic flaws" and the real-world context to flag these as problems.

Simply put, an AI might flag an anomaly, but it takes a human to recognize "this anomaly can be chained into a serious breach."

Real-World Examples of Logic Flaws and Their Impact

Business logic flaws are not just theoretical exercises; they've caused serious real-world security incidents. Let's look at a few illustrative examples across different sectors:

First American Financial (2019) - Broken Access Control

In a headline-making breach, a major financial services firm exposed 885 million sensitive documents (mortgage records, Social Security numbers, etc.) through a simple logic flaw. The company's web application assigned documents a sequential ID and did not ensure that a user requesting a document actually owned it.

This meant an attacker (or in this case, a curious real estate developer testing a hunch) could simply modify a document URL with a different ID and retrieve another customer's files. No alarms went off because to the server, each request looked like a legitimate, authenticated user asking for a document.

This is a classic example of an Insecure Direct Object Reference (IDOR), essentially, the app "trusted" user input (the document ID) without proper authorization checks. A basic vulnerability scan of the site might have found nothing critical, because there was no SQL injection or technical bug. The only issue was the missing logic to verify ownership. The impact, however, was catastrophic: a massive data leak and a lot of embarrassment and regulatory scrutiny.

Key Lesson: Multistep process validation is vital. The application must enforce that a user follows the intended flow (e.g. only see their own docs) and can't skip or circumvent steps.

E-commerce Coupon Abuse - The Double Discount

A medium-sized online retailer discovered that savvy customers were exploiting a flaw in the purchase flow to get items essentially for free. The checkout was supposed to restrict usage to one promo code at a time, but an attacker found that by sending two requests almost simultaneously, each with a different coupon code, both would be applied to the cart.

In one instance, a $200 order was reduced to $0. The system happily generated an order confirmation and processed the shipment, because from its perspective, two separate discount applications came in and no rule checked the combined effect.

Automated testing didn't catch this because it required a precise timing and sequence that wasn't in the test script. This logic flaw (a kind of race condition in business logic) led to direct financial loss for the retailer until a human penetration tester manually experimenting with the checkout identified and demonstrated it.

Tesla API Parameter Tampering (2020) - Free Upgrades

Even high-tech companies can fall victim to logic flaws. In 2020, researchers found a weakness in Tesla's online ordering process that allowed them to get premium features for a vehicle without paying.

By intercepting the web requests during the car purchase checkout, they manipulated certain parameters that indicated which add-ons (like advanced driver assistance or premium interior) were selected. The Tesla system did not properly verify that payment was made for each added feature. It assumed the front-end wouldn't allow a mismatch.

As a result, an attacker could upgrade their car's configuration and receive a higher-tier model or features, while only paying for the base model. This kind of parameter tampering is a business logic flaw: the code didn't validate the business rule that "every selected feature must have a corresponding charge."

A regular vulnerability scanner certainly wouldn't catch this, since it wasn't looking for it. The requests and responses looked perfectly normal, and only someone thinking about how the purchase process is supposed to work would notice the discrepancy. Tesla quickly fixed the issue after it was reported through their bug bounty program.

USPS Informed Delivery API (2018) - Logic Abuse for Data Access

The United States Postal Service's online API had a feature for its "Informed Delivery" service, where users could track their mail. A logic flaw in the API's authentication design allowed any authenticated USPS user to query information about any other user's account by modifying a single parameter (much like the First American case).

Essentially, the API failed to enforce that user A can only access A's data. This was not a code bug per se. The API worked and gave data as requested. It was a security design oversight.

It resulted in 60 million users' data being potentially exposed until it was discovered. The takeaway here was that logic flaws aren't limited to web pages; they lurk in APIs too, where automated scans often just check for technical issues like SQL injection and miss broken access control in logic.

The Common Theme

These examples underscore a common theme: the systems weren't broken in the traditional sense. They did exactly what they were asked to do. The problem was what they were asked to do (or not do). Each time, a human adversary (or researcher) thought of a way to use the application's own logic against itself, in a manner the designers and QA testers hadn't anticipated.

The results range from financial theft and fraud to massive data exposure. It's no wonder that business logic flaws are sometimes called "the invisible threat": invisible to automated testing, yet painfully visible when an incident occurs.

The Critical Role of Human Penetration Testers

Given the stealthy nature of logic flaws, how do we uncover them before attackers do? The answer lies in human-led penetration testing and security review. A skilled penetration tester approaches an application the way a clever intruder would: not constrained by predefined test cases, but guided by curiosity, experience, and an understanding of how systems fail.

This approach is inherently different from automated scanning. It's more akin to an art or a puzzle: figuring out how to break the rules without breaking the system.

Why Human Testers Are Invaluable

Contextual Understanding: Humans can comprehend the business context. A seasoned tester can learn how a banking app is supposed to process loans or how an order workflow should function. With that understanding, they can spot when "something doesn't add up" that a machine would overlook. (For instance, "Should a user really be able to approve a loan without a supervisor's sign-off? What if I try to forge that step?")

Creative Attack Chains: Good testers think outside the box. They will intentionally perform actions out of sequence, combine minor glitches, and generally try to "break the game rules" of an application. This creative exploration is how multi-step exploits are found. Automated tools don't get creatively curious. They follow a script. A human tester might notice a tiny odd behavior and follow that thread to unravel a major flaw.

Chaining Minor Issues into Major Exploits: It's common in penetration tests that two or three low-severity findings, when combined, lead to a critical issue. For example:

An open directory listing (low severity) might reveal a file with default passwords (medium severity)
Which allows admin access to an application where a business logic flaw then permits data exfiltration (high severity)

A scanner would report each issue separately at best and never realize they can be chained. A human tester, on the other hand, is always thinking in terms of end-to-end attack chains: "If I have A and B, can I achieve C (a bigger impact)?"

Real Verification & Exploit Proof: Manual testers don't just identify potential issues, they attempt to exploit them (in a safe, controlled manner). This means when they deliver a report, they can show "I was able to transfer $1000 from Account A to B without authorization" or "I retrieved 100 customer records I shouldn't have access to." This eliminates false positives and provides proof to developers and management. You not only learn that a vulnerability exists. You see the actual business impact if it were abused. That kind of evidence motivates fixes in a way a scanner's generic warning never will.

Adaptive and Intelligent: Unlike tools, humans can adapt their testing on the fly. If during a test something strange happens, say, an error message that hints at a hidden admin panel, a human will pivot and investigate that immediately. Automated tests might log it and move on, missing the opportunity. Humans can also incorporate new information (like documentation, developer hints, business logic diagrams) dynamically into their strategy.

The Value of Certifications

It's important to note that not all penetration testers are equal in this context. To really excel at finding logic flaws, a tester needs a certain mindset and often advanced training.

OSWE (Offensive Security Web Expert): This certification focuses on advanced web application exploitation, often involving custom vulnerabilities and logic bugs that you won't find in textbooks. An OSWE-certified tester has proven they can dissect complex web apps, understand subtle behaviors, and craft exploits for novel bugs.

OSEP (Offensive Security Experienced Penetration Tester): This signifies an expert in broader penetration techniques (including network, Active Directory, and combined attack chains). An OSEP-certified professional is trained to think holistically and exploit chained vulnerabilities in enterprise environments.

When you engage a tester with these credentials, you're bringing on someone who has been through rigorous practical exams specifically designed to weed out all but the most adept and creative security minds.

A Personal Example

From personal experience as an OSWE and OSEP, I can tell you that finding a logic flaw is often the most satisfying part of an engagement. It's like solving a tough riddle.

I recall an assessment of a fintech application that had all the latest security frameworks. Traditional vulns like XSS or SQLi were practically impossible due to excellent coding practices. Automated scans came up nearly empty. But by carefully reviewing how the transaction system was supposed to work, I noticed an odd quirk: under certain conditions, a user could initiate a fund transfer, then change an identifier in a follow-up request, causing someone else's account to be debited.

The developers never anticipated that sequence of steps; it wasn't in any use-case flow. It was a pure logic issue. That single flaw, which no automated tool caught, could have been leveraged by attackers to steal millions.

It's scenarios like this that underscore the irreplaceable value of a human tester's insight.

Active Directory Environments and Logic Flaws: A Threat Modeling Scenario

Business logic flaws aren't confined to web applications and APIs. Design flaws in system architecture can also be seen as "logic" issues. They result from the way complex systems like corporate networks or identity frameworks are intended to work (or trust each other) rather than a bug in code.

A prime example of this is in Active Directory (AD) environments in enterprises.

Active Directory is the backbone for authentication and authorization in many organizations. It wasn't originally built with today's threat landscape in mind, and over the years, clever attackers and pentesters have found ways to abuse its "logical" design trusts.

Scenario: NTLM Relay Attack Chain in an AD Environment

Imagine a company where various internal web services use Windows Integrated Authentication (NTLM) for single sign-on. It's convenient: users log into their PCs and automatically authenticate to internal sites.

Now, an automated vulnerability scanner scanning these internal sites might:

Ensure they don't allow SQL injection
Test for secure cookies
Note, as an informational finding, that "NTLM authentication is enabled"
Flag that certain servers don't have "SMB signing required"

But no single tool screams "DOMAIN WIDE COMPROMISE" from these individual factoids.

This is where human threat modeling comes in.

A penetration tester with AD expertise (say an OSEP-certified consultant) looks at this environment and thinks: "Hmm, we have several pieces in play: an internal web server that will accept NTLM logins, and another server (perhaps a misconfigured file server or printer server) that might be tricked into authenticating to us."

They recall a known technique called NTLM Relay, where an attacker can sit in the middle and forward authentication attempts from one service to another, essentially impersonating a user on a target system.

In our scenario, the tester might use a tool to provoke a privileged server (like a domain controller or a certificate authority server) to initiate an authentication to a machine the tester controls. There are even public exploits like PetitPotam that force a domain controller to do this by exploiting how certain protocols work.

Once the domain controller attempts to authenticate (using NTLM) to the tester's trap, the tester relays that authentication to the internal web service or another system that trusts NTLM, effectively logging in as the domain controller or admin user. Suddenly, the tester has high-level access on that second system.

The Chain of Design Flaws

Here's the kicker: none of what just happened is a single "vulnerability" with a CVE. It's a chain of design quirks and misconfigurations:

The web service accepts NTLM from any source and doesn't require signing or deeper verification. Design flaw / misconfiguration.
The domain controller was accessible for a certain protocol interaction (in PetitPotam's case, the AD Certificate Services via MS-EFSRPC). Not a code bug, but an enabled feature that can be misused.
The combination of these allowed an authentication to be relayed, granting unauthorized access. Logical abuse of the authentication flow.

An automated scanner might flag "SMB signing not required" or "LDAPS not enforced" as medium or low issues in a report. It might not flag them at all depending on scope. But an experienced human tester knows those are puzzle pieces for something bigger.

A Real Engagement Example

In one real engagement, a client had an old server where SMB signing was disabled (a relatively common weakness) and a service account with high privileges was logging into that server. By performing an NTLM relay attack, we were able to use that service account's credentials to impersonate it on the domain's certificate authority and obtain a valid certificate for domain admin, essentially becoming a domain administrator without ever cracking a password or exploiting a memory corruption bug.

The client was stunned because all their scanners had given the AD infrastructure a pass aside from a few "informational" warnings. This attack chain was possible only because a human thought through the threat model: "If I can get this server to talk to me, I can relay to that service and then..." It's a chess game that automated tools simply don't play.

The Lesson

The lesson here for business leaders and security teams: architecture and design flaws require the same creative analysis as application logic flaws.

Whether it's a web app that doesn't enforce a business rule or an enterprise network that implicitly trusts certain connections, you need human eyes to assess how an attacker could exploit the logic of the system.

This is where threat modeling and skilled penetration testing go hand in hand. An expert will map out how data flows, how trust is established (or assumed), and then probe those trust boundaries. In Active Directory, this might reveal issues like unconstrained delegation, weak protocol fallbacks, or trust relationships between domains that can be abused.

These are not the things a typical vulnerability scanner will enumerate with a big red flag, but they can be your worst nightmare if left unchecked.

Bridging the Gap: Integrating Human Expertise with Automation

By now, it should be clear that automated tools alone are not enough when it comes to finding the "invisible" vulnerabilities in your systems. This is not to say automation has no place. Far from it.

The Role of Automation

Automated scanners are excellent for:

Casting a wide net and catching the low-hanging fruit
Finding known issues efficiently
Testing thousands of endpoints for known CVEs or misconfigurations in a short time
Running continuously in CI/CD pipelines to catch regressions

Modern DevSecOps tooling, SAST/DAST solutions, and even AI-driven code reviewers are making it easier to fix the easy stuff early.

The Complete Picture

However, to achieve a thorough security assessment, you must augment these tools with human intelligence.

Think of scanners as your first-line sentries. They'll catch the obvious bandits at the gate. The human expert is like the detective who can uncover the insider plotting a heist using the guard's blind spots.

One without the other leaves you vulnerable:

Relying only on humans would be too slow and expensive for broad coverage
Relying only on tools leaves you with a false sense of security about the tricky attack paths lurking in your systems

Industry Recognition

The industry is increasingly recognizing this need for balance:

Bug Bounty Programs: These have thrived exactly because they bring in external human creativity to complement internal testing.

Red Team Exercises: Many organizations run red team exercises where skilled professionals emulate real attackers in a no-holds-barred test of the organization's detection and response. These often reveal logic and design weaknesses that no scanner would have found.

Layered Approach: The most security-mature companies combine automated scanning, threat modeling sessions, and regular human-led penetration tests to cover the full spectrum.

Shifting Left and Staying Vigilant

There's a trend in security to "shift left," meaning catch issues as early as possible in the development cycle (through code review, design review, etc.). This is great for many bugs, but shifting left doesn't magically eliminate logic flaws, unless you include things like threat modeling and design review in that shift.

During design and development, bringing in a security expert to ask "What if a user does X instead of Y?" or "What assumptions are we making here about user behavior?" is essentially doing a mini penetration test in the design phase. This can prevent a lot of logic issues from ever making it into the code.

The OWASP Top 10 list was updated in 2021 to include "Insecure Design" as a category, highlighting that purely preventive or "shift-left" measures must address design-level flaws, not just bugs in code. The presence of this category is a call for more threat modeling, thinking through abuse cases and logic failure modes, as a part of secure development.

That said, even with the best secure design practices, complex systems can have unforeseen interactions. So, a final human-led test (shift-right, if you will) is still needed as a fail-safe to catch anything that slipped through.

What About AI?

At this point, you might wonder: with AI getting better every day, won't AI eventually learn to catch these logic problems too?

AI will certainly help, and perhaps in the future, it will narrow the gap. It might analyze user behavior patterns or read documentation to form a basic understanding of the business context. But as of now, and for the foreseeable future, AI in security works best as an assistant, not a replacement.

It can highlight suspicious areas for a human to investigate, or handle the grunt work of scanning so humans can focus on creative testing. The creative leap and the judgment call of "is this really a problem, and can I exploit it in a meaningful way?" is something humans still do best.

One recent analysis of AI in vulnerability discovery put it well: AI can detect technical flaws, but it may miss logical vulnerabilities that only humans can understand. That is exactly our experience in the field.

Conclusion: The Case for Expert Human Testing

Business logic flaws and design weaknesses represent an invisible threat that can undermine even the most secure-looking systems. They hide between the cracks of "expected behavior," and no automated report will illuminate them with a simple vulnerability ID.

For organizations, the danger is that you don't know what you don't know, until it's too late. But there is a solution: leverage skilled human experts who specialize in thinking like attackers.

The Value Proposition

Engaging a certified, experienced penetration tester is about more than checking a compliance box. It's about:

Discovering the deep, nuanced issues that scanners and generic audits won't reveal
Having someone on your side who will assume nothing, poke at everything, and use ingenuity to strengthen your security
Finding improvements in logic and design that make your applications and networks more robust overall
Getting assurance that your critical business processes are truly secure against creative abuse

The Business Case

For business leaders, investing in human-led security testing can save countless dollars and headaches down the line. The cost of a breach, especially one leveraging a logic flaw that went unnoticed, can be devastating, from regulatory fines to lost customer trust. On the other hand, the cost of a thorough penetration test or security assessment is tiny by comparison, and it yields actionable fixes.

It's the difference between thinking you are secure and knowing you are secure.

For Security Professionals

To my fellow security professionals, the message is equally clear: nurture and advocate for that blend of automation and human expertise. Use the fancy tools, yes, but also cultivate threat modeling practices and bring in experts (internal or external) to do manual reviews.

If you're a developer or architect, engage with security consultants early. You'll be surprised how much insight a fresh set of adversarial eyes can provide on a new feature or system design. And if you find yourself dealing with AI-driven security solutions, remember their limitations; use them to augment, not replace, experienced humans.

Final Thoughts

In the end, business logic flaws don't have to remain invisible. With the right approach, you can shine a light on them before criminals do.

Certified human penetration testers, armed with knowledge, experience, and an attacker's mindset, are your flashlight. They illuminate the hidden corners of your applications and infrastructure, helping ensure that those clever "unexploitable" flaws never get a chance to harm your business.

In an era of automated everything, the human touch is not a vulnerability. It's your greatest strength in cybersecurity.

Sources

1. Chetan Conikee, "3 Takeaways from the First American Financial Breach," Dark Reading, July 26, 2019.

2. PortSwigger Web Security Academy, "Business logic vulnerabilities - Introduction and examples."

3. Astra Security - GetAstra Blog, "Automated vs Manual Penetration Testing: Which One You Need."

4. WebAsha Technologies Blog, "Can AI Be Used for Zero-Day Vulnerability Discovery? - AI vs. Human Researchers."

5. Seth Dickerson, "Exploiting AD CS: A quick look at ESC1 and ESC8," Crowe LLP Cybersecurity Watch, 2022.

6. Aman Gupta, "IDOR Attack Slips Through the Cracks: Vulnerability Scanners Miss Critical Security Flaw!" Medium.com, Aug 2020.

7. APIsec Blog, "5 Real-world Examples of Business Logic Vulnerabilities that Resulted in Data Breaches," 2021.

8. OWASP Top 10 - 2021 Edition, Category A04: Insecure Design (Discussion of design flaws and threat modeling).