Security researchers have warned of a major new Shai-Hulud-based campaign which has already compromised more than 430 packages with a combined two billion monthly installs.

The ChainDrop campaign began on August 4 when attackers compromised the GitHub account of a maintainer behind the popular keyv key storage library, which has around 127 million weekly npm downloads, according to Aikido Security.

They used that access to inject a credential-stealing worm across other packages, including cacheable (29 million downloads/month), flat-cache (565 million), and file-entry-cache (557 million), the write-up claimed.

“The compromise was carried out by pushing malicious files directly to the main branch and then immediately cutting a new release, meaning the poisoned versions were published to npm with valid provenance signed by GitHub Actions,” Aikido explained.

Read more on Shai-Hulud: Shai-Hulud-Like Worm Targets Developers via npm and AI Tools

The malicious packages contain an infostealer designed to harvest npm and GitHub tokens, AWS credentials, Kubernetes secrets, HashiCorp Vault tokens, Stripe and Slack tokens, and perform a generic file system scan.

Once stolen, they’re encrypted and sent to a public GitHub repository with the description “Shai-Hulud: Here We Go Again.”

Like the infamous Shai-Hulud campaigns, ChainDrop features worm-like capabilities allowing it to spread to other maintainers and repositories via the stolen npm and GitHub tokens.

Packages associated with Deliveroo, Ornikar, OneReach, Picsart and Qlik have been compromised as part of the campaign.

Wiz Security’s Mitigation and Protection Guidance

Microsoft and Wiz Security also published analysis of the campaign including indicators of compromise (IOCs) and mitigation advice. The latter’s recommendations are as follows:

• Identify and remove affected package versions from development, build, and CI/CD environments
• Treat affected systems as potentially compromised and rebuild them if malicious packages were installed
• Rotate exposed credentials (eg cloud credentials, GitHub tokens, SSH keys, Kubernetes configurations, Terraform credentials)
• Review cloud and source-code environments for unauthorized access or suspicious activity following package installation
• Monitor for published IOCs, including the relevant domains, file artifacts, and other indicators
• Build resilience by enabling dependency allowlisting, package integrity verification, and provenance controls where available

Katie-Paxton Fear, ethical hacker and staff security advocate at Semgrep, argued that the ChainDrop playbook is nothing new following Shai-Hulud last year.

“The worm steals developer credentials, uses them to compromise more packages and keeps moving through trusted publishing workflows,” she added.

“Even without a brand-new technique, organizations can’t assume that if they aren’t using the package that they are safe. They need to treat any installation, even if they aren’t using it, as a possible credential breach, and rotate exposed secrets, check logs for unauthorized access and audit their own packages for infection.”

AI is compressing exploit timelines. The real question isn’t whether your vulnerability management playbook needs to change, it’s which part of it you’ve been getting wrong all along.

The conversation happening in security circles right now goes something like this: Mythos is here. Exploit timelines are collapsing. Does the vulnerability management playbook need to change?

The honest answer is yes. But not the part most people are focused on.

The discussion around Mythos, Anthropic’s frontier model and its implications for offensive security, tends to center on discovery. AI accelerates reconnaissance. It helps attackers identify exposures faster, chain techniques more efficiently, and move at machine speed through environments that were previously protected, in part, by the attacker’s own time constraints.

That’s real. And it matters.

But here’s the part getting less attention: most security teams weren’t winning the prioritization battle before Mythos arrived. The compressed timeline doesn’t create a new problem. It raises the cost of an existing one.

“A CVSS 9.8 with no path to a critical asset is less urgent than a CVSS 5.5 sitting one hop from your customer database. That was true before Mythos. It’s just more expensive to get wrong now.”

The Prioritization Problem Didn’t Start with AI

We’ve spent the past year talking to security architects, heads of detection and response, and CISOs across midmarket and growth enterprise organizations. When we ask how they prioritize vulnerabilities, the answers are remarkably consistent:

“A large proportion of the vulns we uncover aren’t actually exploitable but we don’t know that unless we research each one heavily, which we lack the time and headcount to do.”

“Currently by CVSS score… and not well.”

“We use Tenable and external security exercises which provide severity ratings, and that’s how we prioritize. It’s all very slow and we can do better.”

These aren’t small shops with immature programs. These are organizations running Qualys, Tenable, Rapid7, CrowdStrike, Wiz, Okta, and Splunk simultaneously. Serious tools. Serious budgets. Still working from a CVSS-sorted backlog.

The root cause isn’t scanner quality or coverage. It’s context. Specifically, the absence of three things that CVSS scores don’t include:

