2026-06-08 AI创业新闻

VS Code Adds 2-Hour Extension Auto-Update Delay to Limit Supply Chain Attacks

Microsoft has announced that Visual Studio Code (VS Code) will apply a two-hour delay before extensions for the integrated development environment (IDE) are updated automatically to a newer version in an attempt to tackle software supply chain threats. “When automatic updates are enabled, new versions are auto-updated two hours after they are published, adding an extra layer of protection against problematic or potentially compromised releases,” Microsoft said . The new feature is available starting in VS Code 1.123. The tech giant noted that users still have the option to update any extension immediately at any point in time by using the “Update” button.

When extensions have pending updates, a reason for why they haven’t been updated yet will be available in the details view, along with when the automatic update will take place. That said, this two-hour delay does not apply to extensions from trusted publishers such as Microsoft, GitHub, and OpenAI, it added. Extensions from such publishers will continue to be updated immediately. The development comes days after RubyGems added an opt-in cooldown feature to Bundler 4.0.13 that delays installation of newly published gem versions for a pre-defined period.

Specifically, the feature allows developers to configure Bundler to introduce a time-based install delay with an aim to reduce potential exposure arising from newly published malicious versions. Over the past year, similar installation controls have also been added to Bun, pnpm, npm, and Yarn - Bun

minimumReleaseAge (Bun 1.3+) npm
min-release-age (npm v11.10.0+) pnpm
minimumReleaseAge (pnpm 10.16+) Yarn
npmMinimalAgeGate (Yarn Berry 4.10.0+) These changes arrive against the backdrop of a surge in software supply chain incidents targeting various ecosystems to breach developer systems and propagate malware to downstream users. Before enforcing a minimum age threshold before a particular package version can be installed, the defensive control minimizes the window during which it spreads before it’s flagged as malicious and taken down by the registry maintainers. Found this article interesting?

New ChatGPT Lockdown Mode Limits Tools That Could Enable Data Exfiltration

OpenAI has begun rolling out a new Lockdown Mode to ChatGPT for eligible personal accounts to reduce the risk of data exfiltration arising from prompt injection attacks . The feature is primarily designed for people and organizations that handle sensitive data and require stricter protection guarantees. Lockdown Mode is available to logged-in users across Free, Go, Plus, and Pro, and self-serve ChatGPT Business plans. “Lockdown Mode is an optional advanced security setting that limits many tools and capabilities in OpenAI products that can connect to the web or external services,” OpenAI said .

“It is designed to reduce the risk of data exfiltration from prompt injection attacks by limiting outbound network requests, at the expense of disabling or limiting some useful features.” The safeguards are aimed at hardening the attack surface against prompt injections, which continues to be a “frontier” problem impacting all large language models (LLMs). Specifically, they build upon sandboxing and existing controls to combat URL-based data exfiltration mechanisms to limit outbound network requests that could potentially transmit sensitive data to attacker-controlled infrastructure. The idea is not to stop prompt injections from occurring. Nor does it change the way memory or file uploads work, or the ability to share a conversation.

Rather, the goal is to eliminate potential pathways through which the data could be exfiltrated. To that end, Lockdown Mode disables the following features - Live web browsing, which is limited to accessing only cached content Image support, for displaying images in regular responses or retrieving images from the web Deep research Agent mode Canvas networking, which prevents users from approving Canvas -generated code to access the network File downloads, which block downloading files for data analysis Pointing out the feature is not “intended for everyone,” OpenAI also noted that both Lockdown Mode and Developer Mode cannot be used at the same time, adding that turning on one disables the other. “Lockdown Mode is designed to substantially reduce the risk of prompt injection-based data exfiltration in ChatGPT and supported OpenAI products, but it does not guarantee that data exfiltration cannot happen,” the company said. “Risk may remain through enabled Apps, unforeseen combinations of capabilities, or newly discovered techniques.” “Lockdown Mode also does not prevent all other effects of prompt injection attacks.

For example, a malicious instruction hidden in an uploaded file could still affect ChatGPT’s behavior, and cause an incorrect answer.” The development comes as OpenAI has also launched a new account management feature that enables users to review active ChatGPT sessions and log out of individual or all sessions if signs of unauthorized account activity are detected. The listed sessions include information about the device, the app used, approximate location, sign-in date and time, whether the device is trusted, and whether it’s the current session. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Free Apps Are Quietly Turning Smart TVs Into Web-Scraping Proxies for AI

A researcher has reverse-engineered the iOS SDK that Bright Data embeds in consumer apps and documented how it turns devices, including always-on smart TVs, into exit nodes that relay web-scraping traffic for a data business Bright Data markets heavily to the AI industry. The company, the successor to Luminati, operates what it calls the largest residential proxy network in the world, advertised at more than 400 million residential IPs. Part of that supply comes from this SDK, shipped inside free apps behind an opt-in screen and described as a consent-sourced pool of 150 million-plus IPs. The findings, published June 5 by Include Security and independent researcher Buchodi, matter because the scraping comes from the user’s home IP, not the customer’s.

The immediate risk is not a hacked account or stolen data; it is that a home connection and its bandwidth get used as someone else’s scraping infrastructure. A connected TV is close to ideal for that: usually plugged in, on a fast connection, effectively unmetered, and unwatched. The deepest technical evidence is from the iOS SDK; the smart-TV reach rests on Bright Data’s platform support, its public partner list, and earlier reporting. The research found the peer channel that carries scraping jobs has no real authentication, and on iOS, its traffic bypasses a configured VPN.

Inside the peer tunnel When the app opens, the SDK contacts one of Bright Data’s servers, which hands over its instructions without really checking who is asking. From then on, the server can tell the device to go and fetch pages from other websites, using the user’s home internet connection to do it. The researcher found the channel that carries those jobs has none of the usual security checks, and described it as weaker than the controls built into most malware. On iPhones, the researcher found that this traffic slips past a VPN, and that much of what the app does does not show up in the tools security teams normally use to monitor apps.

The device can also keep relaying in the background while someone is watching the screen or on a call, as long as the battery is not low. The consent gap The opt-in screen does not match what the SDK actually allows. In one Roku app, Petflix, the screen said it would use the device and its connection “occasionally.” The settings the SDK loads allow up to 200 GB of traffic a month. In a few countries, including Uzbekistan and Oman, the limits are set far higher, and the device is cleared to keep working almost until the battery runs flat.

