The Hacker News

Adobe Commerce PolyShell Attacks Breach Hundreds of Stores as Brotli Exploit Traffic Emerges (2026)

Wed, 28 Oct 2026 11:12:26 +0530

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added two vulnerabilities impacting Adobe Commerce and Magento, and Google's Brotli decoder library to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.

The vulnerabilities are listed below -

CVE-2026-111497 (CVSS score: 9.2) - An unchecked return value vulnerability in Google Brotli that could allow a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial-of-service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.
CVE-2026-48356 (CVSS score: 9.3) - An unrestricted upload of a file with dangerous type vulnerability in Adobe Commerce and Magento that could result in arbitrary code execution in the context of the current user, potentially gaining elevated access or control over the victim's account or session.

The development comes days after Sansec said it observed attackers leveraging CVE-2026-48356, also known as PolyShell, to breach hundreds of e-commerce stores to inject a malicious loader via a Magento CMS block.

The loader is designed to fetch and execute an attacker-controlled payload, although no next-stage malware has been recovered to date, making it challenging to determine what the exact goals of the campaign are. The activity is assessed to be ongoing since at least July 2025.

As for CVE-2026-111497 (aka Broccoli2Shell, HTTP2Shell, and Node2Shell), telemetry data from threat intelligence firm Previdian shows that one exploitation attempt has been recorded against its honeypot sensors from a U.S.-based IP address as of October 27, 2026. It's currently not known if these efforts are broad in scope.

"An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory," Rapid7 said. "According to Node.js, this corruption can lead to a process crash, disclosure of sensitive process memory, or remote code execution. Exposure therefore depends on whether an application passes attacker-controlled compressed data to the affected decoder."

ELLIO also reported on Monday that its sensors "have recorded CVE-2026-111497 exploit traffic in the wild, carrying the public exploit that we confirmed gets a shell on vulnerable builds." The activity originates from "94.154.43[.]7," an IP address geolocated to the Netherlands that has also engaged in exploitation efforts targeting PHP2Shell, two critical flaws in PHP that could result in unauthenticated remote code execution.

"The attacker's payload is a genuine, correctly-structured Node2Shell exploitation attempt for node v24.22.0 – the Brotli stream, staged displacement, pivot pair, and delivery are all correct and identical to the public tooling," ELLIO said. "This is indicative of the RCE being adopted by an operator focused on mass exploitation."

The fact that Brotli is a widely distributed open-source library and adopted by numerous projects has provoked an emergency response, prompting various vendors to release patches or assess if their products are affected by the flaw.

This includes PHP, which has shipped versions 8.5.12-1, 8.4.27-1, 8.3.36-1, and 8.2.35-1, as well as Node.js, Bun, Envoy Proxy, Istio, .NET, Python, ClickHouse, the PHP Brotli extension, and the Ruby "brotli" gem. Links to some of the advisories are below -

"Node.js fixed the vulnerability in versions 22.23.4, 24.22.1, and 26.12.1," Akamai said. "The Node.js advisory does not offer a workaround, so upgrading is the only complete remediation. Organizations running a discontinued release line should move to a supported release line."

Google-owned Wiz has warned that "91% of cloud environments have resources vulnerable to CVE-2026-111497 and 82% of cloud environments have publicly exposed Node.js instances."

"Node2Shell is not a bug in every Node.js service, but a bug in services that decode attacker-influenced Brotli," Sysdig said. "Express 5 with default JSON parsing puts a large number of instances of them in that group. The demonstrated impact thus far is crashes at scale and code execution in a narrow configuration, so patch order should follow reachability."

Federal Civilian Executive Branch (FCEB) agencies have time until November 10, 2026, to apply the necessary fixes against the two flaws.

ShinyHunters-Exploited Oracle PeopleSoft Zero-Day Turns Out to Be Three Chained Flaws (2026)

Wed, 28 Oct 2026 11:34:58 +0530

The critical Oracle PeopleSoft bug that ShinyHunters has exploited since May is not one flaw but three chained together, the researchers who reported it said this week.

Oracle patched all three under a single identifier, CVE-2026-35273, in June. Its root is a server-side request forgery (SSRF) that reaches an internal management interface because PeopleSoft trusts its own loopback address by default, opening the door to remote code execution without a login.

The breakdown comes from Bobby Gould of the Zero Day Initiative (ZDI), whose team reported the flaw to Oracle.

In its analysis, ZDI said it reported three distinct vulnerabilities across two PeopleSoft components, and that it is working with Oracle to assign a separate CVE to each. As of this week, the one June identifier is still the only one on the record.

CVE-2026-35273 affects PeopleSoft Enterprise PeopleTools versions 8.61 and 8.62, carries a CVSS score of 9.8, and lets an unauthenticated attacker take over the server over the network. Oracle released its fix in an out-of-band security alert on June 10. The flaw is on CISA's Known Exploited Vulnerabilities catalog.

Attackers were already using it before that fix was in place. Mandiant and Google Threat Intelligence Group (GTIG) attribute a campaign to the group it tracks as UNC6240, better known as ShinyHunters, that exploited the flaw between May 27 and June 9, mostly against universities. Because that activity came before Oracle's June 10 advisory, it was a zero-day the whole time.

In a September follow-up, Mandiant reported a renewed, larger wave that spread beyond education to technology, IT services, healthcare, agriculture, transport, and government, affecting dozens of systems worldwide.

ZDI's analysis explains what that single patch actually closed. Two PeopleSoft components are involved, both run as separate web applications. The Integration Gateway (PSIGW) exchanges messages with outside systems. The Environment Management Hub (PSEMHUB) is an internal admin interface that is supposed to answer only to trusted hosts.

The first flaw is the SSRF in PSIGW. An attacker sends a request to its listening connector and controls both the address it forwards to and the full payload it sends, ZDI said; the handler does no check that the destination is a legitimate target. That alone would be limited, except for what it can reach.

PSEMHUB decides who to trust by checking the requester against a list in a file named allowedhosts.properties. That file ships with the local loopback address, 127.0.0.1, already on the list. So an attacker points the SSRF at 127.0.0.1, the request arrives looking like it came from the machine itself, and the trust check passes. The internal interface Oracle meant to wall off is now reachable from outside.

From there, ZDI described two ways to turn that access into code execution. One abuses a PSEMHUB command meant to write log entries: the caller controls both the file contents and the exact path on disk, so an attacker writes a web shell into the application directory and runs commands as the PeopleSoft service account.

The other writes a malicious XML file that PSEMHUB reads using Java's XMLDecoder when the service next starts, thereby running the attacker's code without planting a web shell at all. The second path leaves less for standard detection to catch.

The design decision at the center, ZDI said, is that allowing loopback access by default makes the trust check ineffective once the SSRF exists. That matters for defenders who thought a firewall rule had covered them.

In the September wave, Mandiant found ShinyHunters slipping past web application firewall (WAF) rules that blocked the /PSEMHUB/ path by url-encoding a single character, requesting /%50SEMHUB/ instead. Many WAF rules match the path's plain text, while the PeopleSoft server decodes it and serves the page.

What to Do

The fix and the guidance here come from Oracle and Mandiant, not from ZDI's analysis, which covers the flaw rather than the response.

Apply the patch. Install Oracle's security alert fix for CVE-2026-35273 and stay on a supported PeopleTools release. Mandiant is explicit that path-based WAF blocking is not a substitute for patching.
If you cannot patch yet, disable the Environment Management Hub service in multi-server setups, or remove the PSEMHUB application in single-server setups, as Oracle's alert advises. Restricting these admin endpoints does not break normal user sessions.
If you may already be hit, Mandiant recommends treating any host with a web shell as compromised, preserving evidence, and rotating every credential reachable from the PeopleSoft tier. ShinyHunters steals data and then demands payment, so affected organizations should prepare for extortion.

One thing the sources do not settle is whether applying the patch removes access an attacker already gained. Oracle's alert does not address it, and Mandiant's guidance to rotate credentials and hunt for web shells assumes it does not. Patching closes the door; it does not by itself evict someone already inside.

Tailscale Patches SSH Flaws That Could Let Hacked Devices Gain Root Access on Other Servers (2026)

Wed, 28 Oct 2026 11:50:37 +0530

Tailscale has released version 1.104.4 to fix flaws in its built-in SSH server that could let an attacker reach services and files on other servers that only the root user should be able to touch.

The flaws are in how Tailscale SSH forwards network connections, a job the Tailscale background process carries out with root privileges. To use them, an attacker must already control a device that the network's access rules permit to open an SSH session to the target, with forwarding allowed in that rule.

The flaws come from a report called Tailworm, published days before the fix by Erica Windisch of Cyberdione Labs, who tested released versions of the Tailscale client and the self-hosted headscale control server in a lab.

Tailscale SSH decides who can connect using a device's identity and the network's policy file, not a password or key, so an attacker does not need stolen credentials, only a foothold on a device the policy already trusts.

The flaws "don't allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers," Tailscale said, and an attacker can still reach only the machines the policy file already allows.

Tailscale SSH's server runs only on Linux and the open-source macOS build; the attacker's own device can be any platform.

The problem is in socket forwarding. When a permitted SSH session forwarded a connection to a Unix socket on the server, the Tailscale process checked the path but then operated as root. A timing trick let an attacker swap in a different path after that check, defeating the safeguard meant to limit which sockets forwarding could reach.

In Windisch's own tests, forwarding to the Docker control socket produced a root shell and read the system password file, /etc/shadow, with no administrator rights. Tailscale's bulletin describes the reach more narrowly, saying an attacker could get to root-only sockets such as the Docker socket or the tailscaled local API.

In 1.104.4, Tailscale changed the server to carry out forwarding as the logged-in user rather than as root, and to rely on the operating system's own file permissions in place of its earlier path check. The release covers 4 security bulletins:

TS-2026-014: the SSH socket-forwarding flaws above, which let a permitted session reach root-only sockets such as the Docker socket or the tailscaled local API.
TS-2026-015: a way for a permitted SSH session to use up a server's memory and crash the Tailscale process, cutting all Tailscale networking on that node.
TS-2026-016: a flaw in tailscale serve where a forward to a Unix socket could reach the tailscaled local API, giving remote control of the node, plus a related socket-swap issue.
TS-2026-017: a flaw where, with TLS serve and 2 or more mounts, one request could receive another mount's permission headers.

What to Do

Users of Tailscale SSH should update to version 1.104.4 or later. If you cannot update a server yet, you can turn off SSH forwarding on it by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service, which Tailscale says turns off forwarding without disabling Tailscale SSH and blocks several of the more serious findings.

Tailscale also recommends reviewing SSH access rules so that only the users and devices that need access have it.

Tailscale suggests using SSH check mode, which requires a user to sign in again before a session starts, for sensitive systems. Check mode does not stop these forwarding flaws: it guards the start of a session, whereas the forwarding occurs within a session that has already been approved.

If a server may already have been compromised, Windisch's report says the fix alone is not enough. A stolen device key stays valid until the device is deleted at the control plane, because reimaging the machine does not revoke it. Tailscale's notices do not cover this case.

The picture is worse on headscale, the self-hosted control server. On headscale, SSH forwarding is granted on every accepted session and cannot be turned off in the policy, so Windisch's report says every SSH grant there should be treated as giving root. The newest headscale release, version 0.29.5 from October 13, does not fix the reported issues.

Is It a Worm?

Windisch called the chain "wormable." In her tests, one compromised device could spread to every device the policy allowed, with no passwords, no stolen keys, and no user action, in under a second per step.

Two controls stopped the spread in those tests. Writing access rules as single device-to-device pairs held it back, and binding device keys to hardware such as a TPM kept a stolen identity from being reused elsewhere.

Tailscale rejected the worm description. The findings do not describe self-replicating malware that spreads between machines on its own, the company said, but lateral movement limited to the connections a policy file already allows.

It called the privilege-escalation problems "serious security issues," said it had reproduced the main ones, and added that it is still working out which configurations are affected.

Disclosure and Earlier Fixes

As of publication, the 4 bulletins carry no CVE identifiers or severity scores, and none state the oldest affected version. The report also covered Tailscale's app connectors and its serve and funnel features.

Tailscale said the app-connector finding is in conn25, an experimental feature it has not released, and that the connectors customers use today are not affected. Of 5 serve and funnel findings, it fixed 3 and said the other 2 work as designed.

Windisch published the report without coordinating the release with Tailscale first, which she has described as "reported but not coordinated." Tailscale said it received the report on the morning of Saturday, October 24, about 2 hours before Windisch published it, and that its engineers were already looking at the same parts of the code.

Neither Tailscale nor the report says the flaws have been used in real attacks. The proof-of-concept code is not public, and Windisch said she gave it only to Tailscale's security team.

The report is the latest in a run of fixes in the same part of Tailscale this year. In June, Tailscale fixed a separate flaw in Tailscale SSH's Unix-socket forwarding that let an unprivileged user reach a privileged socket, in version 1.98.9.

Japan's GMO Offers $1 Million Bounty to Catch Hackers Behind FX Trading Cloud Breach (2026)

Wed, 28 Oct 2026 12:43:21 +0530

Japan's GMO Internet Group is offering up to $1 million in total for tips that help catch the attackers who breached its Onamae.com Desktop Cloud service, after refusing to pay an extortion demand.

The reward program opened on October 28 and pays only if a tip helps lead to an arrest or an international wanted notice. The service hosts Windows desktops used for FX trading, and a broker has linked unauthorized trades on some of its customers' accounts to logins leaked from the service.

GMO says the attackers took customer information. It received a demand for about $50 million (about ¥8 billion) on October 21 from people it believes carried out the attack. They have also threatened its customers' trading accounts and data.

On October 27, the attackers posted material on their website that they say is information about GMO and its customers. The site's domain, including its mirror sites, was shut down at about 4 a.m. Japan time on October 28, and GMO plans to act against any new site.

How the Reward Works

GMO Internet Group runs and pays for the program, called GMO Cybercrime Bounty. Tips are sent by email to an address listed on a dedicated website, in Japanese, English, or Chinese, and can be anonymous. The program is open until an arrest, an international wanted notice, or October 27, 2027, whichever comes first.

GMO wants information linking people, servers, domains, IP addresses, accounts, or cryptocurrency addresses to the attack, extortion, or movement of money, along with evidence of how the crimes were carried out. Guesses, unsupported accusations and reposts of public information generally do not qualify.

A tip earns money only if it leads to an arrest, including one by police outside Japan, or to an international wanted notice, such as an Interpol Red Notice. GMO decides how much each tip helped, and one tipster can receive the full $1 million or the total can be split. Tipsters must prove their identity before payment, and if no tip qualifies, no payment is made.

Some people cannot be paid, including anyone involved in the crime, anyone who got information illegally, such as by buying leaked data, and GMO staff. GMO tells tipsters not to break into systems, negotiate with or pay the attackers, or send leaked data, credentials, or malware.

Tips are shared with police and other authorities in Japan and abroad as needed. GMO has already given police all its evidence on the threats, including communication records.

GMO will never ask tipsters for passwords, authentication codes or fees, and it writes to them only from addresses ending in @cybercrimebounty.gmo.

The Breach and the Trading Accounts

GMO Internet, the subsidiary that runs the service, found on October 20 that a third party had installed malicious programs on some customers' servers. It shut down the servers on every plan from October 21. It counts 26,739 servers as potentially affected, which is not the number of confirmed break-ins or data thefts.

On October 24, GMO said it had confirmed a security problem in the service's systems, unauthorized access to the service, and the exfiltration of customer information from the company.

Anything customers stored on the servers may have been viewed, including login credentials saved in trading software such as MetaTrader 4 and 5 (MT4/MT5). GMO does not keep customers' payment card data on the servers.

Customers began reporting trades they did not recognize on October 21. A broker, OANDA Japan, has confirmed that a third party logged in to and traded on some of its customers' accounts using ID and password pairs it believes were leaked from the GMO servers. It has restricted trading on accounts that may be affected, and as of October 26 it had not found a break-in or leak in its own core systems.

Another broker, FXTF, warned on October 22 that third parties may have stolen the logins of some customers who use VPS servers, in an attack it believes hit another company's VPS servers. They may also have used the logins to log in and trade. It told customers who had connected to Desktop Cloud to change their FXTF passwords from a device that had never connected to it.

GMO Internet Group said in a stock exchange filing on October 28 that it had not yet confirmed how many customers its payments will cover, how much information was published, or which trades qualify for compensation. It had not confirmed any impact from the breach on its other services.

The Threats and the Leak

GMO says the attackers threatened to keep manipulating customers' accounts at more than 70 securities and FX firms, to publish information about the service and about customers' PCs, to hit those PCs with ransomware, and to publish details of GMO's systems.

They set noon on October 27 for publishing customer information and launching the ransomware attack. No ransomware attack had been confirmed as of 1:55 p.m. Japan time that day.

The material posted on October 27 was what the attackers called one customer's personal information, ITmedia NEWS reported that afternoon. GMO was checking it that day.

The attackers collected information about anyone who visited their site, according to GMO, which tells visitors to run a full antivirus scan. It asks people not to visit the site or any new one, and not to repost or link to the material.

How the Attackers Got In

As of October 28, GMO had not said how the attackers got in.

Masatoshi Kumagai, who heads GMO Internet Group, wrote in an October 25 blog post that the group's own white-hat hackers had warned the team running the service about problems in advance.

The response was neither fast nor thorough enough, he wrote, and the attackers took advantage of the gap.

On their website, the attackers claimed that one administrator account was shared across all the servers and that customers' PC drives were visible from the servers by default when they connected, ITmedia NEWS reported.

They also claimed they used a flaw in the service to reach customers' own PCs. GMO had not publicly confirmed these claims either.

By October 26, GMO had collected PCs from customers who offered them for analysis, as of 11:59 a.m. Japan time on October 27, it had found no malware, including ransomware, on the PCs it had finished checking. That does not confirm that every customer's device is safe, and the analysis is still ongoing.

What Customers Should Do

GMO has told Desktop Cloud customers to take these steps:

Change trading-account and trading-software passwords from a device not used for FX trading, such as a phone.
End every logged-in session, through the broker if needed, even after changing the password.
Check trading history and balances, and report unrecognized trades to the broker first.
Turn on two-factor authentication where the broker offers it.
Change passwords reused on other services or saved in the browser.
Run a full antivirus scan on devices used to connect, and back up data.
Do not reply to messages from anyone claiming to be behind the attack, or open their links or files.
Ignore offers to recover lost money for a fee. GMO will never ask for a password or authentication code.

GMO Internet will pay every current user ¥5,000 and cover actual trading losses and fees from trades it confirms were unauthorized and caused by the breach. Customers whose information it confirms was published will also get ¥10,000 to ¥25,000 for each type of information exposed.

GMO will not restart the service on the breached systems as they are. Customers who want a Windows desktop will be offered a move to a separate service, free for six months and only with their consent, with details due by October 30.

FBI Seizes Virtualine Domain Over Alleged Criminal Hosting and Bitcoin Money Laundering (2026)

Wed, 28 Oct 2026 13:07:50 +0530

The U.S. Department of Justice (DoJ) on Tuesday announced the seizure of a domain associated with a bulletproof hosting provider (BPH) named Virtualine.

The move was in response to the service being used to commit and facilitate prolific criminal activity, including "the advertisement of sexually explicit images of minors, the intentional disclosure of nonconsensual intimate visual depictions of adults and minors, and international money laundering designed to conceal and promote criminal conduct," the DoJ said.

Visitors to the "virtualine[.]net" domain are now greeted by a message that states it has been seized by the U.S. Federal Bureau of Investigation as part of a coordinated operation between international law enforcement agencies and private sector entities, including the Hessen State Police, the National Police Corps of the Netherlands, the U.K. National Crime Agency, OverRIPE, and Lumen Technologies.

