2026-07-08 AI创业新闻

RedWing MaaS Packages Android Bank Fraud as a Telegram Rental Service

A new Android malware operation called RedWing is being rented out on Telegram as a ready-made bank-fraud service. It lets even low-skill criminals take over a victim’s phone, steal their banking logins, and capture the one-time codes that protect their accounts. Zimperium’s zLabs , which found the operation, says it looks like a new variant of Oblivion , a $300-a-month rent-a-malware tool documented earlier this year. RedWing is sold as a complete product, in subscription tiers with referral discounts, guides, and how-to videos, so a buyer needs no malware-writing skill.

A Telegram bot builds each buyer a custom app on demand. Researchers say a substantial number of the resulting droppers and payloads currently evade conventional security tools. Infection starts with a phishing link that opens a fake app-store page. The kit’s dropper builder can mimic Google Play, the Galaxy Store, and AppGallery, or build fully custom pages, complete with fake ratings, reviews, and download counts.

The page then coaxes the user into installing the app from outside the official store and approving its permissions. The app stages its permission requests one screen at a time. A harmless-looking web page sits in the background while pop-up cards request permissions framed as routine: turn off battery limits, set the app as the default text-message handler, and switch on notifications. It also asks to turn on Android’s Accessibility service, which malware abuses to read the screen and control the phone.

With those permissions, RedWing has broad control of the phone. Its capabilities include: Fake login screens, called overlays, that appear over real banking and cryptocurrency apps to steal passwords. Reading incoming texts for one-time passcodes, and using Accessibility to lift codes, card numbers, and PINs off the screen as they appear. Silently switching the victim’s incoming calls over to the attacker, using a hidden carrier code (21) to turn on call forwarding, which knocks out phone-based verification and bank fraud-check calls.

Live screen streaming and a keylogger, so operators can watch and control the phone in real time. Switching on the camera and microphone, reading files, stealing contacts and call logs, and tracking location. Pooling infected phones to flood a target website with traffic, a denial-of-service attack. Buyers choose their own targets, and the malware splits its targeting into two.

The apps it watches through Accessibility are baked into each copy, which points to a fresh app being built to order once a buyer picks targets. The overlay targets, by contrast, can be changed later from the control panel without pushing out a new app. Zimperium counted 82 targeted institutions across several sectors, with a strong focus on Russian financial firms, though that list can shift at any time. The evidence points to the Russian market: one sample used a fake page for Russia’s RuStore.

Experts say the operation appears linked to Russian threat actors but stops short of confirming it. RedWing fits a wider move in Android crime toward on-device fraud, where attackers operate inside the victim’s own banking session instead of stealing a password to use elsewhere. Researchers flagged a near-identical Russian-market rental kit, Fantasy Hub , last year. The same techniques turn up in Albiriox , aimed at more than 400 finance apps, and Klopatra , which used hidden remote control and fake overlays to drain accounts while victims slept.

RedWing needs no Android exploit. It works only when a user installs the app from outside an official store and approves the prompts, so the first line of defense is what happens at install time. For individuals: Install apps only from official stores, and treat any “update” that arrives by link or text message as suspect. Do not turn on “install from unknown sources,” and do not grant Accessibility, default text-message handler, or battery-exemption access to an app with no clear reason to need it.

Watch for an app that hides its icon after it installs, a common trick for staying out of sight. On managed devices, the same choices can be enforced centrally: block sideloading, and flag apps that request Accessibility or the default-SMS role. Researchers have also published indicators of compromise for teams that want to hunt for it. Because the kit can be reskinned and its overlay targets swapped from a panel, the same code can keep resurfacing under new names, so app names are a poor way to track it.

The behavior is the signal, not the name. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots

A critical flaw in Google’s Dialogflow CX could have let an attacker with edit rights on one Code Block-enabled agent compromise other Code Block-enabled agents in the same Google Cloud project. From there, they could read live conversations, steal the data users shared, and make the bots send attacker-written messages, including requests to re-enter a password. Security firm Varonis found it and named it Rogue Agent. The flaw affected only organizations that built agents with Dialogflow’s Playbooks and custom Code Blocks, which let developers add their own Python.

And it was not a remote, unauthenticated attack. Pulling it off needed the dialogflow.playbooks.update permission on one such agent, which limits the realistic attacker to a malicious insider or a compromised developer account, not a stranger on the internet. From that one foothold, though, the reach extended to every agent in the project. Google has fixed it, and both Varonis and Google say there is no sign the flaw was ever used in a real attack.

One writable file ran every agent’s Code Blocks Dialogflow’s Code Blocks let developers add custom Python to a chatbot’s conversation flow to check input, control behavior, and invoke defined tools. That code runs in a Google-managed Cloud Run environment, and every agent that uses Code Blocks in the same Google Cloud project shares one instance of it. Google runs that environment, the customer cannot see or control it, and Varonis found no real isolation between the agents inside it. When an agent runs a Code Block, the developer’s code is appended to internal setup code and passed to Python’s exec() function.

That setup code defines the variables and functions the block can touch. Variables include history for the full conversation and state for session details like the session ID. Functions include respond(), which makes the bot reply with a given string. Varonis found the file that does this wrapping, code_execution_env.py, sitting in the shared environment with write access.

Because that file was writable, a single Code Block could replace it. That block downloads a modified code_execution_env.py from an attacker-controlled server and overwrites the original inside the running container. From then on, the attacker’s version runs for every Code Block execution across every agent sharing that environment. It sits in the same scope as legitimate code, with the same access to history, state, and respond().

That lets it read each conversation, quietly send it to the attacker’s server, and make the bot post attacker-written messages. One example is phishing: the bot asks the user to re-verify a login, and the attacker collects whatever they type. To cover the tracks, the attacker restores the original Code Block in the Dialogflow console. That changes only what the console displays; the overwritten file is already running in the container and keeps executing underneath.

The sandbox leaked two more ways Varonis reported two related issues, and neither needed the file overwrite. First, the Code Block environment had unrestricted outbound internet access. Using the built-in urllib library, the researchers sent data straight to an external server and could receive commands back. Varonis says this bypasses VPC Service Controls, the Google Cloud perimeter meant to stop data from leaving protected services.

The environment sits outside that perimeter and can reach the open internet, which turns it into a channel for both data theft and remote control. Second, and less serious, the environment exposed the Instance Metadata Service (IMDS), a normally internal endpoint that hands out cloud credentials. Querying it returned a token for a Google-managed service account. That account was low-privilege, so the direct risk was limited; the real point is that a code-execution sandbox should not be able to reach IMDS at all.