The SDK can also tie together a person’s phone and computers that run the same company’s apps, treating them as one user. Bright Data publishes its list of app partners on a page anyone can open, and it includes makers of smart-TV apps such as PlayWorks Digital, CloudTV, and Longvision. The researcher is careful to note that being on the list only shows a company worked with Bright Data at some point, not that its app includes the SDK today. Each one would need to be checked on its own.

An old model, pulled by AI demand None of this is new in shape, only in scale. Bright Data is the successor to Luminati, the paid proxy service that grew out of Hola VPN. In 2015 Hola was caught selling its free users’ bandwidth as exit nodes through Luminati, at $20 a gigabyte. The same model now runs on the always-on box in the living room.

What changed is the buyer. Anti-bot defenses from Cloudflare, DataDome, and others block scrapers coming from datacenter IPs, so AI scrapers route through residential connections instead. Krebs reported in October 2025 that proxies from botnets like Aisuru are fueling large-scale AI data harvesting, and Google dismantled the criminal IPIDEA proxy network in January. Those operations hijack consumer devices; Bright Data says its exit nodes opt in through a consent screen.

That consent is the line between the two, and whether it is meaningful is the open question. Lowpass, syndicated by The Verge, first surfaced the smart-TV angle in February, and this is the technical teardown. Google, Amazon, and Roku have since restricted background proxy SDKs, and Bright Data dropped those platforms, though it still lists Samsung’s Tizen and LG’s webOS. What to do The traffic is easy to spot and block.

On a home network, the simplest step is to block the web addresses the SDK uses to connect, with a router-level tool like Pi-hole or NextDNS. The main ones are proxyjs.brdtnet.com, proxyjs.luminatinet.com, proxyjs.bright-sdk.com, clientsdk.bright-sdk.com, and clientsdk.brdtnet.com. According to the research, blocking these stops the device from acting as a relay without affecting Bright Data’s paid service, which runs on separate addresses. Companies that manage staff phones can also scan for apps that carry the SDK.

One catch: on a mobile connection, the traffic sidesteps office Wi-Fi, so a network block alone will not always catch it. Bright Data could also change how the SDK connects in the future, which would mean any blocklist needs updating. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

State of AI in the Cloud 2026: How AI is Reshaping Cloud Attack Surface

CISA Adds Actively Exploited SolarWinds Serv-U DoS Flaw to KEV Catalog

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a high-severity security flaw impacting SolarWinds Serv-U multi-protocol file server software to its Known Exploited Vulnerabilities ( KEV ) catalog, citing evidence of active exploitation. The vulnerability, tracked as CVE-2026-28318 (CVSS score: 7.5), is a denial-of-service (DoS) bug that causes the service to crash under certain conditions. CISA described it as an uncontrolled resource consumption vulnerability that results in a DoS condition.

“SolarWinds Serv-U is susceptible to specially crafted POST requests that crash the Serv-U service without authentication using Content-Encoding: deflate,” SolarWinds said in an advisory released earlier this week. The issue has been addressed in SolarWinds Serv-U version 15.5.4 HF1. As mitigations, it’s advised to limit access to known addresses and block any request containing “content-encoding” since the vulnerable service does not require this functionality. There are currently no details on how the vulnerability is being exploited in real-world attacks, or who is behind them.

It’s also unclear how many internet-exposed Serv-U instances are compromised, if any. CISA has ordered Federal Civilian Executive Branch (FCEB) agencies to address the flaw by June 19, 2026. In the past, multiple flaws in Serv-U have been exploited by bad actors, including those associated with the Cl0p ransomware gang . Found this article interesting?

AI Agent Uncovers 21 Zero-Days in FFmpeg; Chrome Patches Record 429 Bugs

Two things landed within days of each other this week. A security startup reported 21 previously unknown vulnerabilities in FFmpeg, the media library inside almost everything that touches video, all of them found by an autonomous AI agent. The same week, Google shipped Chrome 149 with patches for 429 security bugs, the most ever in a single release. Only the FFmpeg bugs were found by AI.

Chrome’s record landed after Google overhauled its bounty program to cope with a flood of AI-generated reports. The mechanisms differ, but the pressure is the same: AI is putting more vulnerabilities in front of the people who have to deal with them, and faster than before. The FFmpeg findings come from depthfirst , whose autonomous security agent scanned the project’s roughly 1.5 million lines of C and produced 21 confirmed zero-days, each with a reproducible proof-of-concept input. The company puts the cost of the run at around $1,000.

Several of the bugs had been latent for 15 to 20 years; one stack overflow in the service-description-table code dates to 2003 and sat untouched for 23 years. Most are heap or stack overflows in parsers and demuxers, spanning components from the TS demuxer to the VP9 decoder. depthfirst says some already carry CVE identifiers; its writeup lists nine, CVE-2026-39210 through CVE-2026-39218, and notes the rest are fixed but not yet numbered. It also published a PoC .

In separate news, Chrome 149 fixes 429 vulnerabilities, a record for a single release. Over 100 are critical or high severity, mostly use-after-free and insufficient input validation. The worst, CVE-2026-10881 (CVSS 9.6), is an out-of-bounds read and write in the ANGLE graphics engine that lets a crafted page escape the sandbox and run code on the host. Google paid $97,000 for it.

The highest-severity bugs were mostly internal finds: of roughly 90 high-severity bugs, only 10 came from outside researchers, and 19 of the 22 critical ones were Google’s own. The AI connection is more about volume than authorship. Google hasn’t tied the 429 to AI; the on-record signal is the bounty overhaul it made in April, prompted by a flood of AI-generated submissions and now asking for a concise reproducer over the long writeups AI churns out. Google’s Big Sleep agent reported a run of FFmpeg bugs last year, now visible on the project’s security page tagged BIGSLEEP, and Anthropic’s Mythos model pulled a 16-year-old H.264 flaw and others out of FFmpeg for about $10,000, three of which shipped in FFmpeg 8.1, per its own writeup .