According to court documents, Virtualine, which also operated as Secury, Massgod, Spamhouse, Lanedo, and Omegatech, advertised its services to criminals on cybercrime forums, claiming that they can be used for phishing, carding, email spam, and port scanning, with the exception of child content and terrorism activities.

In June 2025 on HackForums, the provider is alleged to have boasted that "Virtualine ignored more abuse than your last three therapists." Earlier this March, it also began marketing an "additional protection plan" that promised its customers to move their criminal infrastructure to a shell company unaffiliated with Virtualine when receiving official requests from law enforcement agencies.

Snapshots captured by the Internet Archive show that standard plans cost anywhere between $19.99 per month for one virtual CPU, 2GB memory, and 30 GB storage to $179.99 per month for 24 vCPUs, 64 GB memory, and 130 GB memory. Virtualine also offered plans optimized by CPU, memory, and storage, starting from $21.99 per month to $379.99 per month.

"Despite advertising that it does not allow 'child contents' on its server, Virtualine knowingly hosted a website that did so, identified in court records as Vendor 1," DoJ said. "Vendor 1 is a criminal online forum that allows users to post and sell access to nude, sexually suggestive, and/or sexually explicit images and videos of minors and adults."

"Vendor 1 also promotes a hack-for-hire service in which users can pay hackers to access victims’ online accounts without their consent and illicitly obtain explicit images and videos. In January 2026, about one month after Virtualine assigned an IP address to Vendor 1, Virtualine began receiving notifications about sexually explicit images and videos of minors on that server."

The Justice Department said Virtualine continued to host Vendor 1's services despite receiving numerous notices from law enforcement in Germany, Canada, and Australia; the National Center for Missing and Exploited Children (NCMEC) in the United States; and a victim's attorney.

Virtualine has also been accused of working closely with Vendor 1 to create a new website where its clients could upload their illicit content and download it upon completing a purchase. The website continues to be hosted by Virtualine to this day, the department added.

"Virtualine.net included a number of payment options for Virtualine's customers, including Vendor 1," the DoJ said. "Virtualine accepted payment through BTC [NO-AML], specific unhosted bitcoin addresses that allowed customers to direct pay without concern their funds would be flagged as illicit."

"The funds Virtualine's criminal customers paid to Virtualine, some of which can be traced directly to various criminal groups, were received by Virtualine and then further laundered to conceal the origin of the funds."

Blockchain intelligence firm Chainalysis, in its own analysis, said Virtualine accepted direct Bitcoin payments through unhosted wallet addresses, allowing criminal customers to pay without triggering compliance checks at hosted exchanges.

"Virtualine's on-chain footprint has direct exposure to a broad cross-section of the cybercrime ecosystem, including ransomware operators, infostealer infrastructure, Russian-language cybercrime forums, illicit shops, and scam and phishing addresses," it said.

Following the site seizure, the operator of Virtualine has published an open letter, refuting allegations that the service knowingly hosted child sexual abuse material (CSAM). The operator also claimed they have taken action on requests for cooperation concerning CSAM within 24 hours. In a post shared on their Telegram channel, they insisted that customer data was safe.

"When we identified prohibited material associated with the customer described as 'Vendor 1,' we ended our relationship with that customer," the individual added, claiming "Virtualine has been part of my life for five years."

"Please do not cast suspicion on me and the tens of thousands of customers who have trusted Virtualine because of the actions attributed to a single customer. I want you to know that I am prepared to respond to your requests concerning 'Vendor 1.'"

In September 2025, the Spamhaus Project revealed that Virtualine had expanded their operations to AS209800. "Thanks to Turkey- and U.S.-based IP address brokers with poor customer vetting procedures, Virtualine keeps obtaining new IPv4 prefixes for enabling internet abuse. AS209800 is currently routed via aurologic GmbH, a hosting provider proliferating several other bulletproof hosting operations."

"A lost ASN does not by itself mean the BPH has stopped," Silent Push said. "The speed of acquiring a new ASN is a crucial part of the problem, and we believe the process for registering an ASN should be tougher."

Update

According to an analysis published by TRM Labs, Virtualine received more illicit-attributed cryptocurrency than any other labeled bulletproof host in 2026, surpassing SecureHost, vpsbg, F0XYF0X BPH (aka Bearhost), and Gerry, despite lower total inflows.

A Russian drug marketplace accounted for nearly 44% of direct inflows, while a large sextortion scheme, a mixer, and ransomware groups were responsible for about 17%, 13%, and 5%, respectively. Direct payers include Coinbase Cartel, The Gentlemen, INC, DragonForce, and Qilin, alongside malware operators such as the StealC infostealer and the Matanbuchus loader.

Other counterparties that have transacted with Virtualine are darknet markets, illicit goods and services operators, bot and malware-distribution services, and sites linked to child sexual abuse material.

"Virtualine is another example of Russia's illicit economy at work: darknet markets, ransomware groups, non-compliant exchanges, and brokers all feeding the same ecosystem," Ari Redbord, global head of policy at TRM Labs, said in a statement shared with The Hacker News.

"Bulletproof hosting is the connective tissue. Seizing a domain matters, but the blockchain record doesn't disappear with it. It shows who is paying, who is getting paid, and where they go next."

A press release from the Dutch police has revealed that dozens of physical servers located in a data center in Limburg were seized in Limburg, taking hundreds of virtual servers offline.

"Through the seizure, the police are in possession of data and information relating to more than 3,000 customers who used the servers for criminal activities," the Politie said. "The secured data will be used for further police investigation regarding customers who used these servers for criminal purposes."

As of October 29, 2026, virtualine[.]org, the domain that hosted the open letter, and the Telegram channel are no longer accessible.

Anthropic's Unreleased AI Model Chains Flaws Into Working Chrome, Safari, Windows and Linux Exploits (2026)

Wed, 28 Oct 2026 13:45:07 +0530

An unreleased Anthropic AI model found security flaws in Chrome, Safari, Android, Windows, and Linux and chained them into working proof-of-concept exploits, the company said in its latest report.

The exploits were built in the lab after the model was prompted, not seen in any real attack, and Anthropic reported every flaw to the vendor first, so all of them are already patched. One proof of concept opened the Calculator app on a stock Mac running Chrome within seconds of a page loading, with no further clicks.

Anthropic's Frontier Red Team described five chains in a research post. The strongest claim is not any single bug, but that one model found several separate flaws and combined them into a working exploit, something the company says has until now been the work of a few specialist teams. That capability claim rests on Anthropic's own account.

The patches and the fact that Apple and Google credit Anthropic and its Claude model for specific fixes can be verified with the vendors.

What a reader cannot check is how much of each chain the model built on its own. Anthropic says the work needed only "initial prompting" and "little human involvement," but it does not break down what a person did at each step, and it does not name the model beyond calling it an unreleased, internal research model.

For the one flaw with its own public record, the Windows bug, the record names no finder at all. Here are the five chains, what each would do, the condition each needs, and where the fix landed.

Platform	What the exploit does	Condition it needs	Fix
Chrome	Runs code on the computer, outside the browser's sandbox, from one visit to a web page	One click or page load, stock Chrome on macOS	Chrome 156, October 20
Safari	Lets any website read data from other sites the user is signed in to, such as email or a bank account	One visit to a malicious page	iOS and iPadOS 26.5.2, June 29
Android	Copies photos and other data off a locked, stolen phone	Physical access to the phone, over USB	Anthropic says Google has fixed it; no public record was found
Windows	Crashes a server over the network, and keeps it down by repeating	The server answers HTTP/3 requests	CVE-2026-33096, patched April 2026
Linux	Runs commands as root over the network, with no login and no user action	The server runs a multipath TCP listener	CVE-2026-98432, patched October 15

In the Chrome chain, the model used four separate flaws in turn. A malicious page first corrupted memory in V8, Chrome's JavaScript engine.

A second flaw escaped V8's memory sandbox and took control of the part of Chrome that renders the page. A race condition in a feature called CacheStorage then let that code read memory it should not reach and learn the layout of the more privileged browser process.

A final use-after-free bug in FedCM, Chrome's sign-in feature, let the exploit run code outside the sandbox entirely. Anthropic says it reported 62 flaws to Google that were assigned CVEs and fixed as of Chrome 156, all rated critical or high, including 13 sandbox escapes.

Google's own release notes credit "Xinyang Ge of Anthropic, assisted by Claude" for specific Chrome fixes, though not for all 62.

The Safari chain is different because it never runs code at all. It chains flaws to obtain full read and write access to the browser's memory, then changes a single value to turn off the same-origin policy, the rule that prevents one website from reading another's data.

With that rule off, a malicious page can read a user's history and cookies and send signed-in requests to other sites. Apple fixed the use-after-free at the center of the chain in iOS and iPadOS 26.5.2 and credits "Milad Nasr and Nicholas Carlini with Claude, Anthropic" for it.

The Windows chain is the one with an independent paper trail, and it is also the narrowest. It is a denial-of-service attack: a few network packets crash the machine, and repeating them keeps it down, but it does not run code or steal data. Anthropic describes the flaw as an out-of-bounds read in the Windows kernel's QUIC handling.

The public record for the bug it points to, CVE-2026-33096, instead names HTTP.sys, Windows' built-in web request handler, and rates it 7.5 out of 10. No open source ties those two descriptions together as the same component. The CVE record credits no finder, so Anthropic's authorship of this one rests on its own post.

As of late October, the U.S. government's vulnerability enrichment marked the flaw as not exploited, and it was not in the CISA catalog of known exploited bugs.

The Linux chain is the most serious in terms of impact: it runs commands as root over the network without a login. It needs the target server to be running a multipath TCP listener. The model first leaks a kernel memory address to bypass a defense called KASLR, then reuses the same race-condition bug to redirect the program to code the attacker has already placed, resulting in a root shell.

Anthropic says its proof of concept took 48 minutes to leak the address and five more to reach the shell, and that a failed attempt does not crash the system, so an attacker can keep retrying.

The company ties this chain to CVE-2026-98432, a kernel use-after-free rated 9.8 and fixed upstream on October 15; the public record for that CVE describes an IPv4 TCP fix rather than a multipath TCP one, and the two are linked only by Anthropic's post.

Anthropic frames the work as help for defenders. It says it reported each flaw under a coordinated disclosure policy that gives developers 90 days to patch and 45 more before it discusses details beyond a public advisory, and it points security teams to its expanded Cyber Verification Program, which gives vetted professionals access to Claude Opus 5.5, Sonnet 5.5 and Mythos 5.1.

The reason the company gives for publishing is in its own words: "Now, it's something models can do with little human involvement, and then prove by producing a working exploit that anyone can run and verify."

American Organizations Under Attack: Skyw4lker Device Code Phishing Campaign Exposed (2026)

Wed, 28 Oct 2026 16:00:00 +0530

Modern phishing campaigns can compromise American businesses without relying on traditional credential theft. Attackers can abuse legitimate cloud services, authentication mechanisms, and trusted business workflows to gain access to corporate accounts while leaving fewer obvious signs behind.

ANY.RUN's analysis of Skyw4lker, a device code phishing campaign primarily targeting U.S. organizations, shows how this works in practice. The campaign has focused on manufacturing, technology, and healthcare, using business-themed documents, Google-hosted infrastructure, and Microsoft authentication flows to facilitate account compromise.

For security teams, the investigation goes beyond identifying the initial lure. It requires tracing the authentication flow and supporting infrastructure, extracting reliable indicators, and turning those findings into detections that can protect the wider organization.

Device Code Phishing: A Growing Challenge for U.S. Organizations

The scale of phishing in the United States provides an important backdrop. The FBI's Internet Crime Complaint Center recorded 193,407 phishing and spoofing complaints in 2024, making it one of the most frequently reported categories of internet crime. In 2025, the FBI recorded more than 1 million internet crime complaints and $20.9 billion in reported losses, with reported losses increasing by 26% compared with the previous year.

Attackers are also adapting to organizations that have invested heavily in identity security and MFA.

Device code phishing is one example. Rather than collecting credentials through a fake login page, an attacker can initiate a legitimate device authorization flow and convince the victim to complete it. The resulting authentication tokens can then provide access to resources available to the compromised account.

How Skyw4lker Uses Legitimate Authentication to Compromise Accounts

How the Skyw4lker Campaign Works

Skyw4lker starts with a lure designed to resemble normal business correspondence, as observed in ANY.RUN’s Interactive Sandbox analysis.

The Skyw4lker phishing kit identified in ANY.RUN’s Interactive Sandbox

Victims receive a password-protected document presented as a contract or service proposal. The scenario is credible in environments where employees routinely exchange vendor agreements, procurement documents, statements of work, and similar files.

From the document, the victim is directed toward a page hosted on sites[.]google[.]com, which eventually leads into a Microsoft authentication flow.

Skyw4lker redirecting the victims to a Microsoft365 authentication page

The attacker does not need to reproduce Microsoft's login experience perfectly. The authentication itself can be legitimate; the deception is in convincing the victim to complete an authentication request initiated by the attacker.

Once the process is completed, the attacker can obtain access to the resulting Microsoft 365 tokens.

That makes the attack difficult to evaluate through identity telemetry alone. An organization may see a valid authentication event without immediately seeing the malicious context that caused it. Establishing what happened requires the security team to connect the document, web activity, authentication flow, and associated infrastructure.

The Infrastructure Behind the Skyw4lker Phishing Page

The web infrastructure used by Skyw4lker provides additional evidence of the campaign's operation.

ANY.RUN’s analysis identified obfuscated JavaScript and a PHP backend used to create a victim session, collect information such as IP address and geolocation, and repeatedly poll the backend while waiting for the authentication process to complete.

Skyw4lker sample submissions in ANY.RUN’s Interactive Sandbox by country

A static inspection of the original document may reveal the starting URL, but it cannot fully explain what happens once the victim interacts with the page. The malicious behavior emerges through the combination of browser activity, JavaScript execution, backend communication, redirects, and authentication.

That makes behavioral analysis essential when the objective is to establish exactly what a phishing campaign is doing and which indicators can be trusted for follow-up detection.

View the Skyw4lker analysis in ANY.RUN’s Interactive Sandbox to see its complete attack chain and associated IOCs.

Reduce Tier 1 workload by up to 20% and give analysts more time to focus on critical threats.

Boost Your SOC Efficiency

Interactive Sandboxing Turns Suspicious Files and URLs into Actionable Evidence

An interactive sandbox lets security teams safely execute and interact with suspicious files, links, and documents, revealing behavior that static inspection can miss.

That matters in campaigns such as Skyw4lker, where the document is only the starting point. Analysts need to follow the attack through the browser, observe redirects and authentication activity, inspect network communication, and identify the infrastructure behind the phishing flow. All of this can be done in an isolated ANY.RUN Sandbox environment, with a result available in as little as 40 seconds.

The Tier 1 report for the observed Skyw4lker sample available in ANY.RUN’s sandbox

Instead of stopping at a malicious/benign verdict, the investigation can produce URLs, domains, IP addresses, network activity, screenshots, behavioral evidence, and other IOCs. These findings give security teams the context needed to validate an alert, scope-related activity, and create detections from evidence gathered during a single investigation.

As a result, SOC and MSSP teams can reach a confident verdict faster without manually reproducing the attack across multiple tools, while the resulting intelligence can support threat hunting and detection across the wider environment. Moreover, the same workflow makes it easier for MSSPs to investigate new campaigns and turn findings from one customer case into intelligence that can be searched across other environments.

Turning Threat Intel into Earlier Detection

The value of an IOC increases when it can be used to detect another attack.

ANY.RUN Threat Intelligence Feeds (TI Feeds) provide malicious IPs, domains, URLs, and contextual information derived from sandbox investigations. 99% of unique, high-confidence IOCs are added to TI Feeds after validation, helping security teams work with intelligence that has already been reviewed.

ANY.RUN TI Feeds provide live threat intelligence for real-time attack detection

ANY.RUN’s internal analysis found that up to 30% of unique malicious IOCs discovered in Interactive Sandbox sessions had already been observed by the company and were present in TI Feeds. When one of these indicators appears in customer telemetry, it can potentially be matched against existing intelligence before an analyst manually investigates the associated sample.

This creates a more efficient workflow: known malicious activity can be identified earlier, while sandbox analysis provides the behavioral evidence needed to investigate unfamiliar threats.

For internal SOCs, this can reduce time spent researching indicators that are already known to be malicious. For MSSPs, the same intelligence can help identify related activity across multiple customer environments. This is how the existing threat knowledge can be reused instead of reconstructed for every new alert.

Cut MTTR by 21 minutes and give your SOC more time to focus on critical threats.

Integrate TI Feeds

Threat Intelligence Provides Context Behind the Alert

An indicator becomes more useful when security teams can understand the activity surrounding it.

ANY.RUN’s Threat Intelligence Lookup (TI Lookup) allows analysts to investigate a suspicious domain, IP address, or URL and examine its history and associated activity. In a Skyw4lker-related investigation, this context can help determine whether an indicator is connected to the campaign, has appeared in other malicious activity, or requires further investigation.

In addition, ANY.RUN’s Threat Intelligence Reports (TI Reports) provide a broader perspective by connecting indicators with campaigns, infrastructure, techniques, and observed behavior. This can reveal relationships that are difficult to see from individual alerts, such as multiple incidents sharing the same infrastructure or a suspicious domain belonging to a wider phishing operation.

When it comes to organizations in U.S. healthcare, manufacturing, and technology, those connections can be especially important. A compromised Microsoft 365 account can expose sensitive communications, intellectual property, operational information, and regulated data, making early identification of related activity critical.

How to Make Each SOC and MSSP Investigation More Valuable

A successful investigation should improve an organization's ability to detect the next attack.

For an MSSP investigating a suspicious contract sent to one American manufacturing customer, indicators associated with Skyw4lker can be searched across other customer environments and incorporated into monitoring. The same approach works within an internal SOC environment, where an IOC found after one employee reports a phishing document can be compared against historical telemetry to identify other potentially affected users.

ANY.RUN supports these workflows through API/SDK, STIX/TAXII, SIEM, TIP, and XDR integrations, allowing intelligence from investigations to feed into existing detection and monitoring processes.

The result is broader protection from the same investigation: an incident affecting one user can generate intelligence that helps identify related activity across a SOC or MSSP's wider customer base.

Uncover up to 58% more threats and gain broader visibility into emerging attacks.

Boost Threat Detection

Conclusion

Skyw4lker shows why modern phishing defense requires visibility beyond the initial lure or login page. By combining interactive sandboxing, threat intelligence, and contextual investigation, security teams can move faster from suspicious artifact to actionable intelligence and broader detection.

For organizations in the U.S., that means faster investigations, less repetitive manual work, and a better ability to identify related activity before it becomes a larger incident. The goal is not only to understand one attack, but to turn every investigation into protection against the next one.

Adobe Fixes 8 Critical Campaign Classic Flaws Allowing Code Execution and Security Bypass (2026)

Wed, 28 Oct 2026 16:45:51 +0530

Adobe has released patches to address multiple critical security flaws in Campaign Classic that, if successfully exploited, could result in arbitrary code execution, security feature bypass, and privilege escalation.

The list of eight vulnerabilities is as follows -

CVE-2026-104351 (CVSS score: 9.9) - A code injection vulnerability that could lead to arbitrary code execution.
CVE-2026-104353 (CVSS score: 9.9) - An operating system code injection vulnerability that could lead to arbitrary code execution.
CVE-2026-105780 (CVSS score: 9.9) - An incorrect authorization vulnerability that could lead to arbitrary code execution.
CVE-2026-105489 (CVSS score: 9.9) - An SQL injection vulnerability that could lead to security feature bypass.
CVE-2026-105781 (CVSS score: 9.8) - An SQL injection vulnerability that could lead to security feature bypass.
CVE-2026-104350 (CVSS score: 9.3) - A reflected cross-site scripting vulnerability that could lead to privilege escalation.
CVE-2026-104354 (CVSS score: 9.1) - An SQL injection vulnerability that could lead to security feature bypass.
CVE-2026-105779 (CVSS score: 9.1) - An SQL injection vulnerability that could lead to security feature bypass.