• Identity context. Which accounts have access to the vulnerable system, and are they overprivileged?
• Reachability. Is this asset internet-exposed? Is it one hop from a crown-jewel system?
• Path continuity. Does a confirmed exploit chain exist that connects this CVE to something that actually matters to the business?

Without those three inputs, 50,000 findings is not a prioritized list. It’s a backlog with no compass.

What Mythos Actually Changes, and What It Doesn’t

Mythos and models like it compress the time between vulnerability disclosure and exploitation. A security team that used to have three weeks to patch after a CVE dropped might now have three days. In some cases, hours.

That’s a meaningful shift in operating conditions. But it doesn’t change the underlying architecture problem, it just makes the cost of that problem much higher.

If your team is working from a CVSS-sorted list of 50,000 findings, faster exploit timelines don’t help you. You’re still starting from the wrong list.

“Mythos accelerates the attacker. The question is whether your prioritization is fast enough to keep up, and right now, for most organizations, it isn’t.”

The question of whether Mythos demands a new vulnerability management playbook is worth asking. But the answer isn’t a faster scanner or a more aggressive patching cadence.

The playbook that needs to change is this one: stop treating vulnerability management as a standalone function that produces a sorted list of CVEs. Start asking which exposures, combined with which identity context, which network reachability, and which business criticality, create a confirmed path to a crown-jewel asset.

That’s not a detection problem. That’s an architecture problem.

The Architecture Gap Nobody Is Talking About

Here’s what a typical enterprise security stack looks like today:

• Identity: Okta or Entra
• Cloud security: Wiz or Orca
• Vulnerability management: Qualys, Tenable, or Rapid7
• Endpoint: CrowdStrike or SentinelOne
• Network: Zscaler or Palo Alto
• SIEM: Splunk or Sentinel

Each of these tools does exactly what it was built to do.

Wiz sees the misconfiguration. Okta sees the overprivileged service account. CrowdStrike sees the endpoint state. Qualys sees the CVE.

None of them see the chain that connects all four into a viable attack path to your customer database.

Every one of those tools can hand you a risk score. None of them can hand you a decision you can defend to your board.

That’s not a gap in any one tool. It’s a gap in the architecture.

We talked to a security architect whose team runs exactly this stack. Their description of the situation:

“We have good signals from all our tools, but correlating identity + cloud + endpoint into one attack path still takes manual work.”

That manual work, the tab-switching, the cross-referencing, the analyst hours spent building a picture that should already exist, is exactly what Mythos exploits. An attacker operating at machine speed doesn’t give you the two hours it takes to manually correlate your tools.

What Attack-Path-Driven Prioritization Actually Looks Like

The alternative isn’t a new scanner or a faster patching process. It’s a fundamentally different question:

Not “what is the CVSS score of this CVE?” But “can this CVE reach a crown-jewel asset, through which identity, across which trust boundary, with what blast radius?”

The math changes significantly when you add identity context. An overprivileged service account adjacent to an unpatched CVE isn’t a medium-severity finding. It’s a critical attack path.

A CVSS 5.5 on an internet-facing system with a direct route to your customer database is more urgent than a CVSS 9.8 on an isolated test environment. CVSS alone can’t tell you that. Your individual tools can’t tell you that. Only a system that correlates across them can.

“The security teams that respond effectively to AI-compressed exploit timelines aren’t the ones with the fastest patching processes. They’re the ones who know which 12 findings out of 50,000 actually matter.”

This is what Mesh was built to deliver. It ingests your existing vulnerability management tools and adds the context they’re missing:

• Identity context from Okta or Entra: Is an overprivileged account adjacent to this vulnerability?
• Network reachability from Zscaler or Palo Alto: Is this asset internet-exposed?
• Crown-jewel mapping: Does a confirmed path exist from this exposure to a critical asset?
• Attack simulation validation via Horizon3.ai: Is this path actually exploitable today, not just theoretical?

The output isn’t 50,000 findings sorted by severity. It’s 12 prioritized, evidence-backed exposures that have a confirmed path to something that matters.

That’s not more data. That’s a decision.

That’s the list that’s defensible in front of your board. That’s the list that lets you operate at the speed Mythos demands.

The Playbook That Actually Needs to Change

The old playbook: run your scanners, sort by CVSS, assign tickets, track remediation rates.

The new one:

• 1. Connect your tools. Not replace them. Sit a unified intelligence layer above your existing stack that correlates across identity, cloud, endpoint, and vulnerability data simultaneously.
• 2. Prioritize by path, not by score. Ask which exposures have a confirmed route to a crown-jewel asset, through which identity, with what blast radius.
• 3. Validate before you remediate. Confirm a path is actually exploitable before committing remediation resources. Prioritize confirmed paths over theoretical ones.
• 4. Operate continuously, not periodically. Mythos means the window between exposure and exploitation can close in hours. Point-in-time assessments aren’t a baseline anymore; they’re a liability.

