2026-06-22 AI创业新闻

AryStinger Malware Infects 4,300 Legacy Routers to Build Reconnaissance Proxy Network

A new malware family is turning forgotten home routers into a distributed reconnaissance and proxy network, not the DDoS botnet these devices usually end up in. QiAnXin’s XLab calls it AryStinger and counts at least 4,300 infected routers, a total it says is still rising. The distinction matters. AryStinger exists for the stage of an attack that comes before the break-in.

Infected devices scan the internet, fingerprint services, enumerate subdomains, tunnel traffic, and run commands on demand, then ship the results back to the operator. Each router becomes a footprinting node and a relay that hides where the real attacker is. Old chips, older bugs The campaign goes after routers built on Realtek’s RTL819X chips, hardware that was current around 2012 to 2015. XLab first saw it on March 12, 2026, spreading from a single IP, 107.150.106.14.

The binary it pushed was a Linux ELF that no engine on VirusTotal flagged, exploiting two flaws from another era: CVE-2013-3307 in Linksys models and CVE-2016-5681 in D-Link ones. The infected pool is mostly D-Link, with the DIR-850L alone making up about 75 percent. By geography, it skews to South Korea (around 48 percent) and China (around 32 percent), then Sweden, Malaysia, and Singapore. A second strain appeared on April 26, aimed at QNAP NAS boxes through CVE-2025-11837, a code injection flaw in QNAP’s Malware Remover .

The bug was shown at Pwn2Own Ireland 2025 and patched in November 2025, months before this strain began using it. The way in is the appliance’s own malware-removal tool. XLab hasn’t measured the NAS infections, so the 4,300 figure covers RTL819X routers only. Two builds, same job One build is lean, and one is fuller.

The router build is written in C and kept light, because the old hardware can’t run more, so it sticks to mass DNS scanning and traffic tunneling. The NAS build is written in Go and does much more. It scans internal and external networks and runs recon tools like fscan, ksubdomain, and httpx. A “ScriptWork” task executes attacker-supplied Go, Java, or Python source code on the box, so the operator never has to compile a binary per target.

Each infected node, which XLab calls an Executor, talks to its C2 over HTTP/HTTPS, with Protobuf-encoded traffic obfuscated by a simple XOR (the Go build adds gzip). The operator splits a large scan into chunks and spreads them across the fleet, footprinting in parallel. XLab says the same DNS scanning can be aimed at resolvers to generate denial-of-service traffic. Persistence comes from a Dropbear SSH server on a fixed port, 2332 on routers, or gs-netcat on NAS.

The hardcoded key, sh_#@!_2024_secret, carries a “2024” that may point to a 2024 start, though XLab can’t confirm it. Where this fits The shape is familiar. In May 2025, the FBI and Justice Department tore down the 5socks and Anyproxy services , which had turned years-old Linksys and Cisco routers running TheMoon malware into residential proxies sold by the month. The espionage version looks much the same.

Mandiant has tracked operational relay box networks , or ORBs: meshes of compromised end-of-life routers and IoT that state actors use to scan and relay while staying hard to trace. Recent router ORBs like LapDogs farm devices through n-day bugs the way AryStinger does. AryStinger isn’t pinned to anyone yet, and XLab says it’s still working on who is behind it. What’s clear is the model: forgotten hardware, ancient CVEs, turned into quiet infrastructure for the opening moves of an intrusion.

What to do If you run any of the affected gear, the checks are simple. Look for outbound connections to AryStinger’s C2 and download domains (the ajb8.com and related hosts in XLab’s IOC list ), check /tmp/bin for binaries you didn’t put there, and look for processes named syswapd0h or syswapd0w. The durable fix is the one everyone keeps repeating: retire end-of-life routers that no longer get firmware, and turn off remote administration on anything exposed. A box that stopped getting patches in 2016 is not going to start now.

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

INTERPOL Warns Phishing, Ransomware, and AI Scams Are Rising Across Asia-Pacific

A new report from INTERPOL has revealed a “dramatic increase” in cybercrime in Asia and the South Pacific, fueled by rapid digitalization, internet penetration, new technologies, organized criminal networks, and a disparity in cybersecurity maturity. According to INTERPOL’s 2025/2026 Asia and South Pacific Cyberthreat Assessment Report, phishing has emerged as the most widespread and financially damaging form of cybercrime, with a third of countries in the region reporting more than 10,000 cases between January 2024 and March 2025. In all, over half of INTERPOL member countries have reported that cybercrime accounted for no less than 30% of all crimes recorded nationally. “The findings in this report highlight a rapidly evolving cyber threat landscape across Asia and the South Pacific, where cybercriminals are leveraging artificial intelligence, ransomware-as-a-service models and sophisticated social engineering techniques on an industrial scale,” Neal Jetton, INTERPOL Cybercrime Director, said in a statement.

“As digital adoption accelerates across the region, strengthening operational cooperation, information sharing, and cyber resilience remains essential to protecting communities and critical infrastructure.” The growing sophistication of cybercriminal tradecraft has led to a surge in ransomware attacks, as well as deepfake and artificial intelligence (AI)-driven scams that involve impersonating business executives to authorize fraudulent transactions. The region is estimated to have registered more than 135,000 ransomware-related attacks in 2024. A vast majority of the incidents impacted the real estate, manufacturing, and financial services sectors. This has been complemented by the industrialization of cyber-enabled scams by transnational organized crime syndicates in countries like Cambodia, Laos, Myanmar, and the Philippines, who have set up extensive scam centers that make use of forced labor to carry out investment scams, preying on people across the world after building friendly or romantic relationships with them.

“Organized crime in Myanmar, Cambodia, and Laos used deepfakes in ‘romance baiting’ scams, blending AI personas and social engineering to fuel $37 billion in regional cybercrime losses,” INTERPOL said. Some of the other regional trends captured by the report include the following - Banking trojans and information stealers materialized as the second most prevalent type of cybercrime, with malware families like RedLine , Lumma , LokiBot , Negasteal , and ZBot taking up the top spots. 5.5 out of every 1,000 individuals in the Asia and South Pacific region clicked on phishing links monthly, nearly double the global average of 2.9 per 1,000. Distributed denial-of-service (DDoS) attacks surged by 92% in 2024 compared to the previous year.

System intrusions accounted for approximately 80% of all data breaches in 2024. Use of deepfake technology for sexual exploitation, blackmail, or coercion. Exploitation of misconfigured systems, weak encryption, insecure APIs, and insufficient monitoring to breach target networks. Ransomware groups weaponize companies’ regulatory obligations to intensify pressure during extortion attempts.