Almost nothing reached the logs The overwrite happened inside Google’s environment, where customers have no visibility, and Cloud Logging did not record the file change or the injected code. That makes it hard, though not impossible, to catch from the customer side. The setup actions still leave traces, which the checks below rely on. Varonis disclosed the flaw through Google’s Vulnerability Reward Program in November 2025.

Google shipped an initial fix in April 2026 and fully resolved it in June 2026, about seven months from report to resolution. No CVE was assigned. What to check if you used Code Blocks If you ran Dialogflow CX agents with Code Block Playbooks before the fix and want to confirm you were not targeted, start with access. The dialogflow.playbooks.update permission is the whole entry point, so audit which roles and accounts hold it.

Then: Review your DATA_WRITE audit logs for the Dialogflow API for unexpected playbook updates, and correlate them with unusual users, IP addresses, or access times. Run a Cloud Logging query for failed user requests, where the error messages can reveal exceptions thrown by malicious Code Blocks. In the Dialogflow console, open Playbooks for each agent and confirm every Code Block is one you approved. A different kind of AI flaw Many recent AI security flaws have worked by fooling the model.

Varonis’s own Reprompt and SearchLeak turned a single click into data theft in Microsoft’s Copilot. Noma Security’s ForcedLeak hid instructions in a Salesforce web form to pull out CRM data. Microsoft’s researchers showed prompt injection turning into code execution in the Semantic Kernel framework. Rogue Agent did not touch the model at all.

It abused a normal developer feature and a shared, invisible runtime, reachable with one ordinary edit permission. In a setup like this, a permission that looks like a content-edit right is actually a code-execution right. Anyone who can add a Code Block can run arbitrary Python inside a shared environment that the customer cannot inspect. Treat agent-edit permissions as the runtime controls they are.

Even when the provider says nothing needs fixing, customers still have no way to look inside that runtime themselves. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

DEBULL Tooling Abuses Microsoft Device-Code Flow to Target M365 Accounts

A Microsoft 365 device code phishing campaign has been observed leveraging collaboration-themed lures to take control of victim accounts between the last week of June 2026 and into early July, per findings from ZeroBEC. “The campaign did not depend on a fake Microsoft password page. It used a malicious collaboration-style lure to push users into the legitimate Microsoft device login experience, while a backend broker generated and polled Microsoft Authentication Broker device-code tokens,” the email security company said in a report shared with The Hacker News. The activity is assessed to share “strong” overlaps with a campaign documented by Microsoft in February 2025 under the moniker Storm-2372 , including the use of messaging or Teams-style lures to trick unsuspecting victims into entering an attacker-provided device code, along with their credentials, effectively allowing the threat actor to recover the token and hijack their account.

Despite these similarities, it’s assessed that the threat actors are employing Storm-2372-style tradecraft through what has been described as a reusable tooling layer called DEBULL . Device code phishing refers to an identity theft technique where attackers exploit a legitimate OAuth 2.0 authentication mechanism, specifically the Device Authorization Grant flow, to bypass multi-factor authentication (MFA) and gain persistent account access without having to steal user passwords. Unlike traditional phishing attacks that require the operators to set up bogus adversary-in-the-middle (AitM) login pages, device code phishing relies on manipulating a user into completing a real, trusted authentication prompt. Device code authentication, per Microsoft , is a legitimate OAuth flow designed for devices with limited interfaces, such as smart TVs or printers, that cannot support a traditional interactive login.

In this scenario, a user is presented with a short code on the device they are trying to sign in from and is prompted to input that code into a web browser on a separate device to complete the authentication. Threat actors have abused this separation to insert themselves and initiate the authentication flow . Then, they share that code with the target through a phishing lure. Thus, when the user enters the code, they authorize the threat actor’s session without their knowledge, granting them access to the account.

“Device code phishing doesn’t hack its way in,” Huntress notes . “It uses a legitimate authentication flow to walk right through the front door, with no password required, MFA bypassed, and session tokens handed straight to the attacker.” Successful device code phishing attacks can facilitate full account takeover, theft of valuable information, fraud, business email compromise (BEC), lateral movement within a compromised environment, and even disruptive attacks like ransomware. “In most current device code phishing attacks, the code is generated dynamically when a user clicks on the initial phishing link. This seemingly small change allows the user to view the email at any time to kickstart the attack chain,” Proofpoint said in an analysis published in May 2026.

“These new implementations of the device code attack chains can be purchased via phishing-as-a-service (PhaaS) offerings, like EvilTokens or Tycoon, or created and owned by the threat actor conducting the campaigns. “ These campaigns are also known to leverage account takeover (ATO) jumping, a technique where an attacker compromises an initial email account and then abuses it to send phishing links to a broader set of contacts in the form of a button, hyperlinked text, embedded within a document, or a QR code. The links, when visited by the recipient, initiate an attack sequence that employs the Microsoft device authorization process. ZeroBEC said the campaign it observed involves using payment and shared-folder pretexts in phishing emails to deceive victims into clicking on a URL that takes them to a legitimate-but-compromised Croatian rental website, which, in turn, acts as a device code orchestrator used to initiate the Microsoft device code challenge chain.

The workflow is characterized by the presence of Turkish-language developer markers, although the clues aren’t enough to definitively attribute the campaign’s provenance. Further analysis of the infrastructure has revealed that DEBULL is likely a phishing-as-a-service (PhaaS) platform that uses GraphSpy or a GraphSpy-derived workflow for Microsoft 365 and Entra post-exploitation. “Operators can define a page name and slug, edit HTML, CSS, and JavaScript directly, then choose how the lure is published,” ZeroBEC said. “The embedded templates included a Microsoft 365 device-code authentication page, an OAuth callback page, and a modern landing page.

The Microsoft 365 template is especially important because it exposes the exact building block used by the campaign: a user-code display, copy-code behavior, and a link to Microsoft device login.” “The more useful conclusion is that Storm-2372-style identity tradecraft is now being packaged into reusable broker infrastructure. DEBULL provides the campaign-facing and operator-facing layer. GraphSpy or GraphSpy-derived code likely handles the post-authentication layer. The lure can be changed without changing the backend identity stack.” The disclosure comes as Cisco Talos said it identified a fully-featured PhaaS operator panel branded ARToken that shares infrastructure, API contracts, and operational patterns with the EvilTokens device code phishing platform and is made available to affiliates.