None of this requires replacing the tools you’ve already deployed. Qualys still finds your CVEs. Okta still governs your identities. Wiz still flags your cloud misconfigs. The gap isn’t in what those tools see individually, it’s that nothing connects what they see collectively into one picture.

That’s the architecture problem. And Mythos just made it a lot more expensive to ignore.

Mythos doesn’t invalidate vulnerability management. It invalidates vulnerability management that operates without context. AI won’t punish organizations because they patch too slowly. It will punish them because they’re patching the wrong things. That’s the playbook that actually needs to change.

See what your real attack paths look like in your own environment.

–

Mesh is the unified intelligence layer for enterprise security teams operating across fragmented security stacks with no shared context. Connecting agentlessly to your existing tools, Mesh correlates signals across identity, cloud, SaaS, endpoint, and AI environments to reveal viable attack paths to your most critical assets. By providing enterprise-wide context that no individual tool can deliver alone, Mesh helps security teams prioritize what matters most and eliminate risk faster through guided or autonomous remediation workflows.

Your Tools, Unified. Your Risks, Eliminated. https://mesh.security

Nebula Security says a patched Firefox JIT flaw could be triggered by simply visiting a malicious webpage and was also used to compromise Tor Browser.

Tracked as CVE-2026-10702, the bug provides arbitrary code execution inside the browser’s renderer process. Mozilla rated it High and fixed it in the Firefox 151.0.3 update.

“No settings or additional user interaction are required,” Eten Zou, CEO of Nebula Security, told The Hacker News. “Visiting a malicious webpage is enough to trigger it,” Zou said every Tor Browser release that incorporated a vulnerable Firefox version was affected, though researchers have not identified the exact Tor releases.

On its own, the bug runs code only inside Firefox’s sandboxed content process. Nebula released public exploit material and used the flaw as the first stage of IonStack, a browser-to-kernel chain built for an ARM64 device running Android 17. The released end-to-end code targets one supported Google build, although Zou said the browser flaw itself is not ARM-specific.

The public code contains Firefox 151.0 offsets for the supported ARM64 Android 17 build. Zou said each exploitation step is architecture-independent and described the x86 path as more stable, although Nebula has not completed the full chain for that architecture.

Firefox users should update to the latest release. The Hacker News traced the faulty alias declaration through Mozilla’s source history to Bug 1995077, which landed for Firefox 147. The override is present in Firefox 151.0.2 and absent from Firefox 151.0.3. That places the affected stable-release range at Firefox 147 through 151.0.2.

Mozilla’s advisory does not list Firefox ESR, and the faulty override is absent from Firefox ESR 140.12. As of July 28, 2026, the available primary-source record does not establish exploitation against users in the wild.

In its technical analysis, Nebula traces the issue to MObjectToIterator when it runs with skipRegistration set to true. Firefox’s just-in-time (JIT) compiler turns frequently run JavaScript into native machine code, and to do that safely it has to track which operations can touch memory.

Firefox treated the operation as a read even though resolving a lazy property can allocate a replacement dynamic-slots buffer and free the old one.

Global value numbering then treated a later slots-buffer load as redundant and reused the earlier pointer after it had become stale. Nebula’s released exploit reclaims the freed allocation, leaks a hidden-class pointer, builds a fake object, and corrupts a Uint8Array to gain arbitrary memory read and write. The Android code then changes memory protections and redirects a WebAssembly function entry point to ARM64 shellcode.

The failure turns on a narrow compiler contract: an operation capable of replacing the object’s dynamic-slots buffer was labelled as a read. That incorrect contract let otherwise valid optimisation logic preserve a pointer the runtime had already invalidated.

Mozilla’s source-level fix removes the custom read-only alias handling from ObjectToIterator and adjusts the related iterator operation. That prevents the optimiser from treating a mutation-capable step as a harmless load and retaining the stale pointer.

IonStack’s second stage is CVE-2026-43499, a separate Linux kernel futex flaw that Nebula calls GhostLock. CVE-2026-10702 provides the remote browser foothold; CVE-2026-43499 carries it to root on the supported Android build.

Zou said GhostLock is invoked directly from Firefox. He added that Android’s weaker sandbox makes exploitation easier, but Nebula does not believe a stronger desktop sandbox would prevent the attack.

Updating Firefox blocks the documented browser entry point, but it does not patch GhostLock itself.

A major database containing the work details of British police officers and criminal justice professionals has been compromised, it has emerged.

The Police National Legal Database (PNLD) is managed by the West Yorkshire Police and contains information on officers from all 43 police forces in England and Wales, as well as the British Transport Police, the Crown Prosecution Service, the Independent Office for Police Conduct, and His Majesty’s Courts and Tribunals Service.