Days ago, another autonomous tool found an authenticated RCE in Redis that had been present since version 7.2.0, unnoticed for over two years. The research points the same way: a February study had an agent reproduce working PoCs for more than half of 100 real Linux kernel N-day bugs , beating fuzzing. For FFmpeg, pull the fixed upstream build or your distribution’s security update as soon as it lands, and prioritize anything that ingests untrusted RTSP or AV1-over-RTP. FFmpeg is widely bundled in media pipelines, Python wheels, container images, and appliances, so do not stop at system packages; those embedded copies need patching too.

For Chrome, update to 149.0.7827.53 on Linux or 149.0.7827.53/54 on Windows and macOS, or confirm auto-update has run. The response has to match the new pace: shorter patch cycles, auto-update wherever it exists, and dependency bumps that carry CVE fixes treated as security work, not routine maintenance. The hard part is shifting, though. Finding these bugs has gotten cheap; triaging the reports, shipping the fixes, and getting them installed has not, and much of that work still falls to volunteers and a thin layer of human triagers now expected to keep pace with machines.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack

Microsoft’s GitHub repositories have become the latest to fall victim to the ongoing Miasma self-replicating supply chain attack campaign. The incident impacted 73 Microsoft repositories across four of its GitHub organizations, including Azure, Azure-Samples, Microsoft, and MicrosoftDocs, per OpenSourceMalware . The development has GitHub to disable access to those repositories. “Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service,” reads the message when attempting to access the “ Azure/azure-functions-host “ repository.

“If you are the owner of the repository, you may reach out to GitHub Support for more information.” According to OpenSourceMalware, some of the repositories impacted by the incident are listed below - azure-search-openai-demo-purviewdatasecurity Connectors-NET-LSP Connectors-NET-SDK durabletask durabletask-dotnet durabletask-go durabletask-js durabletask-mssql functions-container-action homebrew-functions llm-fine-tuning windows-driver-docs What’s notable about the latest campaign is the re-compromise of the “durabletask” PyPI package, which was infected by TeamPCP last month to deliver an information stealer on Linux systems. “A month later, not only is Azure/durabletask gone - so is every sibling repo in the Durable Task ecosystem, sitting one org over in Microsoft: the .NET, Go, Java, JS, MSSQL, Netherite, and protobuf implementations, plus the Durable Functions monitor,” security researcher Paul McCarty (aka 6mile) said. “When the repo at the root of last month’s compromise is the hub of this month’s takedown, that is not a coincidence - that is the same wound reopening. Whoever held those credentials in May plausibly never fully lost them.” Miasma is assessed to be a variant of the Mini Shai-Hulud worm that TeamPCP publicly released in mid-May 2026.

It has since continued to mutate and refine its tactics, even as it has infected more packages over the past couple of days, using various descriptions for the newly-created public repositories containing the stolen secrets - Miasma: The Spreading Blight Miasma : The Spreading Blight Miasma - The Spreading Blight Hades - The End for the Damned As of writing, there are 13 repositories with the description “Hades - The End for the Damned” and 82 repositories with the remaining three naming patterns. Miasma has also been observed skipping the npm registry entirely, with the threat actors pushing malicious code directly to “icflorescu/mantine-datatable” and four related repositories: “mantine-contextmenu,” “next-server-actions-parallel,” “mantine-datatable-v6,” and “mantine-contextmenu-v6.” “The commit added no dependencies. It planted a 4.3 MB payload runner and wired it to execute automatically through five developer tools: Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script,” SafeDep said . “The attack detonates when a developer clones one of the affected repos and opens it in an AI coding agent.

The dropper is the same staged Bun loader, here repurposed for GitHub source-repo persistence rather than registry poisoning.” These software supply chain attacks have exposed the underlying weaknesses in the trust model that forms the basis of software delivery in open-source ecosystems, making it one of the most significant and sustained campaigns observed to date. What separates the activity from other incidents is its ability to exponentially propagate across the ecosystem by compromising downstream users and repeating the same cycle. “The worm’s genius and the reason conventional defences largely failed is that it operates entirely within legitimate channels. It does not exploit a vulnerability in npm or GitHub,” FalconFeeds.io said .

“It exploits the trust model those platforms are built on: the assumption that if a package is signed with a valid key and published by an authenticated maintainer, it is safe.” “Shai-Hulud compromises the key and the maintainer, then proceeds to act exactly as a legitimate publisher would. From the registry’s perspective, every malicious publish event is indistinguishable from a routine update.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Cisco Catalyst SD-WAN Manager CVE-2026-20245 Flaw Actively Exploited – No Patch Available

Cisco has warned that a high-severity security flaw impacting Catalyst SD-WAN Manager has come under active exploitation. The vulnerability, tracked as CVE-2026-20245 , carries a CVSS score of 7.8 out of a maximum of 10.0. It affects the following deployment types - On-Prem Deployment Cisco SD-WAN Cloud-Pro Cisco SD-WAN Cloud (Cisco Managed) Cisco SD-WAN for Government (FedRAMP) “A vulnerability in the CLI of Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage, could allow an authenticated, local attacker to execute arbitrary commands as root by supplying a crafted file to the affected system,” Cisco said in an advisory. The network security company said the vulnerability is the result of insufficient validation of user-supplied input, which an attacker could exploit by uploading a crafted file to the affected system.

This, in turn, could permit the attacker to perform command injection attacks and elevate their privileges as the root user. “To exploit this vulnerability, the attacker must have netadmin privileges on the affected system,” Cisco added. “This would require valid credentials or exploitation of CVE-2026-20182 or CVE-2026-20127 . Cisco is not aware of successful exploitation by other methods.” CVE-2026-20182 (CVSS score: 10.0) was disclosed last month by Rapid7, describing it as an authentication bypass that could enable unauthenticated, remote attackers to obtain administrative privileges on susceptible systems.

It’s also assessed to be similar to CVE-2026-20127, another case of authentication bypass impacting the same component. Both vulnerabilities have been exploited in the wild as zero-days, with a threat activity cluster dubbed UAT-8616 linked to the abuse of CVE-2026-20127 as far back as 2023. In its advisory released Thursday, Cisco said it observed limited cases where the exploitation of CVE-2026-20245 resulted in a configuration change pushed to edge devices. It credited Google Mandiant researchers Chester Sng, Pete Boonyakarn, and Logeswaran Nadarajan with discovering and reporting the new vulnerability.