“The ARToken panel exposes 80+ API endpoints for device code phishing, Primary Refresh Token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration - all accessible to operators through a React-based dashboard,” Talos said. EvilTokens , like DEBULL, enables attackers to weaponize harvested tokens to exfiltrate emails, files, and other sensitive data from compromised Microsoft accounts, carry out reconnaissance via Microsoft Graph API, and establish persistence access. In addition, it incorporates artificial intelligence (AI)-powered features to automate and scale BEC workflows, such as sifting through thousands of harvested emails, identifying finance-related email threads, and drafting BEC emails. ARToken functions as a complete post-compromise toolkit that allows operators to leverage the captured access token recovered following successful device code authentication to maintain access, perform email operations, access OneDrive and SharePoint, and browse victim Microsoft 365 sessions outside the panel using a dedicated tool known as ARTBrowser.

“These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment,” Talos researcher Michael Kelley said. The surge in device code phishing attacks has also led to other PhaaS kits like Tycoon 2FA adopting the technique to hijack Microsoft 365 accounts in its rebound following a law enforcement operation, signaling a broader shift within the threat landscape. New campaigns using the kit have employed rebuilt infrastructure and multiple layers of obfuscation, while including extensive safeguards against researchers and automated scanning. “Tycoon 2FA operators have repurposed their existing PhaaS kit as the delivery framework for OAuth device code grant phishing,” eSentire noted in May 2026.

“The attack begins when a victim clicks a Trustifi click-tracking URL in a lure email and culminates in the victim unknowingly granting OAuth tokens to an attacker-controlled device through Microsoft’s legitimate device-login flow at microsoft.com/devicelogin.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Take the AI Sprawl CISO Survey. Get fast track to BlackHat swag

Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data

A public issue can trick GitHub Agentic Workflows into leaking the contents of an organization’s private repositories, researchers at Noma Security have shown. The attacker needs only to open a normal-looking issue on a public repository, with no stolen credentials and no access to the organization. If that organization has given the agent read access across its repositories, private ones included, the issue can steer it into pulling private contents into a public comment. Noma calls the technique GitLost .

The target is GitHub Agentic Workflows , a feature now in public preview that GitHub launched in February. Instead of writing automation scripts, you write instructions to an AI agent in plain English in a Markdown file. The agent reads issues and pull requests, runs tools, and replies on its own. It can be powered by GitHub Copilot, Anthropic’s Claude, Google Gemini, or OpenAI Codex.

Workflows are read-only by default, but an organization can hand one a token with read access across its repositories to give it cross-repo context, private ones included. That grant is the setup GitLost turns against it. How the trick works The weakness is a well-known one: indirect prompt injection . An AI agent cannot reliably tell the difference between instructions from its owner and instructions hidden inside the content it happens to read.

So if an attacker writes those instructions into an issue, the agent may simply follow them. In Noma’s proof of concept , the malicious issue was dressed up as a routine request from a VP of Sales after a customer meeting. The workflow it hit was set to wake up when an issue is assigned, read the issue, and reply with a comment. It also had read access to the organization’s other repos.

Once a routine automation assigned the issue, the agent pulled a private repository’s README and pasted it into a public comment on the issue. GitHub built guardrails to stop exactly this. In its own documentation , the company warns that “AI agents can be manipulated by prompt injection, malicious repository content, or compromised tools,” and the product ships with sandboxing, read-only tokens by default, input cleaning, and a threat-detection step that scans an agent’s proposed output before it posts. Noma reported that in its test, a one-word change was enough to slip past.

Prefixing the malicious instruction with “ Additionally “ led the model to treat it as a follow-on task, not something to refuse, and the guardrail let it through. Why is this one different? What sets GitLost apart is what the attacker gets to control. “Earlier prompt injection examples were largely about manipulating what an agent said,” Sasi Levi, Security Research Lead at Noma Security , told The Hacker News.

“GitLost is about manipulating what an agent does with its permissions.” The agent here, he said, is not a chat window but a credentialed actor sitting inside an organization’s CI/CD-adjacent infrastructure, with read access spanning repos the attacker cannot see. It touches no server, needs no stolen credentials, and does not require write access to anything private. The attacker only has to open a public issue. The setup fits what developer Simon Willison named the “lethal trifecta” , and Levi uses the same term: an agent that can reach private data, takes in untrusted outside content, and has a way to send data out.

Combine all three, and you have a leak path. This is not the kind of bug a patch closes; as Levi frames it, it is a structural consequence of giving AI agents standing credentials while having them read attacker-reachable text. Why does this keep happening GitLost is the latest in a run of the same kind of attack, and THN has reported several in recent months. A flaw in Anthropic’s Claude Code GitHub Action let a single malicious issue push the agent into leaking secrets and seizing write access to a repository.

Orca Security’s RoguePilot used a hidden prompt in a GitHub issue to make Copilot leak a repository’s privileged token. The GitHub-agent version of the problem goes back to at least May 2025, when Invariant Labs showed that a public issue could push an agent connected to GitHub’s MCP server into reading a private repo and leaking it through a pull request; the researchers called it architectural, with no server-side patch to close it. A cross-vendor study named Comment and Control then tricked the Claude Code, Gemini CLI, and GitHub Copilot agents into leaking their own API keys through issue and pull-request text, slipping past GitHub’s added runtime defenses along the way. What to do now Noma disclosed GitLost to GitHub and published its findings with the company’s knowledge.

Exposure is limited to organizations that have enabled the preview and wired an agent to read untrusted public input while holding read access to private repositories and are able to post in public. What an attacker could pull depends on what the agent’s token can see, from proprietary source code to internal keys, design documents, or CI/CD secrets. As Levi puts it, scope is what matters most: an agent token scoped to the single repository it triages is “far less dangerous than one issued broad org-wide read access” for convenience. In practice, that cross-repo access comes from a personal access token the organization sets up, so scope the token to the one repository the workflow triages rather than the whole organization.

Writes flow only through declared safe outputs, so limit what a public-facing workflow can post, because the comment it produces is the exfiltration channel. Restrict which authors’ content the agent will act on, and gate its outputs behind human review. GitHub’s threat-detection step scans an agent’s output before it posts, but Noma’s one-word bypass is a reminder that a filter is a backstop, not a boundary. GitHub, like the other vendors, built guardrails for exactly this class of attack, and a one-word change bypassed them.

Researchers and the vendors themselves keep filing the result under “architectural limitation,” and Levi’s point is why the label sticks: in natural language, there is no clean line between data and instruction the way there is in SQL, so the fix leans on architecture rather than filtering the injection away, on isolation, scoped credentials, and staged review. Until that boundary exists, any agent that reads private data, takes in untrusted input, and can post in public is one cleverly worded issue away from a leak. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Court Filing Reveals Windows Device ID Helped FBI Trace Alleged Scattered Spider Hacker