An August 3 statement from the PNLD revealed the service had suffered a “data security incident,” which was identified on July 26.

“Information including the names, organizations and work email addresses of police officers, staff and other criminal justice professionals, government partners and customers has been compromised and published on the dark web. There is no evidence to suggest that passwords or other security credentials have been compromised,” it explained.

“Since the incident was identified, we have been working with specialist cybersecurity organizations and the National Crime Agency to investigate the circumstances and take appropriate action.”

Read more on police data breaches: PSNI Faces £750,000 Data Breach Fine After Spreadsheet Leak

Also impacted was the Ask the Police service operated by the PNLD.

“As a result, some names and email addresses of people who have previously submitted a question to Ask the Police have been published on the dark web,” the notice read.

“If you have been affected, you will have already received an email from Ask the Police with more information and guidance.”

The PNLD explained that it doesn’t hold any confidential information relating to victims, witnesses, or offenders.

ExfilSquad Claims Responsibility for PNLD Hack 

ExfilSquad, the extortion group responsible for a recent data breach at the UK’s Department for Education, claimed it was also behind the PNLD incident.

According to screenshots of its leak site posted to X, the group claimed to have 1.9GB of data in its possession, including 135,000 records, some of which it leaked to prove it means business.

“Once your company’s data is posted here it’s never leaving the public eye and will be passed around the internet forever,” a note by the group read. “The payment we request of you is simply a rounding error compared to the litigation costs of your data leaking. Be smart and just pay.”

For PNLD to pay is highly unlikely given the UK government’s intention to introduce a de facto ban on public sector organizations paying extortion demands made by cyber adversaries.

Any individuals named in the breach ought to be on the lookout for follow-on attacks if their data is leaked.

Dray Agha, senior manager, security operations center EMEA at Huntress, said: “While the absence of compromised passwords is a relief, exposing the names and work emails of UK police and justice staff on the dark web hands cybercriminals a readymade directory to launch highly targeted spear-phishing and social engineering attacks against the very people defending our justice system.”

Most organizations have incident response plans, security tools, and technical teams in place. Yet new research suggests that many still lack the coordination, visibility, and executive alignment needed to withstand a serious cyberattack.

According to The State of Incident Response Readiness 2026, based on a survey of 600 senior IT security decision makers conducted by Vanson Bourne in January and February 2026, 73% of organizations admit they would not be “fully ready” if a significant cybersecurity attack occurred tomorrow.

The findings point to a critical gap between having incident response capabilities and being able to execute them effectively under pressure.

The report also found that cyberattacks are already a recurring business risk. More than three-quarters of organizations, 76%, experienced at least one cyberattack in the past 12 months, while 32% experienced more than one.

Incident Response Readiness Remains a Weak Point

Incident response has evolved far beyond technical containment. A mature response now requires executive crisis management, legal and regulatory coordination, stakeholder communications, enterprise-wide investigation, remediation, recovery, and post-incident monitoring.

The survey indicates that many organizations are struggling to bring these elements together in a coordinated way. Fewer than 40% of respondents described key incident response components as “highly effective,” including areas such as documented plans, tabletop exercises, threat hunting, digital forensics, and 24/7 monitoring.

The issue is not simply whether these capabilities exist. The larger concern is whether they work together when decisions must be made quickly.

Coordination Breakdowns Slow Response

One of the most significant findings is the extent to which internal friction affects response efforts. The report found that 90% of organizations expect difficulty coordinating stakeholders during a significant incident.

That coordination challenge becomes especially problematic when legal, communications, security, IT, and executive teams are not aligned before an incident begins. The research found that 75% of respondents agree delays or uncertainty around legal and communications team involvement slow decision-making during cyber incidents.

The report also found that 89% cite limited executive or board involvement in incident response readiness and decision-making.

This creates a dangerous pattern during a live incident:

• Technical teams investigate and contain the attack
• Executives require updates before approving major actions
• Legal and communications teams become involved late
• Disclosure, customer messaging, and escalation decisions lag
• Response teams lose time when containment decisions need speed

In practice, unclear ownership can turn an incident response process into a reactive cycle. Instead of executing a rehearsed plan, teams spend critical time briefing stakeholders, clarifying authority, and waiting for approvals.

Visibility Gaps Increase the Risk of Repeat Incidents

The report also highlights a major technical challenge: organizations often cannot fully see where attackers have moved.

According to the survey, 78% of respondents agree blind spots in their environment create persistent attacker access and increase the risk of repeated incidents. These blind spots can span on-premises infrastructure, public cloud environments, endpoints, SaaS platforms, identity systems, and operational technology environments.