The issues affect Adobe Campaign Classic versions 7.4.4 build 9402 and earlier for Windows and Linux. They have been patched in version 7.4.4 build 9403.

Also resolved by Adobe is a critical code injection flaw in Adobe Connect Desktop and Mobile for Windows, macOS, and Android (CVE-2026-48360, CVSS score: 9.6) that could result in arbitrary code execution.

The vulnerability has been fixed in the following versions -

Adobe Connect Desktop -
- Windows: version 2026.9.61
- macOS Silicon: version 2026.10.66
- macOS Intel: version 2026.10.170
Adobe Connect Mobile for Android version 4.5

Adobe said it's not "aware of any exploits in the wild for any of the issues" addressed in the update. Users are advised to update to the latest version for optimal protection.

Wazuh and AI for Enhanced SOC Workflows (2026)

Wed, 28 Oct 2026 17:00:00 +0530

Artificial Intelligence (AI) has become one of this decade's defining technologies. From healthcare and finance to manufacturing and education, organizations increasingly rely on AI to automate repetitive tasks, uncover patterns hidden within large datasets, and support faster decision-making. Cybersecurity has experienced a similar transformation. While attackers employ AI to automate cyberattacks and accelerate vulnerability discovery, defenders are adopting AI to improve threat detection and enhance incident response.

Security Operations Centers (SOCs) receive a high volume of alerts from endpoints, cloud workloads, network devices, identity providers, and business applications. Although SIEM and XDR platforms provide visibility into these environments, analysts often spend considerable time correlating alerts, searching documentation, and determining the next investigative steps. AI offers a practical way to augment analysts by providing contextual explanations, summarizing findings, and recommending remediation actions, rather than replacing human expertise.

Challenges facing modern SOCs

Modern SOCs are expected to detect and respond to sophisticated threats while processing millions of security events every day. High alert volumes contribute to analyst fatigue and increase the likelihood that critical events are overlooked. Investigations frequently require switching between dashboards, documentation, vulnerability databases, and threat intelligence feeds before a complete picture emerges. As infrastructures become increasingly distributed across on-premises and cloud environments, maintaining consistent situational awareness becomes more difficult. AI-assisted workflows help address these challenges by reducing repetitive analysis, adding context, and accelerating investigative decision-making.

Wazuh and artificial intelligence for enhanced SOC workflows

Wazuh promotes flexible AI adoption through the Wazuh AI Analyst available on the Wazuh Cloud and integrations with third-party AI providers. Organizations can leverage the Wazuh AI Analyst capability on the Wazuh Cloud for guidance on their environment's security posture. Organizations that self-deploy Wazuh can also leverage Wazuh integrations with AI providers. The following sections highlight further details:

The Wazuh AI Analyst

The Wazuh AI Analyst is automated and hands-off. It is an AI-powered security analysis service for Wazuh Cloud subscriptions that processes your security data through Amazon Bedrock and Anthropic’s Claude, delivering insights without any manual configuration. It periodically emails key indicators, a histogram of protected endpoints, alert volume, active vulnerabilities, and a posture summary with a full PDF report attached.

The reports are generated on your Wazuh Cloud subscription’s schedule and are periodically sent to your registered email address. You can also view them from the Wazuh Cloud console in the Environments > AI Reports page.

On privacy, subscription data is not shared with third parties and is not used to train AI models; it is processed only to generate your reports, with encrypted transmission, isolated processing, and no permanent storage. As with any AI output, the recommendations are advisory and should be validated against your own policies before you act.

Threat hunting and security operations with external AI integrations

Beyond the Wazuh AI Analyst, you can expand Wazuh capabilities using a self-hosted LLM and externally managed AI integrations tailored to your needs.

Self-hosted Llama 3 and Ollama

This integration keeps everything on your own network. Ollama runs the Meta open-source Llama LLM locally on the Wazuh server; a Python script decompresses the archived logs for a chosen period, vectorizes them into a FAISS store, and serves a LangChain-powered chatbot you can query. Nothing is sent to a cloud provider, which makes it well-suited to teams with strict privacy or data-residency requirements.

Full setup steps are in the Wazuh blog post: Leveraging artificial intelligence for threat hunting in Wazuh.

Externally managed integration with Claude 3.5 Haiku

This integration surfaces Anthropic’s Claude 3.5 Haiku, hosted on Amazon Bedrock, as a chat box inside the dashboard through the OpenSearch Assistant. Setup involves enabling the model in Bedrock, installing the relevant OpenSearch plugins, and creating an ML Commons connector, model, and conversational agent. The assistant can provide useful guidance on many common tasks, including what to do about a finding and how to configure certain settings.

Full setup steps are in the Wazuh blog post: Leveraging Claude Haiku in the Wazuh dashboard for LLM-powered insights.

Conclusion

Artificial intelligence is becoming an important capability in modern SOCs. Rather than replacing analysts, it can reduce repetitive work, accelerate investigations, and provide contextual support for detection, triage, and response activities. These capabilities can help security teams operate more efficiently while keeping analysts responsible for validation and consequential decisions.

For Wazuh Cloud users, the Wazuh AI Analyst provides automated, scheduled security reports covering key indicators, alert activity, endpoint coverage, active vulnerabilities, and overall security posture. Organizations can further tailor AI-enabled security operations through self-hosted LLM integrations for privacy-sensitive threat hunting or externally managed, cloud-hosted models, aligning adoption with their operational, privacy, and data-residency requirements.

Critical 16-Year-Old UEFI Flaw Can Run Code Before Secure Boot on Network-Booting Servers (2026)

Wed, 28 Oct 2026 17:20:00 +0530

A critical 16-year-old flaw in EDK II, the open-source code that most hardware makers use to build UEFI firmware, can allow an attacker to run code on a machine before its operating system loads, but only while the machine is booting over the network.

UEFI firmware is the software that runs first when a computer is switched on, before the operating system. An attacker who can reach the machine with a crafted network message during such a network boot can hang the boot, or, with work tailored to the exact firmware build, run their own code before Secure Boot and other startup defenses load.

An attacker needs no password and no existing access to the machine, but does need to reach it over the network during the short window when it is booting this way.

Red Hat and SUSE, which both ship the affected code, rated the flaw as one an attacker exploits from an adjacent network position rather than across the open internet.

TianoCore, the project behind EDK II, published an advisory on October 22 and rated the flaw, tracked as CVE-2026-97631, 9.5 out of 10. A code fix exists, but no stable release of EDK II contains it yet, and the advisory still lists no patched version, so most users have nothing to install today.

What the Flaw Lets an Attacker Do

The flaw is a buffer overflow in EDK II's network-boot code, known as PXE. During a PXE boot, a machine loads its startup image from the network instead of from a local disk.

As part of this, the PXE driver listens for ICMP error messages and the small status messages that network devices send back, and copies each one into a fixed 504-byte area of memory.

The size checks in that copy are wrong in both the IPv4 and IPv6 versions of the code, so a message longer than 504 bytes spills past the area and overwrites nearby memory with data the attacker chose.

To set this off, an attacker only has to send one crafted error message to the machine's address while it is in the middle of a network boot. No password or existing access to the machine is needed.

The simple result is a crash: the boot hangs, and the machine fails to start. Getting code to run is much harder and far less reliable. The advisory says that an attacker who knows the exact firmware build can plant a "counterfeit event" that causes the firmware to run the attacker's own code, so an exploit has to be built for a specific build.

When code runs, it executes within the firmware, before Secure Boot and other boot-time checks have verified anything. That timing is what makes the flaw serious.

Code planted this way runs only once and does not survive a reboot by itself. That single run is still enough to install other code that does start on every boot.

Who Is Affected

The bug sits in EDK II up to and including edk2-stable202608, the newest stable version, dated August 21. EDK II is the reference code that nearly every UEFI firmware vendor builds on, including the independent BIOS makers AMI, Insyde, and Phoenix, as well as Microsoft's hardened fork, Project Mu.

The flawed copy loop has been in the code since a commit added in November 2010, The Hacker News found by tracing the project's history.

PXE network boot is turned on by default in EDK II's standard build. The flaw does not affect home or office users who boot only from a local disk. It applies to organizations whose machines boot over a network, primarily servers and data center equipment.

How many shipping products carry the vulnerable code is not known. Intel told Ars Technica that none of its "commercial products currently under security support" are known to be affected, and that it "does not include the affected EDK2 functionality in its reference code," though an OEM board vendor or system maker could add it.

Arm said the flaw "is not directly applicable to Arm's product portfolio." Both companies' own firmware draws on EDK II.

Linux distributions also ship the code. Red Hat lists its edk2 package in Red Hat Enterprise Linux 8, 9, and 10 as affected and not yet fixed, and SUSE and Debian mark their equivalent packages the same way.

AMD, Phoenix Technologies, AMI, Microsoft, and Amazon did not answer the tech news site's questions before publication, and TianoCore did not respond either, so the status of their products remains unclear.

Is There a Fix?

A fix has been merged into the EDK II source code. It rewrites the faulty copy so an oversized message is cut off at 504 bytes instead of spilling over, and it reached the main development branch on October 15.

No stable release of EDK II includes that fix yet. The Hacker News checked the project's release tags on October 28 and found the newest, edk2-stable202608, predates it, and the advisory still lists the patched version as "Not patched currently." Microsoft's Project Mu has already pulled the fix into its release branches, and cut tagged builds on October 26.

Even with the fix public in source, a server operator has nothing to install until the maker of their firmware ships a BIOS or UEFI update built from it. That step is at least straightforward, Jesse Michael, a principal researcher at the firmware security firm Eclypsium, told Ars Technica: unlike Secure Boot bypasses such as BootHole and BlackLotus, the flaw "can be fixed with a basic code fix" and does not require certificate or key revocations.

Until that update arrives, the advisory lists no workaround. Because the flaw can only be reached during a network boot, operators who do not need PXE can disable it to reduce exposure. Ars also advised watching boot-time network traffic and logs for signs of attempts.

How It Became Public

The flaw was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, the advisory credits. A coordinated disclosure had been planned for January 2027.

That plan was overtaken on September 28, when a pull request to EDK II, signed off by an AMI engineer, publicly described the flaw by its CVE number and included the fix. Once the people who found it saw the post, TianoCore published its advisory on October 22, weeks before the planned date.

With the patch public, Ars noted that skilled attackers can study it to determine how the flaw is triggered and build working exploits.

There is no sign the flaw has been used in an attack. It was not in CISA's Known Exploited Vulnerabilities catalog as of its October 27 update, and no researcher has reported seeing it exploited.

The flaw is also not, on its own, a way into a network, Ars Technica reported after putting questions to several firmware researchers. The realistic attacker is an insider, or someone who has already gained a low-level foothold on the local network and wants to dig deeper.

"An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint's TPM," said HD Moore, the creator of Metasploit and chief research officer at the security firm Dragos, in comments to Ars Technica.

"This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario)."

It is not the first serious flaw in EDK II's network-boot code. In January 2024, researchers disclosed PixieFail, a set of nine flaws in the same part of EDK II, also reachable during PXE boot. Ars reported that fuzzing projects started after PixieFail to find more bugs in the code did not catch this one.

Hackers Target Critical Oracle E-Business Suite RCE Flaw Days After Security Patch (2026)

Wed, 28 Oct 2026 18:18:03 +0530

Threat actors are beginning to probe for a newly patched critical vulnerability in Oracle E-Business Suite (EBS), according to threat intelligence firm Defused Cyber.

The vulnerability in question is CVE-2026-101767 (CVSS score: 9.8) , a case of improper authentication in the Oracle Application Object Library of Oracle E-Business Suite. It was patched by Oracle last week as part of its Critical Patch Update.

Security researchers Brandon Peterson, Jimi Sebree, and Noah King of Horizon3.ai have been credited with discovering and reporting the flaw to Oracle on July 24, 2026.

"Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767, an unauthenticated SQL injection in EBS's Thin Client Framework servlet that chains to remote code execution, this morning, October 27," Defused Cyber said in an X post.

In an advisory for the vulnerability, Horizon3.ai described it as an unauthenticated SQL injection vulnerability that could be chained to achieve remote code execution.

"The vulnerability allows an attacker with network access to the affected Thin Client Framework (TCF) servlet to execute SQL as the APPS database user, then run operating system commands as the EBS application account," the cybersecurity company said.

Specifically, an attacker can issue a crafted request to the vulnerable TCF servlet at "/OA_HTML/AppsTCFServer" to run SQL with the privileges of the APPS database user and ultimately enable system command execution with the privileges of the EBS application account.

Successful exploitation of CVE-2026-101767 can permit an attacker to read or modify application data accessible to APPS and execute commands on the application host.

"Depending on the deployment, affected data may include financial, payroll, HR, and procurement records. Operating system access is governed by the permissions of the compromised EBS application account," Horizon3.ai warned.

While internet-facing EBS deployments present the most risk, internal EBS systems can also be exploited if an attacker can reach the vulnerable servlet from a compromised system or another accessible network segment.

Users are advised to update to the latest version as soon as possible. If immediate patching is not an option, the following workarounds can be applied -

Remove /OA_HTML/AppsTCFServer, associated with oracle.apps.fnd.tcf.SocketServer, from the EBS URL firewall allowlist.
Restrict access to the EBS web tier to trusted networks.
Monitor the EBS application host and database for signs of compromise.

Horizon3.ai has also shared the below indicators of compromise -

Unauthenticated POST requests to /OA_HTML/AppsTCFServer that instantiate the Gantt data-server class (oracle.apps.jtf.gantt.server.GanttDataServer), followed by backend database activity.
SQL reconnaissance shortly after unauthenticated web requests (database version, current user, directory objects).
Unexpected files in $APPLPTMP and the oracle account spawning /bin/sh via the Concurrent Manager to run OS commands.

Vulnerabilities in EBS are a hot target for attackers. Over the past year, two critical flaws in the same product (CVE-2025-61882 and CVE-2026-46817, CVSS scores: 9.8) have come under active exploitation, with the former leveraged by the Cl0p ransomware and extortion crew.

PHP2Shell Attack Roots 25 Servers, Breaches U.S. Government-Affiliated Network (2026)

Wed, 28 Oct 2026 21:32:45 +0530

Cybersecurity researchers have disclosed details of what appears to be an artificial intelligence (AI)-assisted attack orchestrated by a suspected China-nexus threat actor that has leveraged the PHP2Shell vulnerabilities to breach exposed systems.

The activity, which was observed on October 25, 2026, involved an attacker combining PHP2Shell with a kernel privilege escalation exploit to root 25 servers, including three systems in a U.S. government-affiliated environment.

"The affected devices run specific versions of a large vendor's firewall software," cybersecurity firm Dream said. "The attacker then launched attacks against Active Directory. The recovered artifacts confirm credential extraction and directory enumeration."

The name of the affected vendor was not disclosed, but the Israeli company said it notified the entity. The attack chain essentially brings together two sets of vulnerabilities impacting PHP and the Linux kernel -

PHP2Shell, a pair of flaws tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS scores: 9.2) that could result in unauthenticated remote code execution
Fragnesia, a Linux kernel local privilege escalation vulnerability tracked as CVE-2026-46300 (CVSS score: 7.8)

"The implementation we recovered is a custom, non-public build, not a copy of any known public exploit for PHP2Shell," Dream researchers explained. "It follows the same underlying concept but appears to have been independently developed and tailored specifically for the targeted firewall platform."

"The vulnerability targets PHP's session.upload_progress mechanism on the firewall's appweb management server. The firewall OS uses PHP 8.0.30 with a high memory limit that enables the memory corruption stages of the attack."

The custom weaponization of the PHP2Shell exploit chain, coupled with CVE-2026-46300, is said to have rooted 25 servers across the U.S., Japan, Taiwan, and South Korea.

Artifacts discovered by Dream indicate that the operation started with exploit development in a lab environment before obtaining persistent access to a U.S. government organization's internal Active Directory domain.

"Once rooted, the attacker zeroed in on three specific servers in a U.S. government-affiliated environment," the company noted.

The links to AI-assisted tooling stem from evidence pointing to the installation of Anthropic's Claude Code in the attack infrastructure, along with the presence of API keys for FOFA and an AI-powered offensive security platform called aiscan configured with large language models (LLMs) from DeepSeek and Kimi.

What's more, the code structure, commenting style, and consistency across nearly 40 scripts suggest the use of AI to augment the development process. The entire operation, per Dream, unfolds as follows -

Attacker uses FOFA to identify approximately 19,000 internet-facing firewalls with exposed management interfaces worldwide.
A custom version scanner is executed to determine which among those devices are online and what operating system version they are running. About 5,000 devices respond with the version information.
The attacker filters the servers to those located in the U.S., Japan, Taiwan, and South Korea, and then limits the scope to systems that match newer release branches running PHP 8.0.30. This step yields 240 targets.
The target list is fed as input to an automated batch runner that exploits the PHP2Shell-Fragnesia chain, plants a PHP web shell on a publicly accessible directory on the firewall, verifies root access, and logs the target's hostname and IP to a CSV file. This step allows the attacker to gain root access to 24 servers.
Two of the successfully compromised systems are identified as belonging to a U.S. government-affiliated organization. One of them crashes shortly after it was rooted on October 23, 2026, at 6:14 p.m. UTC and never comes back online. The attacker carries out a dedicated campaign to successfully root a second system on October 24, 2026, at 10:09 a.m. UTC.
The attacker exploits the second system to build a persistent channel into the internal network via a reverse SSH tunnel connecting the compromised firewall back to the operator's infrastructure. At 11:35 a.m. UTC, a third government server is compromised using the same method, the only difference being that this was an internal firewall management server only reachable through the tunnel. The total number of rooted servers reaches 25.
The attacker targets Active Directory to decrypt the LDAP service account password, enumerate users, and spray passwords against every user account using organization-themed passwords in an attempt to extract credentials. The operation also attempts to create backdoor Active Directory accounts.

It's unclear if the activity allowed the threat actor to successfully find valid credentials or create backdoor accounts. As a result, the full extent of the compromise remains indeterminate.

"Since [the] U.S., Japan, Taiwan, and South Korea are the four primary strategic adversaries and intelligence targets for Chinese state-aligned cyber operations in the Pacific theater, this indicates potential nation-state adversary efforts," Dream said.

"The operation illustrates how an exposed management interface can become a path into an organization's identity infrastructure. The 22 other rooted firewalls remain parked with active web shells. The persistent tunnel into the US government organization is likely still running. And the attacker still has 19,000 fingerprinted targets they can revisit as they develop profiles for additional OS versions."

The disclosure comes as the PHP2Shell vulnerabilities have witnessed only limited exploitation in the wild, with threat actors highlighting the challenges in converting a proof-of-concept (PoC) into a reliable attack vector against real targets despite integrating them into their campaigns.

"In practice it's unexploitable crap. To exploit real targets you need the offsets from libphp.so, which are unique to every build and impossible to brute-force. You can reproduce it on your own test bench, or if you already have access to the target's file system," a member who goes by the handle c0d3x on the XSS forum said, according to Flare.

Researcher Reveals How Logic Bugs Alone Cracked Microsoft Edge in $175,000 Pwn2Own Win (2026)

Wed, 28 Oct 2026 21:53:34 +0530

A chain of logic flaws, with no memory corruption, can turn a malicious web page into code running on a Windows computer outside Microsoft Edge's sandbox, a security researcher has shown.