U.S. prosecutors linked an alleged Scattered Spider hacker to a break-in at a luxury jewelry retailer using a persistent Windows device ID, according to a newly unsealed federal complaint . Microsoft records tied that ID first to the account the attackers used to keep access during the May 2025 intrusion, then to online accounts prosecutors say belong to 19-year-old Peter Stokes. Stokes is charged with conspiracy, computer intrusion, and fraud.

A dual U.S.-Estonian citizen known online as “Bouquet,” he was extradited from Finland and made his first court appearance in Chicago on June 30, as THN reported . He is presumed innocent pending trial. How the break-in worked Between May 12 and 15, 2025, attackers phoned the retailer’s IT help desk from Google Voice numbers, posed as locked-out employees, and got staff to reset employees’ passwords and the mobile devices tied to their multifactor authentication. Within a few hours, they controlled three accounts, two belonging to IT administrators.

They installed ngrok and a second tunneling tool called Teleport, moved data to Amazon cloud storage, and pulled out at least 77 gigabytes. They appear to have tried to deploy ransomware, but the retailer’s security team blocked it and evicted them from the network. The attackers still sent a ransom email, subject line “IMPORTANT: WE STOLE THE DATA, CONTACT UMMEDIATELY [sic],” and later asked for $8 million in cryptocurrency. The company did not pay.

The breach still cost it about $2 million in disruption, investigation, and cleanup. The way in was the help desk, not a software flaw. The fix is a process, not patching: verify identity before any reset with a callback to a number already on file, manager sign-off, or video checks for privileged accounts. Phishing-resistant MFA like FIDO2 keys blunts the group’s other methods, but does nothing if a help desk will reset an account on a phone call.

The ID that led investigators to Stokes Investigators worked back to Stokes from the device that opened the ngrok account. Microsoft told the FBI it carried Global Device Identifier g:6755467234350028, which Microsoft describes as a persistent identifier tied to a single Windows installation, one that survives operating-system updates but changes when Windows is reinstalled. Microsoft records show that the device visited the ngrok signup page at 19:21 UTC on May 12, 2025, the same minute the ngrok account was created, and reached the retailer’s website through the same proxy about three hours later. The device also kept surfacing on the same IP addresses, at the same times, as Snapchat, Apple, and Facebook accounts prosecutors attribute to Stokes: an address in his home city of Tallinn, Estonia, in June 2024, then New York in November and Thailand in February 2025, matched by State Department travel records.

The complaint shows an operator who hid the attack, behind a VPN proxy, tunneling tools, and aliases, but not himself. Prosecutors say his Snapchat flaunted cash, watches, and diamond chains reading “HACK THE PLANET,” along with the very trips that placed him in those cities. He even posted photos of an Estonian police station and taunted that the feds had no idea what they had let get away. One arrest, and why it may not slow the threat Investigators can now tie a single operator to the machine that set up an attack.

But one arrest barely touches the wider threat. In separate, recent research, Group-IB argues Scattered Spider is not really one group at all. It is a loose collective of small, independent cells, most no bigger than five people, tied together by shared tricks, tools, and chat rooms rather than a shared boss. Group-IB compares it to the Anonymous movement and says arresting some of these cells “will not stop the threat itself.” Prosecutors describe Scattered Spider as one group behind more than 100 intrusions and over $100 million in ransoms.

Group-IB says the label fits a scene better than a gang, and argues that loose structure is why the activity survives each arrest. Part of a longer run of cases Other recent Scattered Spider prosecutions follow the same shape: individuals arrested one at a time, the shared playbook intact. In April 2026, Scottish national Tyler Buchanan pleaded guilty in the U.S. to fraud and identity theft tied to the group.

In 2025, Noah Urban, known as “Sosa,” was sentenced to 10 years over a SIM-swapping scheme linked to Scattered Spider. And in the U.K., two alleged members recently admitted to the Transport for London hack, which cost an estimated £29 million. When Finnish police stopped Stokes at Helsinki airport as he tried to board a flight to Japan, they seized two 2-terabyte hard drives. This whole case was built from that kind of material: device records, account links, and IP trails.

In a network this diffuse, the drives could matter more than the conviction, if they hold the tools, infrastructure, or contacts that reach the next member. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Writer AI Flaw Could Let Agent Previews Leak Session Tokens Across Tenants

Cybersecurity researchers have disclosed details of a now-patched critical session isolation vulnerability in Writer , an enterprise generative artificial intelligence (AI) platform, that could result in cross-tenant compromise. The one-click vulnerability has been codenamed WriteOut by the Sand Security Research team. “An outsider could go from having no access to taking over any Writer AI organization inside industry-leading enterprises, with nothing more than a link,” the cybersecurity company said in a report shared with The Hacker News. Put differently, the shortcoming could be abused to take over a victim’s Writer account, and use it to access private chats, documents, and other sensitive data related to agents, configurations, private models, connectors, and large language model (LLM) credentials.

Even worse, it could be abused to seize administrative control depending on the victim’s role. An important aspect of the flaw is that the attacker and the victim don’t have to belong to the same organization. An attacker can create an agent in their own Writer account and share a preview link. That’s all it takes to trigger the vulnerability, essentially making it possible to hijack the account of a victim who clicks on the link and is signed in with their own session.

“An attacker can abuse Writer’s AI managed sandbox to collect sessions belonging to completely separate companies and act inside each of them as a real user, with no prior foothold anywhere,” Sand Security said. WriteOut also undermines the shared responsibility model as it breaks tenant isolation protections by taking advantage of Writer’s live preview feature that allows users to preview the application via the Writer Framework. The entire attack chain plays out as follows - An attacker builds an agent with a live preview and shares its public preview link. When a logged-in Writer user opens that link, their browser attaches their Writer session cookie to the request.

The preview proxy sends that cookie into the attacker’s sandbox . The code contained within the attacker-controlled sandbox reads the forwarded session token and exfiltrates it. The attacker replays the token and gains control of the victim’s Writer account. Because an attacker can instruct their pre-built malicious agent to run code inside the controlled, managed sandbox, it makes it possible to read the sandbox process’s memory, recover the exfiltrated session token of the victim, and transmit it to a server they maintain.

Following responsible disclosure, Writer has addressed the issue by preventing the user’s session cookie from being forwarded into sandbox previews entirely, and moving them to an isolated origin. “Writer wasn’t careless, there were guardrails. Input-side filtering tried to block users from reading environment variables or submitting obviously malicious code,” Sand Security said. “The problem is what those checks looked at: the instruction, not the runtime behavior.” “Bypassing the guardrail was pretty straightforward: Instead of pasting the payload inline, we simply told the agent to fetch and run a remote script.

The guardrail saw a benign ‘download and run’ request, and the actual exploit logic never appeared in the prompt at all.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