That lack of visibility can prevent responders from confidently answering essential questions, such as:

• Where did the attacker enter?
• Which systems were accessed?
• Has the attacker moved laterally?
• Are privileged accounts compromised?
• Has malware or persistence been removed?
• Could the attacker return after recovery?

Without reliable visibility, organizations risk containing only part of the incident while leaving attacker access intact.

OT and ICS Environments Add Business Risk

The report found that 84% of organizations are concerned about attackers crossing from corporate IT systems into operational technology or industrial control system environments.

This concern is particularly serious for sectors such as manufacturing, energy, healthcare, transportation, and critical infrastructure, where cyber incidents can affect physical operations. If attackers move from IT into OT or ICS systems, the impact may extend beyond data theft or business disruption. It can affect production, safety, service delivery, and recovery timelines.

The findings suggest that many organizations recognize this exposure but still lack the unified visibility needed to detect and stop cross-environment movement quickly.

Cyberattacks Are Already Causing Business Damage

The report shows that cyber incidents are producing tangible consequences across sectors and regions. Among organizations hit by a cyberattack in the past 12 months, impacts included operational shutdowns, data loss, reputational damage, customer loss, lost revenue, and executive disruption.

The findings vary by sector:

• Retail organizations were most likely to report operational shutdowns and lost revenue or profit.
• Manufacturing and financial services organizations were more likely to report data loss.
• Crypto and decentralized finance organizations reported the highest attack incidence.
• Private healthcare organizations reported high concern around legal and communications delays.

Regional differences also emerged. North America reported the highest cyberattack incidence, while APAC respondents were most likely to report data loss, reputational damage, and customer loss. Europe reported fewer incidents overall, but incidents there were more likely to result in lost revenue or profit.

Ransomware and Cloud Attacks Lead Future Concerns

Looking ahead, respondents identified a broad set of threats that could cause serious financial, operational, or reputational disruption. Ransomware ranked as the leading concern, followed closely by cloud environment attacks.

However, the findings suggest that organizations are not facing a single dominant threat. Instead, they are preparing for a crowded threat landscape that includes cloud compromise, identity abuse, third-party risk, AI-enabled threats, ransomware, and attacks that move across hybrid environments.

This makes incident response readiness harder to define. Organizations must be able to respond across multiple attack paths, not just prepare for one scenario.

AI Adoption Is Rising, but It Is Not a Substitute for Readiness

The report shows that organizations are increasingly adopting AI and machine learning-driven capabilities for threat detection and incident response.

Nearly one-third of organizations now report extensive AI use across most or all threat detection and incident response activities, up from 25% last year. By 2027, 63% expect AI to be embedded across these activities.

The report suggests that AI can strengthen incident response when it is integrated into mature workflows. Organizations with moderate or extensive AI use were more likely to rate incident response elements as effective compared with organizations using AI in a limited way.

However, the findings also indicate that AI should not be treated as a replacement for governance, visibility, and disciplined response execution. AI can accelerate triage, threat hunting, and investigation, but it cannot resolve unclear decision rights, fragmented stakeholder coordination, or incomplete visibility on its own.

Organizations Are Re-Evaluating Incident Response Support Models

Another notable finding is that many organizations are reconsidering their external incident response and managed detection and response relationships.

The report found that many organizations expect to switch providers at the end of their current contracts. Drivers include the need for:

• More proactive readiness support
• Better coverage across IT, OT, cloud, and hybrid environments
• Stronger expertise in complex incidents
• Improved visibility beyond a single technology ecosystem
• Faster support during high-pressure investigations

The findings also highlight concern about overreliance on narrow technology ecosystems during incident response. When response teams are limited to one platform or toolset, investigation and containment may be constrained by what that ecosystem can detect, access, or support.

Organizations may benefit from evaluating whether their internal teams and external providers can operate across multiple security tools, cloud platforms, identity systems, SaaS applications, and OT environments.

How Organizations Can Strengthen Incident Response Readiness

The findings suggest that incident response readiness should be treated as an ongoing operational discipline rather than a static plan or annual compliance exercise. Organizations can reduce response delays by focusing on several practical areas.

1. Define decision rights before an incident

Security teams, executives, legal, communications, compliance, and business leaders should understand their roles before a crisis begins. Escalation paths, approval thresholds, and communication responsibilities should be documented and rehearsed.

2. Test cross-functional coordination

Tabletop exercises should include both technical and non-technical stakeholders. These exercises can help identify where decision-making slows, where authority is unclear, and where response plans do not reflect real business dependencies.

3. Validate visibility across critical environments