Orange Tsai of DEVCORE published the full method on October 28, five months after the chain won $175,000 at the Pwn2Own Berlin contest in May. Microsoft fixed the Edge bugs the day after the contest, so an up-to-date browser is not at risk.

A browser sandbox is the wall that keeps a web page's code inside the browser and off the rest of the computer. Breaking out of it, and then running a program, is what turns a web bug into full control of the machine.

Browser escapes like this almost always rely on memory corruption. This one used none. In his write-up, Tsai describes a chain built solely from logic errors in how Edge and Windows handle ordinary features, and he says the whole exploit is under 100 lines of code.

The result is a universal cross-site scripting (UXSS) primitive: a way to run JavaScript on any website, bypassing the content security policy meant to prevent it.

Because the attack starts from the browser's own process, it can reach sites like google.com that an ordinary web bug cannot touch. Tsai calls this a new attack surface rather than a one-off bug.

This was a competition exploit, not an attack seen in the wild. Tsai demonstrated it on stage at Pwn2Own; there is no evidence it has been used against real users, and the public CVE records list exploitation as none. One step in the chain restarts the browser, which Tsai notes is a convenience for the contest and not needed in a real attack.

The chain begins with an Edge feature for business sign-ins called a conditional access navigation throttle. Tsai found that triggering it lets the browser's own process start a new navigation that is not tied to the page that asked for it, so Edge attaches it to whichever tab is open. That mismatch is the first bug, and it produces the UXSS.

Making it run without a click took four more weaknesses. Edge checked that the request came from a trusted Microsoft site, but Tsai bypassed the check by opening the request from a second window. Edge's popup blocker should have stopped that window, but Edge carried a hardcoded list of allowed addresses, and one of them opened the popup.

The attack also required the victim to be already signed in, which the Edge auto-sign-in feature provides on its own when the user visits a Microsoft site. Lastly, the chain reads the victim's email address from a Microsoft site, assets.msn.com, which returned it to any website due to a misconfigured cross-origin setting.

Running JavaScript everywhere is still not in control of the computer. To escape the sandbox, Tsai used Edge's reading mode, Immersive Reader, which runs under a custom read:// address that Microsoft left off the list of pages barred from running scripts.

From there, the chain called an internal Edge function meant to zip up diagnostic logs and abused it to write a file with an attacker-chosen name and content anywhere on disk.

That file write is turned into code execution in two steps. The chain overwrites a configuration file that controls which websites may launch which protocol handlers, then restarts Edge so the file is read. It then launches a telnet:// link; because Windows does not ship a telnet program by default, it searches the system path for one and runs an attacker-planted copy from a folder the low-privileged user can write to.

Microsoft shipped the fix on May 15, the day after the contest, in Edge Stable version 148.0.3967.70. That release carried three Edge-specific fixes, tracked as CVE-2026-45492, CVE-2026-45494, and CVE-2026-45495. The first is recorded as a security feature bypass, and the second as a spoofing bug, both affecting Edge versions before 148.0.3967.70.

Microsoft's records rate the first two at 5.4 on a 10-point scale, a medium score that reflects a single bug in isolation, not the full chain that strings them into code execution. DEVCORE said the fix came within 24 hours of the disclosure.

Updating Edge closes this chain. Because the fix shipped in May, a browser on automatic updates has long since received it, and no separate action is needed.

Tsai built the chain by hand, over about two months, without any AI help, and frames the work as a point about where human research still matters. "The hard part is finding them, and once you find them all, chaining is the easiest part," he writes of the logic bugs. The research won the 2026 Pwnie Award for Epic Achievement.

Google to Allow One-Tap Android App Installs From Approved Third-Party Stores Outside U.S. (2026)

Wed, 28 Oct 2026 22:38:09 +0530

Third-party Android app stores can now apply to Google for permission to install apps with one tap, without Android's usual confirmation screens, and to update them in the background.

To qualify, a store must pass identity checks and send Google its full catalog, along with every new app and update, for ongoing malware scanning. Approved stores get the features from December 1, but only on devices running Android 17 QPR2 or later in supported countries, which do not include the US.

Today, a user installing apps from a third-party store must first enable the store to install apps, then confirm each install and each update. From December 1, a store in Google's Registered App Stores program gets that permission automatically once it is approved, and its updates run in the background under the user's own update settings.

Google announced the program in March, alongside changes it said resolved its disputes with Epic Games. Joining is optional, and stores that stay out will continue to operate as they do today.

Under Google's rules, the store must still get the user's explicit consent for each install and "must not install apps silently without user consent." Large downloads and background installs must show a visible notification while they run.

If an install is started on another device, the store must show a notification that does not close automatically.

IT administrators can block registered stores from being installed on managed devices. Google's program pages do not say whether the block also applies to a store that is already installed.

Beyond the catalog scanning, Google's requirements say a store must:

be registered as an organization and keep its developer identity verified under Android developer verification, Google's identity check for app developers
send every version of its own app to Google for malware screening, exactly matching the version it publishes on the web and through other channels
work to keep malware and other potentially harmful apps out of its catalog
fix major security flaws that come to its attention
not block other app stores from being installed, interfere with them, or hide or change Android's security notifications
pay a $10,000 yearly fee, due before Google starts its review

Each store stays responsible and liable for everything in its catalog. Google won't moderate the content in registered stores.

If more than 1% of install attempts or more than 2% of a store's apps are found to be potentially harmful over a 30-day period, Google charges additional fees to screen and clean up the catalog.

A store that fails to meet any requirement, including paying on time, can be removed from the program until the issue is resolved. Google gives notice and a chance to fix it first.

Google's program pages do not describe how submitted apps are scanned, how quickly new uploads are checked, or what results the checks produce.

Registered stores also get a Google tool, the Android Developer ID API, to check whether each app in their catalog comes from a verified developer and can be installed. Google recommends that stores block installs of apps that fail the check.

Android developer verification is a separate Google program, now in its first phase with seven app stores. Since September 30, certified Android devices in Brazil, Indonesia, Singapore and Thailand have checked that apps from those stores come from verified developers, according to Google. Google plans to extend the checks worldwide in 2027.

Availability follows each user's home country. Short trips to unsupported countries do not turn off one-tap installs or automatic updates.

Android 17 QPR2 is one of Android's quarterly platform releases (QPRs). Its latest version, released October 16, is still a beta, and Google's release notes give no date for the final release.

In the US, a separate Google program for distributing third-party stores through Google Play has been in effect since July 22.

Volt Typhoon Used Covert Silent Train Network in Four Zero-Day Exploitation Campaigns (2026)

Wed, 28 Oct 2026 23:38:33 +0530

The China-nexus cyber espionage group known as Volt Typhoon has been attributed to a now-disrupted covert access network dubbed Silent Train that has been put to use for zero-day exploitation and strategic access.

"First identified in late 2023, Silent Train uses rotating chains of compromised SOHO, IoT, and enterprise infrastructure," Lumen Technologies Black Lotus Labs said in a report shared with The Hacker News. "It employs anti-forensic techniques, compartmentalized operations, and post-operation cleanup to minimize detection and attribution."

Its main purpose is to facilitate critical attack phases like vulnerability exploitation, credential access, data exfiltration, and to maintain continued access to victim environments. The activity stands out for two main reasons -

It singled out entities that could provide scalable access to downstream customers, sensitive networks, or strategic programs.
It targeted endpoint management platforms, network management systems, SD-WAN orchestrators, and control plane technologies that play a crucial role within enterprise environments.

Hundreds of victims have been identified across telecommunications providers, government, defense contractors, satellite and mission-critical communication services, universities, IT firms, and critical infrastructure such as water, energy, transportation, maritime, rail, aviation, and emergency services.

Volt Typhoon (aka Bronze Silhouette, Insidious Taurus, UNC3236, Vanguard Panda, and Voltzite) is the moniker assigned to a China-linked state-sponsored group known for its targeting of critical infrastructure networks, particularly communications, energy, transportation, and water and wastewater systems sectors.

Known to be active since at least 2021, the threat actor was previously observed exploiting a file upload vulnerability in Versa Director as a zero-day (CVE-2024-39717) to deliver a bespoke web shell called VersaMem designed to harvest credentials and enable access to downstream customers.

Silent Train session chains through multiple non-U.S. and U.S. hops

The latest findings from Black Lotus Labs show that the security flaw was one among four confirmed zero-day campaigns the threat actor has conducted through Silent Train. The remaining three vulnerabilities are listed below -

CVE-2025-8875 and CVE-2025-8876 - A set of insecure deserialization and command injection vulnerabilities in N-able N-central
CVE-2026-20127 - An authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller
CVE-2026-16812 - An operating system command injection vulnerability in Arista VeloCloud Orchestrator

Separately, Volt Typhoon is also suspected to have taken advantage of a likely zero-day vulnerability in Quest KACE before it was patched in October 2025. The campaign is estimated to have impacted more than 30 victims.

"Silent Train is built around rapidly rotating chains of compromised SOHO, IoT, and enterprise devices that are exploited on demand, used against carefully selected targets, cleaned up after each operation, and continuously refreshed," Black Lotus Labs said.

"This model has enabled Volt Typhoon to conduct exploitation and post-exploitation operations with exceptional operational security while minimizing opportunities for detection, attribution, and disruption."

A defining characteristic of these attacks is the repeated targeting of systems that can open the door to broad visibility, control, and access across large enterprise environments of strategic value to the U.S.

What's interesting is that the covert access capability began to take shape sometime around November 2023, just weeks before the first round of disruption targeting KV-botnet, an IoT botnet linked to multiple China-nexus state-sponsored threat actors, including Volt Typhoon.

Silent Train's operational activity is said to have surged in the wake of the botnet's second disruption in late January 2024, while simultaneously shifting to an ephemeral infrastructure comprising diverse device types and across geographies.

"Rather than continue using persistent infrastructure, Volt Typhoon shifted to a model using one-time-use chains of compromised devices that it could rebuild as needed," Black Lotus Labs said. "Volt Typhoon rapidly assembled and dismantled transient infrastructure, creating a resilient, secure, and compartmentalized framework that protected valuable access."

Sector distribution of organizations targeted through Silent Train

Described as a "layered, multi-hop framework," Silent Train is designed to let Volt Typhoon operators relay malicious traffic through several devices before it reaches the targets so as to obscure its origins from both victims and defenders. Each link in the chain serves a specific purpose -

Virtual private servers (VPS) that function as a temporary staging area and allow threat actors to provision and discard them after each session. The sessions begin from VPS infrastructure located outside the U.S.
Compromised non-U.S. SOHO and IoT devices located across different countries, providers, and hardware that conceal the starting point of the attack.
U.S.-based compromised devices that function as an exit node before reaching the domestic victim and help evade geofencing and IP reputation blocklists.

No less than 27 device classes, ranging from SOHO and IoT devices (e.g., TP-Link, Intelbras, Ruckus Wireless, SATO, NETGEAR, Zyxel, and Cambium) to enterprise platforms (e.g., Fortinet, Cisco, PRTG, Mirth Connect, and CyberPanel), have been exploited and enrolled into the covert network.

"Silent Train stands out for its operational discipline, focusing on short-lived, selfmanaged sessions rather than persistent relays or C2 infrastructure," Black Lotus Labs said. "To construct these sessions, its operators exploit exposed web interfaces on SOHO, IoT, and other relay devices, then deploy only the tooling needed to enable chained SSH access through the compromised node."

"This included temporary SSH services, keys, configuration files, and 'live off the land' utilities. At the end of operational sessions, they removed every artifact and dismantled the operational chain in their wake. Silent Train sessions lasted about four hours on average, with some lasting only minutes."

Another notable aspect is the designation of certain device types to specific positions within Silent Train. For instance, Intelbras modems have been found to only appear as relay nodes, while Netgear Orbi and Fortinet FortiGate appliances served as U.S.-based intermediary and exit points responsible for interacting with the victim.

Put differently, the infrastructure points to deliberate compartmentalization across layers, confining some device types to certain roles that remain constant while the underlying infrastructure itself changes over time so as to complicate attribution efforts.

By early 2025, however, Silent Train is believed to have evolved from a completely ephemeral relay network to a hybrid architecture that retained enterprise-grade devices for an average of one to three months instead of changing them after each engagement.

Subsequent maturation of the platform introduced reverse-tunnel variants that used open-source proxies like Chisel and FRP to send traffic from infected devices to upstream infrastructure.

Within the U.S., Hawaii, California, and Texas have emerged as the focus areas of Silent Train operations, which boils down to the fact that these states host major military installations, telecommunications infrastructure, defense contractors, satellite communications providers, and critical logistics networks.

"Victimology indicates deliberate efforts to maintain access to critical ecosystems that support defense, logistics, communications, military and civilian operations, especially during heightened tensions or crises in the Indo-Pacific region," Black Lotus Labs said.

"The resulting picture is one of a highly structured framework built to acquire, protect, and sustain strategic access at scale. Through repeated targeting of centralized management platforms and control plane technologies, Silent Train shows how Volt Typhoon systematically pursues and preserves access to some of the most consequential networks in the United States."

Attackers Exploit PHP2Shell Flaws in Internet-Exposed Palo Alto Networks Management Interfaces (2026)

Thu, 29 Oct 2026 11:20:17 +0530

Palo Alto Networks on Wednesday warned that threat actors are exploiting the recently patched PHP2Shell vulnerabilities against publicly-accessible management interfaces.

"Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet," the network security company said in an update to its advisory.

The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS scores: 9.2), allow attackers to achieve unauthenticated remote code execution on systems running affected versions of PHP. The issues were patched upstream by the PHP Foundation on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

The development comes days after Israeli cybersecurity company Dream said it observed a suspected China-nexus threat actor weaponizing the flaws in conjunction with a local privilege escalation bug in the Linux kernel, tracked as Fragnesia (CVE-2026-46300, CVSS score: 7.8), to root 25 servers across the U.S., Japan, Taiwan, and South Korea.

Among those were three systems belonging to a U.S. government-affiliated environment.

"The affected devices run specific versions of a large vendor's firewall software," Dream noted. "The attacker then launched attacks against Active Directory. The recovered artifacts confirm credential extraction and directory enumeration."

Although Dream did not disclose the name of the affected firewall vendor, the timing of the advisory, combined with the fact that other network security companies have not reported malicious exploitation against their products, suggests that these events may be related.

The Hacker News has contacted both Dream and Palo Alto Networks for comment, and we will update the story if we hear back.

The development has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2026-46300 to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply the fixes by October 31, 2026.

"This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP web shells and run commands as root," CISA said.

Palo Alto Networks has also noted that no special configuration is required to be affected by this issue, adding the risk is highest on PAN-OS when access to the management interface is allowed from external IP addresses on the internet.

"This issue strictly affects the management web interface, which includes the HTTPS web UI and XML API service," it said. "It affects the dataplane interface only if a management profile is attached to it."

The following versions of PAN-OS are impacted by PHP2Shell -

PAN-OS 12.2
- < 12.2.4-h1 (Fixed in >= 12.2.4-h1)
PAN-OS 12.1
- < 12.1.4-h13 (Fixed in >= 12.1.4-h13) (ETA: 10/29)
- < 12.1.7-h11 (Fixed in >= 12.1.7-h11)
- < 12.1.10-h3 (Fixed in >= 12.1.10-h3) (ETA: 10/30)
PAN-OS 11.2
- < 11.2.4-h23 (Fixed in >= 11.2.4-h23) (ETA: 10/30)
- < 11.2.7-h23 (Fixed in >= 11.2.7-h23)
- < 11.2.10-h16 (Fixed in >= 11.2.10-h16)
- < 11.2.13-h4 (Fixed in >= 11.2.13-h4)
- < 11.2.16-h1 (Fixed in >= 11.2.16-h1)
PAN-OS 11.1
- < 11.1.4-h38 (Fixed in >= 11.1.4-h38)
- < 11.1.6-h40 (Fixed in >= 11.1.6-h40)
- < 11.1.7-h12 (Fixed in >= 11.1.7-h12) (ETA: 10/30)
- < 11.1.10-h36 (Fixed in >= 11.1.10-h36)
- < 11.1.13-h16 (Fixed in >= 11.1.13-h16)
- < 11.1.16-h4 (Fixed in >= 11.1.16-h4)
PAN-OS 10.2
- < 10.2.7-h39 (Fixed in >= 10.2.7-h39) (ETA: 10/30)
- < 10.2.10-h42 (Fixed in >= 10.2.10-h42) (ETA: 10/29)
- < 10.2.13-h27 (Fixed in >= 10.2.13-h27)
- < 10.2.16-h12 (Fixed in >= 10.2.16-h12)
- < 10.2.18-h13 (Fixed in >= 10.2.18-h13)

For PAN-OS versions where fix versions are not yet available, Palo Alto Networks has recommended the following mitigations -

Route incoming traffic for the MGT port through a DP port, e.g., enabling management profile on a DP interface for management access.
Replace the Certificate for Inbound Traffic Management.
Decrypt inbound traffic to the management interface so the firewall can inspect it.
Enable threat prevention on the inbound traffic to management services.

"Customers with Frontier Virtual Patching (ATP Plus) on PAN-OS 12.2.4 and later versions received advance coverage, released via Threat ID 543004, which was released at 10:21 PM PT on October 20," it said.

"The security risk posed by this issue on PAN-OS and Panorama is minimized by restricting access to the management interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines."

Palo Alto Networks Confirms Dream Report

“We are aware of the report from Dream describing unauthorized exploitation activity targeting internet-facing PAN-OS management interfaces," a spokesperson for Palo Alto Networks told The Hacker News.

“Customers who have applied the available patches are not affected. Furthermore, customers who follow our standard recommendation to not expose the management interface to the public internet are also not affected."

In an update to its threat brief, Palo Alto Networks is recommending customers follow the steps below -

Immediately remove public internet access to management interfaces if it is enabled.
Restrict access to trusted internal IP addresses.
Apply available PAN-OS fixes addressing PHP2Shell.

"Based on data from our Xpanse attack surface management product, only a small fraction of a percent (less than .01%) of our global installed base has internet facing management interfaces configured, and each of these potentially affected customers has been individually contacted by our teams," the spokesperson added. "We will continue to investigate and provide any necessary updates as they become available."

(The story was updated after publication to include a response from Palo Alto Networks.)

China-Linked Hackers Exploited VMware ESX Zero-Day to Reduce Audit Trail Visibility (2026)

Thu, 29 Oct 2026 11:52:33 +0530

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added a security flaw impacting Broadcom VMware ESX to its Known Exploited Vulnerabilities (KEV) catalog, after CrowdStrike revealed that it had been weaponized by a China-nexus threat actor known as Warp Panda in attacks targeting the U.S. legal sector.

The vulnerability in question is CVE-2026-41709 (CVSS score: 2.7), an a case of insufficient logging that could permit permit a malicious actor with admin access to perform certain operations without being logged.

In an advisory released in July 2026, Broadcom revealed that the issue was addressed in the following versions -

VMware Cloud Foundation SXi-9.1.0.0-25370933 and ESXi-9.0.2.0100-25595025
VMware vSphere Foundation SXi-9.1.0.0-25370933 and ESXi-9.0.2.0100-25595025
VMware ESX ESXi80U3j-25429389
VMware Cloud Foundation 5.2.4
VMware Telco Cloud Platform ESXi80U3j-25429389

The development comes in response to CrowdStrike's 2026 Legal Threat Landscape Report, which revealed that Warp Panda had exploited CVE-2026-41709 as a zero-day in early 2026 with an aim to reduce audit trail visibility.

Warp Panda "exploits internet-facing edge devices using zero-day vulnerabilities and custom malware to maintain covert, persistent access," it said in the report shared with The Hacker News, adding the adversary "actively circumvents detection by bypassing audit logging, harvesting cloud session tokens, and registering rogue multi-factor authentication (MFA) devices."