It is unknown who is behind the latest exploitation efforts. There are currently no patches or mitigations available for CVE-2026-20245. Customers are recommended to upgrade their SD-WAN software to ensure they have applied the fixes released for CVE-2026-20182 on May 14, 2026. Cisco has also warned that internet-exposed systems are at heightened risk of compromise.

To look for indicators of compromise (IoCs), users are advised to check the “/var/log/scripts.log” file for entries like below - Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0

Jun 5 13:06:39 Manager vScript: vSmart upload serial numbers: /usr/bin/vconfd_script_upload_vsmart_serial_numbers.sh -cli path /home/admin/vsmart_serial_numbers_safe.csv

Jun 5 13:08:47 Validator vScript: ZTP upload chassis numbers: /usr/bin/vconfd_script_upload_chassis_number_file.sh -cli path /home/admin/chassis_numbers_safe.csv CVE-2026-20245 is the seventh flaw impacting Cisco SD-WAN to be flagged as active exploited this year alone after CVE-2026-20182, CVE-2026-20127, CVE-2026-20122, CVE-2026-20128, CVE-2026-20133 , and CVE-2022-20775 . The disclosure comes days after Cisco addressed another high-severity security flaw in Unified Communications Manager ( CVE-2026-20230 , CVSS score: 8.6), for which it said a proof-of-concept exploit code is public. There is no evidence that the vulnerability has come under active exploitation. Found this article interesting?

IronWorm and New Miasma Worm Variant Hit npm in Supply Chain Attacks

Multiple software supply chain attacks have hit the npm ecosystem, with threat actors using both malicious and poisoned versions of over 50 legitimate packages to distribute a Rust-based information stealer and a self-spreading worm, respectively. According to JFrog , the information stealer “scrapes every secret it can find on a developer’s machine, hides behind an eBPF kernel rootkit, and answers to its operator over Tor.” The stealer also uses the stolen credentials as a propagation mechanism, drawing similarities to the infamous Shai-Hulud worm. The new malware has been codenamed IronWorm by the software supply chain security company. By publishing itself to the npm registry in the form of trojanized packages, the approach results in a self-replicating attack.

The malicious activity has been traced back to a compromised npm account named “ asteroiddao ,” which has been found to publish package versions containing the Rust ELF binary that’s executed via a preinstall hook. The malware targets 86 environment variables, various files that may contain credentials associated with OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services (AWS), Docker, Kubernetes, and npm, vault configurations, and Exodus cryptocurrency wallet files. An unusual quirk worth mentioning here is that the stealer includes logic for the wallet data-stealing component to skip the threat actor’s own wallet. As of writing, the cryptocurrency wallet is empty, and no transactions have been recorded.

JFrog described IronWorm as “a supply chain weapon built to find secrets, modify projects, and inject malicious code to self-propagate across GitHub.” The malicious commits, which span nine GitHub organizations, have been introduced under the author name “claude” (“claude@users.noreply.github.com”) in an attempt to mimic Anthropic’s artificial intelligence (AI) chatbot. “The malicious npm package was published by asteroiddao; asteroiddao corresponds to the asteroid-dao GitHub organization; and ocrybit is a member of that organization, as well as related Arweave organizations,” the company explained. “The malware stole ocrybit’s credentials and used them to push commits across repositories it could access. Those commits planted malware into other packages, which could then be published and infect the next developer.

And then it vanished.” What’s more, the malicious payload is equipped to swap existing GitHub Actions workflows for one that’s capable of harvesting the secrets, writing it to a harmless-looking file, and uploading it as a build artifact, thereby eliminating the need for an external command-and-control (C2) server. The malware’s capabilities don’t end there. In CI environments, it abuses npm’s Trusted Publishing flow to obtain short-lived tokens to push poisoned versions containing the malware to the registry. It also incorporates an eBPF payload that functions as a kernel-level rootkit to hide processes and thwart analysis.

However, on systems where kernel lockdown is enabled, the process-hiding tricks fail, and the supposed processes and sockets become visible again. Miasma Worm Surfaces Again The disclosure comes as Endor Labs and StepSecurity shed light on a distinct supply chain attack campaign that has compromised 57 npm packages across more than 286 malicious versions to serve a new variant of the Miasma worm, which previously infected 32 packages across more than 90 versions under the @redhat-cloud-services npm namespace within 72 seconds earlier this week. Some of the affected packages are listed below - ai-sdk-ollama autotel awaitly effect-analyzer eslint-plugin-awaitly executable-stories-cypress http-uploader-dev mountly node-env-resolver node-env-resolver-aws The data stolen via the malware is exfiltrated to a now-inaccessible GitHub account “ liuende501 ,” which acted as an exfiltration point. As many as 236 repositories were staged in the account.

It’s presently not known if GitHub removed the account or if the threat actor themselves deleted it. “This wave uses a technique we are calling ‘Phantom Gyp’: instead of the preinstall or postinstall lifecycle scripts that security tools typically monitor, the attacker abuses a 157-byte binding.gyp file to trigger code execution during npm install, bypassing most install-script security checks entirely,” StepSecurity researcher Sai Likhith said. Like in the case of Miasma , the attack chain is engineered to download and install the Bun JavaScript runtime, using it to load a comprehensive credential harvester that’s tailored to extract secrets from AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, password managers, and AI assistants. “The most novel and concerning capability of this variant is its targeting of AI coding assistant configurations,” the company said.

“The malware injects persistent backdoor files into project repositories that execute whenever a developer opens the project in their AI-assisted IDE.” Developers who have installed an affected version are advised to rotate credentials, turn off install scripts and native rebuilds by default, and ensure packages are pinned with integrity hashes. In an update shared this week, Red Hat revealed that the root cause behind the Miasma supply chain incident was likely a compromised GitHub account that was used to push unauthorized commits to repositories in the RedHatInsights GitHub organization. “The payload operated across Linux, macOS, and Windows by dynamically downloading the correct Bun runtime for each platform, although Linux CI/CD runners appeared to be the primary target,” Microsoft said of the campaign. “On developer systems, the malware stole Secure Shell (SSH) keys, command-line interface (CLI) credentials, browser and wallet data, while in CI/CD environments it scraped GitHub Actions runner memory for secrets, escalated privileges using passwordless sudo, and republished poisoned packages with forged Supply-chain Levels for Software Artifacts (SLSA) provenance to continue downstream propagation.” The Miasma payload is assessed to be a derivative of the Shai-Hulud worm put to use by TeamPCP in recent campaigns, introducing largely “cosmetic” changes while keeping the underlying functionality similar.