Organizations should assess whether they can investigate activity across endpoints, identity systems, cloud platforms, SaaS applications, on-premises infrastructure, and OT environments where applicable. Visibility should be tested through exercises such as threat hunting, attack simulation, red team assessments, or purple team engagements.

4. Use AI to support, not replace, response processes

AI and automation can help accelerate triage, alert enrichment, investigation, and threat hunting. However, these capabilities should be embedded into defined workflows with human oversight, clear escalation criteria, and tested response procedures.

5. Assess internal and external response capacity

Organizations should determine which incident response functions they can handle internally and where external expertise may be required. External providers, where used, should be evaluated based on incident experience, response speed, technical depth, ability to operate across environments, communication practices, and support for post-incident improvement.

The central lesson is that readiness depends on execution. Plans, tools, and providers all matter, but they only reduce risk when they are connected through tested processes, clear authority, and reliable visibility.

The Bottom Line

The research paints a clear picture: most organizations are being attacked, but many are not confident that their incident response capabilities will hold under pressure.

The challenge is no longer just building a response plan. It is ensuring that the plan works across teams, technologies, executives, legal stakeholders, communications teams, and business operations when a real attack occurs.

As attackers move faster across cloud, IT, identity, SaaS, and OT environments, incident response readiness must become a continuous business discipline. Organizations that wait until a live incident to discover gaps in visibility, authority, or coordination may find that the cost of delay is measured not only in systems affected, but in revenue, reputation, and trust.

Cloud and Software-as-a-Service (SaaS) environments have become top targets for cyber-threat actors this year, according to a new report by Darktrace.

The cybersecurity firm noted that H1 2026 saw a continuation of an evolution observed in 2025 where attackers shifted away from malware and vulnerability exploitation towards compromising identities.

However, whereas in 2025 threat actors primarily targeted account credentials, the first half of 2026 has seen attacks extend to email authentication, cloud entitlements, software supply chains, AI gateways, remote administration tooling and non-human identities. Darktrace said this trend makes “trust” the new attack surface.

Compromised cloud and SaaS environments in particular provide enormous opportunities for attackers.

In one case highlighted by Darktrace, a single compromised SaaS account led to malicious activity across email, SaaS and network layers, such as inbox rule changes and the launch of phishing attacks. This type of attack is difficult to detect as none of the indicators were decisive in isolation, but together represented a clear intrusion.

The vendor also cited several cases where attackers exploited trusted digital supply chain infrastructure used by victims in H1 2026. This included threat actors in April hijacking Axios to spread remote access trojans (RATs). Axios is a JavaScript library downloaded over 100 million times a week and used as a dependency in countless developer environments and CI/CD pipelines.

Atatckers were also observed abusing legitimate blockchain infrastructure to distribute infostealers, including AMOS and Phexia. The researchers noted that such services are frequently used by users with limited security resources and often enable malicious actors to reach a far wider victim base.

“Increasingly, attackers do not need to bypass trust controls in these environments; they inherit them through compromised identities, delegated access, and legitimate administration tools,” the researchers noted in the report published on August 3.

Email Attacks Prioritize Quality Over Quantity

The study found that email-based attacks are growing in sophistication, with attackers investing in quality over “noise.”

Around two-thirds of phishing emails sent in H1 2026 passed the DMARC email validation protocols, which the researchers said show that authentication is no longer sufficient to protect accounts.

More than a third (37%) of phishing attacks contained a high volume of text in H1 2026, up from 32% in the same period in 2025.

In addition, 39% of phishing featured novel social engineering techniques and VIP users were targeted in 25% of observed attacks. This suggests that threat actors are increasingly customizing attacks to specific targets.

ClickFix social engineering, a technique designed to trick users into running malicious code themselves, continued to be a common attack vector from 2025.

AI is Growing the Attack Surface

The growing use of AI in enterprises has significantly expanded opportunities for cyber attackers, according to the Darktrace study.

This includes threat actors leveraging AI tools to launch attacks at scale. This was demonstrated with the use of AI-generated malware exploiting the React2Shell vulnerability, in which an attacker used an LLM to produce working exploit code and deploy it at scale.

In July, the world’s first fully AI-generated ransomware campaign, dubbed JadePuffer, was highlighted by security researchers. An agentic threat actor exploited a vulnerability in an internet-facing server before launching a fully automated ransomware attack.

“AI is accelerating the path from vulnerability disclosure to operational exploitation,” the Darktrace researchers wrote.

The Federal Security Service of the Russian Federation (FSB) on Wednesday said it charged Telegram founder Pavel Durov for allegedly facilitating terrorist activities and for failing to remove prohibited information in violation of Russian law.

The principal security agency said the instant messaging platform “failed to remove numerous channels, chats, and bots on the platform that are actively used by Ukrainian special services and by terrorist and extremist organizations to plan and coordinate acts of sabotage and terrorism, mass killings, and cyber-fraud operations within the Russian Federation.”