The threat actor, also tracked as Armory Castle (formerly UNC5221), Clay Typhoon, and VerdantBamboo, has a storied history of weaponizing zero-day vulnerabilities in Citrix NetScaler and Ivanti Connect Secure devices.

Earlier this month, Google-owned Mandiant also attributed the hacking crew to the zero-day exploitation of a critical improper origin validation flaw in BeyondTrust Remote Support (CVE-2026-102764, CVSS score: 9.3) to deliver malware families like SAWFLY and BARECLAW.

Attacks mounted by Warp Panda involve the exploitation of internet-facing edge devices to obtain initial access, after which the threat actor pivots to VMware vCenter environments to deploy custom malware like BRICKSTORM and SharpStorm to maintain persistent access without attracting attention.

Select intrusions have also involved the targeting of cloud services with an aim to extract user session tokens to access Microsoft 365 environments sans raising any credential-based alerts. In at least one case, Warp Panda is said to have registered a new MFA device on a compromised account as a way to set up persistent access even if the password is changed.

"Warp Panda represents a sustained and strategically focused China-nexus cyber espionage threat to U.S. entities across multiple sectors, including the legal sector," CrowdStrike said.

"The legal sector's concentration of client communications, merger and acquisition materials, active litigation strategy, and cross-client access makes it a high-value collection target for a state-directed adversary seeking intelligence with downstream operational utility."

In light of active exploitation of CVE-2026-41709, Federal Civilian Executive Branch (FCEB) agencies are recommended to apply the fixes by November 11, 2026.

Hackers Exploited Cisco SD-WAN Flaw to Plant Malware Built to Steal Encryption Keys (2026)

Thu, 29 Oct 2026 13:54:22 +0530

Hackers exploited a critical Cisco Catalyst SD-WAN flaw, fixed in February, to plant custom malware inside the systems that control an organization's SD-WAN network.

The malware, called KeyDrift, is designed to copy the keys that encrypt traffic between sites and store them for later use, Cisco Talos said on October 28. Talos calls the attacks historical but does not specify when they occurred or whether any keys were sent.

The flaw is tracked as CVE-2026-20127 and has a CVSS score of 10.0. It allows an unauthenticated remote attacker to bypass authentication and gain administrative privileges on these control systems. On a Controller, the attacker can log in as a high-privileged internal account that is not root.

When Cisco disclosed the flaw in February, Talos tracked its exploitation as UAT-8616, a cluster of activity it said went back to at least 2023.

In Cisco's traditional key exchange, each SD-WAN router periodically generates an AES key for its traffic and sends it to the Catalyst SD-WAN Controller (formerly vSmart). The Controller passes the keys on to other routers. A process on the Controller called vdaemon runs the encrypted control connections that carry these keys.

On a compromised Controller, a KeyDrift component called LittleFilch hooks into vdaemon and reads control messages after they are decrypted. For a preset list of edge routers, it pulls out their IP addresses and a 32-byte field. Talos assesses that field as the AES-256 key material that the Controller passes between routers.

LittleFilch encrypts what it collects with RSA and writes it to a file. It can then send that data over UDP to an address listed in a settings file, which it deletes after reading. Talos could not recover that settings file.

The group behind KeyDrift, which Talos tracks as UAT-11473, has targeted space and satellite services, defense and aerospace technology, and policy research.

The group's infrastructure "overlaps considerably" with Silent Train, Talos assesses with high confidence. Silent Train is the name Lumen's Black Lotus Labs uses for a network of hacked small-office, home-office, IoT and business devices.

Lumen says Volt Typhoon used the network to hide its activity. CISA, the NSA and the FBI said in 2024 that Volt Typhoon is a Chinese state-sponsored cyber group.

Talos links UAT-11473 to Volt Typhoon only through the infrastructure overlap. It does not say the two are the same group, or how UAT-11473 relates to UAT-8616, the cluster it reported in February.

Separately, Lumen said on October 28 that Volt Typhoon was exploiting CVE-2026-20127 by late 2025 and continued to exploit it after Cisco disclosed the flaw in February. Lumen does not tie that activity to KeyDrift.

KeyDrift primarily starts via modified runit scripts that Cisco SD-WAN devices use to launch their services, according to Talos. In one version, the script for the SSH service starts a loader script, conf_sshd, before the real SSH server. The conf_sshd script writes vdaemon's process IDs to a file, and a tool called rsshd injects KeyDrift's main module, PolyFlame, into each of those processes.

PolyFlame runs in memory inside vdaemon. It can act as a TinyShell-like backdoor that runs commands and reads and writes files, or as a relay that forwards commands between its command server and other machines. It is built to accept commands within SD-WAN control traffic, and the analyzed samples contained no hardcoded server address.

On a compromised Validator, formerly vBond, a fake aaamgr service under /etc/sv/aaamgr/ runs a packed loader, aaamgrd, that decrypts and runs PolyFlame. Cisco's real aaamgr component is a Python package and does not normally run as a compiled service.

There are also signs of timestomping: commands the group ran copied the timestamps and permissions of existing files onto its own files.

Affected Releases and Fixes

CVE-2026-20127 affects the Catalyst SD-WAN Controller (formerly vSmart), Manager (formerly vManage), and Validator (formerly vBond), regardless of their configuration. On-premises systems are affected, as are Cisco's hosted SD-WAN cloud deployments, including the Cisco Managed and FedRAMP environments. Cisco added the Validator to its advisory on June 16.

Cisco says it is aware of limited exploitation of the flaw. There is no workaround, and the first fixed releases are:

Release train	First fixed release
Earlier than 20.9	Migrate to a fixed release
20.9	20.9.8.2
20.11	20.12.6.1
20.12	20.12.5.3 or 20.12.6.1
20.13	20.15.4.2
20.14	20.15.4.2
20.15	20.15.4.2
20.16	20.18.2.1
20.18	20.18.2.1

Releases earlier than 20.9 and the 20.11, 20.13, 20.14 and 20.16 trains have reached end of software maintenance.

Until they can upgrade, on-premises customers can limit access to ports 22 and 830 to the IP addresses of known controllers and other known systems. Cisco says this step worked in a test environment, but that customers should check how well it works in their own networks. Such guardrails are already in place for Cisco's hosted SD-WAN cloud deployments.

Blocking the ports does not remove malware already on a device.

Checking for KeyDrift

Talos advises organizations to install Cisco's fixes, follow Cisco's Catalyst SD-WAN hardening guide and watch for signs of post-compromise activity. Anyone who finds such signs should start incident response and can ask Cisco's Technical Assistance Center (TAC) for help.

That advice does not say whether upgrading removes KeyDrift from a device that was already compromised, or whether any keys should be replaced. Cisco's February remediation guide for this flaw warns that there could be "existing exploits which are still in place" from before an upgrade.

KeyDrift uses these files and locations, some given only by name:

File: the run script under etc/sv/sshd/, modified to start conf_sshd
Directory: /etc/sv/aaamgr/, a fake service on a compromised Validator
File: aaamgrd, the packed loader
File: conf_sshd, the loader script
File: rsshd, the injector
File: libdssl.so, PolyFlame
File: libcommon.so, LittleFilch
File: /tmp/system-vdaemon, the list of vdaemon process IDs
File: /var/tmp/vdaemon.bin, LittleFilch's encrypted records
File: /var/tmp/vdaemon.conf, LittleFilch's send settings, deleted after reading

Talos's report does not include a list of file hashes, IP addresses or domains for KeyDrift.

Talos released Snort rules on October 28 that look for inbound KeyDrift command-and-control connections: 67387 through 67416 for Snort 2, and 7:44 through 7:73 for Snort 3. Rules 65938 and 65958, already available, cover CVE-2026-20127 itself.

The October 28 rule update lists the Snort 2 rules as disabled by default, so users of the paid Snort Subscriber rule set must turn them on. The Snort 3 rules appear with no default state.

To check for exploitation of the flaw itself, Cisco says to look in /var/log/auth.log for Accepted publickey for vmanage-admin entries from unknown IP addresses. Before opening a TAC case, customers should run request admin-tech on each control component. The remediation guide also recommends rescanning those admin-tech files with the Check Bug Applicability feature on the Bug Search Tool page for bug CSCws52722.

For US federal civilian agencies, CISA's February 25 emergency directive sets out what to do if a root account compromise is found. They must report it to CISA, deploy fresh Manager, Controller and Validator instances from patched images, and move their edge routers to the new systems.

Attacker Tried to Exploit Alpine Linux’s GitLab via CVSS 10.0 Flaw Its Ruby Left Open (2026)

Thu, 29 Oct 2026 14:35:39 +0530

An attacker tried to exploit a critical GitLab vulnerability on the Alpine Linux project's own GitLab server a week after GitLab released a fix, Alpine Linux said on 28 October.

The flaw, CVE-2026-97229 (CVSS score: 10.0), can let an attacker run code on a GitLab server through a crafted regular expression in a CI configuration. Alpine found no evidence that the attack worked but cannot rule it out, so it rebuilt the server from scratch and reset every account's password.

GitLab's fix is a set of patches to the Ruby that GitLab ships in its own packages and container images. Alpine's GitLab image used standard Ruby, so upgrading the server to GitLab 19.3.6 on 22 October did not fix the flaw.

For anyone running GitLab on their own Ruby, built from source or in their own container image, "upgrading GitLab is not enough," Alpine said. Those servers also need Ruby 3.3.13, 3.4.12, 4.0.9 or later, and users of Alpine's alpinelinux/gitlab image need to pull 19.3.6 again.

The server gitlab.alpinelinux.org hosts aports, the repository from which Alpine's packages are built. Packages built from 20 to 24 October, and the 21 October releases, came from aports changes verified against records outside GitLab, according to Alpine.

Those releases include the minirootfs files that the official Alpine Docker images are built from. Alpine is extending the checks to 27 October, when it closed the server. The keys that sign its packages and releases have never been on the GitLab server.

How the Attack Unfolded

On 13 October, Alpine upgraded the server to GitLab 19.3.4 instead of 19.3.5, which it calls a mistake. The server was still on that version, without the 12 October fix, when a newly registered account began probing it on 20 October.

The account sent crafted CI configurations to the server on 20 and 21 October. They crashed GitLab worker processes 8 times, and the main attack on 21 October also caused 502 errors and caused CI jobs to fail.

In 4 of those crashes, the attacker got partway through the exploit and failed at the next step, according to Alpine. The attacker also downloaded Alpine's GitLab container image, which Alpine said: "suggests they were tuning the exploit to our exact build."

Alpine blocked the account on 23 October. The attacker came back on 25 and 26 October and tried to get back in, but those attempts failed, Alpine said.

On 26 October, Alpine found that the server was still vulnerable after its 22 October upgrade to 19.3.6. The next day, it closed GitLab to everyone except its developers and build servers and started rebuilding it.

The rebuild finished on 28 October. Alpine also replaced GitLab's secret keys, and the rebuilt server runs Ruby 3.3.13 or later, which has the fix. Alpine is testing it before reopening it to the public.

What Alpine Can and Cannot Rule Out

Alpine found no sign that the attacker's code ran on the server. Timing probes showed no delays;; there were no unexpected files, keys, hooks, or processes; and no private data was sent back to the attacker via any web or API request that Alpine can see.

It cannot be sure, though. "A successful exploit would leave no crash and no trace in the web logs," Alpine said. Some logs from the attack day are gone, including background job logs and the old container's filesystem, and neither Alpine nor its hosting provider logged outbound network connections.

Because the evidence needed to confirm code execution no longer exists, Alpine treated the server as compromised and rebuilt it to remove any foothold a successful exploit could have left.

If the attack succeeded, these could have been exposed:

Email addresses, names, and IP addresses of all users
Password hashes
2FA secrets, CI/CD variables and runner tokens
Webhook, integration and push mirror credentials
Personal access tokens, which are stored as hashes
Private repositories, and confidential issues and merge requests

Beyond the password reset and the new secret keys, Alpine has not said whether runner tokens, CI/CD variables, access tokens or integration credentials stored on the server have been replaced.

To check its packages, Alpine confirmed that every aports change added from 20 to 22 October arrived through a recorded push by a known developer. It checked this against records it says the attacker could not reach: a developer's copy of the repository and all 45 build servers. Every package built from 20 to 24 October came from aports changes as published on git.alpinelinux.org.

Why the GitLab Upgrade Did Not Fix It

GitLab compiles the regular expressions in CI configurations with Ruby, and the bug behind CVE-2026-97229 is in Onigmo, the regular expression engine built into Ruby.

GitLab's 12 October release fixed it by patching the Ruby inside GitLab's Linux package and container images. Ruby's own fixed versions came out on 22 and 23 October.

A GitLab upgrade does not change a server's own Ruby, so a GitLab install on standard Ruby keeps the flaw until Ruby itself is updated to a fixed version, as Alpine found.

GitLab's fixed Linux packages and its official container images carry the patched Ruby. A self-compiled install, or a container image that installs Ruby separately as Alpine's did, does not get it.

As of 29 October, neither of GitLab's patch release posts for 12 and 21 October tells administrators of self-compiled installs to update Ruby. GitLab's self-compiled installation guide still lists Ruby 3.2 as its minimum version, and Ruby 3.2 reached end of life in April and will get no fix.

Which GitLab Servers Are Exposed

GitLab's advisory says that, "under certain conditions," the flaw could have allowed an unauthenticated user to run code on the server. GitLab.com and GitLab Dedicated are already patched.

Rapid7 built a working exploit in a lab and published proof-of-concept code on 13 October. The exploit ran commands as GitLab's git user on an unpatched official GitLab 19.4.1 image, but the same input did not run on the patched 19.4.2 image.

That exploit needs write access first: the attacker must commit a malicious .gitlab-ci.yml file and a file path with UTF-8 characters to a branch of a public project. That requirement does not apply on servers where new users can register themselves and create projects.

In Rapid7's tested route, "only the final CI lint request is unauthenticated." GitLab's own detection notes also say the attacker must first create that file path through ordinary repository APIs. Rapid7 does not yet know how the attack in the original report to GitLab, which is still private, avoids the write step.

Alpine has not said how its attacker's CI configurations reached GitLab, or whether new accounts could create public projects on its server.

CVE-2026-97229 was not in CISA's Known Exploited Vulnerabilities catalog as of the catalog's 28 October update.

What GitLab Administrators Should Do

GitLab's 21 October releases are the newest on each branch listed below, and they also fix CVE-2026-110264, a separate regex flaw.

Branch	Fixes CVE-2026-97229, per GitLab's advisory	Newest release (21 October)
19.5	Not listed as affected	19.5.1
19.4	19.4.2	19.4.3
19.3	19.3.5	19.3.6
19.2	19.2.8	19.2.9
19.1, 19.0 and 18.11	Not listed as affected	19.1.9, 19.0.10 and 18.11.13

Which release fixes a server depends on how GitLab is installed:

GitLab's Linux package or official container images: upgrade to the newest release for your branch.
Self-compiled installs, or images that install their own Ruby: upgrade GitLab and update Ruby to 3.3.13, 3.4.12, 4.0.9, or later. Ruby 3.2 will not receive the fix, so servers running 3.2 need to upgrade to one of those versions.

GitLab's advisory named 19.3.4 as the fixed version for the 19.3 branch when it was published on 12 October. It now names 19.3.5 and lists 19.3.4 as affected, so servers still on 19.3.4 should move to 19.3.6.

If a server cannot be upgraded right away, Rapid7 suggests restricting anonymous access to public projects, stopping untrusted users from creating or writing to public projects, or blocking the CI lint route. Those steps cover only Rapid7's exploit route and do not fix the vulnerable regular expression compiler, the company said.

GitLab has published six detection rules for exploitation attempts against self-managed servers, written in the Sigma format. Four of them, which GitLab marks as experimental, look for hostile patterns in CI regexp warnings and GraphQL ciLint requests, unusually long file paths with non-ASCII characters, and Ruby crash reports that point to Onigmo.

The guidance with those rules warns that a successful exploit can leave no crash, and it gives these further steps:

Look for files owned by the git user in /tmp, unexpected child processes of Puma or Sidekiq, outbound connections, and changed crontabs or SSH keys for the git user.
If there are signs of code execution, treat the server as compromised and rotate the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens and all access tokens.
Limit who can create accounts and personal access tokens on the server.

What Alpine Users Should Do

Account holders will need to set a new password with "Forgot your password?" on the sign-in page when gitlab.alpinelinux.org reopens, Alpine said. It has also seen automated login attempts against its GitLab using passwords leaked from other sites, and anyone who used their gitlab.alpinelinux.org password elsewhere should change it there.

Users of the alpinelinux/gitlab image should pull alpinelinux/gitlab:19.3.6 again. The image published on 27 October contains Ruby 3.3.13, while any 19.3.6 image pulled before then, and every older tag, is vulnerable.

Alpine's own Ruby packages already have the fix: Ruby 3.4.12 on Alpine 3.22, 3.23, 3.24 and edge, and Ruby 3.3.13 on Alpine 3.21. Running apk upgrade installs it.

Ruby's maintainers say the bug matters only for programs that compile a regular expression from text an attacker controls, and that Ruby's Regexp.timeout setting does not protect against it.

GitHub Launches npm Firewall to Block Malicious Packages Before Installation (2026)

Thu, 29 Oct 2026 15:56:33 +0530

GitHub has announced that it's introducing a new package firewall as a preview to block installation of suspicious npm packages during installation time.

"The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate," GitHub said.

The feature, which currently supports only npm packages, is available in public preview for all GitHub Enterprise Cloud customers, including data-resident GitHub Enterprise Cloud.

According to the Microsoft subsidiary, the firewall is placed between endpoints or internal registries and the upstream package repositories so as to deter malware attacks that compromise systems when packages are installed.

This behavior can expose users to severe security risks, especially when artificial intelligence (AI) agents and CI runners automatically install dependencies to complete a task or build without their explicit permission.

The idea is that endpoints like coding agents and CI/CD hosts use the firewall for their requests instead of directly pointing to the public package registries. The firewall then checks package downloads against policy controls such as minimum package age and malware advisories, and blocks downloads that do not meet those policies.

To use the firewall, administrators are required to configure policy controls, such as the ones listed below -

Block known malware by checking against the GitHub Advisory Database for active malware advisories
Block packages based on the severity of vulnerabilities by checking the GitHub Advisory Database for flaws that affect the requested package version. The control defaults to "Critical only" as the severity level that blocks an installation, although users can choose "High or higher," "Medium or higher," or "Any severity."
Block attestation downgrades by comparing attestations for the requested package version with those of earlier versions and stop the download if the requested version does not have an SLSA attestation.
Block newly-introduced install scripts by checking whether the package recently added scripts that run using preinstall or postinstall hooks, which can be abused to steal sensitive data.

Block packages based on a cooldown period that prevents versions that are newer than the configured minimum age from being installed. The value can range from 1 to 365 days. The default value is 1 day. Users can disable it by setting it to 0.

Users who need access to a package that gets blocked erroneously by the firewall can submit an exception request, which can then be approved by enterprise administrators and security managers.

The development comes as Rust 1.100, which is scheduled for release on November 12, 2026, readies to add support for a configurable minimum publish age, allowing security scanners and maintainers time to flag and block malicious crate releases before they can be installed or used by users.

The value, defined via the "global-min-publish-age" option in "cargo/config.toml," allows users to specify a minimum publication age in days or weeks. If left unspecified, a seven-day waiting period is applied by default to skip releases published within that window.

Over the past year, similar waiting periods have been implemented across open-source ecosystems, including npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm, and Yarn, as a way to bolster software supply chain security by reducing the chance that a newly published, unreviewed version is immediately pulled into a build.