What Changes When Your Software Supply Chain Includes AI Writing Your Code?

Software supply chain security was hard enough. Then AI joined the build pipeline. For five years, “software supply chain security” meant one question: what’s in your code? Which open-source packages, which versions, which transitive dependencies three layers deep that nobody chose on purpose?

SolarWinds, Log4Shell, and XZ Utils all taught the same lesson: the risk lives less in the code a team writes and more in everything that produces it. Shai-Hulud, the self-propagating malicious package campaign that spread through developer toolchains this year, taught the next one: knowing what’s in your code is still necessary, but it’s no longer sufficient. In the roughly 20 months since the Model Context Protocol launched, AI tools, models, and the infrastructure around them have become load-bearing parts of how software gets built, deployed, and run. Code is written by agents.

Packages are pulled in by autonomous tools that decide they are needed. Prompts have become a real input to the build, which means they’re a real way to compromise it. None of this was in scope when most security programs were designed. Where the risk actually moved It’s tempting to treat AI-generated code as just more code, run it through the same scanners, and call it covered.

That misreads where the risk moved. The provenance question that has always defined supply chain security - where did this come from and can I trust it - now applies to the model, the agent, and the tooling, not only the artifact. An AI coding assistant suggests a dependency and a developer accepts it without the package ever crossing a human’s threat model. An autonomous agent reaches for a tool over MCP to complete a task, and that tool reaches for another.

A prompt, crafted by an attacker and planted somewhere the model will read it, steers what gets written or what gets pulled in. Validating AI-generated code before it’s committed is table stakes. The harder problem is governing the agents doing the writing and the tools they call. What a program looks like when AI is in scope The teams we work with aren’t short on findings.

They’re drowning in them. Adding “scan the AI output too” to an already overloaded queue makes the alert pile taller, not the program stronger. Two things change when AI is genuinely in scope. First, lineage has to extend to everything entering the pipeline, including the models and agents.One approach is extending lineage to the pipeline itself - tracing activity, provenance, and configuration changes from first commit to runtime, and applying the same rigor to models and agents as to any other dependency.

Second, prioritization has to be based on real exploitability, not volume. Correlating findings with runtime context with what’s actually reachable is the difference between a vulnerability list and a workable chain of exploit. That difference matters more, not less, once an agent can generate a thousand lines of plausible code before lunch. This is the gap that Gartner formalized in June when it published the inaugural Magic Quadrant for Software Supply Chain Security - the market’s acknowledgment that a problem teams have been defending without a budget line is now something worth evaluating systematically.

On July 22, OX researchers are hosting a webinar - How AI Is Reshaping Supply Chain Security As We Know It

to walk through new research alongside security leaders doing this work from the inside. We’ll cover how AI integration changed the attack surface, findings from the first systematic look at MCP servers in the wild, and what a supply chain security program actually looks like when AI is in scope rather than bolted on after. Register here . Bring hard questions.

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

Suspected China-Aligned Hackers Exploit Roundcube Flaws Against Universities

A suspected China-aligned threat activity cluster has been observed exploiting Roundcube webmail software belonging to physics and engineering departments of U.S. and Canadian universities as part of a new campaign. The activity involves the exploitation of now-patched, critical security flaws in the open-source email solution, such as CVE-2024-42009 (CVSS score: 9.3), to siphon credentials, followed by either the deployment of a web shell for persistent access or a known post-exploitation tool called VShell . The emerging threat cluster is being tracked by Proofpoint under the moniker UNK_MassTraction .

It was first detected in May 2026, specifically focusing on administrators and professors in departments with either national security ties or entities studying astrophysics and particle physics. “The emails targeting university departments used both compromised senders, as well as abused domains vulnerable to spoofing due to lax DMARC policy to send the emails,” the enterprise security company wrote in a technical report shared with The Hacker News, adding the use of generic lures indicates a “larger targeting swath” beyond its visibility. While the nature of the cross-site scripting (XSS) exploit is such that it only requires the recipient to open the email in the Roundcube client in order to obtain access to the mail server, it’s assessed that the targeted departments were singled out because they were all running versions of Roundcube susceptible to N-day security flaws. This indicates that the threat actor likely carried out preparatory reconnaissance into these targets to gather information about their environments prior to sending phishing emails that trigger an exploit for CVE-2024-42009 and execute arbitrary JavaScript code in the context of the victim’s web browser.

“The actor is likely abusing Roundcube servers as a pivot point to enter target networks, and the operators have deliberately crafted their infection chain to avoid detection,” Proofpoint researchers Greg Lesnewich and Mark Kelly said. The payload delivered following the exploitation of the XSS flaw, codenamed IceCube, is designed to siphon credential information stored in the browser along with two-factor authentication (2FA) and cookies. It also carries out reconnaissance of its own to collect information about the browser language, screen size, and form field values. screen size, and form field values.

The harvested information is sent to an external system by means of an HTTP POST request. In the next step, IceCube leverages the session’s CSRF token to weaponize a second post-authenticated remote code execution flaw in Roundcube - CVE-2025-49113 (CVSS score: 9.9) - with the goal of obtaining a foothold in the mail server and dropping VShell or a web shell dubbed SquareShell in memory. The web shell, deployed by means of a PHP gadget shell command, is remotely reachable at the endpoint “plugins/newmail_notifier/mail_preview.php” and enables arbitrary code execution. However, if the web shell installation fails for some reason, the attack chain falls back to an alternate mechanism in which a shell script is executed via the Roundcube vulnerability to ultimately deliver VShell .

The secondary method is said to have been introduced in June 2026, when previously the attack chain would simply exit upon failing to deploy SquareShell. The shell script acts as a conduit for an ELF loader referred to as SNOWLIGHT and has been put to use in other intrusions orchestrated by Chinese adversaries. The use of both SNOWLIGHT and VShell has been linked to a China-linked cluster tracked as UNC5174 in the past. Lesnewich, principal threat researcher at Proofpoint, told The Hacker News that there is currently no data that links UNK_MassTraction to UNC5174 or other known adversaries, adding the toolkit has been put to use by multiple Chinese threat actors.

This suggests that the shell script is possibly shared by multiple China-nexus clusters in a private capacity, similar to ShadowPad and other tools. The script’s main responsibility is to fetch a version of SNOWLIGHT that’s compatible with the host’s system architecture and then execute it. “IceCube also sets up what it calls ‘deferred triggers’ to ensure continuance of the infection chain,” Proofpoint said. “The deferred triggers monitor if the user closes the page or changes tabs, checks if the mouse leaves the browser window, and hijacks the logout button.” “If any of those actions are taken, IceCube hooks those events, and re-attempts exploitation of CVE-2025-49113, and beacons to the C&C [command-and-control] that the user left the Roundcube session.” Upon completing these actions or running into a timeout, the JavaScript malware destroys user and malware-initiated sessions on the server, causing the user to log out and erase forensic evidence associated with the compromise from the Roundcube server.