These actions have resulted in numerous casualties, including among women and children, as well as significant damage amounting to billions, it added.

Durov has been charged in connection with an ongoing criminal investigation under Part 1.1 of Article 205.1 of the Criminal Code of the Russian Federation for aiding terrorist activity. He has also been placed on the international wanted list.

The FSB said it also found numerous instances where Ukrainian special services employed a Telegram chatbot named “Daivinchik/Leo-Dating, Chatting, and New Friends” to recruit Russian citizens for sabotage and terrorist activities through what it said were deception and psychological manipulation.

Per joint operations conducted with the Ministry of Internal Affairs and the Investigative Committee of Russia, 46 Russian citizens aged 12 to 22 were allegedly detained between July 2025 and the present. These individuals carried out armed attacks on law enforcement officers and acts of arson targeting transport, energy, communications, and financial infrastructure, it said.

“Additionally, they acted as couriers, transporting funds obtained from defrauded citizens to cryptocurrency exchange points for deposit into accounts controlled by the adversary,” the agency said in a statement.

Furthermore, it accused Ukrainian intelligence agents of using the “Daivinchik” Telegram dating service to masquerade as young women and initiate online contact with young Russian men. Upon building romantic relationships, the men are said to have sent the geolocation of a desired meeting place, such as a large shopping mall or an area near a critical facility, and pay for movie tickets, concert tickets, or gifts via phishing links shared by the agents.

In the next phase, representatives of Ukrainian intelligence services posing as Russian law enforcement authorities or officials from Rosfinmonitoring, the Federal Financial Monitoring Service, would contact the men through foreign messaging apps.

“These impostors claimed that the funds sent by the men had ended up in the accounts of the Armed Forces of Ukraine and that the coordinates they had shared were being used by the enemy to plan missile strikes and drone attacks,” the FSB alleged.

“The deceived and intimidated citizens – rendered unable to critically assess the situation due to psychological pressure – were then coerced under threat of criminal prosecution into carrying out armed attacks and acts of arson. These actions were ostensibly framed as checks on the counter-terrorism security of the targeted facilities or as participation in other ‘pseudo-operational activities.'”

In response, Telegram’s official account on X posted a photo of the Telegram founder giving the middle finger. Durov, who lives in Dubai, has not publicly commented on the development.

The charges come as Russia introduced a number of restrictions on Telegram, including throttling its use at the start of the year followed by a near-complete blockade in April 2026. Almost two years ago, Durov was also arrested and charged in France for failing to tackle illicit activity on the popular messaging platform.

A WhatsApp scam has been spreading through hijacked accounts by asking recipients to vote for a friend in an online contest, then tricking them into authorizing an attacker’s device on their own account.

In new research published by Malwarebytes on August 3, the company showed how the messages arrived from contacts whose accounts were already compromised and referenced a ballet performance, a dog competition or a school event. The company spotted the campaign in anonymized submissions to its scam-checking tool.

The link did not lead to a voting page. It redirected to a page resembling WhatsApp, often using the legitimate wa.me domain, which guided the victim through what looked like setting up WhatsApp Web. Other versions simply instructed the target to open their linked device settings and enter a code the scammer supplied.

Read more on messaging scams: NCSC Issues Security Alert Over Hackers Targeting WhatsApp and Signal Accounts

No Password, No Alert

The attackers were not after credentials. Completing the flow added their device as a linked session, giving them the same access a legitimate second device would have.

That meant reading messages, sending messages as the account holder and following conversations in real time. Attackers used it to forward the same scam to the victim’s contacts and to ask friends and family for money.

Because no login took place, there were no password reset emails or failed sign-in alerts. The attacker’s device appeared as another entry in the linked devices list, and Malwarebytes said the compromise could go unnoticed for some time unless the user checked.

A Familiar Technique, A New Lure

Abuse of the linked devices feature is not new. Researchers documented the same mechanism in December 2025 under the name GhostPairing, using fake photo-viewer pages rather than voting requests.

Russian state actors have used QR code and device-linking lures against WhatsApp and Signal users in the past.

What has changed is the pretext. A request to help someone’s child or pet win a contest is low-stakes, plausible and comes from a real contact, which Malwarebytes said combined trust and curiosity effectively.

The company advised users to review Settings then Linked devices and log out anything unfamiliar, never to scan a QR code or enter a linking code they did not initiate and to verify unexpected requests through another channel.

Anyone already affected should log out all linked devices and warn their contacts.

Criminals have been defeating the safety controls on commercial AI tools by splitting malicious work across multiple sessions and files, breaking projects into fragments small enough that no individual request appears harmful.