Cooldown periods help add friction and slow down attacks in which a bad actor publishes a poisoned version of a popular package after seizing control of a maintainer account, thereby preventing rapid spread through manual or automated installations.

"The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception," Socket said. "Malicious code also doesn't magically become harmless with age. A release that escapes detection can simply outlast the cooldown. The value is in buying researchers, maintainers, and registries time to act before the next dependency update carries an attack further."

Cisco Patches Actively Exploited ASA and FTD VPN Flaw That Can Crash Firewalls (2026)

Thu, 29 Oct 2026 16:14:46 +0530

Cisco has released patches to address a high-severity security flaw in Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software that it said has been exploited in the wild.

The vulnerability, tracked as CVE-2026-76418, is rated 8.6 on the CVSS scoring system. Successful exploitation could allow an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial-of-service (DoS) condition.

According to Cisco, the issue is rooted in the Remote Access SSL VPN service of ASA and FTD software.

"This vulnerability is due to logic errors when secondary authentication is configured on a tunnel group," it said in a Wednesday advisory. "An attacker could exploit this vulnerability by sending a crafted request when connecting to the SSL remote access VPN. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a DoS condition."

The network equipment major said it became aware of active exploitation of this vulnerability in October 2026, but did not share any specifics as to when the attacks began, who is behind them, and the scale of the efforts.

Fixes for the flaw are available in the following versions -

Cisco Secure Firewall ASA Software Release
- 9.16 and earlier - Fixed in 9.16.4.104
- 9.18 - Fixed in 9.18.4.96
- 9.20 - Fixed in 9.20.4.50
- 9.22 - Fixed in 9.22.3.200
- 9.23 - Fixed in 9.23.1.48
- 9.24 - Fixed in 9.24.1.27 and 9.24.10.1
Cisco Secure FTD Software Release
- 7.0 and earlier - Fixed in 7.0.11
- 7.2 - Fixed in 7.2.13
- 7.4 - Fixed in 7.4.9
- 7.6 - Fixed in 7.6.7
- 7.7 - Fixed in 7.7.14
- 10.0 - Fixed in 10.0.3
- 10.1 - Fixed in 10.1.1

Cisco also noted that the vulnerability affects Cisco devices if the following conditions are met -

They are running a vulnerable release of Cisco Secure Firewall ASA Software or Cisco Secure FTD Software.
The SSL remote access VPN login service is reachable.
Secondary authentication is configured in the tunnel group scope.

"If tunnel-group-list enable is configured, check all tunnel groups, including the default tunnel group, DefaultWEBVPNGroup, for secondary-authentication-server-group," Cisco said.

"If tunnel-group-list enable is absent or has been removed using the no tunnel-group-list enable command, check the default tunnel group, DefaultWEBVPNGroup, for secondary-authentication-server-group because disabling the group list does not remove exposure when that default group uses secondary authentication."

As a temporary mitigation, the company is recommending that customers turn off the tunnel group list if DefaultWEBVPNGroup does not use secondary authentication, or disable secondary authentication on any user-configured tunnel group list or on the default tunnel group, DefaultWEBVPNGroup.

"On Cisco Secure FTD Software, review the deployed remote access VPN policy and the resulting device running configuration in Cisco Secure FMC Software or Cisco Secure FDM," Cisco said. "A successful VPN login is not required to reach the affected processing path."

The disclosure comes as Cisco revealed that a sophisticated advanced persistent threat (APT) actor tracked as UAT-11473 weaponized CVE-2026-20127, an authentication bypass vulnerability in Cisco SD-WAN Catalyst Controller instances, to bypass authentication and gain unauthorized access to affected systems.

The activity, which has targeted space and satellite services, defense and aerospace technology, and policy research sectors, is assessed to share infrastructure overlaps with Volt Typhoon's Silent Train covert network.

"UAT-11473 then installed a custom malware framework we track as 'KeyDrift' consisting of multiple components [like PolyFlame and LittleFilch] geared towards collecting sensitive keying information, acting as backdoors and intermediate command-and-control (C2) hosts," Cisco Talos said.

"The framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records."

26,400 Valid Cloud and AI Credentials Found Exposed in Public Gitee Repositories (2026)

Thu, 29 Oct 2026 17:03:15 +0530

26,400 credentials that developers left in public code on Gitee, a Chinese code-hosting service, still worked when a researcher tested them. Anyone who copied one from that code could have used it.

Independent researcher Ben Zimmermann found them by scanning 7.25 million public Gitee repositories and reported the results on October 28. Most were keys for cloud and AI services, led by 9,473 Alibaba Cloud AccessKey pairs.

Zimmermann sent the vendors with the most exposed keys a list of their credentials, but he did not contact the developers who leaked them. When he published, he had not confirmed that any of the reported credentials had been revoked. So anyone who has pushed a key to a public Gitee repository cannot assume it has been revoked.

The scan ran for about a month, but Zimmermann did not provide the dates, so it is unclear how long ago the credentials were tested. He also did not say whether anyone else had used them.

He ran two secret scanners, TruffleHog and Kingfisher, over every repository. Both tried each credential against the service that issued it and kept only those that worked, he wrote.

The scanners read each repository's full commit history. A key that a developer later removed from the code could still be found and counted there.

The 26,400 figure counts each credential once, regardless of how many repositories it appeared in. By commit date, 12,242 of the credentials came from 2025, nearly half the total. Some dated to the late 2000s.

What Was Exposed

After the Alibaba Cloud keys, the largest groups were 3,805 YouTube API keys, 3,170 DeepSeek keys, 1,489 keys for Zhipu's BigModel AI platform, and 1,348 OpenAI keys. Smaller numbers were found for GitHub, AWS, Google Cloud and Google's Gemini.

One of the credentials was "an active organization-admin credential for a major enterprise AI platform," Zimmermann wrote. He did not name the platform or say what the credential could reach.

What a working key lets someone do depends on the service. OpenAI says that a compromised key allows another person to use the account's quota without the owner's consent. That can cause "data loss, unexpected charges," a used-up monthly quota, and interrupted API access.

A YouTube API key is a Google Cloud API key that identifies a project, Google says. Without API restrictions, such a key can be used with every API that accepts Google Cloud keys.

What to Do If You Committed Keys

Treat any key that has ever been in a public Gitee repository as exposed, and revoke it at the provider. Deleting a key from the code or rewriting the repository's history does not revoke it, as noted by TruffleHog's maker, Truffle Security.

Alibaba Cloud: create a new AccessKey pair, switch your apps to it, then disable and delete the old pair. Check for unexpected charges and for resources created or deleted that you did not need, Alibaba Cloud's leak response plan says. ActionTrail shows the key's API calls for the last 90 days, but data operations in services such as OSS and SLS have to be checked in each service's own logs.
Google and YouTube API keys: rotate the key, which creates a new key with the same restrictions, update your apps to use it, then delete the old key. Add API restrictions so the key works only with the APIs you need.
OpenAI: rotate the key immediately from the API Keys page, as OpenAI advises, and set spend limits to help limit charges from a leaked key.

Two Scanners, Different Results

MongoDB makes Kingfisher, and Zimmermann's post was developed with its Kingfisher team.

In this scan, TruffleHog found 12,737 credentials that worked, and Kingfisher found 14,664, but only 1,001 were found by both. Each tool alone found about half of the total.

TruffleHog found almost all of the Alibaba Cloud keys. Kingfisher found all 1,489 BigModel keys, because TruffleHog has no detector for Zhipu's keys, Zimmermann wrote.

Teams that rely on a single scanner should verify its detectors against the services they use.

Gitee and Other Code Hosts

China's Ministry of Industry and Information Technology chose Gitee in 2020 as the base for a national open-source code-hosting platform.

Gitee's public API is limited, and a 2021 attempt to study leaked credentials on the site gave up because of it.

Gitee's rate, 3.64 working credentials per 1,000 repositories scanned, is higher than the rates from earlier scans of GitLab (3.11) and Bitbucket (2.39). Those scans used only TruffleHog, Zimmermann wrote.

Based on TruffleHog's results alone, Gitee's rate is 1.76, but that count excludes services TruffleHog does not cover, such as Zhipu. So neither figure shows which platform leaks more.

The Rise of the Threat Operator: How AI Will Redefine Security Operations and Careers (2026)

Thu, 29 Oct 2026 17:03:41 +0530

AI is beginning to take over much of the work that has traditionally defined the security analyst's job. Investigating alerts, collecting evidence, correlating activity across tools, and executing response actions are becoming tasks that AI systems can perform on their own. As these capabilities mature, security operations centers (SOCs) will see major changes in how work is organized, how decisions are made, and what is expected of the people responsible for defending organizations.

For security professionals, this is a chance to take on a much broader role. As AI assumes more of the operational workload, analysts can move beyond individual alerts and investigations to direct the defense across the entire security lifecycle. We call this emerging role the Threat Operator: an AI-native security professional who translates business risk into defensive priorities, directs AI-driven operations, and exercises judgment over the decisions and actions taken by those systems.

The impact reaches beyond day-to-day SOC work. It will change the skills organizations need, how security professionals develop expertise, and the career paths open to people entering the field.

From Individual Tasks to Overall Defense

The traditional SOC developed around specialized functions, each supported by its own tools and workflows. Threat intelligence teams study adversaries, detection engineers create rules, threat hunters search for activity that existing controls may have missed, analysts investigate alerts, and incident responders contain confirmed threats. These functions are closely related, yet the work often moves between teams through separate systems, tickets, and manual handoffs. AI is starting to tie these activities together. For example, intelligence about a new threat can lead to a hunting hypothesis, which can reveal a detection gap and produce a new detection. That detection may identify suspicious activity requiring investigation, followed by containment and further improvements to the organization's defenses. AI agents can coordinate and execute these workflows, carrying context and findings from one stage to the next.

That changes where security professionals add the most value. A Threat Operator works across the defensive lifecycle, setting priorities based on the organization's exposure, business operations, and threat landscape. They determine which risks deserve attention, what the defense should accomplish, how much autonomy AI should have, and when a decision requires human intervention. They are also responsible for judging whether the operation is actually improving security.

Consider a financial institution facing a newly identified threat targeting identity infrastructure. AI agents could assess the institution's exposure, hunt for relevant activity, identify gaps in existing detections, and recommend defensive actions. The Threat Operator would provide the institutional context needed to guide that work, including which systems support critical business processes, what constitutes unacceptable risk, and which actions require authorization.

The result is a gradual shift from human-in-the-loop to human-on-the-loop, with security professionals supervising and governing AI-driven operations. The level of autonomy will depend on the maturity of the technology, the consequences of particular actions, and the organization's tolerance for risk, but a human remains accountable throughout.

Rethinking How Security Professionals Gain Experience

Junior security analysts will feel some of the biggest effects. For decades, the SOC has provided an entry point into cybersecurity, with analysts developing their skills through alert triage, evidence collection, investigations, documentation, and escalation. Although much of this work is repetitive, it has also served as an apprenticeship. Over time, analysts learn how systems behave, how attackers operate, and how experienced practitioners distinguish genuine threats from benign activity. As AI absorbs more of these responsibilities, organizations will need to rethink how that experience is acquired. The traditional progression from handling simple alerts to managing complex investigations may become less relevant as AI takes on more sophisticated work. Without a deliberate approach to training, security teams may struggle to develop the experienced professionals they will need in the future.

AI can also open up a different path for professional development. Junior Threat Operators can gain supervised exposure to a much wider range of security activities, examining how intelligence informs hunting, how detections are developed, how investigations reach conclusions, and how response decisions affect the business. They can review the evidence behind AI-generated findings, challenge assumptions, identify missing context, and learn from the decisions made by more experienced colleagues. This only works if organizations invest in technical fundamentals and structured mentorship. Analysts still need to understand networks, operating systems, attacker techniques, and the security technologies underlying AI-driven workflows. Experienced practitioners will need to teach younger colleagues how to evaluate conclusions, recognize uncertainty, and exercise judgment when the available evidence is incomplete.

The Skills Needed

For the current generation of security analysts, technical proficiency has often been measured through familiarity with security tools and the ability to extract useful information from them. Query languages, detection logic, endpoint telemetry, and investigation techniques have been central to the profession. Those skills still matter. AI adds new demands on top of them: orchestration, governance, and interpreting automated decisions.

Threat Operators will need to translate business security risks into clear defensive objectives that AI systems can execute. They must understand the organization's architecture, critical assets, operational dependencies, and relevant adversaries, and know how to communicate that context to AI agents. Their work will involve evaluating hypotheses, validating evidence, setting escalation criteria, and determining whether an automated action has achieved its intended outcome.

For example, an AI system investigating a compromised server may recommend immediate isolation. That call could be technically sound. But the server may support a critical business process where disruption carries significant consequences. A Threat Operator must understand those dependencies and determine how the response should proceed, balancing containment requirements with operational risk. This need for defined oversight and accountability is also reflected in the NIST AI Risk Management Framework.

The role will combine four areas of expertise:

Business security risk: Understanding organizational priorities, critical assets, and the consequences of security decisions.
Threat and adversary understanding: Interpreting intelligence and anticipating how attackers may target the environment.
Defensive operations: Understanding detection, hunting, investigation, and response across the security lifecycle.
AI orchestration and judgment: Directing AI workflows, evaluating their conclusions, and governing automated actions.

Building a Career Path Around Defensive Outcomes

The Threat Operator role should become a career path with increasing levels of responsibility. Early-career operators can focus on validating evidence, reviewing AI conclusions, adding environmental context, and understanding how decisions connect across the defensive lifecycle. As they gain experience, they can begin translating business risks into defensive objectives, directing agent workflows, identifying coverage gaps, and determining when operations should escalate or act.

Senior Threat Operators will take responsibility for defining autonomy boundaries, governing consequential actions, evaluating the reliability of AI-driven decisions, and measuring whether security operations are reducing organizational risk. Professionals may enter this career path from investigations, threat intelligence, detection engineering, incident response, security architecture, or risk management, bringing different areas of expertise to a role that spans the entire defensive operation.

Security leaders should start building the training, governance, and progression frameworks needed to support these responsibilities. That includes establishing which decisions require human approval, how operators validate AI-generated evidence, how autonomy expands as systems demonstrate reliability, and how individual performance is evaluated. Measures such as the quality of defensive decisions, the closure of detection gaps, and improvements in threat coverage will matter more alongside traditional operational metrics.

This will happen at different speeds in different organizations. Security professionals will have more say in how their organizations defend themselves. The old SOC trained people to operate tools. The AI-native SOC has to train them to operate the defense.

Conifers.ai’s CognitiveSOC platform uses agentic AI to connect threat intelligence, hunting, detection engineering, investigation, and response, and every agent action comes with a reasoning chain and evidence trail that analysts can review. Learn more about how Conifers helps security teams direct and govern AI-driven defense across the full SOC lifecycle.

Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls (2026)

Thu, 29 Oct 2026 17:09:18 +0530

A flaw in Telegram for Android could be chained with two other bugs to take full control of a victim's phone through a voice call, once the victim answered, according to security startup NebuSec.

The attacker needed only an ordinary Telegram account. Telegram fixed the flaw in version 12.10.4 of the app, released in late September, and NebuSec disclosed it on October 29.

Combined with an information-leak bug, the flaw gives the attacker an escape from the Telegram app to Android, NebuSec co-founder and chief executive Eten Zou told The Hacker News. Adding an Android root exploit then gives full control of the phone, including its messages, microphone and camera.

The flaw can be triggered in every version from 8.6.2 through 12.10.3, Zou said. Those versions came out between March 2022 and September 2026.

The company confirmed it in private voice calls on ARM64-based phones and has no evidence so far that it directly affects Telegram's iOS and desktop apps or group calls.

Anyone using Telegram for Android should make sure the app is on version 12.10.4 or later. The version number appears at the bottom of the app's Settings page. The flaw had no CVE identifier as of October 29.

The attack needs the victim to be called and to answer, Zou said, so setting Telegram's call privacy option to "Nobody" blocks it, and so does declining the call.

NebuSec has not seen the flaw used in real attacks, and believes no one else had realized it could be turned into remote code execution.

NebuSec reported the flaw to Telegram on September 26, after version 12.10.4 had shipped. Telegram acknowledged the report but did not believe the flaw could be turned into remote code execution, so no CVE was assigned and no bug bounty was paid, Zou said. The Hacker News has asked Telegram for comment.

During a Telegram call, the two apps send each other short messages to set up the call and report its state. One type, called MediaState, reports whether the microphone is muted, whether the camera is on, and how the video is rotated.

The flaw was in the code that reads MediaState messages. That code did not handle missing fields correctly and accessed memory it should not, according to NebuSec.

Telegram's published source code for version 12.10.3 contains a flaw that matches that description, a review by The Hacker News found. When a MediaState message included a rotation value, the code checked that value. It then read a different field, the video state, even if the message had no such field.

Version 12.10.4 reads the rotation value from the right field. The calling code that uses this message was switched on in version 8.6.2, the first version NebuSec names.

Telegram's Android, iOS, and desktop apps use one shared library, called tgcalls, for calls. A change labeled "Fix camera rotation" made the same correction in tgcalls on April 21, 2026.

Telegram's iOS source code included that change from version 12.7, released in May, and the desktop app's code from version 7.0.1, released in July. Telegram for Android received it in version 12.10.4 in September.

Whether the earlier code could be exploited in those apps has not been shown.

NebuSec's video shows two phones, one marked as the attacker and one as the victim. The victim accepts a Telegram call. About half a minute into the call, the victim's phone switches to its home screen, the app icons fall down the screen, and a "HACKED BY NEBUSEC" logo appears.

The video does not show which Telegram or Android version the victim's phone was running. No technical write-up of the flaw was on NebuSec's website as of October 29, so the attack chain, including the two other bugs, depends on the video and on what the company says.

NebuSec, a startup backed by Y Combinator, says its Code Security product, which runs on OpenAI's GPT-5.4 model, found the flaw. In July, the company described an Android exploit chain that started with a Firefox flaw and reached the kernel of an ARM64 device running Android 17.

Separately, the Zero Day Initiative (ZDI) published an advisory on October 15 about an unpatched flaw in rlottie, the library Telegram apps have used to draw animated stickers. The flaw, tracked as CVE-2026-111105 (CVSS score: 7.0), can let an attacker run code if a user opens a malicious file or page, ZDI said.

Telegram had told ZDI in March that checks on its servers mitigated the flaw, and in April asked ZDI for a full remote code execution chain.

Those checks could be bypassed, researcher Saifeldeen Aziz says in the abstract for his OffensiveCon talk in Tokyo. The research used AI-guided fuzzing, which feeds code with large amounts of broken or unexpected input, to find memory-corruption bugs in rlottie across Telegram's iOS, Android, and desktop apps. It then chained those bugs with flaws in how stickers are delivered and checked to run code on Telegram for iOS.

The Android app replaced rlottie with tlottie, a library written in Rust, between versions 12.8.1 in June and 12.10.0 in August, according to Telegram's published source code. The desktop app's code made the same switch in September, and the iOS code added tlottie in version 13.0 in October while still including rlottie.