“In response, law enforcement organizations across the region – supported by INTERPOL – are scaling up joint efforts to combat cybercrime,” INTERPOL said. “These include the coordination of operations against cybercriminal infrastructure, collaborative investigations, specialized training initiatives, and the creation of policies to improve cyber resilience.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Hackers Exploit Gravity SMTP WordPress Plugin Bug to Expose API Keys

Threat actors are exploiting a recently patched security flaw impacting Gravity SMTP, a WordPress plugin that’s installed on about 100,000 sites. The vulnerability, tracked as CVE-2026-4020 (CVSS score: 5.3), is a medium-severity information disclosure flaw that can allow unauthenticated attackers to extract sensitive data, such as configuration data, API keys, secrets, and OAuth tokens configured for the plugin’s email integrations. “This is due to a REST API endpoint registered at /wp-json/gravitysmtp/v1/tests/mock-data with a permission_callback that unconditionally returns true, allowing any unauthenticated visitor to access it,” Wordfence said . “When the ?page=gravitysmtp-settings query parameter is appended, the plugin’s register_connector_data() method populates internal connector data, causing the endpoint to return approximately 365 KB of JSON containing the full System Report.” As a result, an unauthenticated attacker can weaponize this issue to retrieve a wide range of information, including - PHP version Loaded extensions Web server version Document root path Database server type and version WordPress version All active plugins with versions Active theme WordPress configuration details Database table names API keys/tokens configured in the plugin, such as Amazon SES, Google, Mailjet, Resend, and Zoho Attackers could then leverage this exposure to harvest credentials that could be abused to send email on behalf of the site, as well as glean extensive details of the site’s software stack, which could act as a foundation for follow-on attacks.

“As with all sensitive information exposure vulnerabilities, the impact depends on what data is exposed,” Wordfence added. “In this case, the exposure of live third-party API credentials means an attacker could abuse the site’s connected email services, while the detailed system report significantly lowers the effort required to plan further attacks against the site.” A patch for the vulnerability has been released in version 2.1.5 of the plugin. Bad actors have already pounced on the defect by sending unauthenticated HTTP GET requests to the vulnerable REST API endpoint with the “?page=gravitysmtp-settings” query parameter, causing the server to return valuable information about the site without requiring any authentication. Wordfence has blocked more than 17 million exploit attempts targeting CVE-2026-4020 to date, with initial activity commencing at the start of May 2026 before spiking up dramatically around June 6, 2026, touching a high of over 4,000,000 requests a day later.

The exploit efforts have originated from the following IP addresses - 45.148.10.95 193.32.162.60 176.65.148.139 173.199.90.188 45.148.10.120 185.8.107.155 185.8.106.37 185.8.106.92 185.8.106.145 176.65.148.30 Site owners running a vulnerable version of the Gravity SMTP plugin and have configured third-party email integrations should assume compromise, and rotate the credentials after updating the plugin to the latest version as soon as possible. It’s also advised to review server log files for requests originating from the aforementioned IP addresses for any suspicious requests to the API endpoint. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Unpatchable ‘usbliter8’ Exploit Breaks Apple A12 and A13 SecureROM Boot Chain

Security researchers at Paradigm Shift have published a working exploit, dubbed usbliter8 , that achieves arbitrary code execution inside the SecureROM of Apple’s A12 and A13 chips. That code is burned into the silicon at manufacture. No software update can reach it. Affected devices will carry this flaw for as long as they stay in use.

This is not a remote attack. It requires physical possession of the device, which must be in DFU mode and connected via USB to a dedicated RP2350-based microcontroller board. With that setup, the exploit finishes in under two seconds, before Apple’s signed boot chain loads. The full technical write-up and a working proof of concept went public on June 18, 2026, following coordinated disclosure with Apple Product Security.

Affected Devices The public PoC supports A12, A13, S4, and S5 SoCs. A12X and A12Z support is described as theoretically possible but not yet implemented. Device families in that range include the iPhone XS, XS Max, and XR; the iPhone 11, 11 Pro, 11 Pro Max; the iPhone SE (2nd generation); the iPad Air 3rd gen, iPad mini 5th gen, and iPad 8th gen; Apple Watch Series 4 and 5; the first-generation Apple Watch SE; the HomePod mini; and other Apple products built on those chips. A11 is not affected.

A14 and later appear to be out of reach for this exploit path. The Bug The root issue is a hardware flaw in the Synopsys DWC2 USB controller. The controller stores incoming USB Setup packets via DMA, buffers up to three, then resets its write pointer on the fourth by decrementing it by a fixed 24 bytes. It also accepts smaller-than-standard packets, incrementing the pointer only by the actual bytes written.

That mismatch accumulates into a repeatable buffer underflow, stepping the write pointer backwards through memory 12 bytes at a time. What makes this exploitable on A12 and A13 is how Apple configures the USB DART (Device Address Resolution Table, the chip’s IOMMU) inside SecureROM. On affected devices, it runs in bypass mode, so the underflowing DMA pointer can reach and overwrite arbitrary SRAM. A11 is not affected because its USB driver manually resets the DMA address after every packet, so the mismatch never accumulates.

A14 and later appear to configure DART correctly, which Paradigm Shift says makes the vulnerability unexploitable on newer hardware. Getting Code Execution On A12, the DMA buffer sits adjacent to the USB task’s stack on the heap. Overwriting a saved link register hands the attacker program counter control on the next context switch. A13 is harder.

Pointer Authentication (PAC) protects stack-stored return addresses. Paradigm Shift bypassed it in stages. Corrupting DART-related heap structures created limited write primitives. Overwriting the panic depth counter made the chip loop on errors instead of rebooting.

Careful DMA write timing avoided clobbering the USB task’s saved registers. The final step overwrote the USB interrupt handler pointer in BSS. The next USB interrupt then ran attacker-supplied code. Either path ends with execution at EL1, the chip’s privileged mode, inside SecureROM.

What an Attacker Gets Post-exploitation, usbliter8 injects a custom USB request handler and stamps PWND:[usbliter8] into the device’s USB serial string. From there, an attacker can temporarily demote the SoC’s production mode or boot a raw, unsigned iBoot image with no signature checks, stepping outside Apple’s chain of trust entirely. The research does not show a Secure Enclave compromise. Apple’s Secure Enclave is designed as a separate protection boundary, isolated from the application processor.

Paradigm Shift warns that BootROM-level control may open new routes for attacking it. No Software Patch The closest public precedent is checkm8 , the 2019 SecureROM exploit that permanently put A5-through-A11 devices outside Apple’s patch authority. Like checkm8, usbliter8 requires physical access and DFU mode and cannot be closed with a firmware update. usbliter8 extends that condition to the next chip generation.