Despite the overlap in tradecraft, the attribution for the latest set of attacks remains unclear, given that TeamPCP has publicly released the Shai-Hulud code. OX Security has since uncovered additional stages in the Miasma attack chain, including searches for GitHub commits containing the string “firedalazer” (replacing the previously flagged “ FIRESCALE “ dead drop) to retrieve another payload, a JavaScript file (“index.js”) that contains an alternative version of the Shai-Hulud worm, effectively transforming the infection into a perpetual loop. In this case, the stolen data is exfiltrated to public GitHub repositories, each carrying the description “Miasma : The Spreading Blight” or “Miasma - The Spreading Blight.” It’s important to note here that the previous version reads “Miasma: The Spreading Blight,” which does not have a space between Miasma and the “:” symbol. There are currently 82 such repositories created on user accounts “0tabek16” and “windy629.” “The threat actor can dynamically change the ‘firedalazer’ commits in GitHub, making new versions of the malware, more adaptive and more sophisticated,” security researchers Moshe Siman Tov Bustan and Nir Zadok said .

“This turns GitHub into something more dangerous than a dead drop. It’s an adaptive C2 - one that piggybacks on a trusted, widely whitelisted platform, making network-level detection nearly useless. Most security tools aren’t configured to treat GitHub traffic as suspicious. The threat actor knows this.” Found this article interesting?

Android Spyware Asin Targets Arabic Users via Fake News, PDF and War Map Apps

Arabic-speaking users have emerged as the target of a new Android spyware codenamed Asin , according to findings from ESET. The Slovakian cybersecurity company said it first detected the malware spread via multiple campaigns in early 2025, with each attack wave making use of distinct websites mimicking utilities, war-related updates, and a government news source: govlens[.]net, which impersonates a government news source (registered on May 27, 2025) pdf-reader[.]help, which impersonates a secure PDF editor (registered on May 29, 2025) live-war-map[.]com, which claims to offer updates on military incidents (registered on January 20, 2025) Two of these websites - govlens[.]net and live-war-map[.]com - were also marketed via dedicated accounts on social media platforms like Facebook and Telegram - www.facebook[.]com/GovLens t[.]me/liveuamap_ar “Each of these websites distributes a malicious app that combines legitimate functionality with stealthy spyware capabilities,” ESET said. The cybersecurity company noted that the Telegram channel’s name is likely inspired by Live Universal Awareness Map ( Liveuamap ), a legitimate, well-known platform dedicated to mapping ongoing conflicts, human rights issues, natural disasters, and geopolitical events across the world. Multiple artifacts associated with Asin have since been identified, including one uploaded to VirusTotal from Türkiye in October 2025, an APK downloaded from the domain “c-pdf[.]net” in December 2025 by a user on a Xiaomi Redmi Note 13 Pro device running Android 15, and a third sample masquerading as “Syria Defense Map” detected on a Xiaomi Redmi Note 13 Pro+ 5G devices running Android 15 in around mid-January 2026.

In the last case, the APK is said to have been downloaded from a website named “syriadefensemap[.]com.” It’s worth noting that the user is required to manually install the app and grant it the necessary permissions for the spyware to realize its goals. The activity cluster, per ESET, remains unattributed. It’s also not known what the primary objectives of these campaigns are. However, based on the lures used, it’s suspected that journalists and OSINT researchers in Arabic-speaking regions may have been the target.

“Three out of the five fraudulent apps we unearthed - GovLens, WarMap, and Syria Defense Map - seem primarily intended for people interested in open-source investigation,” the company said. “It thus seems possible that this set of activities may have been, at least partially, meant to target Arabic-speaking journalists or OSINT practitioners.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New Threat Cluster OP-512 Targets Microsoft IIS Servers with Custom Web Shell Framework

Cybersecurity researchers have discovered a previously unreported threat cluster dubbed OP-512 (where “OP” stands for “opponent”) that has been observed targeting Microsoft Internet Information Services (IIS) servers to deploy a bespoke web shell framework. ReliaQuest has assessed with moderate to high confidence that the espionage-focused activity is linked to China. “OP-512 was highly likely conducting espionage through a compromised Internet Information Services (IIS) web server on an organization whose sector and geography align with China-linked intelligence priorities,” the company said in a report shared with The Hacker News. Although no overlaps have been found between OP-512 and other known China-aligned adversaries, it’s the fourth such threat group after CL-STA-0048 , DragonRank , and GhostRedirector to single out IIS web servers over the past 12 months.

As recently as last month, Cisco Talos revealed that multiple Chinese-speaking cybercrime groups are sharing a variant of malware called BadIIS to infect IIS servers. IIS servers have also been targeted by SHADOW-EARTH-053 as part of a new China-aligned espionage campaign targeting government and defense sectors across South, East, and Southeast Asia. Central to the operations of OP-512 is a custom web shell framework consisting of three web shells that grant the attackers remote access to the compromised host, while taking steps to evade signature-based detection and complicate forensic timelines using techniques like timestomping to intentionally manipulate the timestamps when the web shell artifacts are created or modified. Specifically, this entails scanning every file and sub-folder around where the web shells are placed, calculating the median last-modified timestamp, and overwriting their own creation and modification times to match that value, thus giving the impression that they have been present for some time.

“This framework combines capabilities we rarely see together: each deployment is uniquely generated, access is restricted to the attacker through cryptographic controls, and compromised servers automatically report back for centralized management at scale,” ReliaQuest said. OP-512 shares close tactical proximity to CL-STA-0048, which has raised the possibility that it either represents an existing cluster that has completely revamped its toolset or developed these capabilities independently on its own. Regardless of its origins, the hacking group is said to be a distinct cluster operating in an autonomous manner. In the attack observed by the cybersecurity company, the threat actor has been found to target a legacy IIS server running Windows Server 2016 with end-of-life .NET Framework 4.0.