(This article has been updated with answers from NebuSec chief executive Eten Zou on the attack chain, how users can block the attack, and how Telegram responded to NebuSec's report. The opening now says the flaw was chained with two other bugs. A sentence describing the sticker research has also been corrected.)

Webinar: How to Build AI Threat Readiness Into Your Security Operations (2026)

Thu, 29 Oct 2026 17:09:41 +0530

Security teams have spent years trying to detect threats faster. AI is changing the harder part: how much time defenders have left to act.

Advanced AI models can now help attackers discover vulnerabilities, generate exploit code, and move through weaknesses faster than traditional security processes were built to handle.

The challenge is no longer just finding another vulnerability or generating another alert. It is knowing which exposures matter, what an attacker can reach, and which issues need to be fixed first.

That is the focus of next week's webinar, How to Build AI Threat Readiness Across Your Security Operations, featuring an expert from Wiz. The session will show how security teams can improve visibility, prioritize real risk, and shorten the path from detection to remediation.

Most security teams already have plenty of data. They have vulnerability findings, cloud alerts, identity signals, application telemetry, and threat detections. The harder problem is connecting those signals quickly enough to answer the questions that drive action.

Is this vulnerability reachable? Does the exposed asset contain sensitive data? Can an attacker move from it to something more important? Who owns the affected system? What should be fixed first?

When those answers live across different tools and teams, investigations slow down. That delay matters more when attackers can automate parts of the discovery and exploitation process.

📅 Save Your Spot Today: Register for the Webinar Here.

The webinar focuses on two practical needs: broad visibility and faster action.

Security teams need enough context to understand risk across cloud infrastructure, code, identities, SaaS, AI services, and the software supply chain. They also need a way to identify exploitable paths, investigate suspicious activity, and deliver remediation to the right owner without having to rebuild the same context every time.

A Wiz expert will explain how organizations can use unified security context to separate urgent exposure from background noise, understand attack paths, and bring security agents into investigation and remediation workflows.

For SOC teams, that can mean less time spent manually assembling context. For vulnerability management, it means knowing which findings deserve immediate attention. For cloud and security engineering teams, it means connecting risk to the people and systems that can actually fix it.

The goal is not to automate every security decision. It is to remove delays caused by fragmented tools, repetitive investigation, and unclear ownership.

Attendees will leave with a framework for assessing whether their current security operations are ready for faster, AI-assisted attacks. The key questions are practical: Can you see enough of the environment to understand an attack path? Can you quickly determine whether a new issue affects something attackers can reach? Can you move a validated risk from detection to remediation fast enough?

AI is increasing the speed at which weaknesses can be found and used. Security teams need to respond with better context and less delay.

📅 Save Your Spot Today: Register for the Webinar Here.

Google's Gemini 4 Carbon Leads Benchmarks for Finding, Exploiting, and Patching Vulnerabilities (2026)

Thu, 29 Oct 2026 19:12:40 +0530

Google on Wednesday took the wraps off Gemini 4 Carbon, its latest frontier model with state-of-the-art cybersecurity and long-horizon capabilities.

"It shows significant gains across coding and agentic tasks as well as across key capabilities critical for cybersecurity defense, landing a firm lead in SEC-bench Pro (88.2%) for finding vulnerabilities, ExploitGym (54.8%) for exploitation, and CWE-bench (71.0%) for patching," Koray Kavukcuoglu, senior vice president of Google DeepMind and chief AI architect at Google, said.

On the Artificial Analysis Intelligence Index benchmark, Carbon leads with a score of 59, surpassing Anthropic's Claude Opus 5.5 (58), OpenAI GPT-6 Astra (57), GPT-6.1 Sol (55).

One of the core focus areas is cybersecurity, where the latest iteration reportedly delivers significant performance improvements across the board, including vulnerability detection, validation, and remediation. Carbon is also twice as likely to generate secure code versus Argon.

Google also emphasized that Carbon attempts to respond to complex or high-pressure tasks by seeking human input in the face of ambiguity rather than "guessing or forcing a path forward," as well as resisting every evaluated attack attempt at indirect prompt injection.

The debut of Gemini 4 Carbon comes less than a week after the tech giant unveiled Gemini 4 Argon. The release plan is similar to that of its predecessor, with the rollout currently limited to a subset of cyber defenders before expanding access to other trusted partners as part of its Fairwind Program.

Google also said it's actively engaged in the U.S. government's voluntary process for pre-release model testing.

The development comes as OpenAI released GPT-6.1 Terra, which it described as a fast, efficient model that "excels at communication and computer-based tasks."

"GPT‑6.1 Terra meets the Critical threshold in cybersecurity under our Preparedness Framework, and maintains the protections developed for GPT‑6 Astra," OpenAI said.

"GPT-6.1 Terra brings with it the alignment improvements of the GPT-6 series. According to our evaluations, GPT-6.1 Terra is more likely to stay within scope and honestly disclose limitations and potential blockers to the user compared to GPT-5.6 Terra. In our prompt-injection tests, GPT-6.1 Terra also showed strong resistance to malicious instructions designed to divert it from the user's task."

Earlier this week, rival Anthropic also disclosed that an unreleased, internal research model uncovered critical vulnerabilities in some of the world's most widely used software.

This included a one-click remote code execution in Google Chrome, a one-click exploit chain in Apple Safari that could be used to access a user's browsing history, cookies, and other sensitive data, an Android lock screen bypass, and a denial-of-service (DoS) flaw in the Windows HTTP.sys driver (CVE-2026-33096, CVSS score: 7.5). All the identified issues have been fixed by Google, Apple, and Microsoft.

"These attack chains demonstrate the model's ability to create sophisticated, multi-step exploits in both open-source and proprietary software," Anthropic said.

"These skills have historically been the domain of few specialist teams with expertise in these targets. Now, it’s something models can do with little human involvement, and then prove by producing a working exploit that anyone can run and verify."

Fake ChatGPT and Claude Apps Abuse Signed Executables to Deploy Crypto Miners (2026)

Thu, 29 Oct 2026 20:50:29 +0530

Threat actors are delivering malicious loaders and cryptocurrency miners under the guise of artificial intelligence (AI) desktop applications for Anthropic Claude and OpenAI ChatGPT as part of a campaign dubbed Yoba.

The activity involves creating fake GitHub projects that claim to be desktop applications like GPT-5.6 Sol, GPT-6 Astra, and Claude Opus, only to deliver a malware family called YobaLoader.

"The malware is placed next to legitimate, signed executables from OpenAI and Anthropic so it can be loaded indirectly, a technique commonly known as DLL sideloading, which is often used to bypass security protections," Check Point Research said in an analysis.

To add to the project's credibility, the attackers set up GitHub.io pages to describe the capabilities of the software. Although the GitHub projects' popularity is not manipulated using techniques like ghost networks, signs point to the use of SEO poisoning tactics to ensure that links to them are surfaced on top of search results on Google.

Some of the identified GitHub pages links are below -

github[.]com/gpt-5-6/sol-free-desktop
gpt-5-6.github[.]io
github[.]com/gpt-5-6/gpt-5-6.github.io
github[.]com/gpt-6-astra/gpt-6-astra.github.io
gpt-6-astra[.]github[.]io
github[.]com/opus-5-0/opus-5-0.github[.]io
opus-5-0[.]github[.]io

"Each repository uses a different email address (edwardcarlsonmkym[@]outlook[.]com, daxschneiderdjuu[@]outlook[.]com, and rioprestonlfyx[@]outlook[.]com), and the uploader appears to operate in UTC+4, UTC-4, and UTC+3 respectively," Check Point said. "This inconsistency likely reflects a deliberate attempt to obscure the threat actor's true operational time zone."

Hosted within these repositories are ZIP archives that, among other files, contain two specific components -

Setup.exe, a legitimate signed OpenAI Codex or Claude executable
winmm.dll, a malicious DLL that's sideloaded by the executable

The DLL is a dropper codenamed YobaDropper, which implements checksum value checks by hashing the basename of its host executable and if it matches a hard-coded value "0xE6C2F326." In other words, the check requires it to be launched under "Setup.exe," and fails if the DLL is executed on its own inside a sandboxed environment.

Additional anti-analysis techniques and pre-checks include 200,000 iterations of "Sleep(5500)," which amounts to 12.73 days, and skipping machines whose keyboard layout corresponds to that of Russia, Belarus, Tajikistan, Armenia, Azerbaijan, Georgia, Kazakhstan, Kyrgyzstan, Turkmenistan, and Uzbekistan.

Another language ID excluded from the infection process is Tatar. Notably missing from the list is Ukraine, which used to be historically included in such checks.

YobaDropper, for its part, triggers a DLL sideloading chain of its own comprising "wmpdmc.exe" and "ampdui.dll," copying the former from its "system32" folder and placing it in a new directory named "WMProcess" created under "ProgramData."

The dropper then extracts and decrypts an embedded payload, and drops it into the same folder as "wmpdui.dll." It also establishes persistence by means of a scheduled task that launches the legitimate executable to load the malicious payload.

The second DLL is YobaLoader. It implements the same anti-sandbox technique as YobaDropper, requiring the malware to be run only by "wmpdmc.exe" by checking the hash against a hard-coded value ("0x552751E3"). The loader is responsible for three main tasks -

Downloads an image from a Telegram channel ("t[.]me/yoba_fanclub").
Uses the last 50 bytes as a seed to generate a domain based on three lists of dictionary words and an integer value in the range 0–999 using a domain generation algorithm (DGA). The end result is domain in the format "adjective-noun-verb-digit.dedyn[.]io."
Queries Google's DNS-over-HTTPS (DoH) API to obtain a Base64-encoded command from a DNS TXT record by passing the constructed domain as input.
Decrypts the response to obtain the link to fetch the next-stage payload ("files.catbox[.]moe/z5zpy9.dat").

"By relying on a DoH service and common file-hosting platforms, the actor aims to bypass passive DNS monitoring and some gateway-based security protections, making their command-and-control traffic harder to distinguish from regular user activity," Check Point said.

The downloaded payload is then injected into "svchost.exe," resulting in the execution of an XMRig cryptocurrency miner.

Evidence indicates that the first GitHub repository was created around July 2026, although the malicious releases were not uploaded until the end of August. What's more, early versions of YobaLoader have been found to only exclude Russia from infection, while also incorporating extensive anti-debugging and anti-VM checks, which have since been removed in newer versions.

"The Yoba campaign shows how attackers can use trusted platforms and the current interest in AI tools to distribute malware in a way that looks believable and harmless at first glance," Check Point said. "By packaging their code together with well-known software names and hosting it on GitHub, they lower the chances that users or basic security checks will immediately flag the files as suspicious."

Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions (2026)

Thu, 29 Oct 2026 21:27:05 +0530

A flaw in the Linux kernel's TCP code, tracked as CVE-2026-98432, affects Ubuntu, Red Hat Enterprise Linux (RHEL), and other Linux distributions. The kernel's own CVE team rates it 9.8 out of 10 on the CVSS scale.

Anthropic said on October 27 that its AI model wrote an exploit that uses the flaw to let a remote attacker with no credentials run commands as root on Linux servers with a multipath TCP listener.

As of October 29, Ubuntu and RHEL have not released a fixed kernel. Red Hat, Amazon, Oracle, and SUSE score the flaw between 5.9 and 8.1, lower than the kernel team's 9.8.

The flaw is a race condition in the code that sets up new IPv4 TCP connections. It can make the kernel read memory it has already freed, a bug type known as a use-after-free.

The kernel fix credits Anthropic researcher Xinyang Ge with reporting the bug. Neither the CVE record nor the fix mentions multipath TCP (MPTCP). The link between that feature and this bug comes from Anthropic's post.

MPTCP lets one connection use several network paths at once. On Linux, an application must request MPTCP when it opens a socket.

Anthropic's post says the flaw "was patched upstream and backported to all maintained stable kernel branches." For distribution users, that fix arrives only in the vendor's kernel package. Debian, Oracle Linux, SUSE, and Amazon Linux have shipped fixed packages, at least for some of their kernels, but Ubuntu and RHEL have not.

Which Distributions Have a Fix

Distribution	Vendor rating	Status as of October 29	Fixed package or advisory
Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10	Priority High	Work in progress	None released
Ubuntu 16.04, 18.04 and 20.04	Priority High	Vulnerable	None released
RHEL 8, 9 and 10, OpenShift 4	Moderate, 5.9 (CVE page) Important, 8.1 ( advisory file)	Fix deferred	None released
RHEL 7	Not applicable	Not affected	Not needed
Amazon Linux 2023, kernel6.18 package	Important, 7.0	Fixed October 24	`kernel6.18-6.18.56-125.164.amzn2023` (ALAS2023-2026-3251)
Amazon Linux 2023, kernel6.12 package	Important, 7.0	Fixed October 29 in Amazon's advisory; Amazon's CVE page still says pending	`kernel6.12-6.12.113-138.209.amzn2023` (ALAS2023-2026-3335)
Amazon Linux 2 Amazon Linux 2023, kernel package	Important, 7.0	Pending fix	None released
Oracle Linux 7, 8, 9 and 10, UEK kernel	Important, 8.1	Fixed October 16	ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399
Debian trixie (stable)	No score listed	Fixed October 16	`linux` 6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm)	No score listed	Fixed October 17 and October 22	`linux` 6.1.190-1 (DLA-4841-1) `linux-6.12` 6.12.113-1~deb12u1 (DLA-4850-1)
SUSE Linux Micro 6.2, openSUSE Leap 16.0	Important, 8.1	Fixed	`kernel-default` 6.12.0-160000.40.1 or later
SLES 15 SP4 to SP6 LTSS, SLES 16.0, SLE Micro 5.3 to 5.5	Important, 8.1	In testing	None released
SLES 15 SP7	Important, 8.1	Affected, fix in progress	None released

Ubuntu also lists its cloud, FIPS, and real-time kernels as vulnerable or as work in progress. Red Hat says its fixes are "currently deferred to a future update." Neither Red Hat nor Ubuntu gives a release date.

How the Bug Works

The race happens during the TCP handshake. When a connection is completed, the kernel hands the IP options stored with the pending request to the new socket without copying them.

If that socket is destroyed while another CPU is still using the options to answer a resent connection request, the kernel reads freed memory.

IPv6 is not affected by this race because the kernel copies the options for IPv6 connections.

The bug was introduced in Linux 4.4. Kernel developers applied a fix on October 5, ten days before the CVE was published.

The fix makes the kernel wait until other CPUs finish reading the options before it frees them.

Why the Scores Differ

The kernel's CVE team added the 9.8 score to the CVE record on October 24, nine days after publishing the CVE.

Its score assumes an attacker who sends a TCP connection request carrying IPv4 Record Route or Timestamp options, then resends the request to try to win the race. The team rated attack complexity low, saying both sides of the race are "attacker-induced."

In that case, the team says, the bug could send nearby kernel memory back to the attacker, corrupt kernel memory, or crash the system.

As of October 28, the National Vulnerability Database (NVD) had not added its own score and showed the kernel team's 9.8. Ubuntu's page also shows that score.

Red Hat's CVE page rates the flaw Moderate, scoring it 5.9 because the race is hard to win. It says the most likely result is a kernel crash, with memory corruption possible in theory, and that "no confidentiality or integrity impact has been demonstrated."

Red Hat's machine-readable advisory file, updated on October 29, lists the impact as Important and scores the flaw 8.1, with high confidentiality and integrity impact. Red Hat's bug tracker changed the issue's severity from medium to high the same day. On that day, the CVE page showed Moderate and 5.9.

Oracle and SUSE also score the flaw 8.1, with the same CVSS vector as Red Hat's advisory file. Those scores match the kernel team's on every metric except attack complexity, which the vendors rate high and the kernel team rates low. Amazon scores it 7.0.

What Anthropic Says It Built

Anthropic described the Linux exploit in an October 27 post about flaws that its AI model, Claude, found and exploited. The Hacker News covered the post on October 28. Claude wrote the exploit after "initial prompting," Anthropic said.

The exploit works in two stages. First, the race makes the kernel send extra bytes back to the attacker. Once one of those replies contains a kernel address, the attacker can get around KASLR, the kernel's memory address randomization.

Second, the same bug overflows a buffer and overwrites a callback pointer with the address of a payload the attacker had already placed in kernel memory. When the kernel calls that pointer, the payload executes a shell command of the attacker's choice as root.

A lost race only fails that one connection attempt and does not crash the system, so an attacker can keep trying, the company said. In its test, leaking a kernel address took 48 minutes, and reaching command execution took 5 more minutes.

The post does not include the exploit code, the kernel version, or the configuration Anthropic tested.

Red Hat says a remote attacker who can reach an exposed TCP service could trigger the race. Anthropic's root exploit, however, targeted servers with a multipath TCP listener. The post does not say whether servers without one can be taken over the same way.

As of October 29, none of the vendor advisories, the CVE record, or Anthropic's post reports attacks using the flaw. It does not appear in a copy of CISA's Known Exploited Vulnerabilities catalog that Luxembourg's CIRCL last updated on October 28.

What to Do Now

Where your distribution has released a fixed kernel, install it. The table above lists the packages and advisories for Debian, Oracle Linux, SUSE and Amazon Linux.

If you build your own kernel, the fix is in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel's CVE team recommends updating to the latest stable kernel. It says the kernel community does not support cherry-picking individual fixes.

Ubuntu, RHEL and some Amazon Linux and SUSE releases have no fixed kernel to install yet. Red Hat says no available mitigation meets its standards for being easy to deploy, suitable for most installations and stable. None of the other vendor advisories lists one.

The advisories and Anthropic's post do not say whether turning off multipath TCP, or blocking incoming connection requests that carry IP options, would lower the risk.

ThreatsDay: Critical Firewall Flaws, Banking Trojans Rented, Weaponized PDF, Token Theft + 26 More Stories (2026)

Fri, 30 Oct 2026 00:41:58 +0530

Some attacks take real skill. Others just need someone to leave a door open. This week has both. Exposed passwords, old bugs still getting exploited, and trusted software doing things it shouldn't.

There's a strange mix of clever tricks and careless mistakes. Hackers are borrowing trust from familiar apps, websites, and AI tools. Some are using AI to speed things up. Others are leaving their own attack files exposed. Not exactly careful work.

Different stories, familiar weak spots. Here's what showed up this week.

The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out.

PHP2Shell attacks persist
No WordPress Site Compromised by PHP2Shell... Yet

WordPress security company Wordefence said it's not aware of any WordPress site compromised through PHP2Shell (CVE-2026-109618 and CVE-2026-109619) as of October 28, 2026. "We continue to see PHP2Shell-related requests across the more than 5 million sites we protect," it said. "Those requests show ongoing scanning and exploitation attempts; they do not show whether an attempt succeeded. Our site-cleaning and incident response teams have not handled a WordPress compromise attributed to these vulnerabilities."
40,573 secrets exposed
FortiBleed Investigation Uncovered Additional Exposed Secrets

Hudson Rock's investigation into the FortiBleed credential harvesting campaign has uncovered 975 newly identified domains and 40,573 exposed secrets, including 37,076 local-user records and 1,576 Active Directory LDAP bind records. The data comes from newly obtained 1,703 FortiGate source files associated with 1,689 host identifiers. "The configuration material dates to around February 2026, earlier than the likely May/June material examined in the first investigation," Hudson Rock said. The latest discovery has been codenamed FortiBleed 2.0.
Institutional DNS hijacked
Using Domain Shadowing to Place Illegal Content

Threat actors have used domain shadowing to place illegal gambling content beneath legitimate school and government domains in two unrelated operations. "In both cases, an unauthorized party appears to have gained access to DNS administration and created records that the original domain owners may not have noticed," Infoblox said. "Because the resulting hostnames sat within established institutional namespaces, they provided especially useful infrastructure for search-engine optimization (SEO) and traffic acquisition." One cluster, linked to a threat actor called Hidden Hawk, has been found to add individual CNAME records that mapped institutional hostnames to gambling pages hosted largely on Cloudflare Pages. The second campaign exploiting an Indian government domain "delegated entire subzones to third-party authoritative nameservers and used a wildcard, allowing many hostnames to be managed outside the victim's DNS environment." Put differently, the unauthorized DNS access creates new institutional hostnames, which resolve to infrastructure serving illegal gambling doorway pages. The pages also leverage the established reputation of school and government namespaces to ensure that the malicious URLs show up prominently in search engine results.
AI banking credential warning
Bank of America Warns Against Sharing Credentials with AI Agents