As of June 19, 2026, no CVE, CVSS score, Apple security advisory, or CISA alert had been issued, and no in-the-wild exploitation had been publicly reported. For most users, the practical risk is low: an attacker needs the physical device, the right cable, and the knowledge to force DFU mode. For high-security environments, this is now a hardware-retirement and device-custody problem. If a device runs one of the affected chips, the physical boundary is permanently gone; safety depends on controlling when and where the device can be plugged in.

Inventory A12, A13, S4, and S5 hardware in sensitive roles, prioritize refreshes toward A14 or newer, and avoid DFU mode over untrusted USB cables or hosts. The code is public. That is usually how exploit research stops being a demo and starts being someone else’s tool. Found this article interesting?

The Gentlemen RaaS Uses GentleKiller EDR Framework Targeting 400 Security Processes

The Gentlemen ransomware-as-a-service (RaaS) operation is actively developing and maintaining a suite of endpoint detection and response (EDR) killers that it hands out to affiliates for impairing system defenses before deploying the encryptor. This mature portfolio of EDR-terminating tools is centered around a framework that’s known as GentleKiller . “They also incorporate third-party or leaked tools such as HexKiller, ThrottleBlood, and HavocKiller,” ESET security researcher Jakub Souček said in a report shared with The Hacker News. “These tools are standardized through a shared defense-evasion layer, impersonating predominantly security vendors using fake version information, and copied legitimate certificates and icons.” The Slovakian cybersecurity company also called out the ransomware crew for its ability to “unusually quickly operationalize” newly disclosed proof-of-concept (PoC) exploits related to an attack technique called bring your own vulnerable driver ( BYOVD ), in many cases within days of their public release.

Since its emergence in March 2025, The Gentlemen has swiftly risen up the ranks and made a name for itself as one of the most active ransomware groups. Per data from Ransomware.live, the group has claimed 504 victims to date , with most of them located in Southeast Asia, South America, and Western Europe. Recent reports from cybersecurity journalist Brian Krebs and PRODAFT have revealed that a 36-year-old Russian national named Alexander Andreevich Yapaev (aka hastalamuerte) has been leading the operation, after acting as an affiliate for other ransomware schemes, including Qilin. ESET has described The Gentlemen as one of the most technically agile RaaS groups, using a set of techniques to ensure that the compiled EDR killer samples sidestep detection.

This includes binary protection using Enigma or Themida and using file names that resemble well-known cybersecurity vendors, right down to their version information, digital signatures, and icons. The most prevalent of them is GentleKiller, which comes in eight different variants, each mimicking a different legitimate product and abusing a different vulnerable or malicious driver as part of the BYOVD attack. GentleKiller specifically looks for 400 processes associated with 48 distinct security programs from a number of vendors. The list of drivers exploited by each of the variants is as follows - Kaspersky (“eb.sys”) FACEIT Anti-Cheat (“nseckrnl.sys”) Valorant (“GameDriverX64.sys”) Javelin (“stpm_old.sys” or “stpm_new.sys”) WatchDog (“dmx.sys”) Network Blocker (“360netmon_wfp.sys”) Cleaner (“IMFForceDelete.sys”) G11 (“PoisonX.sys”) It’s worth noting that the abuse of “PoisonX.sys” has been recorded in recent months in connection with various BYOVD attacks, one of which was used to kill CrowdStrike Falcon EDR .

A second campaign, detailed by Huntress, involved an intrusion in which unknown threat actors leveraged BeyondTrust Remote Support to successfully deploy ransomware on the network, but not before terminating security tooling via “PoisonX.sys” and “hrwfpdrv.sys.” “When abstracting away the impersonation layer and the specific drivers used, the underlying code reveals numerous structural and behavioral commonalities that strongly suggest the use of a shared development template,” Souček said. “This design prioritizes ease of deployment and operational flexibility for affiliates, while minimizing development effort for the operators. It allows The Gentlemen operators to integrate abused drivers into their toolset very soon after an EDR killer PoC is disclosed.” The third-party, BYOVD-based EDR killers employed by the group are below - HexKiller (“googleApiUtil64.sys”), a tool previously assumed to be exclusive to the Warlock ransomware gang ThrottleBlood (“ThrottleBlood.sys”), a tool observed in attacks mounted by MedusaLocker and DragonForce affiliates HavocKiller or HwAudKiller (“havoc.sys”) ESET said it also detected a Rust-based credential stealer codenamed OxideHarvest (aka buildx641) that’s capable of harvesting data from popular web browsers, including Google Chrome, Microsoft Edge, Torch, Comodo, Epic Privacy Browser, Vivaldi, Brave, Opera, OperaGX, Mozilla Firefox, Waterfox, BlackHawk, and IceCat. “While most ransomware gangs continue to delegate EDR killing to affiliates, Gentlemen has chosen to centralize this function by offering affiliates a ready-to-use, standardized EDR-killer suite,” ESET said.

“This decision makes Gentlemen an attractive operator for affiliates as it materially lowers the entry barrier for them, making their job consequently easier.” The disclosure comes as the CERT Coordination Center (CERT/CC) issued an advisory about multiple vendor-signed UEFI applications being vulnerable to Secure Boot bypass via a BYOVD attack. ESET researcher Martin Smolár has been credited with researching and reporting the vulnerability. The impacted applications are from Acer, AMD, ASUS, ECS, Getac, GIGABYTE, Toshiba, and Uniwill. “If a target system trusts the affected vendor’s certificate, an attacker [with administrative privileges or physical access] can exploit these applications to execute arbitrary code during the early pre-boot phase before the operating system initializes,” CERT/CC said .

“To mitigate this risk, system administrators should apply updates to the UEFI Forbidden Signature Database (DBX) that revoke trust in the affected vendor-signed binaries, preventing these vulnerable applications from executing during the boot process.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

AutoJack Attack Lets One Web Page Hijack AI Agent for Host Code Execution

Microsoft researchers have detailed an exploit chain, named AutoJack , that turns an AI browsing agent into a delivery vehicle for remote code execution. Steer the agent to load an attacker’s web page, and that page’s JavaScript can reach a privileged local service on the same machine and spawn a process on the host. No credentials, no sign-in screen, and no further user interaction once the agent loads the page. The attacker only has to get the agent to open it, and a planted link, a URL field, or a prompt injection will do.

The flaw sits in AutoGen Studio , the open-source prototyping interface for Microsoft Research’s AutoGen multi-agent framework. This is not a bug that hits everyone who installs the package, and the packaging detail is worth getting right. A plain pip install autogenstudio pulls the current stable release, 0.4.2.2, the build Microsoft inspected, and it has no Model Context Protocol (MCP) route at all. That is the basis for Microsoft’s statement that the vulnerable MCP WebSocket surface “was never included in a PyPI release.” It holds for the stable build.