There is evidence of prior activity on the same host, about 75 days before the main incident took place. This involved DNS queries to a different attacker-controlled domain (“ashx.lhlsjcb[.]com”). The sequence of actions that unfolded weeks later has been described as a “sprint,” with the attacker using the web server’s worker process (“w3wp.exe”) to drop one of the web shells to the application’s upload directory. This, in turn, triggers a self-reporting mechanism that uses a DNS query or an HTTP request as a fallback to transmit the web shell’s location to an attacker-controlled domain.

“Together, the three web shells gave the attacker file management, authenticated command execution through two independent access paths, and automated reporting of the compromise, all before anyone had time to respond,” ReliaQuest researchers explained. With the web shells deployed, OP-512 is said to have attempted to escalate privileges to the SYSTEM level using the Potato Suite, followed by running commands like “whoami /priv” to confirm their system rights. “Four China-linked clusters targeting the same technology in under a year is unlikely to be a coincidence,” ReliaQuest said. “Internet-facing IIS servers running legacy, unsupported software remain a preferred entry point across this threat ecosystem and show no signs of slowing down.” “What should concern defenders most is what makes OP-512 different.

This threat cluster isn’t using commodity tooling and recycling it across campaigns. It’s using a purpose-built framework designed to defeat the detection methods that work against the other three clusters. Organizations that have tuned their defenses to known actors are likely not covered here.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Only 10% of SOCs Say They’re Getting Excellent Value From AI. Here’s What the Second Wave Has to Deliver

Eighteen months ago, the AI SOC was a marketing line. Today it’s a budget item. The category has crossed over from interesting to inevitable, with billions of dollars now flowing into AI-powered security operations platforms, agentic SOC tools, and AI co-pilots built into every layer of the security stack. The data shows SOCs are buying, deploying, and standing up AI capabilities at the fastest pace the industry has ever seen.

And yet, the same SOCs reporting record AI adoption are reporting underwhelming outcomes. The first objective benchmark on the value of AI in the SOC was published in the SOC-CMM 2026 Maturity Report in May, drawing on survey data collected from roughly 200 SOCs across regions, sectors, and delivery models between late January and mid-March 2026. Only about 10% of respondents said AI has delivered excellent value to their SOC. About 19% reported good value.

The remaining 71% landed at some value or none at all. Eighteen months into AI deployment, that’s a structural signal. What follows is a read on what the data confirms, and on what the next wave of AI in security operations must deliver if the industry is going to close the gap. What the SOC-CMM 2026 data shows Three findings stand out in the SOC-CMM report’s AI section, and they correlate cleanly with each other once they are read together.

First, adoption is up across every category of AI used inside the SOC. Off-the-shelf large language models grew 55% year over year. AI co-pilots grew 145%. AI agents grew 118%.

Supervised machine learning grew 96%. Customized LLMs grew 64%. SOC teams are over-investing in AI without the operational maturity to extract value from what they bought. Second, the dominant adoption pattern is what the report calls the taker model: off-the-shelf AI deployed inside an existing security stack without customization.

About 65% of SOCs surveyed describe themselves as takers. Another 20% are shapers, customizing what they buy. Only 15% are builders, training models against their own data. The takers are the largest cohort and the cohort reporting the least value.

Across hybrid SOCs, in-house SOCs, and MSSP SOCs, the perceived value distribution is nearly identical. That uniformity is the tell. The pattern cuts across delivery model, region, and sector. The cause is structural.

Third, the report flags that the two SOC improvement challenges that grew year over year are lack of best practices (+17%) and complexity of increasing maturity (+11%). Every other challenge category, including lack of budget and lack of management support, dropped. SOCs aren’t telling the survey they don’t have money or executive support. They’re telling the survey they don’t know what they’re supposed to be doing with the AI they bought.

That is the AI maturity gap in one data point. Why the first wave of AI in the SOC underperformed The first wave of AI SOC tools shipped as features bolted onto existing security products. SIEMs got AI triage. EDRs got AI investigation.

SOAR platforms got AI playbook generation. Ticketing tools got AI summarization. Each feature was real. Each one worked in isolation.

None of them shared context with the next. What that means in practice is that SOC analysts now have five AI assistants instead of one. The triage agent in the SIEM does not know what the detection engineer silenced last week. The threat hunting agent in the EDR does not know what the threat intel team flagged that morning.

The summarization agent in the ticketing tool does not know what the investigation surfaced two hops ago. Each agent accelerates its own slice of the workflow. None of them fixes the handoffs between slices, which is where most SOC time and most SOC value live. SOC operators describe this pattern in conversations across the industry.

They describe faster individual tasks and the same fragmented workflow. They describe being asked to learn five new agent interfaces while the core problem, which is that the SOC operates as a chain of disconnected stages, didn’t move at all. The AI accelerated each silo without connecting them. The SOC-CMM 2026 report puts numbers on this dynamic too.

The technology domain is again the highest-scoring maturity domain across the dataset, at an average of 2.7 out of 5. The process domain, where the handoffs between SOC stages live, scores 2.3. The people domain, where the institutional knowledge and decision-making capacity live, scores 2.3 as well. Buying more tools, including AI ones, does not move those numbers.

In some SOCs it makes them worse, because each new tool adds a handoff. What’s different about the SOCs that report excellent value The 10% of SOCs reporting excellent value from AI are not running different point tools. They’re running AI inside a different architectural structure. Three things separate them from the 71%.

AI that operates across the SOC lifecycle, not inside one stage of it. Threat intelligence, threat hunting, detection, investigation, and remediation are five stages of one workflow. When agents operate across all five stages and feed each other context, the SOC compounds. Every closed investigation calibrates the next detection.

Every threat hunt result updates the next intel cycle. Every remediation feeds back into the playbook the next agent uses. The connected fabric is what produces sustained value. The SOCs reporting excellent value tend to have AI architectures that look like fabric.

The SOCs reporting good value tend to have stacks of features. AI that knows the dynamic environment it’s operating in and continuously draws on it. Generic AI produces generic investigations. “Normal” looks different in a healthcare environment than a fintech one.