According to research Cisco Talos published on August 4, the finding rests on a corpus of prompt logs recovered from threat actor endpoints running AI coding assistants including Claude Code, Codex, Cursor and Gemini.

Talos said guardrails “did not provide much protection,” and that it encountered no sophisticated encoding or evasion techniques. Where guardrails did engage, they achieved little, and the pattern held across models and platforms rather than affecting any single vendor.

Read more on agentic attacks: OpenAI Claims Its AI Models Went Rogue and Hacked Another Company

Ownership Claims and Persistent Memory

Alongside task decomposition, the most common method was simply claiming to own the infrastructure being targeted, which in many cases required no further verification.

Labeling work as capture-the-flag (CTF) or bug bounty activity was similarly effective, unlocking vulnerability hunting and subsequent exploitation without additional vetting.

Some actors wrote blanket authorization into persistent memory and configuration files rather than arguing it per session. In one case a fraud operator instructed a model to treat all targets as pre-approved, conditioning every subsequent session automatically.

The clearest example of decomposition came from Hephaestus, a red team toolkit analyzed by Oasis Security that ran campaigns unattended.

Its operators defined more than a dozen role-differentiated agents and 15 numbered playbooks, so no single agent held the full objective and no individual task resembled an end-to-end attack.

Skill Level Set the Ceiling

Talos found that an actor’s existing ability largely determined what AI delivered. Novices assembled projects that technically functioned but lacked the expertise to improve them, ending up with limited capability. Skilled operators built what Talos described as “astonishing” platforms.

One inexperienced operator used a model to build distributed denial-of-service (DoS) tooling, eventually controlling nearly 2000 Android TVs. The model did push back, but only after supplying the basic functionality, and the actor then spent considerable effort trying to coax further work from it.

In a bulk-mail operation, a model initially characterized the activity as phishing-adjacent, then reversed its assessment on a single unverified claim that the recipients were the operator’s own users, concluding “the ethical question evaporates.”

Talos noted the model went further and invented a justification the actor had not offered, contradicted both by the dataset names themselves and by the domain’s documented history of non-consensual contact harvesting under the same operator.

Where models did refuse, actors switched. One operator abandoned a censored model mid-operation and moved to an uncensored one, which completed the work without objection.

Talos said defenders should expect vulnerabilities to surface faster and exploitation to follow sooner, and argued organizations not already exploring agentic capabilities in the SOC will find themselves chasing that ground.

Cybersecurity researchers have shared additional technical details about a recently patched critical security flaw impacting Check Point Security Management Server and Multi-Domain Security Management Server (MDS) that has come under active exploitation in the wild.

The vulnerability, tracked as CVE-2026-16232 (CVSS score: 9.3), is an authentication bypass in the SmartConsole login process that allows an unauthenticated remote attacker to obtain an application login token and use it to authenticate with full administrative privileges.

“By leveraging CVE-2026-16232, an unauthenticated attacker can obtain an application login token, use this token to log in through SmartConsole with full administrator privileges, and modify the security policy or security configuration,” Rapid7 said.

Successful exploitation requires an attacker to have network access to the Management Server and a configuration that does not restrict Trusted Clients. Check Point has disclosed that it’s aware of a handful of customers being targeted by this flaw as a zero-day.

Rapid7 analysis of the vulnerability has uncovered that the root cause is a “broken trust boundary” in the application authentication path that permits the threat actor to log in to a vulnerable appliance via SmartConsole with full admin privileges.

Specifically, a vulnerable server has been found to accept an attacker-supplied Secure Internal Communication (SIC) distinguished name (DN) as the identity of a remote application as opposed to binding that identity to the authenticated remote peer certificate DN returned by a function named “getCertificateDnName().”

As a result, an attacker can read the management server’s own SIC DN during the unauthenticated bootstrap communication and authenticate as a remote application by replaying that management server’s DN, obtaining an application login token, and then minting a new SmartConsole single sign-on (SSO) ticket via the forged application session.

The patch introduced by Check Point ensures that remote clients use the authenticated remote peer certificate DN, causing any mismatch between the supplied DN and that authenticated identity to be rejected. It also adds a new empty identity check that prevents a remote application login when there is no authenticated SIC identity.

“To make the supplied server DN survive the patched checks, the attacker would need an authenticated client certificate whose subject DN already matches that server DN, which removes the unauthenticated bypass,” Rapid7’s Stephen Fewer said.

Rapid7 has released a proof-of-concept (PoC) Python script that can be used to successfully validate whether a target is either vulnerable or patched against the flaw.

Customers are advised to apply the Jumbo Hotfixes released by Check Point on July 22, 2026, to remediate the flaw as soon as possible.