But the vulnerable handler did ship to PyPI, in two pre-release builds, 0.4.3.dev1 and 0.4.3.dev2. The Hacker News downloaded and inspected both. The MCP WebSocket route is present, the handler takes the command to run straight from the request, and it does not authenticate the caller. Neither build has been yanked.

pip does not install pre-releases unless you pass –pre or pin the version, so a plain install was never exposed. Anyone who installed one of those pre-releases was. There is still no PyPI build carrying the main-branch hardening for them; the fixed code is in GitHub main at commit b047730. How the chain works AutoJack chains three weaknesses in the MCP WebSocket.

First, the socket trusted localhost, a check meant to block a normal browser pointed at a malicious site. But a browsing agent running on the same box is localhost, so anything it loads inherits that localhost identity and passes the check. Second, the authentication middleware skipped MCP paths on the assumption that the handler would verify tokens itself. It never did, so the socket accepted unauthenticated connections regardless of the configured auth mode.

Third, the endpoint took a command straight from a request parameter and ran it, with no allowlist on which executable could launch. Put together, a page on the open internet, rendered by a local agent, could run an attacker-chosen command under the account running AutoGen Studio. Microsoft describes this as research, not an active campaign, and reported no exploitation in the wild. The proof of concept used a “Web Content Summarizer” agent that, when fed an attacker URL, pops calc.exe on the developer’s desktop, launched by the AutoGen Studio process.