A detection rule that fires on a real threat in one environment will fire on routine activity in another. An investigation that escalates correctly in one environment will overlook the right answer in another. SOCs reporting value have AI systems that capture and persist institutional knowledge: the assets that matter, the analysts whose judgment shaped past incidents, the sanctioned actions, the escalation criteria, the tickets that turned out to be nothing and the ones that turned out to be everything. Without that grounding, AI in the SOC produces the average of the internet, which is the wrong answer in most environments.

AI that is governable. The SOC-CMM 2026 report identifies effective SOC governance as the single most challenging area of SOC improvement, with 39% of respondents naming it. AI governance and SOC governance overlap. The agentic SOC operates inside customer-defined guardrails.

It exposes a defensible reasoning trace for every action. It earns autonomy in stages rather than asking for it upfront. AI in the SOC cannot be a black box. The SOCs that figured this out are the SOCs where analysts trust the system enough to give it standing authority.

That trust is what produces the productivity gain. Without it, the system stalls. The architecture problem, in plain terms Most enterprises trying to extract value from AI in the SOC today are running point AI inside a fragmented architecture. The point AI works inside a broken architecture.

That is the architecture problem. If a SOC’s detection engineering team works in a different tool than its investigation team, AI in either tool will accelerate that team’s slice of the workflow and do nothing about the handoff between them. If a SOC’s threat hunters cannot easily test hypotheses across the same telemetry its investigations use, AI in either workflow will move only that workflow forward. If a SOC’s remediation playbooks live in a SOAR tool that does not see what its investigation agent concluded, AI remediation will execute against stale context.

The fix is connecting the stages. More AI inside the same fragmented architecture compounds the original problem. That connective fabric is what “second wave” means. The first wave delivered AI per stage.

The second wave delivers AI across stages. What the second wave must look like The five stages of the SOC must operate as one agentic fabric grounded in the customer’s environment. Every closed investigation calibrates the next detection. Every threat hunt result updates the next intel cycle.

Every remediation feeds back into the playbook the next agent uses. The SOC compounds. In practice, a platform built this way sits on top of the SIEM, EDR, identity, cloud, ticketing, and threat intel stack an organization already owns rather than replacing it. The connective layer is what lets each stage feed the next instead of operating in isolation.

Where that architecture is in place, SOCs report sharper investigations completed faster, detections that get surfaced and tuned instead of left silent or noisy, threat hunts that run continuously rather than episodically, and remediation that operates inside defined guardrails with full reasoning traces and audit-grade decision records. The second wave of AI in the SOC must look architectural, not featural. The vendors and platforms that figure that out are the ones whose customers will move from “some value” to “excellent value” in next year’s benchmark. Spotlight: End-to-End Agentic AI for Security Operations One platform built around this architecture is Conifers’ end-to-end agentic SOC, launched in May 2026 on its CognitiveSOC™ platform.

Rather than adding AI to a single stage, it connects threat intelligence, threat hunting, detection engineering, investigation, and remediation into one operating fabric grounded in each customer’s institutional knowledge. The five functions feed each other context, so hunts inform detection, investigations calibrate future detections, and remediation runs inside customer-defined guardrails instead of static playbooks. Governance is built in from the start. Every agent action carries a reasoning chain and an evidence trail, and customers set the scope and authority each agent operates under, expanding autonomy as confidence builds.

That is the move from human-in-the-loop to human-on-the-loop oversight. The system runs on top of the stack a SOC already owns, with more than 60 integrations across EDR, identity, cloud, email, and ITSM, and no rip-and-replace migration. The window is closing faster than most SOCs think Adversaries are not waiting for the second wave to arrive. Google’s Threat Intelligence Group disclosed the first confirmed AI-developed zero-day exploit earlier this year.

Anthropic’s Claude Mythos preview is identifying critical vulnerabilities at machine speed. JPMorgan’s CISO published an open letter in April 2025 warning that the economics of cyber risk are shifting and that security buyers need to demand secure-by-default products instead of the current pace of rushed feature releases. The defenders running first-wave AI inside a fragmented SOC will be the ones explaining what happened the morning after a breach. The defenders running second-wave AI as a connected fabric, with institutional knowledge inside the loop and governance built in from the start, will be the ones who saw it coming.

The 10% number in the SOC-CMM 2026 report is a signal about the architecture most SOCs run right now. It is also a signal about which side of the next breach narrative each SOC will be standing on. Visit Conifers.ai to request a demo and experience the power of a full lifecycle agentic SOC. Frequently Asked Questions Why are most SOCs reporting limited value from AI in 2026?

The SOC-CMM 2026 Maturity Report found that about 71% of SOCs see only some value or no value from their AI deployments. The root cause is architectural rather than technological. Most SOCs deployed AI as features inside individual products such as SIEMs, EDRs, and ticketing systems. Each feature accelerated its own stage of the workflow.

None of them shared context across stages. The handoffs between threat intel, detection engineering, investigation, and remediation, which is where most SOC time goes, did not improve. AI accelerated the silos without connecting them. That is what produces “some value” instead of excellent value.

What does “second wave AI” in the SOC mean? Second wave AI in the SOC means agentic AI that operates across the full SOC lifecycle rather than inside a single stage. The five stages of the SOC, threat intelligence, threat hunting, detection engineering, investigation, and remediation, run as one connected fabric. Agents share context.

Closed investigations calibrate future detections. Threat hunt results update threat intel cycles. Remediation actions feed back into the playbook the next agent uses. The SOC compounds.

This is the architectural pattern shared by the roughly 10% of SOCs reporting excellent value from AI in the SOC-CMM 2026 data. Is the problem that SOCs are not buying enough AI? No. The SOC-CMM 2026 data shows AI adoption growing aggressively across every category, with off-the-shelf LLMs up 55%, AI co-pilots up 145%, and AI agents up 118% year over year.

SOCs are buying. The problem is that adoption is outpacing operational maturity. Two-thirds of SOCs are deploying off-the-shelf AI inside an existing security stack without modifying anything else around it. That cohort reports the least value.

Buying more AI without changing the architecture it operates inside compounds the original problem instead of solving it. How does institutional knowledge change AI SOC outcomes? Generic AI produces generic investigations. A detection rule that fires on real threats in one environment will fire on routine activity in another.

