Join Amy and Pierre Cadieux as they unpack the ransomware and vulnerability trends that defined 2025. From the persistent ransomware threats targeting the manufacturing sector to the rise of stealthy living-off-the-land tactics, we break down what these shifts mean for your defense strategy.
Why are attackers are increasingly targeting your management infrastructure? How do you spot the difference between a system admin and a threat actor? Tune in to hear Talos’ insights on how to move beyond reacting to threats and start building a more resilient, proactive security posture for the year ahead.
Speed and age shouldn’t be allowed to pair up, but that is the theme of the Talos 2025 Year in Review vulnerability findings.
Figure 1. React/React2Shell (2025) at the top, with PHPUnit (2017) and Log4j (2021) following up.
The year was characterized by an unending beat-down on infrastructure that relied on older enmeshed dependencies (e.g., Log4j and PHPUnit), while React2Shell rocketed to the highest percentage of attacks for the entire year within the last three weeks of 2025. Agentic AI’s capacity for building and deploying new proofs-of-concepts and exploit kits lowered attacker time-to-exploit, and the landscape shifted for defenders.
“The speed at which these CVEs climbed into the top tier reflects a larger systemic challenge: Newly disclosed vulnerabilities in widely deployed software can generate significant, organization-wide impact long before typical patch cycles catch up, leaving defenders with small reaction windows and escalating consequences for even short-lived exposure.” – 2025 Talos Year in Review
Top-targeted infrastructure
Outdated infrastructure continues to expand the attack surface. Components like PHPUnit, ColdFusion, and Log4j are often embedded within applications, tightly coupled to legacy applications. Technologies age quickly, and companies are under pressure to adopt first, ask questions later. Low-use systems in a network can fossilize, unnoticed and unpatched. Others become mainstays that often cannot be swapped out or even patched without destabilizing an organization.
Attackers prioritized software and firmware inside network appliances, identity-adjacent systems, and widely deployed open-source components:
Remote code execution (RCE) flaws, which enable access without requiring user interaction, avoiding a need for social engineering
Legacy systems and widely used components
Perimeter devices, especially without endpoint detection and response (EDR)
Figure 2. Top 50 network infrastructure CVEs.
The theme was identity, identity, identity. Controlling identity meant controlling access, so attackers focused on components that authenticate users, enforce access decisions, and broker trust between systems. A small number of vulnerabilities targeting these vectors drove outsized risk. This can invalidate multi-factor authentication (MFA) checks and bypass segmentation.
Defender recommendations
Attacker prioritization is now guided less by vulnerability age or maturity and more by exposure, exploitability, and proximity to trust, reshaping how organizations must think about risk in modern environments.
Attackers exploit patching gaps and policy weaknesses in vendor lifecycles. Organizations should evaluate their identity-centric network components and management platforms and prioritize patching of network devices accordingly.
For a more in-depth analysis of these trends, as well as how company size impacted CVE targeting trends, why the management plane matters, and the shortening window defenders have for putting defenses in place, see the 2025 Year in Reviewreport.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 11:06:422026-04-07 11:06:42Year in Review: Vulnerabilities old and new and something React2
Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved.
During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity.
Platform abuse, social engineering, and SaaS notification hijacking
Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos’ analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering.
The PaaP model
The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform’s own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a “seal of approval” that few security gateways are configured to challenge.
Anatomy of GitHub campaign: Abusing automated notification pipelines
The GitHub vector is a pure “notification pipeline” abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.
Figure 1: Email headerFigure 2: The body of the message
By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page.
Figure 3: List-Unsubscribe link
The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.
Figure 4: Raw headers
The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the “invoice” lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set.
Abusing workflow and invitation logic (Jira)
The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a “pipeline” of activity, but an abuse of the collaborative invitation feature.
Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious.
In this example, the attacker sets the “Project Name” to “Argenta.” When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees “Argenta” as the sender or the subject, which the platform has verified as the project name.
Figure 5: Email header
The attacker placed their malicious lure subject into the “Welcome Message” or “Project Description” field. They use the “Invite Customers” feature and input the victim’s email address. Atlassian’s backend then generates the email. Because the system is designed to be a “Service Desk,” the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.
Figure 6: The body of the message and the footer branding
Strategic implications
The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform’s own reputation to launder their malicious content.
How do we fundamentally change the trust model?
Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.
Identity andinstance-levelverification: We must move from “global domain trust” to “instance-level authorization.” Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization’s internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action.
Upstream API-levelmonitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform “precursor activities” within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a “Project Creation” event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack.
Semanticintent andbehavioralprofiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional “Communication Baseline.” GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect “semantic discontinuity,” when the content of a notification (e.g., urgent financial billing) is incongruent with the platform’s primary utility. Any notification that deviates from the expected functional profile should trigger an automated “Suspicious” banner or be routed for manual review, regardless of its technical validity.
Mitigatingcognitiveautomationfatigue: PaaP attacks exploit “automation fatigue,” where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the “reflexive trust” that attackers rely on. This ensures that the platform’s “seal of approval” is validated by a deliberate human action.
Automatedtakedownorchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable.
By adopting this framework, the security posture evolves from “Is this email authenticated?” to “Is this platform activity authorized and consistent with our business logic?” This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline.
Acknowledgements
Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors.
Indicators of compromise (IOCs)
IOCs for this threat can be found on our GitHub repository here.
For years, macOS environments carried an aura of relative safety. Not immunity, but lower priority in the threat landscape. That perception has aged about as well as an unpatched server.
The reality in 2026 is very different. Apple devices now make up a significant share of corporate endpoints. And they sit in the hands of the people attackers most want to reach. Engineers, product leads, finance teams, and the C-suite are disproportionately Mac users. They have access to source code repositories, financial systems, privileged cloud credentials, and sensitive business data.
Key Takeaways
macOS is no longer a low-risk environment. Engineering, product, and executive teams are disproportionately Mac users with privileged access, making them high-value targets.
A single compromised Mac can be an enterprise-wide breach entry point. Stolen session tokens, Keychain credentials, and SaaS cookies harvested from one device can grant attackers persistent access to cloud environments and internal systems without triggering authentication alerts.
The ClickFix technique has evolved. Attackers now mimic and abuse legitimate AI platforms like Claude Code and Grok, exploiting the trust employees place in these tools to bypass traditional security controls entirely.
Automated sandboxes miss macOS threats by design. Without interactive analysis, the execution paths are never triggered, and the threat goes undetected.
ANY.RUN’s macOS sandbox closes a years-long visibility gap. Security teams can now investigate Apple-targeted threats inside the same unified workflow used for Windows, Linux, and Android — eliminating the context-switching and tooling fragmentation that slows incident response.
Why macOS Threat Analysis Now Belongs in Your Security Stack
Static or automated scanners often miss the full picture because many macOS threats stay dormant until a user enters a password, approves a dialog, or interacts with the system. This creates dangerous visibility gaps, longer dwell times, and slower incident response in mixed Windows/macOS environments.
Interactive sandbox analysis lets security teams safely detonate suspicious files or URLs, observe real-time behavior, and simulate genuine user actions, revealing hidden intent, data exfiltration paths, and attacker capabilities that would otherwise remain invisible.
Moonlock’s Mac Security Survey 2025 found that 66% of Mac users have encountered at least one cyber threat within the past year.
Over 80 countries affected by major Mac stealer malware campaigns.
A 67% increase in registered macOS backdoor variants in 2025.
The Use Case: A macOS ClickFix Campaign Targeting AI Users
ANY.RUN recently uncovered a sophisticated macOS-specific ClickFix campaign aimed squarely at users of popular AI development tools — including Claude Code, Grok, n8n, NotebookLM, Gemini CLI, OpenClaw, and Cursor.
Multi-OS attack: malicious terminal commands for various platforms
Attackers bought Google ads that redirected victims to convincing fake documentation pages mimicking legitimate AI platforms (Claude Code in this case). Once there, a ClickFix-style social engineering prompt tricked users into running a terminal command.
macOS terminal command downloading the malicious script
This downloaded an obfuscated script that installed the AMOS Stealer malware.
ZIP archive containing the stolen data
AMOS escalated to root privileges, swept browser credentials and session cookies from Chrome, Safari, and Firefox, emptied cryptocurrency wallet applications, harvested saved passwords from the macOS Keychain, collected files from the Desktop, Documents, and Downloads folders, and installed a persistent backdoor that restarted itself within seconds if terminated.
Backdoor C2 registration request
This backdoor upgraded from basic command polling to a fully interactive reverse shell over WebSocket with PTY support, giving attackers real-time, hands-on control of the compromised Mac.
To validate your detection coverage, research the campaign’s IOCs collected in our X post and subscribe to ANY.RUN via X.
Why This Attack Works
This campaign represents a fundamental shift in how risk reaches organizations. The delivery mechanism was not a phishing email or a malicious attachment — two threat vectors that corporate security infrastructure is built to intercept. It was a search engine result, a paid advertisement, and a trusted AI interface. Employees were not behaving carelessly; they were using the same research tools they use every day to get work done.
AI workflows normalize experimentation: users expect to copy commands, test tools, and troubleshoot issues. The attack blends into that behavior.
macOS users often operate with elevated trust: there is still a lingering perception that macOS is less targeted, which lowers suspicion.
Security tools are not built for “user-driven execution”: when a user intentionally runs a command, many controls interpret it as legitimate activity.
In short, the attack doesn’t break the rules. It borrows them.
Close the macOS visibility gap before it becomes a breach Equip your SOC with deeper multi-platform threat analysis
This type of campaign doesn’t rely on technical failure, but on human-process alignment:
Compromise without exploitation: traditional vulnerability management offers no protection here. The attack path is behavioral.
High-value users are directly exposed: the targets of AI tools are often the same people with access to sensitive systems and data.
Detection timelines increase: without clear malicious signatures, identifying the attack depends on recognizing suspicious behavior patterns.
Incident scope can expand quickly: once access is established, attackers can pivot into internal systems, especially in loosely governed tool environments.
Traditional security tools largely failed to detect this campaign because the initial payload (a shell command pasted from a legitimate website) produced no files, no installer, and no warning dialogs. Understanding and blocking the full attack chain required behavioral analysis in an environment that could replicate what a real macOS user would experience. That is precisely what interactive sandbox analysis provides.
ANY.RUN Now Covers the Full Enterprise Attack Surface
Recognizing that modern enterprises are not single-OS environments, ANY.RUN has extended its Interactive Sandbox to include macOS virtual machines, now available in beta for Enterprise Suite customers. This brings the platform to four major operating systems (Windows, Linux, Android, and macOS) within a single unified investigation workflow.
When a macOS-specific file surfaces alongside Windows samples in a phishing campaign, analysts no longer need to switch context, stand up separate infrastructure, or route the sample to a different team. Cross-platform campaigns can be investigated as a whole.
Interactive analysis catches what automated tools miss. A critical characteristic of many macOS threats, including the AMOS campaign described above, is that they are designed not to trigger until a user takes a specific action.
ANY.RUN‘s interactive environment allows analysts to replicate genuine user actions during live sandbox execution. The result is that deceptive authentication dialogs, staged execution chains, and social engineering lures become visible and documentable, rather than hidden behind an execution condition the sandbox never triggered.
In one documented analysis of the Miolab Stealer, a macOS-targeting infostealer, the sandbox surfaced the malware’s fake authentication prompt, the AppleScript routine used to collect files from user directories, and the outbound data transfer via a curl POST request, providing a complete behavioral picture of the attack chain in minutes.
The practical impact of adding macOS to the sandbox workflow is measurable at multiple levels:
Security teams can now validate suspicious files and URLs targeting Mac endpoints within minutes using behavioral analysis, rather than escalating to manual investigation or accepting the risk of unconfirmed alerts. The reduction in triage time directly compresses Mean Time to Detect and Mean Time to Respond: both metrics that translate directly into breach risk and regulatory exposure.
For organizations where macOS represents a significant portion of the device fleet this closes a visibility gap that has existed for years. Attackers have been aware of and exploiting that gap. The tools to close it now exist.
For MSSPs managing diverse client environments, the ability to investigate macOS threats within the same platform used for Windows and Linux analysis means consistent SLAs, fewer escalation paths, and the capacity to handle cross-platform incidents without specialized personnel for each OS.
Expand your SOC’s cross-platform threat visibility Speed up triage and response across 4 major OS
The campaign that weaponized AI platforms to deliver credential-stealing malware to macOS users is a clear indicator of where threat actors are investing their development effort. AI services trust, search engine visibility, and macOS endpoints are converging into a high-value attack surface: one that is actively being exploited against enterprises today.
ANY.RUN’s expansion of its Interactive Sandbox to macOS gives security leaders a direct answer to a question that has grown more urgent with every major Apple-targeted campaign: when a threat targets our Mac users, can we actually see what it does? That answer is now yes.
The capability is available in beta for Enterprise Suite customers. For organizations running mixed-OS environments — which today means nearly every enterprise — it represents a concrete step toward closing the gap between the threats targeting their users and the tools available to analyze them.
About ANY.RUN
ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams investigate threats faster and with greater clarity across modern enterprise environments.
It allows teams to safely execute suspicious files and URLs, observe real behavior in an Interactive Sandbox, enrich indicators with immediate context through TI Lookup, and monitor emerging malicious infrastructure using Threat Intelligence Feeds. Together, these capabilities help reduce investigation uncertainty, accelerate triage, and limit unnecessary escalations across the SOC.
ANY.RUN is trusted by thousands of organizations worldwide and meets enterprise security and compliance expectations. It is SOC 2 Type II certified, demonstrating its commitment to protecting customer data and maintaining strong security controls.
FAQ
Is macOS really at risk in enterprise environments, or is this overstated?
The volume and sophistication of macOS-targeted malware has grown substantially since 2023. Campaigns like the one described in this article are not isolated incidents; they reflect a sustained, commercially organized effort targeting Apple endpoints.
Why couldn’t existing security tools detect the AI-abusing ClickFix campaign?
Because the initial infection vector produced nothing that traditional tools are built to flag. Signature-based detection and perimeter controls had nothing to intercept. Only behavioral analysis, observing what happens after that command executes, can surface the full attack chain.
What is the difference between interactive and automated sandbox analysis for macOS threats?
An automated sandbox executes a sample and records what it does without any user interaction. Many macOS threats are specifically engineered to detect this: they stay dormant, exit cleanly, or display nothing until a user takes a specific action — entering a password, clicking a dialog, or running a terminal command. Interactive analysis allows an analyst to replicate those real user actions inside the sandbox, triggering conditional execution paths that automated tools never reach.
What should organizations do immediately to reduce exposure to this type of attack?
Three steps deliver the most immediate risk reduction. First, ensure your SOC has the capability to analyze macOS-specific samples behaviorally — not just flag them as unreviewed. Second, implement user education specifically around AI platform trust: employees need to understand that content appearing on ChatGPT or Grok is not inherently safe, and that no legitimate service will ask them to paste commands into Terminal. Third, treat macOS endpoints with the same endpoint detection, logging, and incident response coverage you apply to Windows systems. Coverage parity is the baseline.
Is ANY.RUN’s macOS sandbox available to all customers?
The macOS virtual machine environment is currently available in beta for Enterprise Suite users. Organizations interested in evaluating macOS threat analysis capabilities as part of their existing or planned ANY.RUN deployment should contact the ANY.RUN team directly to discuss access and roadmap.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-07 11:06:402026-04-07 11:06:40ClickFix Meets AI: A Multi-Platform Attack Targeting macOS in the Wild
In the span of just a few weeks, we have observed a dizzying array of major supply chain attacks. Prominent examples include the malicious modification of Axios, a popular HTTP client library for JavaScript, as well as cascading compromises from TeamPCP, a “chaos-as-a-service” group that injected malicious code into hijacked GitHub repositories for open-source projects, including Trivy, an open-source security scanner.
The impact of these supply chain attacks can be vast. Axios receives 100 million downloads weekly and innumerable organizations rely on the frameworks and libraries compromised by TeamPCP. The headache they pose to organizations and their security personnel is considerable as well; affected utilities can be integrated so deeply that it may be difficult to fully catalog, let alone remediate.
Although the timing, scale, and severity of these attacks can be shocking, this is not a new phenomenon. The supply chain has remained an attractive target for some time because of its fragility and the fact that a successful compromise can lead to countless additional downstream victims.
Findings from the recently published Talos 2025 Year in Review illustrate these long-standing trends. Nearly 25% of the top 100 targeted vulnerabilities we observed in 2025 affect widely used frameworks and libraries. Digging deeper into the list reveals additional insights. The React2Shell vulnerability affecting React Server Components became the top-targeted vulnerability of 2025 despite being disclosed in December, reflecting the speed at which these supply chain attacks can reach massive scale. The presence of Log4j vulnerabilities shows how deeply embedded these utilities can be and therefore how difficult it can be to reduce the attack surface. Although these particular examples represent extant vulnerabilities that can be weaponized by numerous adversaries versus a deliberate attack carried out by a single adversary, they show how impactful and disruptive threats to the supply chain can be. Follow-on attacks can range from ransomware to espionage, which is reflective of the broad swath of adversaries that carry them out — from sophisticated state-sponsored groups to teenage cyber criminals.
If we are all building on such shaky foundation, what can we do to keep safe? After all, it certainly seems dire when a tool such as Trivy that we could normally use to scan for supply chain vulnerabilities becomes compromised itself. But there are concrete steps we can take to improve our security posture.
As highlighted in the Year in Review, protecting identity is key. This includes securing CI/CD pipelines to prevent these types of compromises from occurring in the first place, as well as limiting the impact and lateral movement of an adversary should they obtain access to a downstream victim.
In addition, organizations must try to the best of their abilities to inventory the software libraries and frameworks they employ, stay informed of security incidents, and respond rapidly to implement patching and other mitigations.
Just as supply chain attacks are evergreen, so too is the efficacy of security fundamentals, such as segmentation, robust logging, multi-factor authentication (MFA), and the implementation of emergency response plans.
As trust continues to break down, the only viable solution may be to double down on vigilance. Since this recent spate of attacks represents a trend that will likely only grow in intensity and breadth, the time for action and planning is now.
Coverage
Below, find a sample of the some of the recent coverage we offer to protect against these threats:
ClamAV: Txt.Trojan.TeamPCP-10059839-0
Txt.Trojan.TeamPCP-10059839-0
Behavioral Protections: LiteLLM Supply Chain Compromise – alerts during installation of compromised packages
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-03 19:06:402026-04-03 19:06:40Do not get high(jacked) off your own supply (chain)
Cisco Talos is actively investigating the March 31, 2026 supply chain attack on the official Axios node package manager (npm) package during which two malicious versions (v1.14.1 and v0.30.4) were deployed. Axios is one of the more popular JavaScript libraries with as many as 100 million downloads per week.
Axios is a widely-deployed HTTP client library for JavaScript that simplifies HTTP requests, specifically for REST endpoints. The malicious packages were only available for approximately three hours, but if downloaded Talos strongly encourages that all deployments should be rolled back to previous known safe versions (v1.14.0 or v0.30.3). Additionally, Talos strongly recommends users and administrators investigate any systems that downloaded the malicious package for follow-on payloads from actor-controlled infrastructure.
Details of supply chain attack
The primary modification of the packages introduced a fake runtime dependency (plain-crypto-js) that executes via post-install without any user interaction required. Upon execution, the dependency reaches out to actor-controlled infrastructure (142[.]11[.]206[.]73) with operating system information to deliver a platform-specific payload to Linux, MacOS, or Windows.
On MacOS, a binary, “com.apple.act.mond”, is downloaded and run using zsh. Windows is delivered a ps1 file, which copies the legitimate powershell executable to “%PROGRAM DATA%wt.exe”, and executes the downloaded ps1 file with hidden and execution policy bypass flags. On Linux, a Python backdoor is downloaded and executed. The payload is a remote access trojan (RAT) with typical associated capabilities allowing the actor to gather information and run additional payloads.
Impact
As with most supply chain attacks, the full impact will likely take some time to uncover. The threat actors exfiltrated credentials along with remote management capabilities. Therefore, Talos strongly recommends organizations treat any credentials present on their systems with the malicious package as compromised and begin the process of rotating them as quickly as possible. Actors are likely to try to weaponize access as quickly as possible to maximize financial gain.
Supply chain attacks tend to have unexpected downstream impacts, as these packages are widely used across a variety of applications, and the compromised credentials can be leveraged in follow-on attacks. For additional context, about 25% of the top 100 vulnerabilities in the Cisco Talos 2025 Year in Review affect widely used frameworks and libraries, highlighting the risk of supply chain-style attacks.
Talos will continue to monitor any follow-on impacts from this supply chain attack in the days and weeks ahead, as well as any additional indicators that are uncovered as a result of our ongoing investigation.
As we already talked in a previous post, modern software development is practically unthinkable without the use of open-source components. But in recent years the associated risks have become increasingly diverse, complex, and numerous. When, first, vulnerabilities affect a company’s infrastructure and code faster than they’re remediated; second, data is unreliable and incomplete; and third, malware may be lurking within popular components, it’s not enough to simply scan version numbers and toss fix-it tickets at the IT team. Vulnerability management must be expanded to cover software download policies, guardrails for AI assistants, and the entire software build pipeline.
A trusted pool of open-source components
The main part of the solution is to prevent the use of vulnerable and malicious code. The following measures should be implemented:
Having an internal repository of artifacts. The sole source of components for internal development needs to be a unified repository to which components are admitted only after a series of checks.
Performing rigorous component screening. These include checks of: known versions of the component, known vulnerable and malicious versions, publication date, activity history, and the reputation of the package and its authors. Scanning the entire contents of the package, including build instructions, test cases, and other auxiliary data, is mandatory. To filter the registry during ingestion, use specialized open-source scanners or a comprehensive cloud workload security solution.
Running dependency pinning. Build processes, AI tools, and developers mustn’t use templates (such as “latest”) when specifying versions. Project builds need to be based on verified versions. At the same time, pinned dependencies must be regularly updated to the latest verified versions that maintain compatibility and are free of known vulnerabilities. This significantly reduces the risk of supply chain attacks through the compromise of a known package.
Improving vulnerability data
To identify vulnerabilities more effectively and prioritize them properly, an organization needs to establish several IT and security processes:
Vulnerability data enrichment. Depending on the organization’s needs, this is needed either to enrich information by combining data from NVD, EUVD, BDU, GitHub Advisory Database, and osv.dev, or to purchase a commercial vulnerability intelligence feed where the data is already aggregated and enriched. In either case, it’s worth additionally monitoring threat intelligence feeds to track real-world exploitation trends and gain an insight into the profile of attackers targeting specific vulnerabilities. Kaspersky provides a specialized data feed specifically focused on open-source components.
In-depth software composition analysis. Specialized software composition analysis (SCA) tools allow for the correct navigation of the dependency chain in open-source code to fully inventory the libraries being used, and discover outdated or unsupported components. Data on healthy components also comes in handy to enrich the artifact registry.
Identifying abandonware. Even if a component isn’t formally vulnerable and hasn’t been officially declared unsupported, the scanning process should flag components that haven’t received updates for more than a year. These warrant separate analysis and potential replacement, much like EOL components.
Securing AI code and AI agents
The activities of AI systems used in coding must be wrapped in a comprehensive set of security measures — from input data filtering to user training:
Restrictions on dependency recommendations. Configure the development environment to make sure that AI agents and assistants can only reference components and libraries from the trusted artifact registry. If these don’t contain the right tools, the model should trigger a request to include the dependency in the registry, rather than pulling something from PyPI that simply matches the description.
Filter model outputs. Despite these restrictions, anything generated by the model must also be verified to ensure the AI code doesn’t contain outdated, unsupported, vulnerable, or made-up dependencies. This check should be integrated directly into the code acceptance process or the build preparation stage. It doesn’t replace the traditional static analysis process: SAST tools must still be embedded in the CI/CD pipeline.
Developer training. IT and security teams must be intimately familiar with the characteristics of AI systems, their operating principles, and common errors. To achieve this, employees should complete a specialized training course tailored to their specific roles.
Systematic removal of EOL components
If a company’s systems utilize outdated open-source components, a systematic, consistent approach to addressing their vulnerabilities should be taken. There are three primary methods for doing this:
Migration. This is the most organizationally complex and expensive method, involving the total replacement of a component followed by the adaptation, rewriting, or replacement of the applications built upon it. Deciding on a migration is especially daunting when it demands a massive overhaul of all internal code. This frequently affects core components — it’s impossible to migrate away from Node.js 14 or Python 2 easily.
Long-term support (LTS). A dedicated support-services market exists for large-scale legacy projects. Sometimes this involves a fork of the legacy system maintained by third-party developers; in other cases, specialized teams backport patches that fix specific vulnerabilities into older, unsupported versions. Transitioning to LTS generally requires ongoing support costs, but this can still be more cost-effective than a full migration in many cases.
Security, IT, and business must work together to choose one of these three paths for every documented EOL or abandoned component, and reflect the made choice in the company’s asset registries and SBOMs.
Risk-based open-source vulnerability management
All of the measures listed above reduce the volume of vulnerable software and components entering the organization, and simplify the detection and remediation of flaws. Despite this, it’s impossible to eliminate every single defect: the number of applications and components is simply growing too fast.
Therefore, prioritizing vulnerabilities based on real-world risk remains essential. The risk assessment model must be expanded to account for the characteristics of open source, answering the following questions:
Is the vulnerable code branch actually executed in the organization’s environment? A reachability analysis for discovered vulnerabilities should be performed. Many defective code snippets are never actually run within the organization’s specific implementation, making the vulnerability impossible to exploit. Certain SCA solutions can perform this analysis. This same process permits evaluating an alternative scenario: what happens if the vulnerable procedures or components are removed from the project entirely? Sometimes, this method of remediation proves to be surprisingly painless.
Is the defect being exploited in real-world attacks? Is a PoC available? The answers to these questions are part of standard prioritization frameworks like EPSS, but tracking must be conducted across a much broader set of intelligence sources.
Has cybercriminal activity been reported in this dependency registry, or in related and similar components? These are additional factors for prioritization.
Considering these factors allows the team to allocate resources effectively and remediate the most dangerous defects first.
Transparency is the new black
The security bar for open-source software is only going to keep on rising. Companies developing applications — even for internal use — will face regulatory pressures demanding documented and verifiable cybersecurity within their systems. According to the estimates of Sonatype experts, 90% of companies globally already fall under one or more requirements to provide evidence of the reliability of the software they use; therefore, the experts deem transparency “the currency of software supply chain security”.
By controlling the use of open-source components and applications, enriching threat intelligence, and strictly monitoring AI-driven development systems, organizations can introduce the innovations the business craves — all while clearing the high bar set by regulators and customers alike.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-03 17:06:362026-04-03 17:06:36Managing open-source vulnerabilities | Kaspersky official blog
It used to be that only specialized software houses and tech giants had to lose sleep over open-source vulnerabilities and supply chain attacks. But times have changed. Today, even small businesses are running their own development shops, making the problem relevant for everyone. Every second company’s internal IT teams are busy writing code, configuring integrations, and automating workflows — even if its core business has absolutely nothing to do with software. It’s what modern business efficiency demands. However, the byproduct of that is a new breed of software vulnerabilities — the kind that are far more complicated to fix than just installing the latest Windows update.
Modern software development is inseparable from open-source components. However, the associated risks have proliferated in recent years, increasing in both variety and sophistication. We’re seeing malicious code injected into popular repositories, fragmented and flawed vulnerability data, systematic use of outdated, vulnerable components, and increasingly complex dependency chains.
The open-source vulnerability data shortage
Even if your organization has a rock-solid vulnerability management process for third-party commercial software, you’ll find that open-source code requires a complete overhaul of that process. The most widely used public databases are often incomplete, inaccurate, or just plain slow to get updates when it comes to open source. This turns vulnerability prioritization into a guessing game. No amount of automation can help you if your baseline data is full of holes.
According to data from Sonatype, about 65% of open-source vulnerabilities assigned a CVE ID lack a severity score (CVSS) in the NVD — the most widely used vulnerability knowledge base. Of those unscored vulnerabilities, nearly 46% would actually be classified as High if properly analyzed.
Even when a CVSS score is available, different sources only agree on the severity about 55% of the time. One database might flag a vulnerability as Critical, while another assigns a Medium score to it. More detailed metadata like affected package versions is often riddled with errors and inconsistencies too. Your vulnerability scanners that compare software versions end up crying wolf with false positives, or falsely giving you a clean bill of health.
The deficit in vulnerability data is growing, and the reporting process is slowing down. Over the past five years, the total number of CVEs has doubled, but the number of CVEs lacking a severity score has exploded by a factor of 37. According to Tenable, by 2025, public proof-of-concept (PoC) exploit code was typically available within a week of a vulnerability’s discovery, but getting that same vulnerability listed in the NVD took an average of 15 days. Enrichment processes, such as assigning a CVSS score, are even slower — Sonatype in the same study estimates that the median time to assign a CVSS score is 41 days, with some defects remaining unrated for up to a year.
The legacy open-source code problem
Libraries, applications, and services that are no longer maintained — either being abandoned or having long reached their official end of life (EOL) — can be found in 5 to 15% of corporate projects, according to HeroDevs. Across five popular open-source code registries, there are at least 81 000 packages that contain known vulnerabilities but belong to outdated, unsupported versions. These packages will never see official patches. This “legacy baggage” accounts for about 10% of packages in Maven Central and PyPI, and a staggering 25% in npm.
Using this kind of open-source code breaks the standard patch management lifecycle: you can’t update, automatically or manually, a dependency that is no longer supported. Furthermore, when EOL versions are omitted from official vulnerability bulletins, security scanners may categorize them as “not affected” by a defect and ignore them.
A prime example of this is Log4Shell, the critical (CVSS 10) vulnerability in the popular Log4j library discovered back in 2021. The vulnerable version accounted for 40 million out of 300 million Log4j downloads in 2025. Keep in mind that we’re talking about one of the most infamous and widely reported vulnerabilities in history — one that was actively exploited, patched by the developer, and addressed in every major downstream product. The situation for less publicized defects is significantly worse.
Compounding this issue is the visibility gap. Many organizations lack the tools necessary to map out a complete dependency tree or gain full visibility into the specific packages and versions embedded within their software stack. As a result, these outdated components often remain invisible, never even making it into the remediation queue.
Malware in open-source registries
Attacks involving infected or inherently malicious open-source packages have become one of the fastest-growing threats to the software supply chain. According to Kaspersky researchers, approximately 14 000 malicious packages were discovered in popular registries by the end of 2024, a 48% year-over-year increase. Sonatype reported an even more explosive surge throughout 2025 — detecting over 450 000 malicious packages.
The motivation behind these attacks varies widely: cryptocurrency theft, harvesting developer credentials, industrial espionage, gaining infrastructure access via CI/CD pipelines, or compromising public servers to host spam and phishing campaigns. These tactics are employed by both spy APT groups and financially motivated cybercriminals. Increasingly, compromising an open-source package is just the first step in a multi-stage corporate breach.
Common attack scenarios include compromising the credentials of a legitimate open-source package maintainer, publishing a “useful” library with embedded malicious code, or publishing a malicious library with a name nearly identical to a popular one. A particularly alarming trend in 2025 has been the rise of automated, worm-like attacks. The most notorious example is the Shai-Hulud campaign. In this case, malicious code stole GitHub and npm tokens and kept infecting new packages, eventually spreading to over 700 npm packages and tens of thousands of repositories. It leaked CI/CD secrets and cloud access keys into the public domain in the process.
While this scenario technically isn’t related to vulnerabilities, the security tools and policies required to manage it are the same ones used for vulnerability management.
How AI agents increase the risks of open-source code usage
The rushed, ubiquitous integration of AI agents into software development significantly boosts developer velocity — but it also amplifies any error. Without rigorous oversight and clearly defined guardrails, AI-generated code is exceptionally vulnerable. Research shows that 45% of AI-generated code contains flaws from the OWASP Top 10, while 20% of deployed AI-driven applications harbor dangerous configuration errors. This happens because AI models are trained on massive datasets that include large volumes of outdated, demonstrational, or purely educational code. These systemic issues resurface when an AI model decides which open-source components to include in a project. The model is often unaware of which package versions currently exist, or which have been flagged as vulnerable. Instead, it suggests a dependency version pulled from its training data — which is almost certainly obsolete. In some cases, models attempt to call non-existent versions or entirely hallucinated libraries. This opens the door to dependency confusion attacks.
In 2025, even leading LLMs recommended incorrect dependency versions — simply making up an answer — in 27% of cases.
Can AI just fix everything?
It’s a simple, tempting idea: just point an AI agent at your codebase and let it hunt down and patch every vulnerability. Unfortunately, AI can’t fully solve this problem. The fundamental hurdles we’ve discussed handicap AI agents just as much as human developers. If vulnerability data is missing or unreliable, then instead of finding known vulnerabilities, you’re forced to rediscover them from scratch. That’s an incredibly resource-intensive process requiring niche expertise that remains out of reach for most businesses.
Furthermore, if a vulnerability is discovered in an obsolete or unsupported component, an AI agent cannot “auto-fix” it. You’re still faced with a need to develop custom patches or execute a complex migration. If a flaw is buried deep within a chain of dependencies, AI is likely to overlook it entirely.
What to do?
To minimize the risks described above, it will be necessary to expand the vulnerability management process to include open-source package download policies, AI assistant operating rules, and the software build process. This includes:
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-02 21:06:362026-04-02 21:06:36Risks, emerging when developing or using open-source software
Welcome to this week’s edition of the Threat Source newsletter.
Last weekend, I witnessed a crime. Not a notable crime that you might read about in the press, but an unremarkable fraud attempt that nevertheless illustrates how new threat actor capabilities are emerging.
I imagine that most people reading this probably field IT questions from friends, family, and your local community. I assist with the IT provision for a local community association. It’s not a wealthy, large association — just your typical volunteer-run nonprofit like many others in the region providing community services.
This weekend, the chair emailed the treasurer requesting a bank transfer. The treasurer replied asking for the recipient’s details, and the chair promptly responded. The emails appeared authentic: correct names, a sum consistent with the association’s regular expenditure. Yet something made the treasurer pause. The reason for the transfer felt vague, and the tone seemed slightly off. They picked up the phone to verify. The chair had no idea what they were talking about. The emails and the request were an attempted fraud by a third party.
This is a variant of the business email compromise (BEC) scam in which an attacker impersonates a trusted individual and requests a fund transfer to an account they control. The attacker relies on social engineering to trick someone with payment authority to send the money. Once received, funds typically pass through money mules or compromised personal accounts before being rapidly shuffled through multiple transfers, obscuring the trail and drastically reducing the chances of recovery.
The initial email is often sent from a plausible email address. Closely scrutinising the sender’s email address may not help, since the attack may originate from the sender’s genuine account that has previously been compromised.
Historically, BEC targeted large organisations where anticipated payouts justified the time investment required to research key personnel and craft targeted attacks. The anticipated payout would more than cover the costs involved.
However, the fact that attackers are willing to target a small community organisation for a relatively small sum of money shows that the economics of the attack have changed.
AI has fundamentally altered the economics of BEC. Attackers can now reconnoitre many small organisations rapidly and cheaply. AI-generated content can be tailored to each target: referencing specific projects, using appropriate terminology, matching organisational tone.
The attack no longer needs to be labour-intensive or highly targeted. It’s become democratised, and an accessible playbook for targeting any organisation. Community associations, local charities, or small businesses can now be targeted, both because the attack is easier to execute, but also because scamming smaller sums from many victims can be as profitable as scamming large sums from few victims. Unfortunately, because this profile of organisation may never have encountered this threat before, they may be unaware and consequently more vulnerable.
For every treasurer who pauses when something doesn’t quite feel right, there are others who will accept an apparently legitimate email at face value. Protection begins with awareness of how the fraud operates. Be suspicious of any unexpected request for payment, especially if there is a sense of urgency or reasons why a phone call “isn’t possible” right now. Verify through separate channels before any transfer occurs. Call a known number for your contact, not one provided in the suspicious email. Enforce strict procurement rules that prevent any last-minute urgent payments.
Above all, recognise the democratisation of business email compromise scams. They’re no longer something that only happens to large corporations with complex supply chains and international operations. They’re for everyone now.
The one big thing
Cisco Talos has identified a large-scale automated credential harvesting campaign that exploits React2Shell, a remote code execution vulnerability in Next.js applications (CVE-2025-55182). Using a custom framework called “NEXUS Listener,” the attackers automatically extract and aggregate sensitive data — including cloud tokens, database credentials, and SSH keys — from hundreds of compromised hosts to facilitate further malicious activity.
Why do I care?
This campaign uses high-speed automation to exploit React2Shell, enabling attackers to rapidly harvest high-value credentials and establish persistent, unauthenticated access. This creates significant risks for lateral movement and supply chain integrity. Furthermore, the centralized aggregation of stolen data allows attackers to map infrastructure for targeted follow-on attacks and potential data breaches.
So now what?
Organizations should immediately audit Next.js applications for the React2Shell vulnerability and rotate all potentially compromised credentials, including API keys and SSH keys. Enforce IMDSv2 on AWS instances and implement RASP or tuned WAF rules to detect malicious payloads. Finally, apply strict least-privilege access controls within container environments to limit the potential impact of a compromise.
F5 BIG-IP DoS flaw upgraded to critical RCE, now exploited in the wild The US cybersecurity agency CISA on Friday warned that threat actors have been exploiting a critical-severity F5 BIG-IP vulnerability in the wild. (SecurityWeek)
EuropeanCommission investigating breach after Amazon cloud account hack The threat actor told BleepingComputer that they will not attempt to extort the Commission using the allegedly stolen data, but intend to leak it online at a later date. (BleepingComputer)
Google fixes fourth Chrome zero-day exploited in attacks in 2026 As detailed in the Chromium commit history, this vulnerability stems from a use-after-free weakness in Dawn, the underlying cross-platform implementation of the WebGPU standard used by the Chromium project. (BleepingComputer)
Anthropic inadvertently leaks source code for Claude Code CLI tool Anthropic quickly removed the source code, but users have already posted mirrors on GitHub. They are actively dissecting the code to understand the tool’s inner workings. (Cybernews)
Can’t get enough Talos?
Qilin EDR killer infection chain Take a deep dive into the malicious “msimg32.dll” used in Qilin ransomware attacks, which is a multi-stage infection chain targeting EDR systems. It can terminate over 300 different EDR drivers from almost every vendor in the market.
An overview of 2025 ransomware threats in Japan In 2025, the number of ransomware incidents increased compared to 2024. Notably, it was a year in which attacks leveraging Qilin ransomware were observed most frequently.
A discussion on what the data means for defenders To unpack the biggest Year in Review takeaways and what they mean for security teams, we brought together Christopher Marshall, VP of Cisco Talos, and Peter Bailey, SVP and GM of Cisco Security.
When attackers become trusted users The latest TTP draws on 2025 Year in Review data to explore how identity is being used to gain, extend, and maintain access inside environments.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-02 19:06:342026-04-02 19:06:34The democratisation of business email compromise fraud
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-04-02 15:06:382026-04-02 15:06:38[Video] The TTP Ep 21: When Attackers Become Trusted Users
![[Video] The TTP Ep 21: When Attackers Become Trusted Users](https://blog.talosintelligence.com/content/images/2026/04/2025YiR-report_cover.jpg)
![[Video] The TTP Ep 21: When Attackers Become Trusted Users](https://blog.talosintelligence.com/content/images/2026/03/YiR2025_background-2.jpg)