Microsoft reported the behavior to the Microsoft Security Response Center, and the maintainers hardened the main branch in commit b047730 (PR #7362). The fixed handler no longer reads the command from the URL; parameters are stored server-side behind a one-time session ID, and unknown IDs are refused. MCP routes now run through the normal authentication path. That hardening has not landed in a PyPI release yet.

What to do A plain pip install autogenstudio gives you 0.4.2.2, which has no MCP route, so you are not affected. If you installed a pre-release, you have the vulnerable handler and no patched PyPI build to move to. Pull from GitHub main at or after commit b047730. That is the real fix.

Until there is a release, separate the pieces the attack needs. Do not run AutoGen Studio on the same machine as a browsing or code-execution agent that touches untrusted content, because the chain only works when both share the same localhost. If they have to run together, isolate them in separate containers or VMs and run AutoGen Studio under a low-privilege account. The AutoGen Studio bugs are patched in the source.

The pattern is not. Microsoft expects the same shape in other agent frameworks: a local service with too much power, a localhost check treated as security, and an agent that opens untrusted pages. THN saw it last month in ChatGPhish , where ChatGPT’s page summaries became a phishing vector. Microsoft made a similar localhost argument in its Semantic Kernel RCE research , tracked as CVE-2026-26030 and CVE-2026-25592.

Another localhost check is not enough. Authenticate the control plane, keep process execution behind an allowlist, and give the agent an identity that is not the developer’s own session. Once an agent can browse the open web and reach privileged local services, localhost is no longer a trust boundary. Found this article interesting?

Operation Endgame Disrupts SocGholish Servers, Cleans 14,971 WordPress Sites

Dutch law enforcement authorities, along with counterparts from Canada , Germany, and the U.S., have disrupted malicious infrastructure associated with SocGholish and cleaned up nearly 15,000 infected WordPress websites. “With these actions we deprive cybercriminals of access to infected computer systems,” Maikel Rollman of the Netherlands National High Tech Crime Unit said . “This prevents further damage to the digital systems of citizens, businesses and organizations worldwide and limits the spread of malware. It also reduces the risk that these systems are used for cyber attacks on critical infrastructure and other essential societal processes.

This marks the beginning of further action against SocGholish.” The takedown is part of Operation Endgame , an ongoing international law enforcement initiative to combat botnets and associated criminal infrastructures. It was launched in 2024. As part of the effort, 106 servers linked to SocGholish have been taken down and 14,971 WordPress sites have been rid of the infections. Website owners have been notified to update their content management system (CMS), change their credentials, and delete any suspicious accounts.

Active since 2017 and also known as FakeUpdates, SocGholish is a JavaScript (JS)-based downloader malware that typically serves as a conduit for next-stage malware from various threat actors like Evil Corp (aka DEV-0243, Indrik Spider, and UNC2165), LockBit, RansomHub, Dridex, and Raspberry Robin (aka Roshtyak). “The malware establishes an initial foothold into victim computers, collectively known as a botnet, and is then used by threat actors for further targeting with ransomware campaigns and espionage,” the U.S. Federal Bureau of Investigation’s (FBI) Cyber Division said in a post shared on LinkedIn. It’s distributed via compromised websites by masquerading as deceptive updates for web browsers like Google Chrome or Mozilla Firefox, and other popular software.

The operators of the malware have been tracked under various aliases, such as Gold Prelude, Mustard Tempest, Purple Vallhund, TA569 and UNC1543. “SocGholish infections typically originate from compromised websites that have been infected in multiple different ways,” Silent Push noted in an analysis of the malware last year. “Website infections can involve direct injections, where the SocGholish payload delivery injects JS directly loaded from an infected webpage or via a version of the direct injection that uses an intermediate JS file to load the related injection.” In November 2025, Arctic Wolf revealed that SocGholish was being used by the RomCom threat actors to deliver the Mythic Agent, highlighting the use of the initial access broker’s services by a broad range of actors with varied motivations. IP-geolocated SocGholish compromised WordPress sites per country Orange Cyberdefense said it has observed SocGholish infections delivering loaders like Gholoader (another JavaScript-based loader) and MintsLoader , which, in turn, lead to the deployment of additional payloads like GhostWeaver, LockBit, AsyncRAT, and NetSupport RAT.

“SocGholish uses a layered delivery model and has been observed enabling multiple categories of follow-on payloads,” the cybersecurity company said , adding the threat actor also collaborates with traffic distribution system (TDS) operators like TA2726. TDS is a technology used to route site visitors to different destinations based on different factors. This can range from compromised or fake login websites hosting phishing pages to bogus sites that prompt users to download software updates containing malware, which can then obtain access to victim networks for ransomware or other financial scams. “Cybercriminals use TDS to bypass traditional firewall rules that would otherwise block connections to malicious websites, and to analyze potential victims for targeting by collecting their IP address, operating system, location, device, and browser information,” the FBI said .

“After driving users to a TDS, often through various social engineering techniques, cybercriminals can exploit users’ devices at the end of the TDS redirection chain by delivering phishing pages, financial scams, and other malware.” Many of the compromised WordPress instances have been modified to include criminal infrastructure operated by SocGholish, according to the Shadowserver Foundation. The vast majority of the hacked sites were located in the U.S., followed by Germany, France, India, Brazil, Singapore, Italy, Indonesia, Canada, and Vietnam. “The abuse also includes the use of a process known as ‘Domain Shadowing,’” the non-profit said . “This is a technique where a threat actor gains access to the authoritative DNS provider or registrar account panel for a legitimate domain, and uses their access to quietly create additional subdomains beneath the main (‘apex’) domain.” “These malicious subdomains are often given common host names that hide in plain sight and blend in with the domain owner’s legitimate DNS infrastructure, but will point to criminal-operated external malicious infrastructure – effectively piggybacking on a domain’s established reputation and making it harder for defenders to easily detect or block illicit activity.” A simplified view of affiliates that drive potential victims to SocGholish What’s more, the infected websites are frequently exploited by multiple threat actors, exposing unsuspecting site visitors to a sophisticated cluster of potential threats.

The malicious behavior exhibited by these sites is dictated by various crucial factors, including the user’s country of origin, the type of browser being used, and the underlying operating system. “TA569 indiscriminately compromises websites and is opportunistic, although sites with higher traffic numbers lead to more victims,” Proofpoint said . “The actor has also compromised websites in virtually every industry, from nonprofits and schools, to healthcare and hospitals, to legal and real estate organizations.” DNS threat intelligence firm Infoblox described SocGholish as a multi-stage JavaScript framework that converts compromised websites into drive-by download malware delivery vehicles. The framework is enabled by four main steps: traffic acquisition, traffic filtering, payload lures, and on-device implant execution.

“TA569 compromises a very large number of websites themselves,” it said . “But they also accept traffic from affiliates. It’s a classic commercial relationship: when a user visits the site, the affiliate typically fingerprints them and then passes potential victims to SocGholish through an embedded link. In return, the affiliate will be paid for these ‘leads.’” Some of the prominent affiliates that have sold traffic to the SocGholish framework over the years include TA2726, Parrot TDS , and JunkyTDS.

Threat actors have also employed commercial offerings like Keitaro and zTDS to filter traffic for redirection to SocGholish, or sending them to the original website or any other content if the visitor to the compromised site does not match the criteria. Data from Infoblox shows that approximately 55% of its cloud customers attempted to reach SocGholish infrastructure this year alone, with the attacks targeting almost “every industry sector” over the past five months. Some of the most targeted verticals included government, education, banking, healthcare, non-IT services, financial services, IT consulting, utilities, insurance, and transportation. “This distribution […] reinforces that SocGholish is not a niche threat limited to one vertical,” the company said.

“Instead, its large-scale webinject and TDS ecosystem reaches into both public-sector and commercially important environments, making it a broadly relevant threat across our customer base.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

CISA Warns Fortinet Customers as FortiBleed Hits 86,644 FortiGate Devices

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday urged Fortinet customers with FortiGate appliances to take steps to secure against ongoing malicious activity aimed at thousands of internet-accessible devices. The sweeping campaign, believed to be the work of Russian-speaking threat actors, has been codenamed FortiBleed . The number of compromised devices stands at 86,644 as of June 19, 2026.

According to data from SOCRadar, generic admin accounts (35%) and built-in Fortinet system accounts (28.3%) together make up the majority of compromised credentials. Organization-specific accounts account for 36.7% of the remaining breached credentials. “This points directly to a widespread failure to rename default accounts or rotate factory credentials, giving the attacker a highly reliable target list before any brute force was even needed,” SOCRadar said. “Org-specific accounts topping the list is significant.

It means the attacker is not just harvesting default credentials but has also successfully compromised accounts created by the organizations themselves, possibly sourced from prior breaches where passwords were never changed.” Telecom, government, and education have emerged as the top three impacted sectors, with the most exposures located in India, the U.S., Mexico, Colombia, and Thailand. The threat actor is said to have mass-scanned the internet for Fortinet remote login endpoints, and then employed a bespoke tool to spray those identified endpoints with known login and password combinations in an attempt to break into them. The fully-automated attack is built around a self-sustaining, two-step approach - The threat actor attempts a curated list of leaked Fortinet passwords against devices across the internet. Once access is obtained, they passively monitor network traffic going through the devices to collect additional credentials, which are then used to compromise more appliances.

The credentials are legitimate and valid, with the attackers verifying each of them before they are added to a database of confirmed, working logins. “The scale of this breach touches nearly every sector of the global economy, sparing no industry,” Hudson Rock said . “The threat actors have built a verified database of working credentials for some of the largest enterprises on the planet.” The U.K. National Cyber Security Centre (NCSC) has described FortiBleed as a global campaign targeting internet-facing Fortinet firewalls and VPN gateways using methods like brute-force, dictionary attack, and credential stuffing.

It’s suspected that the threat actors likely exploited older credential hashing mechanisms and the way credentials have historically been stored within FortiGate configuration files to pull off the large-scale attack. “Fortinet introduced PBKDF2-based password hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing the legacy SHA-256-based storage mechanism,” Arctic Wolf said . “However, when upgrading from earlier versions, existing administrator passwords remain stored as SHA-256 hashes until the corresponding administrator successfully logs in following the upgrade.” “As a result, many organizations likely continue to store administrator credentials using older SHA-256 with Salt hashing mechanisms.” In a statement shared with The Hacker News, a Fortinet spokesperson said “the data involved is likely a resharing of data from previous incidents, as well as brute-forcing of credentials, and not related to any current incident or advisory,” urging organizations to follow best practices, including regularly rotating security credentials and enabling multi-factor authentication (MFA). CISA has outlined the following recommendations to defend against the activity - Terminate all active SSL VPN and administrative sessions, reset all Fortinet VPN and administrative passwords, especially on internet-facing systems, and enforce strong password policies.

Ensure use of the Password-Based Key Derivation Function 2 ( PBKDF2 ) algorithm to store administrator credentials and remove weaker legacy hashes. Review firewall, VPN, authentication, and domain controller logs for signs of suspicious actions, including unauthorized configuration changes. Enable phishing-resistant MFA on all external gateways and administrative interfaces. Reduce the attack surface and lock down management.

The FortiBleed incident first came to light last week after security researcher Volodymyr “Bob” Diachenko discovered a server containing the database of working login credentials for thousands of firewalls and VPN gateways across 194 countries. Per SOCRadar, the server also staged the attacker’s tools and automation scripts. The findings once again demonstrate how credential reuse and poor password hygiene can be weaponized by malicious actors, not to mention that perimeter security appliances remain a lucrative target for gaining initial access to enterprise environments. Update In a post shared on June 19, 2026, Fortinet said the FortiBleed campaign likely involves the threat actors reusing credentials from previous incidents, such as CVE-2026-24858 , CVE-2025-59718, and CVE-2025-59719 , along with employing brute-force techniques against devices with weak password hygiene and no multi-factor authentication (MFA).

To defend against the malicious activity, the company has outlined the following recommendations - Terminate all admin and VPN sessions and reset credentials. Implement MFA. Upgrade to the latest versions of 7.4, 7.6, or 8.0. Review firewall and VPN users and other configurations for unauthorized changes.

Audit logs for unexpected administrator access from an unknown IP address, as well as for lateral movement, unusual access, suspicious accounts, or unauthorized configuration changes. Restrict external management via trusted hosts (good), a local-in policy (better), or remove internet administration altogether (best). “If AD/LDAP integration is configured, it is important to treat this account as compromised and monitor your AD for its use for authentication elsewhere or the creation of additional accounts and monitor your network for lateral movement,” Carl Windsor, chief information security officer (CISO) at Fortinet, said. Found this article interesting?

From Assistive to Agentic: The AI Shift That’s Redefining Threat Management

Introduction The average enterprise security team has 40 or more security tools, giving a lot of visibility into internal telemetry and asset data. But often, these tools are working in siloes, generating (overlapping) alerts and data. And yet, breach dwell times remain stubbornly long (~43 days), response windows keep closing before teams can act, and analysts burn out triaging noise instead of stopping threats. The problem isn’t effort.

It’s architecture. Security programs were built for a world where threats moved slowly enough for humans to coordinate responses manually. That world no longer exists. With the way AI capabilities are getting developed and used, especially with frontier AI tools, a much more proactive stance to security is needed as well as machine speed response to combat fast moving adversaries.

Gartner’s Continuous Threat Exposure Management (CTEM) framework helps this shift from reactive, point-in-time assessments to a continuous, iterative cycle of scoping, discovery, prioritization, validation, and mobilization. But for most organizations, operationalizing CTEM end-to-end has remained out of reach, because the tools needed to do it still don’t talk to each other. The Architecture Problem Behind Every Security Gap Modern security stacks are collections of specialized tools: a threat intelligence platform here, a vulnerability scanner there, a separate BAS (breach and attack simulation) tool, and a SIEM trying to stitch it all together. Each generates data.

None of them closes the loop. By the time intelligence is correlated, exposures are prioritized, validation is run, and a remediation ticket is acted on, the adversary has often already moved. The bottleneck isn’t any single tool. It’s the white space between them.

This is the architecture problem that keeps security leaders up at night, and it’s the one that generic AI assistants, bolted onto existing workflows, don’t actually solve. Asking a chatbot to summarize a threat report is useful. It is not the same as having an AI system that autonomously correlates that report against your live exposure surface, validates whether your controls hold, and prioritizes what to fix first. What “Agentic” Actually Means and Why It Matters Now The term “AI” has become so overloaded in security marketing that it’s worth being precise about what agentic AI actually means in this context.

Assistive AI waits to be asked . It summarizes, translates, and retrieves. It makes analysts faster at doing the same things they were already doing. Agentic AI acts .

It understands context, sets priorities autonomously, and executes multi-step workflows across systems, not as a one-time query, but continuously, in the background, at machine speed. The distinction matters because the threat environment is increasingly operating at machine speed too. With rapid advancements in frontier AI models, discovery-to-exploit timelines are shrinking significantly. The security teams that stay ahead won’t be the ones with the most analysts.

They’ll be the ones whose AI infrastructure can match that pace autonomously. For CTEM specifically, this means three functions need to stop being separate workflows: Operationalizing threat intelligence: Continuously ingesting, structuring, and contextualizing threat, exposure and vulnerability data against your environment. Understand what adversaries are doing and which asset and infrastructure is potentially exposed to those risks. Testing and validating your security posture: Continuously testing whether your controls, teams and processes actually hold against the adversary behaviors you’re tracking Mobilizing response: Automatically prioritizing and routing remediation actions based on validated, intelligence-driven evidence and risk.

When those three functions operate as a closed loop, with AI agents moving information and decisions between them without waiting for human handoffs, a CTEM program stops being a framework on a slide and starts being an operational reality. Agentic AI to Operationalize CTEM and Proactive Security An Agentic threat management architecture is what makes the difference between a CTEM framework that lives in a strategy document and one that runs continuously in the background. This requires a dedicated AI orchestration layer that acts as a foundational, contextual layer with interconnected agents. Instead of analysts manually connecting threat intelligence to exposure validation, agents do the heavy lifting continuously and with the right context and reasoning.

The whole workflow is autonomous, where agents handover tasks from one to another and across products while still keeping human-in-the-loop for final decision making. Analysts can truly become the orchestrator of intelligence-driven actions. The security teams building this capability now aren’t waiting for a perfect toolset. They’re building the operational model first and letting the architecture catch up.

The ones that get there first will have a structural advantage that compounds over time: better data, better analysis, better evidence, and furthermore, better-tuned AI. General purpose LLMs aren’t cut for this, it requires context and the product-based know-how. The organizations closing it fastest are the ones treating CTEM as an operating model, not as a single tool, and choosing AI infrastructure built specifically to run it end-to-end. You can see the operational model at work with XTM One CTEM Assistant .

Watch It in Practice: Live Webinar Filigran is running a live session that walks through what this looks like in practice: how security teams are using agentic AI to connect intelligence, exposure validation, and response into a single continuous workflow, without the handoff gaps that slow down every step in between. The session will cover: Why the shift to agentic AI changes the operational model for security programs, not just the tooling Where purpose-built agents outperform general-purpose AI when precision matters How to evaluate agentic AI infrastructure for your own program Register for a live session or get the recording: Tuesday, June 30 · 3pm GMT / 10am EST Thursday, July 2 · 1pm AEST Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Forget Data Leakage: Shadow AI’s Real Threat Is Access Control

The first wave of enterprise AI concern was straightforward. It was simply employees pasting sensitive data into public AI tools. Security teams responded with usage policies, domain blocks, and data loss prevention rules. That response made sense at the time.

It doesn’t fit the problem anymore. Shadow AI has shifted from a data leakage concern to an access control problem. The threat isn’t about what employees type into AI tools. It’s about which AI agents are running inside the organization, what enterprise systems they’re connected to, and what actions they’re authorized,or not, to take.

From passive tools to active actors Employees and business units are building AI agents at a pace most security teams can’t keep track of. Custom assistants, coding agents, workflow automations, and agentic applications are being created across departments with some in sanctioned platforms, but many through browser extensions, SaaS-native features, developer tools, MCP servers, endpoint-based agents, and custom scripts. Many start as quick experiments. Some become embedded in critical business processes within days.

The risk profile of these agents is fundamentally different from traditional shadow IT. An unsanctioned SaaS application is a destination for data. An AI agent is an actor that can call APIs, use stored credentials, retrieve records, modify configurations, trigger downstream workflows, and take actions in production systems, often without a human explicitly authorizing each step. An employee pasting a customer record into a public AI tool is a data leakage incident.

A custom AI agent connected to Salesforce, Snowflake, GitHub, Gong, and Slack is an access control incident waiting to happen. It could expose data, but it could also perform read, write, and delete actions on that data. It may also run on service accounts with permissions nobody audited and stay active six months after the employee who built it changed roles or left the company. New research from Token Security and the Cloud Security Alliance maps exactly how widespread this exposure has become.

Why existing controls don’t reach it Most enterprise security controls were designed for human identities and deterministic workloads. IAM policies, DLP rules, and network monitoring assume predictable behavior and defined access paths. AI agents break those assumptions. An agent tasked with resolving a failed deployment might read logs, query monitoring systems, modify infrastructure configurations, open tickets, trigger automation pipelines, and notify engineering teams, all in sequence, all using the same inherited credentials.

To avoid breaking workflows, developers grant broad permissions upfront. Those permissions accumulate. Agents inherit creator-level privileges, temporary access becomes permanent, and security and identity teams lose visibility into what those identities are actually doing. Blocking public AI domains doesn’t reach any of this.

By the time an agent has credentials to enterprise systems, the boundary has already been crossed. Automated remediation of non-human identities is where that gap gets closed. What a real shadow AI inventory looks like Discovering shadow AI requires looking across the environments where agents actually live, such as AI platforms, SaaS apps with built-in automation, cloud accounts, developer tools, endpoints, and identity providers. Here are six questions to define whether security teams have real control.

Where are agents being created or installed? This includes obvious AI platforms but also coding assistants, SaaS-native agent features, local developer tools, and internal applications that have quietly added AI capabilities. Who owns each agent, and who can use it? Without ownership, there’s no accountability.

An agent built for a three-person finance team that gets shared across the organization carries a very different risk profile than one scoped to a single user. What resources and services is the agent connected to? An agent can appear harmless at the platform level while holding connections to sensitive databases or production systems through credentials that were granted informally and never reviewed. What identities and secrets does it use?

Agents authenticate through service accounts, API keys, OAuth tokens, cloud IAM roles, and long-lived secrets. Each credential type carries different risks. What is the agent’s intent and what has it actually done? Configuration alone doesn’t show whether an agent is reading data, writing records, or accessing systems outside its intended scope.

Understanding intent and behavioral context is required to prioritize response. Is the agent still active? Token Security’s Agentic Pulse data found that 65.4% of agentic chatbots have never been used since creation, but their credentials remain active. Dormant agents with live access are a persistent and underappreciated exposure.

The maturity curve to ensure agentic AI security Most organizations are at the beginning of this and have little to no agent inventory. The next step is to gain partial visibility to know which agents exist, even without full context. After that they need enrichment and context to understand intent and map ownership, access, and credentials to each agent. The next step is to apply enforcement with automated controls that remediate excessive permissions, notify owners of inactive agents, and flag new agents connecting to sensitive systems.

The goal isn’t to block AI adoption. Teams are under real pressure to use these tools, and many of the productivity gains are legitimate. If security becomes a hard blocker, usage moves further underground and unseen. The better outcome is governed enablement to provide a path for teams to deploy agents with automated controls running continuously in the background.

This requires treating AI agents the same way you’d treat any other identity in the enterprise with continuous discovery, defined ownership, scoped access, and lifecycle management from creation through decommissioning. The shadow AI question has changed. It’s no longer: what data are employees putting into AI? It’s now: which agents are operating in our environment and what did we give them access to?

Those are different questions. The second one is the one that defines an organization’s exposure and risk. If you’re working through that inventory now, it’s worth seeing how others are approaching it . Found this article interesting?

This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Salesforce Disables Klue App Integration After OAuth Token Abuse Exposes Customer Data

Salesforce has revealed that it disabled the Klue Battlecards app integration within its platform in response to a security incident impacting the competitive intelligence company on June 11, 2026. To that end, organizations will be unable to connect to Salesforce via the app until further notice, the American cloud-based software company noted in an alert published this week. “Salesforce took this action because our security teams recently detected unusual activity involving the app that may have resulted in unauthorized access to a subset of customer data via the app’s connection to Salesforce,” it noted . “This issue is limited to Klue’s app connection and does not arise from a vulnerability within the Salesforce platform.” The development comes as an extortion group dubbed Icarus compromised and exfiltrated data from customers of Klue, including cybersecurity company Huntress.

“The data that was copied from our Salesforce account includes business contacts, price quotes, and other sales-related data and messaging,” Huntress said . “No threat data, passwords, payment card information, or engineering data relating to the Huntress agent or telemetry we collect was affected.” In its own update, Klue said it detected unauthorized activity affecting a portion of Klue’s integration infrastructure on June 12, 2026, adding the attackers gained access through a compromised legacy credential associated with an integration service. “The attacker used that access to obtain OAuth tokens used to connect Klue with certain third-party platforms, including Salesforce, and subsequently accessed data within a number of connected customer environments,” Klue CEO Jason Smith said . “Based on our investigation to date, the incident was limited to the affected third-party platforms, and there is no evidence that customer content stored within the Klue platform was impacted.” Specifically, the intrusion is said to have allowed the threat actor to push a code update capable of collecting OAuth tokens that its customers use to connect Klue to their own systems.

In response to the breach, Klue has taken steps to revoke affected credentials and tokens, remove unauthorized code, stop remote access, disable potentially impacted integrations, and launch a comprehensive investigation. As of June 16, 2026, some of Huntress employees have received an email with the subject line “top secret email” and a warning that states: “Your Salesforce data has been downloaded … You have 48 hours to communicate with us. Do the right decision.” “The threat actor seems to have leveraged a long-disused but still active credential to conduct the initial compromise – one that was originally created by Klue for them to prototype a third-party integration they later abandoned,” the company said.

“The threat actor then pivoted into Klue’s infrastructure to steal the tokens used by Klue’s customers, then used those stolen credentials to query those customers’ CRM tools directly and, eventually, to exfiltrate the data.” Not much is known about the Icarus actor other than the fact that they have been active since April 28, 2026, and have claimed a total of two victims to date. That said, the data theft campaign mirrors prior attack waves mounted by ShinyHunters and UNC6395. ReliaQuest, in its own analysis of the Klue integration abuse, said the activity shares similarities with the third-party OAuth-abuse playbook associated with the Salesloft Drift and Gainsight compromises that targeted Salesforce environments last year. “In the attacks we observed, the adversary first authenticated through a compromised Klue integration service account, generated OAuth tokens, and ran automated Python scripts (identifiable by Python-urllib user-agent strings),” ReliaQuest researchers Thassanai McCabe and Alexa Feminella said .

“These scripts first enumerated the org’s object catalog via GET /services/data/v59.0/sobjects, then looped REST API queries against the Salesforce query endpoint (/services/data/v59.0/query) and paginated results via the QueryMore cursor for almost 24 hours.” These are assessed to be bulk data retrieval actions designed to pull large volumes of CRM records through the Salesforce REST API. This included a “concentrated burst” of nearly a thousand queries in 15 minutes against at least one environment and an extraction window that lasted more than six hours in another case. It’s unclear how many Salesforce customers were affected by the latest attacks, although Klue said it has been communicating directly with impacted customers, sharing investigative findings, and assisting with their response efforts. “The common thread is the abuse of OAuth tokens or credentials from a trusted third-party vendor,” ReliaQuest said.

“These integrations are non-human identities with persistent, often broad access to sensitive data, yet they are typically monitored far less closely than employee accounts. That gap is why a 24-hour automated query loop could run from a ‘trusted’ integration account without tripping the usual alarms.” Update The threat actor known as Icarus has officially listed Klue as one of their victims as of June 19, 2026. “This appears to confirm the attribution of who was behind the original attack, however,” Huntress said. “As you’ve probably already heard, Klue.com has been impacted by us recently,” according to a message posted on Icarus’ leak site.

“A number of other companies’ Salesforce instances, which were partners to Klue, were exfiltrated.” “We advice [sic] Klue to contact us for a swift resolution, in order not to affect the companies you work with. On the other note, if Klue doesn’t want to accommodate this request, we advice [sic] the companies who want to protect their data to contact us via Session.” In the aftermath of the incident, a number of security vendors and other firms have publicly confirmed they have been impacted - Jamf (Impact limited to business data fields within the Salesforce environment) Recorded Future (Impact limited to business data fields stored in our Salesforce database, such as client contact names and email addresses, along with certain business contract information) Tanium (Compromised information includes sales account data, such as opportunity names and values, and other sales-related messaging, as well as business contact information stored in Salesforce, such as names, job titles, and email addresses, and in some cases phone numbers, social media contact details, and business addresses) Gong (Compromised information includes internal licensed user data for a subset of customers, such as names, business titles, emails, but not call recordings or transcripts) Insurity (Investigation ongoing) Sprout Social (Impact limited to business contact details, such as names, professional email addresses, phone numbers, job titles, and mailing addresses, along with organizational and account information, including company details, industry, and account-status information, and related commercial CRM records) Huntress security researcher John Hammond told The Hacker News there are no indications at this stage that suggest any potential connections with past Salesforce-related attacks. “As far as we know, Icarus does not seem to be related or involved with the previous Salesforce incidents,” Hammond said. “Their leak site states they have only been active since April 2026 and have only indicated two prior victims unrelated to past Salesforce campaigns.” “SaaS supply chain breaches are accelerating,” Obsidian Security said .

“Threat actors have shifted from targeting individual organizations to targeting the SaaS vendors those organizations trust, because compromising one vendor means access to hundreds of enterprise environments at once.” “When the attacker gained access to Klue’s OAuth tokens, they didn’t need a password, an MFA code, or a phished employee. They had the token. From Salesforce’s perspective, that token is Klue. So access was granted and CRM records were queried at scale.

Login activity did occur, but it came from infrastructure with no connection to Klue’s legitimate environment.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Apple Patches Beats Studio Buds Flaw Letting Nearby Attackers Spy via Microphone

Apple has updated its Beats Studio Buds wireless earbuds to patch a high-severity vulnerability that could be exploited by nearby hackers to eavesdrop on users. The vulnerability, tracked as CVE-2025-20701 (CVSS score: 8.8), refers to a case of incorrect authorization impacting the Airoha Bluetooth audio SDK that makes it possible to pair a Bluetooth audio device without user consent. Successful exploitation of the flaw could lead to remote escalation of privilege without requiring any additional execution privileges or user interaction. The issue has been addressed in Beats Firmware Update 1B211.

“An attacker within Bluetooth range may be able to listen through the microphone of a device which is not yet paired and actively seeking pair requests,” Apple said in an advisory released this week. Details of the vulnerability first emerged in June 2025 when ERNW GmbH researchers Dennis Heinze and Frieder Steinmetz flagged it alongside two other flaws in Airoha SoCs (CVE-2025-20700 and CVE-2025-20702) at the TROOPERS security conference in Germany. Similar patches were released by Jabra in December 2025. “In most cases, these vulnerabilities allow attackers to fully take over the headphones via Bluetooth.

No authentication or pairing is required,” the researchers noted at the time. “The vulnerabilities can be triggered via Bluetooth BR/EDR or Bluetooth Low Energy (BLE). Being in Bluetooth range is the only precondition. It is possible to read and write the device’s RAM and flash.” “These capabilities also allow attackers to hijack established trust relationships with other devices, such as the phone paired to the headphones.

These capabilities allow for multiple attack scenarios.” New Unpatchable Exploit Discovered in Apple’s A12 and A13 Chips The disclosure comes as Paradigm Shift disclosed a novel iPhone SecureROM (aka BootROM) vulnerability impacting Apple’s A12 and A13 chips, in addition to a proof-of-concept (PoC) exploit codenamed usbliter8 . “The exploit leverages both a hardware bug in the USB controller and a specific configuration flaw present in the device firmware,” the European cybersecurity company said . “As these vulnerabilities reside in immutable code, affected users should be aware that migrating to newer hardware remains the most effective mitigation.” At a high level, the exploit works by leveraging a flaw in the USB controller built into Apple SoCs. The controller uses a memory buffer to store SETUP and OUT packets transmitted at the start of data transfer.

The research found that it’s possible to trigger a buffer underflow primitive by taking advantage of the fact that the controller also accepts smaller packets, effectively allowing for malicious code injection and execution under certain conditions. The problem, Paradigm Shift noted, is likely rooted in the USB controller hardware itself, not in Apple’s software. The A11 chip is not susceptible to the vulnerability, while A12 and A13 are confirmed to be susceptible. “The difference is that the A11 USB driver manually resets the DMA address to its initial value after receiving each packet,” the company said.

“On A12 and A13, USB DART is configured in bypass mode, allowing us to overwrite SRAM data freely. In contrast, A14 and later generations appear to configure the DART correctly in SecureROM, making the vulnerability unexploitable.” The usbliter8 exploit is comparable to checkm8 , the publicly known BootROM exploit of this kind that impacted all iOS devices ranging from iPhone 4s (A5 chip) to iPhone 8 and iPhone X (A11 chip). “The usbliter8 exploit demonstrates that even on more recent SecureROM generations, including those protected by Pointer Authentication , subtle hardware bugs can still be leveraged to achieve full code execution and break the chain of trust,” Paradigm Shift said. “The security of the BootROM is critical: vulnerabilities at this level can compromise the integrity of the entire device.

Although usbliter8 doesn’t affect SEP itself, it opens up wider attack vectors to compromise the Secure Enclave.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.