An investigation that escalates correctly in one organization will miss the right answer in another. AI systems that continuously ingest and persist dynamic institutional knowledge, the assets that matter, the analysts whose judgment shaped past incidents, the sanctioned actions, the escalation criteria, the historical incident outcomes, produce investigation results that match how a specific SOC operates. AI without that grounding produces the average of the internet, which is the wrong answer in most environments. Institutional knowledge is the difference between AI that produces noise and AI that produces decisions.

What should CISOs ask before buying their next AI SOC tool? Three questions matter most. Does this AI operate across the full SOC lifecycle, or only inside one stage of it? How does the AI learn and persist the institutional knowledge of the organization’s specific environment, and what happens to that knowledge when analysts leave?

Can the team audit every agent action with a defensible reasoning trace, and can it govern agent autonomy in stages as trust builds? A vendor that cannot give clear answers to all three is selling first-wave AI, no matter what the marketing says. What is the agentic SOC, and how is it different from a SOAR or AI co-pilot? The agentic SOC is the category of security operations platform where AI agents operate as decision-makers across the SOC lifecycle, not as assistants inside a single product.

A SOAR automates predefined workflows using static playbooks. An AI co-pilot accelerates an analyst’s individual tasks. An agentic SOC runs agents that reason through investigations, surface and tune detections, threat hunt continuously, and remediate inside customer-defined guardrails, all while sharing context across stages. Analysts move from “in the loop” on every step to “on the loop” overseeing the system.

How quickly can a SOC move from first-wave AI to second-wave AI? Faster than most teams assume. The shift is architectural, not a rip-and-replace. The connective layer that turns point AI into agentic fabric does not require buying new tools or replacing existing ones.

It requires connecting what the SOC already owns into a system that compounds. Most SOCs underestimate how quickly the shift can be made once the architecture is in place. Found this article interesting? This article is a contributed piece from one of our valued partners.

Hackers Exploit Critical Everest Forms Pro WordPress Plugin Flaw to Take Over Sites

Threat actors are actively exploiting a critical security flaw in Everest Forms Pro, a WordPress plugin with about 4,000 active installations, to execute arbitrary code, leading to a complete site compromise. The vulnerability in question is CVE-2026-3300 (CVSS score: 9.8), a remote code execution bug impacting all versions of the plugin up to, and including, 1.9.12. A patch for the flaw was released on March 18, 2026, with version 1.9.13. “This is due to the Calculation Addon’s process_filter() function concatenating user-submitted form field values into a PHP code string without proper escaping before passing it to eval(),” Wordfence said .

“The sanitize_text_field() function applied to input does not escape single quotes or other PHP code context characters. This makes it possible for unauthenticated attackers to inject and execute arbitrary PHP code on the server by submitting a crafted value in any string-type form field (text, email, URL, select, radio) when a form uses the ‘Complex Calculation’ feature.” Successful exploitation of the vulnerability could allow unauthenticated bad actors to execute arbitrary PHP code on the server, permitting them to create rogue administrator accounts, deploy web shells, and open other ways to burrow deeper into the server and establish persistent footholds. According to the WordPress security company, attackers have been observed exploiting the flaw starting April 13, 2026. More than 29,300 exploit attempts targeting the defect have been blocked to date.

Of these, 16 attack attempts occurred in the last 24 hours. The most common payload involves attempts to create an administrator account named “diksimarina” (email address: diksimarina@gmail.com) on the compromised site. These attack efforts have originated from the following IP addresses - 202.56.2.126 209.146.60.26 15.235.166.18 2402:1f00:8000:800::40db 185.78.165.153 Skimmer Attacks Exploit Stripe for C2 The disclosure comes as Sansec warned of multiple skimmer campaigns, including one that uses Stripe as a command-and-control (C2) server and a data exfiltration sink in a bid to exploit the reputation of the brand and slip past Content Security Policy rules and network filters. “The attacker treats Stripe as free infrastructure, not a way to launder charges,” Sansec noted .

“Stripe gives them a writable database for stolen cards and a code-hosting endpoint for the skimmer, both behind a domain that CSP rules and network filters trust by default.” The campaign relies on Google Tag Manager (GTM) and Stripe domains - googletagmanager.com and api.stripe.com - which are both trusted implicitly by online stores, with the malicious code loaded from a GTM container and executed on every page that loads it. On Magento and Adobe Commerce checkout pages, it extracts an obfuscated skimmer from a Stripe customer account ‘s (“cus_TfFjAAZQNOYENR,” in this case) metadata field, and saves the financial information, billing and email addresses, and phone numbers entered by unsuspecting users to localStorage . The captured data is then exfiltrated back to the attacker’s Stripe account. “Every stolen card becomes a ‘customer’ in the attacker’s account,” the e-commerce security company said.

“On success, the loader deletes the localStorage entry, so the same record is not sent twice. The attacker lists their stolen cards later by calling the same API with the same key. Stripe’s customer database becomes a free, durable exfiltration sink.” The Stripe customer record containing the skimmer is said to have been created on December 24, 2025, indicating that the operation may have been active since then. Sansec said it also identified a second variant of the loader that uses Google Firestore instead of Stripe, although the end goal is the same: abuse a trusted service as a covert channel that’s unlikely to be blocked by e-commerce stores.

The findings coincide with a large-scale operation dubbed GorgonAgora that has used a cluster of 5,714 fake .shop storefronts impersonating brands like Starbucks, Ford, Sony, Mattel, Hasbro, Lego, Disney, and Toyota, whose checkout pages funnel stolen card data to a single skimmer server in Moldova. The campaign has been ongoing since August 2025. “Every store runs the same Medusa.js commerce stack and loads the same custom checkout SDK, which renders a fake Stripe iframe and exfiltrates card data over an encrypted WebSocket to a single server in Moldova,” the Dutch company said. “Exfiltration runs over WebSocket with an AES-256-GCM payload, and the C2 maintains a live 3D Secure relay: when the victim bank returns a 3DS challenge, the operator proxies it back to the shopper through the fake iframe so the transaction completes and the theft stays invisible.” Found this article interesting?