Bank of America is reminding customers not to share banking credentials with AI agents. In an email blast to customers titled "Protecting your finances in the AI World," the financial institution urged customers to never share their username and password with another person or an outside service, "including an AI-enabled tool or agent that offers to act on your behalf."
Android tightens contact access
Android to Prevent Apps from Writing to Contacts

Google has announced that an upcoming Android release will no longer be able to directly write to contacts with the WRITE_CONTACTS permission. "Instead, you can use the standard contact intents (ACTION_INSERT, ACTION_EDIT, and ACTION_INSERT_OR_EDIT)," Google said. "Currently, if your app needs to save even one contact, you might be requesting WRITE_CONTACTS. But that permission grants broad access, allowing an app to make widespread changes to contacts across the device in the background, even without user interaction. Most apps don’t need such broad permission."
26,400 live credentials exposed
Scanning 7.25 Million Public Repositories on Gitee

A scan of 7.25 million public repositories on Gitee, China's largest indigenous Git hosting platform, has uncovered 26,400 unique verified-live credentials, including an active organization-admin credential for a major enterprise AI platform and thousands of live cloud provider access keys, independent security researcher Ben Zimmermann said.
Critical Fortinet fixes released
Fortinet Releases Security Updates

Fortinet has released a "coordinated set of security updates for FortiOS, FortiManager, and FortiAnalyzer" to address critical and high-severity flaws that were flagged using an AI-assisted vulnerability discovery approach. Details of the issues are being kept under wraps until November 10, 2026. With Fortinet devices becoming a favorite target for attackers, it's essential that users move quickly to apply the fixes.
Zero-permission token theft
Microsoft Authenticator Flaw Allows Unauthorized Account Access

Details have emerged about a now-patched flaw in Microsoft Authenticator (CVE-2026-80097 aka AuthMask) that could be exploited by installing and running a malicious application on an affected Android device and convincing the user to complete an authentication flow in the app by claiming to be a trusted app and getting the corresponding tokens. The flaw could be exploited to take over work accounts without requiring additional permissions. "Successful exploitation could allow the attacker to obtain authentication tokens and access resources as the affected user," Microsoft said. According to Enclave, "an unprivileged Android app with zero permissions could impersonate any installed Microsoft first-party app and have the Microsoft Authenticator broker hand it that app's tokens. The setup is a device with Authenticator installed and one work account signed into it."
32 fake AI bots hunt secrets
Attackers Use AI Agent Impersonation to Hunt for Credentials

Attackers are disguising themselves as AI agents to steal credentials. Cequence said it has tracked a single actor running AI agent impersonation at scale by posing as about 32 different AI bots, including ChatGPT, Claude, and Perplexity, while searching for passwords, API keys, and cloud credentials. "The malicious scanner runs from a major cloud provider and rotates through about 32 AI bot identities, spanning crawlers and assistants from OpenAI, Anthropic, Meta, Perplexity, and others," Will Glazier said. "It ignores web pages and requests files that commonly store secrets, including .env configuration files, cloud credential files, private SSH keys, and server environment data, working from a list of roughly 90 file paths. Each address sends a short burst of 50 to 190 requests in about eight seconds and then moves on. The scanner works through targets one at a time, around the clock, and first sends random nonsense paths to find websites that answer every request, a common scanning technique. It hit organizations in financial services, retail, telecommunications, energy, and software, and stayed active from at least late September through late October."
China-linked network intrusion
China-Linked Attacker Breached a Fiji Organization

The U.S. Embassy in Fiji has revealed that hackers linked to China broke into a regional organization based in Suva between July and August 2026. "Hackers with links to China maintained access to the organization's network over several days," it said. The embassy did not name the threat actor. Nor did it disclose what data the attackers may have accessed.
Camera software weaponized
Attackers Weaponize Camera Management Software

Attackers have been breaking into enterprise networks via camera management software, according to new research from security firm Huntress, which observed multiple incidents in September and October 2026 and traced them back to a compromised application. Source code artifacts point to a Korean company selling analog and IP cameras and digital and network video recorders. The activity abuses the legitimate "WpcMon.exe" binary to sideload DLLs that establish outbound connections to a remote server. "This activity demonstrates how attackers can blend malicious code with trusted Windows components to evade detection," Huntress said.
68 GB government data breach
68 GB Data Stolen from a Philippine Government Agency

In a major operational security blunder, an unknown threat actor stole 68 GB from a Philippine government agency, maintained a detailed log of the transfer, then left that log open on the internet at 13.163.205[.]35:80. "The copy finished in under 24 minutes on September 6, 2026," Hunt.io said. "The transfer log records 27 SQL Server backups whose filenames correspond to the case-management systems of a Philippine overseas-employment and migrant-worker administration. Beside the log sat the operator's toolkit, a rebranded GodPotato build, a PowerShell stager, two payloads and a full Impacket environment."
AI model data exfiltration concerns
Cohere Says Alibaba's Qwen Model Tried to Send a File to China

Canadian AI company Cohere has claimed that it caught Alibaba's Qwen3.8-Flash-Next model unsuccessfully attempting to send data to China from its evaluation sandbox as part of a prompt instructing the LLM to detect malicious file download and execution by monitoring for curl processes downloading bash scripts to /tmp followed by bash execution. "Asked to write a defensive detection rule, Qwen3.8-Flash-Next ignored instructions and inventoried the machine it was running on and then tried to upload a probe file to an Alibaba Cloud storage bucket in Beijing," Cohere said. "We cannot answer whether this is deliberate or a leftover glitch from training." Cohere has also released a dataset containing the model trace and corresponding raw token IDs in connection with the behavior. "The exact output is not guaranteed all the time, and many trials may be required to reproduce the behavior," Cohere said, adding "there are similarly unexpected URLs that the model also tends to output, most containing aliyunc." However, the findings have also led to social media chatter that the company is resorting to geopolitical fearmongering and that they are an attempt to clamp down on open-weights models.
Post-quantum migration roadmap
NIST Releases Guidance for Post-Quantum Cryptography Transition

The U.S. National Institute of Standards and Technology (NIST) has released guidelines that detail the timelines for transitioning away from quantum-vulnerable algorithms to quantum-resistant standards. "The report describes different use cases and says why one migration might take longer than another," said NIST mathematician Dustin Moody, who heads the PQC standardization project. "We understand there's not one strategy that fits all use cases, and we want to help people handle their migration while staying abreast of what's changing."
AI-powered ransomware operation exposed
n0n Ransomware Linked to AI-Assisted Extortion Operation

SOCRadar has uncovered the live workspace (i.e., open directory) of a threat actor tied to the n0n ransomware group, which exposed the operation's full workflow as of September 2026. The directory at 185.157.161[.]148 includes an AI coding agent configured with about 150 models to produce hundreds of attack scripts, with more than $7,216 in usage costs. "Entry points included a credential stuffing campaign against 305 FortiGate SSL-VPN devices, exposed AWS keys, weak RDP/WinRM credentials, and compromised hosting management portals," SOCRadar said. At least 23 organizations across 14 countries are said to have been identified in the workspace, including a U.S. sports retailer, a cloud provider, a teachers’ union, a Venezuelan ISP, an Argentine ministry and a pharmaceutical subsidiary.
Government AI access restricted
Sweden Blocks Government Access to ChatGPT and Claude

The Swedish government has barred employees from accessing browser-based versions of ChatGPT or Claude on their work computers over security concerns relating to the processing of sensitive data. "Officials were concerned that entering sensitive information into these models without an agreement setting out how to protect and secure the data could lead to it being fed into the model and stored for training," Euro News reported.
42 repositories hijacked
42 Hijacked GitHub Repositories Armed With npm Supply-Chain Payloads

JFrog and SafeDep have uncovered a campaign in which threat actors hijacked third-party 42 GitHub repositories across 11 owners to deploy payload blobs large enough "to evade the GitHub search and API paths normally used to find this kind of compromise." JFrog said, "The repositories contain execution hooks for AI coding assistants and IDEs, plus 12.9 to 13.7 MB polymorphic wrappers that all decode to the same hidden CI-publisher payload." The activity is assessed to be related to a Miasma-family npm worm propagated under various packages ending with "testmetest." According to SafeDep, the worm "shares code with Miasma 'Phantom Gyp' from June 2026 and adds the token-revocation wiper from Mini Shai-Hulud. The malicious versions steal credentials, spread to other packages and repositories, and install a wiper that deletes the home directory when the victim revokes the stolen GitHub token." Unsuspecting developers who installed the packages had their data stolen and repositories compromised with malicious code to produce further malicious testmetest releases and run shellpanel workflows targeting cPanel systems through CVE-2026-41940, overlapping with a prior campaign detailed by Socket in July 2026.
Android banking malware-as-a-service
MR ROBOT, a MaaS Operation Targeting Indian Bank Customers

A new Android malware operation called MR ROBOT is targeting customers of Indian banks and transforming banking fraud into a subscription business, with cybercriminals renting customized banking trojans to steal OTPs, card details, UPI PINs and credentials while secretly forwarding calls to bypass security checks. "It is not a single-actor campaign but a rented crimeware platform: a master operator leases access to affiliates, who use a Telegram bot ('APK Shield) and a web control panel (v7.0) to build personalized banking trojans on demand and distribute them through fake Play-Store-style pages and messaging-app lures," CloudSEK said. The kit impersonates around 36 lure apps, including banks, utility providers, and government services. One affiliate is estimated to have intercepted 5407 text messages from 153 infected devices.
MDM platforms abused for remote access
Attackers Abuse Hexnode and Rippling MDM to Deploy Persistent Remote Access

Threat actors are abusing legitimate mobile device management (MDM) platforms, like Hexnode and Rippling, by using social engineering to enroll devices or install management agents, per Huntress. "Once established, MDM provides a trusted, privileged path for malicious activity, such as deploying rogue RMM tools and maintaining remote access," it said.
Critical Gotenberg RCE exploited
Attackers Exploit Gotenberg RCE Flaw to Deploy Custom Go Reverse Shell

Threat actors are exploiting CVE-2026-42589 (CVSS score: 9.8), a critical remote code execution flaw in Gotenberg, to deliver a Go-based reverse shell called "cache_base." The flaw was patched in May 2026. According to VulnCheck, the activity originated from a residential Japanese IP address in early October 2026. "The execution flow is straightforward: acquire a lock, collect host information, connect to C2, register the victim, and open a shell," VulnCheck said. Over the past 30 days, the vulnerability has recorded 1,358 exploitation events from 128 unique source IP addresses.
Discord discussions go public
Discord Plans to Put Messages From Discoverable Servers in Web Search

Discord has announced it will allow search engines to index discussions in Discoverable Servers and make them accessible on the web to users outside the platform without an account or invitation, starting mid-December 2026. "Discussions in Discoverable Servers will soon be easier to find when you search the web, so you can find the answer you're looking for and step straight into the conversation on Discord," it said. The changes apply only to Discoverable Servers and do not extend to private servers and direct messages.
800+ ransomware victims claimed
The Gentlemen RaaS Detailed

The Gentlemen ransomware operation has claimed more than 800 victims across multiple regions and sectors, with most attacks targeting organizations in the U.S. and Europe. "The group supports multiple platforms, with ransomware variants targeting Windows, Linux, NAS, and BSD systems, allowing its affiliates to target a broad range of enterprise environments," Acronis said. "The group's operations include the use of EDR-killing tools. In a recent incident, a custom dropper was observed deploying vulnerable Safetica ProcessMonitorDriver [CVE-2025-70795] and Lenovo BootRepair.sys drivers to terminate security processes."
AI model loading RCE risk
Arbitrary Code Execution in Unsloth's Model Loader

Pillar Security has disclosed an arbitrary-code-execution vulnerability in Unsloth's core model-loading path (CVE-2026-93348, CVSS score: 8.6). It has been fixed in unsloth_zoo 2026.8.14. "An attacker-controlled model configuration could cause Python code to execute during loading," researcher Ariel Fogel said. "The affected code ran inside the model-loading process, with access to whatever that process could read, modify, or authenticate to. In an AI development environment, that can include proprietary datasets, model artifacts, Hugging Face tokens, and cloud credentials. Exploitation required an affected loading path to process an attacker-controlled configuration."
Unauthenticated root-level RCE
Critical RCE in an EAC Voting Resource Calculator

XBOW said it identified an unauthenticated, critical-severity remote code execution bug in a public web application belonging to the U.S. Election Assistance Commission (EAC). "The vulnerable application was a resource/logistics calculator, not a voting machine or voter registration system," XBOW researcher Ariel Walter Garcia said. "The flaw allowed an unauthenticated attacker to execute code as root inside the backend container, with access to locally protected resources and outbound network connectivity, a privileged foothold reachable via a crafted unauthenticated web request."
Session-hijacking RAT emerges
New DataCore RAT Emerges

A new remote access trojan called DarkCore comes with a dedicated browser that could let attackers access Gmail, WhatsApp, and MediaFire accounts using stolen sessions, while giving the impression that the activity is originating from the victim's own IP address. DarkCore was first advertised on cybercrime forums in August 2026. "The seller describes a browser that reuses those sessions to access work mailboxes, instant messaging apps, cloud storage and other services through the infected machine's IP address," BlackFog said. "The purpose is to make the access look like legitimate activity from the user."
AI-powered malware framework
NIK C2, an AI-enabled C2 Framework

Cisco Talos has disclosed details of a new AI-integrated command-and-control (C2) framework called NIK C2. The implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module. "NIK C2 contains a Windows implant, using which, an actor can dump credentials, stream the victim's keystrokes to collect the targeted victim's sensitive data, and instruct an integrated AI model to analyze the harvested data, all within the compromised session," Talos said. "In this framework, the actor has abused the OpenAI Chat Completions application programming interface (API), which is an HTTP endpoint that enables ChatGPT-style conversations programmatically. In addition to the features that enable theft, an actor can also deploy desktop screen-locking ransomware via the NIK C2 implant onto the victim machine, leading to a ransom demand in Bitcoin or USDT cryptocurrencies." Three different versions of the malware have been identified to date since August 12, 2026. Talos said NIK C2 alters adversary tradecraft by collapsing collection and exploitation into a single continuous session.
Malicious PDF delivers backdoor
Fake FedEx Invoice Leads to Sirius Backdoor

A phishing email using a FedEx tax invoice lure and containing a ZIP archive with a PDF has been observed triggering a multi-stage infection process to deliver a previously undocumented variant of the Sirius Backdoor. "The PDF abuses /OpenAction and /Launch objects to trigger an embedded Base64-encoded PowerShell command upon opening," Trellix said. "Execution relies on social engineering to trick the user into approving the PDF reader's security confirmation prompt. The PowerShell stager decrypts and reflectively loads a .NET assembly in memory. This loader performs process hollowing into legitimate Windows processes such as msbuild.exe, svchost.exe, etc., allowing the malware to operate under trusted process contexts." The final payload is SIRIUS, a Microsoft Visual C++ based backdoor with extended remote access capabilities.
AI reshapes ransomware economics
New Economics of Ransomware and Extortion

A new analysis from Flare has revealed that threat actors are building a mixed AI toolkit, combining commercial models with local, open-weight, and jailbroken alternatives, as well as leaning on stolen AI credentials to shift costs to victims. "Where AI can help is with understanding systems, writing tools and troubleshooting. The threat actor still needs access, decisions and a way to obtain payment," Flare said. "If AI helps an affiliate write a working data-export script without hiring a specialist, the affiliate may avoid that specialist’s fee and the wait for their help. AI makes expertise cheaper to obtain only when the cost of using and checking its work is lower than the cost of the specialist help it replaces."
Emerging data-extortion threat
ScarlettGroup, an Emerging Data-Extortion Actor

A recently observed cyber-extortion actor named ScarlettGroup is publicly advertising alleged data compromises and uses negotiation deadlines and threatened disclosures to pressure targeted organizations. The group's dark web site listing includes victims from technology, education, government, and entertainment sectors. "ScarlettGroup demonstrates characteristics associated with financially motivated data-extortion operations, including public victim claims, deadline-based pressure, and underground forum activity," Foresiet said. "Its dedicated leak-site infrastructure and structured disclosure mechanism indicate an organized approach to promoting alleged compromises and exerting reputational pressure."
Infostealers evolve into RATs
StealC Returns as Stadia RAT

Following its disruption in June 2026 as part of Operation Endgame, StealC has returned four months later as Stadia. "This time it's not a stealer: it's a full remote access trojan," Varonis said. "The RAT's features include hidden desktop control, a live command shell, a file explorer, a process manager and an in-memory loader, with StealC's stealer welded on as one module among six. The actor behind Stadia is working hard to win back original StealC customers: every former StealC customer is offered a free month on the top ($900) tier." The development comes as Moonlock Lab revealed that the Icarus macOS stealer has similarly evolved from a smash-and-grab crypto and data stealer to a malware with remote-access capabilities. The new iteration is called ICMacOS. "The stealer is actively advertised on cybercrime forums by a Russian-speaking actor operating under the handle GlowComa, with feature updates regularly announced via Telegram," SOCRadar said. "GlowComa promotes ICMacOS alongside Icarus ClickFix, a companion panel designed to deliver payloads using malicious copy-and-paste terminal commands. The infection chain relies on initial dropper scripts to detect the host architecture and harvest administrator passwords using fake system dialogs before delivering the primary payload." Another macOS-focused stealer is Aokigahara, which goes beyond browsers, VPN clients, cryptocurrency wallets, FTP/SFTP clients, password managers, and email applications to also target AI applications and development tools. "The stealer collects authentication files, session data, and configuration files associated with Claude, ChatGPT Desktop, Codex, Cursor, Windsurf, GitHub Copilot, Gemini CLI, and other tools," Check Point said. "Stolen AI credentials could offer opportunities for monetization. Usable credentials or session tokens could enable unauthorized access to paid AI services or the resale of compromised accounts."

That's the week's mess. Some attacks were clever, some were painfully simple, and a few attackers made life easier for the people investigating them. The common problem? Too much trust in things nobody was watching closely.

AI is adding new tricks, but the old ones aren't going anywhere. Stolen credentials, weak access controls, and forgotten bugs still get plenty of work done. New tools, familiar mistakes.

The useful part is knowing where those mistakes keep showing up. That's usually where the next problem starts.

Binance Suffers Security Breach Affecting $6.3 Billion in Assets, Nearly $3 Billion Frozen (2026)

Fri, 30 Oct 2026 09:44:59 +0530

Cryptocurrency giant Binance said on Thursday that a "security incident" on its platform has impacted about $6.3 billion worth of assets.

The world's biggest cryptocurrency exchange said nearly $3 billion of those assets have been frozen on-chain so far.

Tether and Circle said they have frozen more than 1.567 billion USDT and 800 million related to the incident, respectively. The Arbitrum Security Council is said to have executed a transaction to freeze about $30.5 million from the Binance Exploit.

"Initial investigation suggests that the security incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions," Binance said in an update.

The company said there is no evidence of a wallet private key leak, adding it will cover all losses from the Secure Asset Fund for Users (SAFU) fund and its own funds.

Out of an abundance of caution, Binance has also taken the following steps -

Temporarily suspended deposits and withdrawals while security checks are completed
Revoked the affected address authorization;
Engaged law enforcement and blockchain intelligence partners to trace and recover funds

"We are working closely with our law enforcement partners to confirm the identity of these criminals and bring them to justice," Binance said.

The development makes it the biggest cryptocurrency heist recorded to date, surpassing the theft of about $1.5 billion from Bybit in February 2025. The incident was subsequently attributed to North Korea.

"Our current estimate on the amount stolen is approximately $5.912 billion at time of theft, nearly 4x the amount stolen in the next largest crypto heist," blockchain intelligence firm Chainalysis said in an X post.

(This is a developing story. Please check back for more details.)