Written in Go, VShell is a remote administration tool that provides post-compromise capabilities similar to Cobalt Strike. It has been utilized by various China-aligned adversaries in recent years. The development marks the first time a Chinese hacking group has been tied to the exploitation of Roundcube flaws, which have been traditionally abused by state-sponsored threat actors from Russia. “While the targeting of this campaign is captivating to the imagination, it is unlikely that UNK_MassTraction will be solving deep theoretical physics questions or the Fermi Paradox in the near future,” Proofpoint researchers concluded.

“UNK_MassTraction displayed a mature toolkit and unique usage of n-day vulnerabilities. The campaign is a reminder that email delivery can facilitate compromise of the mail server, and that Chinese operators will continue to treat them like any other edge device, so defenders should prioritize defending the mail servers of their networks as thoroughly as they do their VPN concentrators and other remote access nodes on their networks.” (The story was updated after publication to include a response from Proofpoint.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

CERT/CC Warns of Hidden Admin Backdoor in Tenda Router Firmware

Several versions of firmware released by Chinese network device manufacturer Tenda have been found to embed an undocumented authentication backdoor that enables administrative access to the devices’ web management interfaces, the CERT Coordination Center (CERT/CC) warned Monday. “An attacker can exploit this vulnerability, tracked as CVE-2026-11405 , to bypass the password verification process and obtain full administrative control without valid credentials,” the CERT/CC said in an alert. The vulnerability impacts multiple versions of the firmware - US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE US_AC10V1.0re_V15.03.06.46_multi_TDE01 US_AC5V1.0RTL_V15.03.06.48_multi_TDE01 US_AC6V2.0RTL_V15.03.06.51_multi_T The backdoor functionality is present within the “login()” function of the “/bin/httpd” web server binary. While the method initially follows a normal authentication path using MD5-based password verification, it activates an alternate code path if the authentication fails.

Specifically, this involves calling “GetValue(“sys.rzadmin.password”)” to fetch an alternate password value from the device configuration, and performing a direct plaintext comparison between the user-supplied password and the configuration-stored value. Should these values match, the application grants admin-level access (role=2) and creates a valid session with elevated privileges. “The associated [“rzadmin”] username is not validated, so any provided username will succeed when paired with the backdoor password,” the CERT/CC said. “This backdoor authentication mechanism is not documented or visible through any administrative interface.” Successful exploitation of this standard username validation override allows full administrative access to the device’s web interface regardless of the administrator account credentials.

It can permit an attacker to make unauthorized remote modification of settings, disable security features, or reconfigure the device, potentially leading to a complete device takeover. The vulnerability, reported by an anonymous researcher, remains unpatched as of writing. The Hacker News has contacted Tenda for comment, and we will update the story if we hear back. In the interim, users are advised to disable remote management on the device and change the default LAN IP address to prevent bad actors from reaching it and reduce opportunistic discovery by automated scanners that target known default IP ranges.

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

BeyondTrust Patches Critical Auth Bypass Flaws in Remote Support and PRA

BeyondTrust has released updates to address two critical security flaws affecting Remote Support (RS) and Privileged Remote Access (PRA) products that, if successfully exploited, could allow unauthenticated attackers to take control of susceptible devices. The vulnerabilities are listed below - CVE-2026-40138 (CVSS score: 9.2) - A pre-authentication vulnerability exists in the authentication subsystem of BeyondTrust Remote Support and Privileged Remote Access stemming from improper validation of authentication data that could allow a network-positioned attacker to bypass access controls and gain unauthorized access to the appliance, including accounts with elevated privileges. CVE-2026-40139 (CVSS score: 9.2) - A pre-authentication vulnerability exists in the authentication subsystem of BeyondTrust Remote Support stemming from improper processing of authentication requests that could allow an unauthenticated remote attacker to bypass access controls and gain unauthorized access to the appliance, including accounts with elevated privileges. CVE-2026-40140 (CVSS score: 8.7) - A pre-authentication vulnerability in the network communication subsystem stemming from insufficient validation of client-supplied input that could allow an unauthenticated remote attacker to trigger a denial-of-service condition, affecting appliance availability.

CVE-2026-40141 (CVSS score: 8.5) - A vulnerability exists in a web application component of BeyondTrust Remote Support and Privileged Remote Access stemming from insufficient validation of user-supplied input that could allow an authenticated attacker with limited privileges to access unintended resources or data beyond their authorization scope. It’s worth noting that the successful exploitation of CVE-2026-40138 and CVE-2026-40139 hinges on a specific authentication configuration being enabled. In the case of CVE-2026-40141, exploitation, should it occur, is restricted to accounts with specific permissions. BeyondTrust said all the identified internally as part of ongoing security assessments, with assistance using publicly available artificial intelligence (AI) models like Anthropic Claude Opus 4.8 and its own proprietary research tooling.

“The most severe vulnerabilities may allow an unauthenticated remote attacker to bypass access controls and gain unauthorized access to the appliance under specific configurations,” it said. “Additional vulnerabilities may allow service disruption, unintended data access, and, under distinct configurations, elevated access by an authenticated user that may impact system integrity.” The issues have been addressed in the following versions - Remote Support RS 25.3.2 or lower (Fixed in RS 25.3.3 and above) Privileged Remote Access PRA 25.3.2 or lower (Fixed in PRA 25.3.3 and above) BeyondTrust makes no mention of the vulnerabilities being exploited in the wild. However, security flaws in RS and PRA products ( CVE-2024-12356 and CVE-2026-1731 ) have come under repeated exploitation in the past to deploy web shells and backdoors, making it essential that users move quickly to apply the fixes. Found this article interesting?

Iran-Linked Hackers Use New Cavern C2 Framework to Target Israeli Organizations

An Iranian hacking group affiliated with Iran’s Ministry of Intelligence and Security (MOIS) has been wielding a previously undocumented modular command-and-control (C2) framework dubbed Cavern (aka Cav3rn) targeting Israeli organizations. The activity, which has primarily singled out IT providers and government sectors, has been attributed to a threat cluster tracked by Check Point Research under the moniker Cavern Manticore , which it said shares some level of tactical overlaps with MuddyWater and Lyceum , the latter of which is assessed to be a subgroup within OilRig . “The framework reflects a mature and adaptable toolset built around a shared .NET foundation, while using multiple compilation formats across different components, including .NET Framework, .NET Mixed-Mode C++/CLI, and .NET Native AOT ,” the cybersecurity company said . “The compilation format itself becomes the anti-analysis layer that forces reverse engineers into multiple toolsets and metadata-reconstruction workflows.” The components of the C2 framework are used as Cavern Agent and Cavern modules, demonstrating a clear division of responsibilities between core communication capabilities and mission-specific post-exploitation functionality.

This architecture has inherent advantages as it allows the operators to tailor deployments based on the victim profile, reduce forensic visibility, and ensure persistent access through bespoke modules for reconnaissance, data theft, tunneling, and lateral movement. The attack chain documented by Check Point Research commences with SysAid’s software update feature, which is leveraged by the adversary to initiate a DLL side-loading chain that leads to the execution of a trojanized DLL (“uxtheme.dll”) containing the Cavern Agent. The agent, for its part, loads a standalone communication DLL module (“n-HTCommp.dll”) to contact the C2 server (“hospitalinstallation[.]com”) and fetch additional post-exploitation modules on the fly over HTTPS or WebSocket. As many as five DLL modules have been uncovered - mhm.dll , for file operations, enumeration, recursive file search, archive handling, and bidirectional file transfer db.dll , for SQL database enumeration, query, export, and manipulation ode.dll , for Active Directory reconnaissance, user/group enumeration, and LDAP brute-force attempts n-ten.dll , for network reconnaissance, port scanning, share enumeration, and SMB brute-force attempts n-sws.dll , for SOCKS5 proxy and WebSocket tunneling A defining trait of the framework is its use of three different .NET compilation targets spanning its components: while mhm.dll, db.dll, and ode.dll are pure .NET Framework modules, n-HTCommp.dll, n-ten.dll, and n-sws.dll make use of Native AOT (Ahead-of-Time) compilation.

The main agent, uxtheme.dll, combines managed .NET code with native C++ in a single portable executable. Embedded within the agent is a unified module dispatcher that treats components whose names start with n- as native DLLs and loaded via the LoadLibraryA Windows API, while the rest is interpreted as managed .NET assemblies and loaded through a mechanism known as AppDomain isolation . “The framework’s anti-analysis posture relies on uncommon .NET compilation formats (Mixed-Mode C++/CLI and Native AOT) that force reverse engineers into multiple toolsets and metadata-reconstruction workflows, together with per-module AppDomain isolation as an anti-forensics measure,” Check Point explained. Attacks orchestrated by Cavern Manticore have involved the threat actor moving from an initial compromised IT provider to a second-hop provider before ultimately reaching the intended target organization, indicating their ability to weaponize trusted relationships in the software supply chain to their advantage.

“This activity highlights the operational value of trusted service-provider relationships, particularly where Remote Monitoring and Management (RMM) solutions are deployed,” the company noted. “By abusing these tools, the actor can move laterally between victims and deliver malicious software disguised as legitimate updates. The actor also appears to leverage browser-based remote desktop technologies to access targets of interest and, in some cases, abuse built-in features such as remote printing to exfiltrate data when clipboard-based copy-paste or file-transfer capabilities are restricted.” The development unfolds against the backdrop of the ongoing joint military operation launched by Israel and the U.S. against Iran.

In recent months, the Iranian state-sponsored threat actor tracked as MuddyWater has been observed conducting a broad reconnaissance campaign across more than 12,000 internet-exposed systems by exploiting known security flaws in internet-exposed SmarterMail, n8n, N-central, Langflow, and Laravel Livewire systems. The list of exploited vulnerabilities is as follows - CVE-2025-52691

SmarterMail remote code execution vulnerability CVE-2025-68613
n8n remote code execution vulnerability CVE-2025-9316
N-Central unauthenticated sessionID generation vulnerability CVE-2025-34291
Langflow remote code execution vulnerability CVE-2025-54068
Laravel Livewire remote code execution vulnerability The operation is said to have pivoted from broad reconnaissance to targeted credential harvesting and data exfiltration attacks against aviation, energy, and government sectors in the Middle East, including aviation, energy, and public sector entities in Egypt, Israel, and the United Arab Emirates. “The operation leveraged a combination of vulnerability exploitation, Outlook Web Access (OWA) brute-force attacks, and newly identified command-and-control (C2) controllers supporting multi-protocol communication,” Oasis Security said . “The activity progressed beyond reconnaissance and access attempts, resulting in confirmed exfiltration of sensitive data from compromised environments.” Found this article interesting?

16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems

A use-after-free bug in Linux’s KVM hypervisor can be triggered from a guest virtual machine to corrupt the shadow-page state of the host kernel that runs it. Dubbed ‘ Januscape ‘ and tracked as CVE-2026-53359 , the flaw sits in the shadow MMU code that KVM shares across both Intel and AMD. The public proof-of-concept panics the host; the researcher claims that a separate, unreleased exploit turns the same bug into full host code execution. Security researcher Hyunwoo Kim (@v4bel) found and reported the bug.

He described Januscape as the first guest-to-host exploit triggerable on both Intel and AMD, to the best of public knowledge. The flaw went unnoticed for roughly 16 years. According to Kim, the exploit was used as a zero-day submission in Google’s kvmCTF , the controlled KVM vulnerability reward program that offers up to $250,000 for full guest-to-host escapes. How It Works To run a virtual machine, KVM keeps its own private set of page tables that mirror the guest’s memory layout.

When it needs one of these tracking pages, it looks for an existing one to reuse. The problem: it matched them by memory address alone and ignored what type of tracking page it was grabbing. Two different types can share the same address but do completely different jobs, so KVM would sometimes reuse the wrong kind. That mix-up scrambles KVM’s internal records of which page belongs where, and once those records are wrong, something has to give.

Most of the time, the kernel notices the mess and shuts itself down on the spot to avoid doing damage. That crash is what the public demonstration triggers: a guest can knock over the whole host, taking every other VM on that machine down with it. The rarer, worse case happens when the freed tracking page gets handed out for another use before the kernel cleans up. The cleanup then scribbles a value into memory it no longer owns.

An attacker only controls where that write lands, not what gets written, but even that limited foothold can be worked up into running code on the host. The flaw behaves the same on Intel and AMD chips; only the final, hardest step of turning it into full control takes different work on each. Who Is Affected The vulnerable code has been present since commit 2032a93d66fa in August 2010 (kernel 2.6.36 era) and was fixed by commit 81ccda30b4e8 , merged into mainline on June 19, 2026. The attack requires two things from the guest side: root inside the VM, a common condition on rented cloud instances, and nested virtualization exposed by the host.

Even on hosts that run hardware EPT or NPT by default, nested virtualization forces KVM back through the legacy shadow MMU, which is where the bug sits. The exploit needs no cooperation from QEMU or any userspace VMM. It is purely an in-kernel KVM bug. The practical concern is any x86 environment that hosts untrusted guests with nested virtualization enabled.

An attacker who rents a single such instance can panic the host, taking down every other tenant VM on the same physical machine. Kim said the withheld full exploit runs code as root on the host, which would expose other guests on the same machine to that root access. On distributions like RHEL, where /dev/kvm is world-writable (0666), Kim noted the same bug could also serve as a local privilege escalation to root, though the guest-to-host path is the higher-impact use. A Busy Few Months for One Researcher Januscape is Kim’s third Linux kernel exploit disclosure in roughly two months.

In May 2026, he disclosed Dirty Frag ( CVE-2026-43284 / CVE-2026-43500 ), a page-cache write vulnerability chain that delivers deterministic root on most major distributions, extending the same bug class as Dirty Pipe and Copy Fail. In June, he published ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host escape on KVM/arm64, exploiting a race condition in the virtual interrupt controller. Januscape now adds the x86 side; the same trigger fires on both Intel and AMD, with the PoC carrying a separate code path for each vendor. Google launched kvmCTF in 2024 specifically because KVM underpins both Android and Google Cloud.

A separate KVM x86 shadow paging use-after-free ( CVE-2026-46113 ) involving a related but distinct rmap mismatch was fixed in May 2026. That makes two shadow MMU use-after-frees in the same legacy code path within two months. What to Do The fix is a one-line addition to kvm_mmu_get_child_sp(): the reuse condition now checks role.word alongside the gfn, so a shadow page is only reused when both the frame number and the role match. KVM maintainer Paolo Bonzini wrote the patch .

Fixed stable versions shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260. NVD has not yet assigned a CVSS score; do not wait for one. If you operate an x86 KVM host that accepts multi-tenant guests with nested virtualization, confirm that your kernel includes commit 81ccda30b4e8. Distribution backports may carry the fix under a different version number, so check the package changelog rather than relying on uname -r alone.

If you cannot patch immediately, disabling nested virtualization (kvm_intel.nested=0 or kvm_amd.nested=0) removes the attack path for untrusted guests. ARM64 hosts are not affected by Januscape; ITScape (CVE-2026-46316) is a separate KVM/arm64 issue. The public PoC demonstrates a reliable host panic from a guest with a loadable kernel module and seconds to minutes of racing. Treat exposed x86 KVM hosts with nested virtualization as high-priority patch targets.

Update: Distribution Patch Status
Updated July 6, 2026. The fix reached the mainline stable kernels on July 4 (
7.1.3
,
6.18.38
,
6.12.95
,
6.6.144
,
6.1.177
,
5.15.211
,
5.10.260
). Downstream distributions ship the backport on their own schedules, so confirm status against your vendor’s tracker rather than the upstream version alone. Debian: Fixed in DSA-6381-1 (July 5) for testing/trixie ( linux 6.12.95-1 ) and unstable/sid ( 7.1.3-1 ).
Stable (bookworm) and oldstable (bullseye) were still vulnerable, fixes pending. SUSE / openSUSE: Rated important. Status is Pending across most SUSE Linux Enterprise 15 SP7 and Leap products, with kernel updates in QA rather than released. Apply via zypper patch once published.
AlmaLinux, Rocky Linux, Oracle Linux: These rebuild from RHEL and track its kernel errata; expect their advisories to follow the corresponding Red Hat update. Red Hat; Per-product status and the RHSA, once released, are on the Red Hat CVE page . Ubuntu; Canonical’s per-release status is on the Ubuntu CVE tracker . NVD had not scored the CVE at the time of writing, but SUSE rated it 8.8 (v3.1) / 9.3 (v4.0), a reminder not to wait on an NVD number before patching exposed hosts.

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

Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure

Threat actors have been observed attempting to exploit a recently patched critical security flaw in Gitea Docker images, according to Sysdig . The vulnerability in question is CVE-2026-20896 (CVSS score: 9.8), a vulnerability that stems from the DevOps platform trusting the “X-WEBAUTH-USER” header from any source IP address, effectively allowing an unauthenticated internet client to get elevated access. In a statement shared with The Hacker News via email, security researcher Ali Mustafa (@rz1027), who is credited with discovering and reporting the flaw, said the Gitea Docker images shipped an “app.ini” template that hard-codes “REVERSE_PROXY_TRUSTED_PROXIES = *” by default. The “ app.ini “ file is a core configuration file for managing server parameters, database connections, security behavior, and application settings.

“With reverse-proxy login enabled, that wildcard trusts every source IP, so anyone who could reach the port could send an X-WEBAUTH-USER header and be authenticated as any user, with no password and no token,” Mustafa explained. “With auto-registration on, an admin username gives admin.” It’s worth noting that the documented safe value for the “REVERSE_PROXY_TRUSTED_PROXIES” internal variable is “127.0.0.0/8,::1/128,” meaning only localhost, aka the loopback interface, is allowed as a trusted proxy server. However, the official Docker image doesn’t use this default, hard-coding “*” instead. In other words, the allowlist check is as good as not having it.

Thus, when an admin sets “ENABLE_REVERSE_PROXY_AUTHENTICATION = true” to put Gitea behind an authenticating reverse proxy and leaves the “REVERSE_PROXY_TRUSTED_PROXIES” setting to its default value, it allows a X-WEBAUTH-USER custom HTTP header from any source IP that can reach the container. “Any process that can reach the Gitea container’s HTTP port directly – not through the intended authenticating proxy – can impersonate any user whose login name is known or guessable,” according to Gitea’s advisory. “Admin accounts (admin, gitea_admin, etc.) are the obvious targets.” The vulnerability affects Gitea Docker images versions before and including 1.26.2. It has been addressed in version 1.26.3 released late last month, with the “*” wildcard now removed and reverse-proxy authentication made opt-in.

Cloud security company Sysdig has since revealed it detected the first in-the-wild exploitation attempt 13 days after public disclosure of the vulnerability. There are about 6,200 internet-facing Gitea instances. “So far, the activities have been related to initial investigation by the threat actor,” Michael Clark, senior director of threat research at Sysdig, told The Hacker News. “While we saw the first action from an IP from the ProtonVPN service, 159.26.98[.]241, it has not so far progressed to any exploitation or attack progress.

We think this is because we have seen this one early before it has had the chance to develop beyond that initial phase.” Given the severity of the issue, it’s essential that users apply the fixes as soon as possible for optimal protection. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.