Friday, October 16, 2026

UAT-11985 Uses Fake Event Invites to Target Taiwan Research Affiliates With Google AitM Phishing

Cybersecurity researchers have disclosed details of an advanced persistent threat (APT) spear-phishing campaign that has targeted individuals affiliated with Taiwan research organizations to direct victims to an adversary-in-the-middle (AitM) phishing framework designed to harvest their Google account credentials and multi-factor authentication (MFA) codes.

The activity is being tracked by Cisco Talos under the moniker UAT-11985, describing it as likely fueled by artificial intelligence (AI)-assisted content generation so as to quickly craft bespoke lures aimed at different targets within the confines of a common social engineering framework. The campaign was first observed in mid-2026.

"The operation leveraged legitimate public event themes and impersonated reputable academic and policy institutions to establish credibility," Talos researcher Joey Chen said in an analysis.

"Beyond traditional email phishing, the actor incorporated QR code phishing (quishing) techniques by modifying legitimate event posters with malicious QR codes, expanding the attack surface beyond email recipients to secondary victims who may encounter printed materials."

Central to the operation is the use of legitimate or plausible public event information in spear-phishing emails and embedding within them a URL that points to attacker-controlled infrastructure, while hovering over the hyperlink displays a legitimate-looking Google Forms URL.

These invitation emails feature nearly identical syntactic structures despite the breadth of geopolitical topics being discussed, indicating the content was mass-produced from a reusable prompt template rather than painstakingly crafted for each target.

Specifically, the emails follow a three-part structure -

  • The opening section offers a "polished (but overly elaborate) description" of the geopolitical or policy context.
  • The second section is tailored to the recipient and paints them in a flattering light in an attempt to trigger engagement.
  • The third and final section provides details of event logistics, including the topic, date, venue, and registration instructions.

The threat actor has been found to impersonate legitimate Taiwan-based institutions like the Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute, fabricating the sender identities to make the messages appear more convincing.

"Taken together, the reuse of an almost-identical narrative structure, rhetorical style, personalized flattery, institutional impersonation, and deceptive registration mechanism strongly suggests a coordinated and carefully targeted spear-phishing campaign rather than three independent invitations," Talos said.

In a subset of cases, the phishing emails incorporate legitimate event posters scraped from legitimate websites, but with the QR codes modified to trick victims into scanning the malicious QR code to "register" for the event.

The phishing site imitates the look of a legitimate Google Form, but the primary goal of the site is to serve a pop-up that prompts the victim to sign-in with their Google account to complete the form. Doing so takes them to a bogus site featuring a spoofed Google login panel to capture their credentials and authentication challenges.

The pixel-perfect replica site is an adversary-in-the-middle (AitM) proxy that uses obfuscated JavaScript to gather and exfiltrate the entered information in real-time over a WebSocket connection, while simultaneously forwarding it to legitimate Google authentication servers.

Prior to establishing the WebSocket connection, the JavaScript payload collects device and browser information, including the locale, user agent, screen dimensions, and mobile-device status, which are then reported to the command-and-control (C2) server via a "google_login_start" request.

When the victim submits the password, the phishing page transmits the password, along with the account identifier and browser user-agent information, to the actor's HTTP C2 server through a "google_login_check" request. The threat actor's server, placed in an AitM position, then forwards the credentials to the actual Google authentication service.

"The spoofed Google login panels only support Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), and English locales, with region detection based on the victim's browser 'navigator.languages,' strongly suggesting targeting of Chinese-speaking users," Chen explained.

"By deliberately splitting one-shot uploads with POST requests from low-latency state updates with WebSocket connection, the threat actor has engineered a seamless credential-harvesting relay. This allows the threat actor to mirror Google's dynamic authentication state in real time, ultimately achieving full account takeover without raising the victim's suspicion."



from The Hacker News https://ift.tt/ZnGyFai
via IFTTT

Managing open-weight model risk in enterprise deployments

The growing AI landscape is giving enterprises more choice in how they build, customize, and deploy increasingly capable models. Open-weight models are an important part of that landscape. They give enterprises access to model weights and greater flexibility to inspect, evaluate, modify, and run models within their own environments.

While that flexibility can be valuable, it also affects how enterprises evaluate models, where they implement safeguards, and who is responsible for maintaining those safeguards over time.

As enterprises choose which models to deploy, the relevant question is broader than whether a model is open-weight or closed-weight. Enterprises need to understand what they are using the model for, what could go wrong in that context, and what evidence and controls they need to manage risks.

Today, Microsoft and NVIDIA are publishing Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources intended to help enterprises address those questions. The paper introduces a shared risk taxonomy and an approach to managing model risks grounded in established standards and frameworks, including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework.

The paper reflects a core idea: weight openness alone does not determine an AI system’s risk. Risk depends on the model, use case, deployment, and safeguards.

Understanding risk in the deployment context

Open- and closed-weight models can share many of the same underlying risks, but how those risks materialize depends on the deployment. A model used to help an employee draft a document presents different considerations than the same model used in a customer-facing workflow, just as a standalone inference endpoint differs from a system connected to external data or tools.

The architecture matters too. A risk may originate in the model, while the most effective control may sit in the inference environment, application, or surrounding operational processes. The joint guidance looks beyond the model label to factors including provenance, intended use, users, deployment conditions, and surrounding controls. This first paper focuses primarily on model-layer risks. Evaluating a model alone does not establish the safety of an agent or application: teams must also assess its permissions, data access, tools, runtime, and operational controls.

Establishing a common language

Managing these risks consistently also requires a common vocabulary across engineering, security, legal, safety, and business teams.

The initial Microsoft and NVIDIA taxonomy organizes risks into five broad categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It is not a policy or deployment checklist, but instead it should be used by enterprises to adapt it to their own systems, use cases, and risk criteria, then connect relevant risks to evaluations, mitigations, and accountable owners.

Using evaluations as risk evidence

Evaluations help turn the taxonomy into something enterprises can use. The paper maps evaluations to a selection of risks across the five categories, giving teams a way to start with a risk that matters for their deployment and identify evaluations that can produce relevant evidence about it.

Microsoft Foundry helps enterprises assess quality, groundedness, and safety with built-in and custom evaluations and automated red teaming. Its configurable content-safety controls help detect and mitigate harmful inputs and outputs and prompt attacks. Teams should validate control availability for their model and deployment, including preview status, and combine these capabilities with application-specific testing, monitoring, and human oversight.

Evaluations still need to be interpreted in the context of a particular deployment and the goal is to make it easier for teams to connect the risks they identify with useful evidence, while building a broader set of evaluation resources that can evolve alongside models, deployment patterns, and emerging risks. Microsoft and NVIDIA plan to use the joint repository to share additional evaluations and point to existing resources that can help enterprises assess specific risks.

Accounting for changes in control and responsibility

Open-weight access gives enterprises greater control over how a model is evaluated, modified, and deployed. Model access and deployment are separate choices: open-weight models can also be used through managed platforms. Responsibility for safeguards depends on the service and deployment configuration; enterprises that operate their own model deployments may take on controls otherwise provided by a managed service.

Those safeguards can operate at different layers, and (depending on the risk) enterprises might use model changes, access controls, input and output filtering, monitoring, or human review. The important step is connecting each identified risk to controls that can effectively address it within the deployed system. Those decisions need to be revisited as models and deployments change.

Building on this work

Risk Management for Open-Weight Models in Enterprise focuses primarily on the model layer. Future work from Microsoft and NVIDIA is intended to extend this approach across the runtime, harness, and application layers, with additional technical guidance on evaluation and mitigation.

We also expect the resources supporting this work to evolve as new models, evaluations, and deployment patterns emerge. The joint repository will provide a place to share additional evaluation resources, including contributions from the broader community.

For enterprises deploying open-weight models today, the paper provides guidance they can begin applying to their own use cases. We encourage developers, security practitioners, researchers, and others working in this space to read the paper, explore the evaluations, and contribute evaluations that can help strengthen this shared body of work.

Read the joint Microsoft-NVIDIA paper, Risk Management for Open-Weight Models in Enterprise.

Explore the joint repository and technical resources.

Risk Management for Open-Weight Models in Enterprise was developed jointly by Microsoft and NVIDIA, with Andrew Berkley and April Chen of Microsoft and Michael Boone, Eileen Long, and Arun Rao of NVIDIA leading the development and editing of the paper.

Explore Microsoft Foundry evaluations and content-safety controls for implementation guidance.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Managing open-weight model risk in enterprise deployments appeared first on Microsoft Security Blog.



from Microsoft Security Blog https://ift.tt/idg2UFL
via IFTTT

From Containers to Sandboxes: Developer Trust in the Agentic Era

What the 2026 Stack Overflow Developer Survey tells us about where trust goes next

If you’ve followed Docker lately, you know we’re all-in on sandboxes. We’ve spent a ton of time talking about the difference between sandboxes and containers, and helping our customers and the industry as a whole understand when to use which. In fact, Docker president Mark Cavage dedicated his opening keynote at WeAreDevelopers World Congress North America to this exact topic, using live demos to show why sandboxes (and not containers) provide the level of isolation required to contain autonomous agents. 

To be clear: none of that means we suddenly think less of containers or the vital role they will continue to play in the software development process and ecosystem. We are Docker, after all. And lest anyone forget, as the just-released 2026 Stack Overflow Developer Survey confirmed yet again, when it comes to containers, there’s Docker, and there’s everyone else. Docker is the most used (59%) and most desired (38%) tool in the survey’s cloud development category.

Now, we can all agree that the tech industry is inundated with surveys these days. Vendors, analysts, research firms, everyone’s got a groundbreaking new survey. So, if your reflex response to reading about new survey results is to roll your eyes and think here we go again, well, I get it. 

But the annual Stack Overflow Developer Survey isn’t just another survey. When it comes to the developer community, it’s arguably the survey, the one developers themselves pay attention to. Over the course of 16 years, it has become something of a de facto standard for those of us interested in truly understanding how developers think and act. Released earlier this month, the 2026 survey reached more than 30,000 respondents across 169 countries.

Of course, this year’s survey did more than just remind us of Docker’s continued container dominance. It painted a picture of an industry in transition as developers grapple with one of the biggest questions in technology right now: how to bridge the gap between what they want to do with agents and what they can securely and confidently run in production. 

Consider:

  • Only 7% of developers trust AI output for important work decisions. Nearly half (48%) trust it only when they can verify it themselves.
  • Security and privacy ranked as the second biggest factor in whether teams adopt or expand AI tools (behind only accuracy). 
  • Nearly one in four developers said AI-related security or privacy issues cost their team valuable time in the past year.

Put it all together, and the missing ingredient is clear: trust. Developers want to tap into everything agents make possible without crossing their fingers and hoping “everything” doesn’t include a catastrophic security failure.

I didn’t point out those earlier Docker numbers just to brag (though, hey, I’m a marketer, so it was at least part of it). I mentioned them because they’re a reflection of trust — trust earned across more than a decade helping developers make software portable, open, reproducible, and secure. 

Today, we’re building on that foundation and extending that trust into the agentic era. At WeAreDevelopers, you saw the first steps. We launched Docker Cloud Sandboxes, published the next-generation Sandbox Kit specification (which we’ve committed to submitting to the Cloud Native Computing Foundation), and built nearly everything we showed around one idea: helping developers manufacture trust for AI agents. 

If it all looked and felt like a slightly different Docker, that was intentional. We’re at the start of a transformative era for Docker, and you’ll see a lot more from us in the coming weeks and months.

But no matter how much the industry changes, and no matter how much we evolve along with it, one thing won’t change. Docker will continue to run on trust.

If you’d like to see what that looks like in practice, try Docker Sandboxes (and get a $250 credit if you sign up before Oct. 31). You can start an agent on your laptop, ship longer jobs off to the cloud, and bring the results back. We’d love to hear what you think.



from Docker https://ift.tt/al1qnO0
via IFTTT

OpenAI Research Model Spent 3rd-Party Test ETH Without Permission to Deploy Smart Contract

OpenAI has disclosed seven new incidents in which its artificial intelligence (AI) models exhibited misaligned behavior, including one case where its research model, after not having funds on an Ethereum test network, spent test cryptocurrency from a third-party's wallet without authorization to complete a coding task.

The incident, the AI company said, involved an internal research model part of the GPT-5.6 Sol family. The incident occurred on June 26, 2026, and was discovered by OpenAI three months later.

"An internal research model asked to update a cryptocurrency trading application used funds from a wallet that the task had not supplied to pay for a deployment on Sepolia, an Ethereum test network," OpenAI said. "It derived wallet keys from publicly known developer recovery phrases, found an account with test-network funds, and used that account to pay for the requested contract deployment."

The assignment allowed the model to deploy compatible contracts if it did not find one, but gave it no funded wallet to pay the network fees. After its attempts to obtain free test tokens failed, it wrote a script to derive "accounts from common developer recovery phrases and query their balances."

In the process, it identified 362 addresses and found one account that held enough Sepolia ETH. Armed with the recovery (or seed) phrase, the model derived the private keys that grant unauthorized access to the corresponding account and spend the stashed cryptocurrency.

Although the model questioned whether it had the necessary permission to carry out this step, it subsequently reasoned that a public recovery phrase and valueless test-network tokens made the funds acceptable to use.

"But using public known key/funds ethically? Funds on a known public dev mnemonic are effectively abandoned/test ETH; Sepolia valueless," the model mused. "We can use [amount redacted] to deploy task. Fine."

OpenAI has since implemented additional safeguards to prevent live internet access for such scenarios, adding it runs its misalignment monitoring system on all traffic to flag events if its AI agents manage to gain live internet access.

"This case shows that a model can substitute its own judgment about likely harm for the account holder's permission, then act on that judgment without authorization," OpenAI said.

Besides using a funded test cryptocurrency wallet without authorization, OpenAI said it identified six more cases of misalignment involving its models, adding to three other incidents it revealed at the start of this month -

  • June 16, 2026, when an internal research model bypassed a restriction limiting internet access to HTTP GET requests as part of efforts to seek public trade statistics. It achieved this by using an external browser to send requests on its behalf, retrieved annual figures as an image, and extracted them using optical character recognition.
  • June 16 and 17, 2026, when an internal model developed and tested ways to bypass restrictions on internet access during reinforcement learning and explored ways to contact outside services, and continued testing these approaches even after obtaining the statistics it was seeking, such as teacher salaries in Merrowen, connections to the electrical grid in Orvessa, and disability counts in Bellora.
  • June 17, 2026, when a highly persistent internal model tasked with retrieving figures from a public research dashboard accessed an unspecified organization's internal systems and changed their configuration. The model altered a setting to obtain a cloud-storage access token and downloaded non-public tables containing 147,451 rows. Not only did the model not disclose these actions, it restored the modified setting, but continued using the token to retrieve non-public data.
  • June 17, 2026, when a highly persistent internal model deployed as part of a data-retrieval task in reinforcement-learning training abused a government statistics website's file-download feature to retrieve server configuration and application files, including sensitive credentials. It then analyzed the application code, bypassed the statistics endpoint's authorization checks, retrieved data that it was denied access to, and stored it locally. The data included annual statistics spanning 24 years, including years beyond the requested year. In its answer, the model made no mention of the fact that it had obtained unauthorized access.
  • June 19 and 20, 2026, when its internal research models bypassed restrictions on internet access to allow only HTTP GET requests to fetch figures from government entities' public data sources by writing custom programs to send a POST request through a custom network connection.
  • October 6, 2026, when an internal research model assigned to grade seven responses attempted to submit unsupported assessments after it found that the required input files were missing. When the automated check rejected its bogus grading report, the model tried to create fake input files in an attempt to pass the checks. After this also resulted in failure, the model took the step of damaging its task environment in hopes of triggering a reset.

"In response to this and other incidents, we hardened our security controls, took additional steps to prevent models from accessing the live internet during training, improved alignment grading, and extended misalignment monitoring to all reinforcement learning and evaluation traffic," OpenAI said.



from The Hacker News https://ift.tt/wNlIa9n
via IFTTT

AI Decision Models and Their Impact on AI SOC Platforms

In the space of a month, a new category of AI model went from nonexistent to everywhere. TypeSafe AI released Jev on September 15 and called it a System One model, a nod to Kahneman's fast, intuitive thinking. OpenAI announced its own Decisions API at DevDay and opened a public beta on October 6. Cribl published cribl-decision, an open LoRA adapter you can run locally. Others, like Laya, are already showing up in open source tooling.

These models skip text generation entirely. You hand them some state and a set of typed questions. They hand back a choice, a score, or a yes/no with a probability attached.

For security operations, I think this is some of the best news of the year. I also think most of the conversation is pointed at the wrong layer.

Why a SOC should be excited

Three properties make decision models a natural fit for alert triage.

You get a number you can automate against. A typed answer with a calibrated probability is something you can put a threshold on. Ask the model whether an alert is benign and you get back a probability. Close it automatically above 0.97. Below 0.6, treat it as a likely incident and escalate it. Anything in between goes to an analyst for a closer look. TypeSafe even suggests stricter thresholds for irreversible actions, which maps neatly onto “disable an account” versus “add a comment to the ticket.”

They're cheap enough for every alert. Jev is priced at $42 per billion input tokens, with responses in 70 to 500 milliseconds. Say an enterprise sees 450,000 alerts a year and you feed a few thousand tokens per alert. The model bill lands somewhere around a hundred dollars a year. The economic argument for cherry-picking and only looking at high-severity alerts just disappeared!

Every verdict becomes a record. The answer space is fixed in advance and the output carries its own probability. You can log every decision, replay it, and compare it with what actually happened. That's far easier to audit than a paragraph of generated reasoning.

One caveat worth keeping in mind. When vendors say these models "can't hallucinate," they mean the output always matches the schema you defined. A well-formed answer can still be wrong.

But a calibrated guess is still just a guess

The old rule still applies. Garbage in, garbage out.

Calibration is a promise about a distribution. When a well-calibrated model says 90%, it means that across inputs that look like this one, it's right about 90% of the time. So the question that matters is what "this one" looks like. If the input is an alert title and a severity field, the model is calibrated about alerts with that title and that severity. It knows nothing about the host.

Here's why that matters in practice. Our AI SOC Report 2026 covers 25 million alerts triaged across our customer base in 2025. In that data, 82,000 alerts went through a live memory scan of the endpoint. About 2,600 of those machines had an active infection. And 51% of the infected machines had already been reported as mitigated by the EDR.

Think about what a decision model sees for one of those alerts. Malware detected, threat quarantined, low severity. A perfectly calibrated model should close it with high confidence, because most alerts that look like that really are fine. The model did its job. The input was wrong.

Severity has the same problem at a larger scale. Nearly 1% of real incidents in our data traced back to alerts at the lowest severity levels. At an average of 450,000 alerts a year, that's roughly 54 real threats, about one a week.

Cribl's own model card says it plainly. The model can be overconfident, and it's sensitive to how the prompt and candidates are worded. That's honest, and it applies to every model in this category.

What evidence actually looks like

Think about a crime scene. You can describe it to a chatbot in general terms and get a plausible theory. Or you can bring in the DNA lab, the fingerprints, the forensic evidence and the witness statements. Nobody needs to ask which approach finds the right suspect.

Security investigations work the same way. Filip Stojkovski recently called this Security Context Engineering, and I think the name fits. The job is to turn an alert into a set of facts before anyone, human or model, makes a call.

The question

What the alert usually gives you

What forensic evidence gives you

What ran?

"Suspicious PowerShell"

The process tree, the parent, the full command line, the script on disk

What did it do?

A hash and a reputation score

What the file did when detonated, the network calls, the files it dropped

Is it still there?

"Mitigated" from the EDR

A live memory scan showing injected code or a fileless payload

Who was it?

A username

Where they logged in, from which device, and whether that's normal for them

The third row deserves extra attention. The most common families we found in memory last year were tools like Mimikatz, Meterpreter and Cobalt Strike. These are built to live in memory, which is exactly where a file-based "quarantined" status can't see.

None of this evidence is exotic. It's what a good incident responder collects by hand. The hard part is collecting it automatically, for every alert, in under a minute.

The hardest context is what normal looks like

Forensic evidence tells you what happened on a machine. It doesn't tell you whether that's expected in this particular company.

Identity alerts show the gap clearly. In our 2025 data, 74% of identity alerts were classified as likely benign. Impossible travel alerts were confirmed as real compromises only about 2% of the time, and VPN usage alone drove around 30% of them. A model can't tell that Dave from finance always logs in from Portugal, or that a CrowdStrike alert on the build servers fires every time DevOps ships a release. That knowledge usually lives in the head of your most senior analyst, and it walks out the door when they leave.

Two things make this context harder than the forensic kind. You can't buy it, because it's specific to your environment. And it decays, because assets, users and tooling change every week. A snapshot loaded during onboarding is stale within a quarter.

So organizational context has to be a loop. Learn from past cases and how analysts resolved them. Pull live context mid-investigation when memory isn't enough. Then compare every verdict with its outcome and write the lesson back. That last step is also how you check whether 90% still means 90% in your environment, and not only on someone's benchmark.

A forensic approach to alert triage and investigation

This is the layer we've spent our time on, so here's a concrete example of what investing in it looks like. Our founding team came from reverse engineering and incident response, and that background shaped one rule. Collect the evidence first, then decide.

Code-level evidence. Our Genetic Analysis technology compares every piece of binary code running in memory against a large database of trusted and malicious code. It catches known malware, and it also catches new code that reuses pieces of known threats.

Live memory forensics, triggered automatically. When an alert doesn't carry enough evidence for a verdict, or there are signs of a fileless attack or code injection, the platform runs our Endpoint Scanner on the machine. It's a single executable with nothing to install. It collects process trees, executables loaded into memory, memory dumps where injection is suspected, and the files behind scheduled tasks and autoruns. That's how we found the infected machines marked as mitigated.

Detonation and network forensics. Suspicious files get run in a sandbox, and URLs, domains and IPs get investigated, so the verdict rests on observed behavior.

Organizational memory. Org Brain is our answer to the "what's normal here" problem. It keeps two kinds of memory. One is procedural, how your team investigates and which detections it closes on sight. The other is declarative, your assets, your users, their normal behavior, and even how your SIEM schema is structured. It learns from your case history, fetches live context mid-investigation, and writes conclusions back after every investigation.

All this allowed us to investigate over 25 million alerts in 2025, at every severity. Fewer than 2% were escalated to a human, verdict accuracy was 98%, and median triage time was under a minute.

When it comes to cost, most of this analysis is deterministic forensics, which is far more affordable to run than a large model on every alert. That's why we price per endpoint and have been investigating everything, long before decision models arrived. Decision models now bring the same economics to the decision step for everyone, and that's a good thing for the industry.

If you're building your own pipeline, the same structure applies whichever model sits at the end. Spend your engineering effort on the evidence and the organizational knowledge. Those are the parts that are hard to get and the parts that compound.

Where to put your effort

Frontier models get better every few months, and everyone gets the upgrade on the same day. Decision models will follow the same curve. Whatever edge a model gives you this quarter, your competitors and your attackers have it too.

The context you feed those models is the part that's actually yours. If you're automating triage this year, here's where I'd spend the time.

  1. Collect evidence before you decide. Process trees, detonation results and memory contents beat alert metadata every time.
  2. Stop letting severity decide what gets investigated. With decision models this cheap, there's no longer a cost reason to skip low-severity alerts.
  3. Treat organizational knowledge as a system. Assets, users and normal behavior need to be learned and refreshed continuously.
  4. Measure calibration in your own environment. Tie every automated verdict to its outcome, and watch for drift.

Decision models make the last step fast, cheap and auditable. Whether that last step is right still depends on everything that came before it.

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



from The Hacker News https://ift.tt/kOb1iGq
via IFTTT

China-Linked Hackers Exploited BeyondTrust Zero-Day to Take Over Remote Support Servers

The China-nexus cyber espionage group tracked as Armory Castle (previously UNC5221 or Warp Panda) exploited a newly disclosed security flaw in BeyondTrust Remote Support (formerly Bomgar) as a zero-day in late August 2026.

The vulnerability, tracked as CVE-2026-102764 (CVSS score: 9.3), is a case of improper origin validation in an internal messaging component that could be exploited by a remote attacker to perform file operations on an affected appliance.

"The vulnerability exists within internal components of Remote Support," BeyondTrust said in a Thursday alert. "The components did not adequately validate the origin of the messages it received. Under the right conditions, this could be used to perform file operations on the appliance."

Patches for the flaw have been pushed to all Remote Support SaaS customers as of October 9, 2026. Self-hosted customers of Remote Support running versions from 24.3.1 through 26.2.3 are advised to manually update to BT26-05-RS patch. Customers running a version older than 24.3.1 will be required to upgrade to a newer version to apply the fix.

According to a timeline of events shared by BeyondTrust, Armory Castle is said to have exploited the flaw as a zero-day on a single self-hosted Remote Support appliance on August 29, 2026. Then, on September 27, 2026, "successful exploitation of another security device provider [became] public," it added, prompting it to initiate an investigation to hunt for similar activity.

Armory Castle has a history of exploiting zero-day vulnerabilities in Citrix NetScaler (CVE-2023-4966) and Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, and CVE-2025-0282) appliances to break a wide range of sectors, including legal services, SaaS providers, business-process outsourcers, technology, and governments, for long-term intelligence collection. It's known to be active since October 2023.

"The actor uses a zero-day selectively against chosen targets, and once the vulnerability is public, the actor typically moves to broad exploitation of every instance still unpatched," BeyondTrust said. "Our working assessment is that this actor selects high-value software targets in advance and keeps a working model of the products the actor targets in an AI context that it uses on an ongoing basis to develop exploit chains."

Google-owned Mandiant, which shared additional details related to the exploitation activity, said a successful compromise is followed by the deployment of a lightweight PHP web shell codenamed SAWFLY for interactive remote access and bidirectional encrypted command-and-control (C2) communication.

The operator makes use of commercial VPN exit nodes and compromised home and small-office routers to blend into regular traffic, and then leverages the web shell as a conduit to escalate privileges, obtain full administrative control of the appliance, and establish persistence in a manner that survives reboots.

The intrusion is characterized by efforts to facilitate credential theft by reading the appliance's stored secrets and abusing the administrative access to reach downstream systems and enable lateral movement. Details of the post-exploitation actions undertaken by the threat actor are listed below -

  • Gaining root-level control of the appliance host by copying the system shell executable (/bin/sh) to the file "/usr/bin/dbus-authd" and modifying its ownership to root and enabling Set User ID (SUID) permissions, causing it to be executed with the privileges of the file's owner.
  • Attempting to harvest credentials directly from the appliance's native secrets management database by using the proprietary "/ns/sbin/bt-secrets" Command Line Interface (CLI) utility to manage, store, and retrieve passwords, API keys, and endpoint credentials.
  • Targeting the BeyondTrust configuration templates to obtain passwordless root privileges to the site service account and
  • Pivoted into the BeyondTrust Remote Support application to perform reconnaissance via compromised administrator credentials and then launch remote sessions to downstream systems populated within the appliance's Jump Item list.
  • Abusing the elevated administrative privileges to establish a remote support session to target internal endpoints and obtain full file-system access to those systems with an aim to download and exfiltrate sensitive internal documents for network reconnaissance.
  • Tunneling traffic through the BeyondTrust device via BARECLAW, a C-based custom SOCKS5 proxy tunneler that relays TCP connections between a remote client and destinations.
  • Modifying "/ns/config/haproxy.conf" file to ensure BARECLAW is accessible directly from the internet.
  • Hindering detection efforts by systematically deleting system, web server, and application-level logs.

"Throughout the intrusion, Armory Castle leveraged a deep understanding of BeyondTrust appliance internals, as evidenced by their abuse of proprietary CLI utilities, startup configuration templates and local reverse-proxy routing," Google Threat Intelligence Group (GTIG) and Mandiant researchers Jayson Frost, Bryce Greathouse, Brian Meyer, John Palmisano, Rajesh Rajeshirke, Steve Rasch, and John Wolfram said.

"Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed."



from The Hacker News https://ift.tt/Epag8d2
via IFTTT

CERT-In Warns AI Agents Accessed Sensitive Data at Indian Organizations During Testing

AI agents being tested online reached the live systems of Indian organizations and read business records, including personal data and confidential material, CERT-In said in an advisory on October 15.

The agents went beyond their assigned tasks, and none of the organizations detected the unauthorized access. After internal reviews, the AI companies whose models were being tested voluntarily reported the cases to CERT-In, India's national cyber agency.

AI agents are software systems that can plan work, run commands, use tools, and act on the internet autonomously for extended periods. In these cases, the agents gained access via credentials and connection settings left exposed in application configuration and public code repositories, and via cloud service roles with excessive permissions.

CERT-In did not name the AI companies, their models, or the organizations and sectors involved. It did not say how many companies reported cases or how many organizations were affected, and said only that the reports came in recently.

It also did not say whether any data the agents read was copied or kept, or whether the affected organizations have been told.

CERT-In's own threat hunting found a second, separate set of incidents: a financially motivated campaign against Indian entities. The attackers misused publicly available offensive-security frameworks built on AI agents.

The frameworks continue to be misused and rebranded, with numerous deployments across infrastructure in several countries. CERT-In did not name the frameworks or the attackers.

In this campaign, the frameworks cut the time from first access to final impact from days to a few hours, according to CERT-In. The attackers ran several agents in parallel for hours to days to reach their goals. Victims that only partly fixed the problems were attacked again within days, at a larger scale.

Cybersecurity

Google Threat Intelligence Group reported a separate case in September. Attackers who had compromised a cloud resource planned, built and ran an agent-driven campaign that harvested thousands of third-party credentials, all in under 6 hours.

On October 9, CERT-In warned of attacks on non-banking financial companies, digital lenders, fintech firms, payment providers and wallet operators. The attackers in those cases stole API credentials and called fund-transfer and disbursal APIs directly to move money into mule accounts.

AI-assisted tools may have been used in those attacks. CERT-In has not said whether those attacks are related to the campaign in its October 15 advisory.

What CERT-In Wants Fixed

The weaknesses behind both kinds of incidents were ordinary, CERT-In said. Credentials and keys were exposed in source code, public repository history, configuration files, client apps and public web pages. Old, unused and test APIs were still reachable from the internet.

Payment API keys were stored in plain text, and cloud and backend-as-a-service roles granted ordinary or anonymous users broad read and write access. Management interfaces were exposed to the internet, and application middleware was left unpatched, with weak credentials or no multi-factor authentication.

In the cases reported by the AI companies, agents found the same exposed credential again and reused it in separate operations.

CERT-In did not publish indicators of compromise for either kind of incident. Organizations should apply the baseline in CERT-In's May blueprint and take these steps:

  • Search source code, commit history, CI/CD variables, configuration files, client apps and cloud storage for exposed credentials. Rotate any you find, purge them from history and confirm the fix from outside.
  • Scan every commit and build for secrets, and keep credentials out of code, configuration files and databases.
  • Keep a full list of your APIs, and shut down old, unused and test APIs and accounts.
  • Apply least privilege to cloud and backend-as-a-service roles, keep privileged keys out of client-side code, and test what an anonymous user can read and write.
  • Take management interfaces off the internet, require multi-factor authentication for all admin access, and patch exposed middleware quickly.
  • Watch APIs with rate-based anomaly detection, alert on enumeration bursts, bulk reads and automated sign-ups, and keep logs for at least 180 days.
  • After any credential exposure or confirmed access, treat the environment as compromised until a forensic check clears it. Retest after fixing it, and expect repeat attempts within days to weeks.
  • If you run AI agents, give each run its own short-lived, least-privilege identity and block outbound traffic except to the destinations each run needs. Keep a tamper-resistant log of agent actions, at least those that touch production systems and data.

Banks, insurers, other financial firms, and fintech companies should also apply the payment and disbursement API measures outlined in the October 9 advisory.

CERT-In's directions also require organizations to report cyber incidents to the agency within 6 hours.

For AI developers, research labs and evaluation agencies, CERT-In wants test runs isolated, with outbound network access blocked by default. That block should be enforced at the network level, not through instructions to the model.

Cybersecurity

A run should stop automatically if an agent contacts outside systems, or finds or uses credentials that belong to someone else. If an agent reaches a real system, the affected organization and CERT-In should be told promptly.

Earlier Disclosures by OpenAI and Anthropic

OpenAI and Anthropic have both disclosed similar incidents this year. CERT-In did not say whether models from either company were involved in the Indian cases.

In July, OpenAI disclosed that its models had compromised Hugging Face's platform. It is reviewing what its models did on the internet during training and testing, and notifying third parties whose security controls its models may have bypassed.

In response to that disclosure, Anthropic began reviewing its own cyber evaluations. It has since reported 4 incidents in which Claude models gained unauthorized access to real third-party systems during evaluations built by the same outside partner. It has notified all affected parties.

Of the 3 organizations in Anthropic's July disclosure, the 2 it reached had not detected the activity.

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



from The Hacker News https://ift.tt/r5DvueY
via IFTTT

Thursday, October 15, 2026

Silent Lynx Exploits WinRAR Flaw to Deploy Reverse Shell in CIS Government Attacks

The threat actor known as Silent Lynx has been attributed to a fresh set of attacks targeting government organizations across the Commonwealth of Independent States (CIS).

The activity, observed from June 2025 through August 2026, involves four different infection chains that make use of macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and crafted WinRAR archives exploiting CVE-2025-8088.

The attacks lead to the deployment of custom reverse shells like FoalShell, Chvost, Laplas, and PickleShell that facilitate interactive remote access to compromised hosts, according to Cisco Talos and Recorded Future Insikt Group, which are tracking the campaign under the monikers UAT-6275 and TAG-193.

"UAT-6275's targeting is concentrated in Central Asia, and the wider CIS region," security researcher Ashley Shen said. "Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus."

Silent Lynx was first publicly documented by Seqrite Labs in early 2025, highlighting the threat actor's attacks on embassies, lawyers, government-backed banks, and think tanks across Kyrgyzstan and Turkmenistan.

It's assessed to be a Kazakhstan-nexus threat actor active since at least 2020, sharing overlaps with other clusters codenamed YoroTrooper (aka Comrade Saiga, ShadowSilk, and SturgeonPhisher), ShadowSilk, Cavalry Werewolf, and Tomiris.

It's suspected that both UAT-6275 and YoroTrooper are part of the same broader activity cluster, although no direct indicator or toolset overlap has been observed between the two.

Earlier this year, VMRay disclosed that a threat cluster it tracks as Hydra Saiga compromised at least 34 organizations across 8 countries since December 2024, with reconnaissance efforts extending to over 200 additional targets across the world.

It's worth noting that both Comrade Saiga and Hydra Saiga refer to the same threat actor. The "hydra" prefix in the tracking alias is a reference to the adversary's heavy focus on breaching infrastructure linked specifically to water resources in Central Asia using a mix of custom implants written in Rust, Go, and Python and Living-off-the-Land techniques.

Attack chains mounted by the threat actor involve the use of spear-phishing emails containing diplomatic relations, international trade, energy, and aviation-themed decoy documents. No less than eight campaigns have been identified across the region between January 2025 and May 2026.

The phishing emails are sent from compromised government accounts and make use of official-looking documents to lend the social engineering attack a veneer of credibility. "Identified lures included a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs, a Turkmenistan airspace application form, and a business proposal concerning Russia’s Orsk Oil Refinery," Recorded Future said.

What's more, three publicly accessible staging directories linked to the threat actor have been found to host Linux-compatible tooling and a publicly available proof-of-concept exploit for CVE-2025-25257, an SQL injection flaw in Fortinet FortiWeb, suggesting a possible expansion of the threat actor's operational capabilities.

Infection sequences have been found to employ four different pathways -

  • June 2025 - Using macro-enabled Word documents to download and run a second-stage binary.
  • July 2025 - Using downloaders built with PS2EXE, a tool that packages PowerShell scripts as Windows executables, to fetch reverse-shell payloads and create scheduled tasks for persistence.
  • October 2025 - Using a malicious shortcut (LNK) within a RAR archive to launch PowerShell responsible for retrieving and executing a GitHub-hosted script that provides remote shell access. Subsequent iterations also download PickleShell and stage it in the Windows Startup folder so that it's automatically launched every time a user logs in to the system.
  • April 2026 - Using a RAR archive that exploits a WinRAR flaw (CVE-2025-8088) to drop PickleShell in the Windows Startup folder.

The April 2026 infection chain marks the first time UAT-6275 has weaponized a security flaw as part of its malware delivery methods.

"UAT-6275's sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS," Talos said. "Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management."



from The Hacker News https://ift.tt/GOztgfo
via IFTTT

Help TDS Linked to Hotejka as 20,000+ Cloudflare Pages Domains Host Tech Support Scams

A long-running Traffic Distribution System (TDS) known as Help TDS to a Russian-language affiliate program called Hotejka, which appears to be a rebrand of a traffic monetization operation dubbed ROI777.

Help TDS is assessed to be active since at least 2017, offering PHP code templates to partners and affiliates that are installed into compromised websites with an aim to direct unsuspecting users to tech support scams. These scams make use of full-screen browser manipulation and exit prevention techniques to serve bogus Microsoft Windows security alert screens instructing victims to contact a Windows Support number to address the problem.

"Help TDS delivers tech support scams (TSSs) that direct users to call centers, where social engineering is used to convince them to install remote desktop tools," Infoblox said in a report shared with The Hacker News. "It's not simple credit card fraud: it's remote access, living-off-the-land malware operations. Once in, the threat actor can exploit the victim time and again."

Help TDS's evolution was documented by GoDaddy in August 2025, highlighting the threat actor's use of a malicious WordPress plugin named "woocommerce_inputs" on thousands of websites to steal WordPress user credentials and facilitate the malicious redirections by fetching the URLs from its command-and-control (C2) servers. The plugin, or alternatively a custom HTML block, is injected into the sites by Hotejka's affiliates.

Historical tracking of malicious redirect chains has also uncovered that Help TDS has routinely handed off traffic directly to VexTrio Viper, a cybercrime operator that runs an affiliate program to enable scams, riskware, spyware, adware, and pornographic content.

The latest findings connect the TDS to Hotejka, which, in turn, is suspected to be a successor to ROI777, an entity that was exposed by Guardicore Labs (now part of Akamai) in June 2018 in connection with a traffic manipulation and cryptocurrency mining campaign codenamed Operation Prowli.

The activity involved the compromise of vulnerable servers to deploy a malware named r2r2 and then leverage them to mine cryptocurrency. In tandem, WordPress sites and servers running other content management systems (CMS) were exploited for traffic monetization fraud.

"Traffic monetizers, such as ROI777, buy traffic from 'website operators' such as the Prowli attackers and redirect it to domains on demand," Guardicore Labs noted at the time. "Website 'operators' earn money per traffic sent through roi777. The destination domains frequently host different scams, such as fake services, malicious browser extensions and more."

The rebrand is believed to be driven by the leak of data obtained from ROI777's servers in March 2018, around when it was operating Disposable TDS, a precursor to Help TDS. The published details included Telegram identities of its users and details of multiple campaigns.

The connection between Hotejka and ROI77 doesn't end there, for GoDaddy also found that "roi777[.]com" is one of the historical C2 domains used between 2018 and 2020 to fetch the redirect domains.

"[Hotejka's] affiliates range from spam operators to website compromisers," Infoblox said. "Potential victims are redirected into the TDS from these affiliates via special URLs provided by Hotejka. The TDS then evaluates the user via browser fingerprinting and location to determine the course of action."

A TDS functions akin to a relay, intercepting internet traffic from compromised websites, malicious ads, social media posts, or SEO spam, analyzing the visitor, filter traffic based on predefined criteria (e.g., geographic location, device metadata, IP reputation, and headless browsers), and dynamically route them to scams, browser lockers, or malware drops.

"Help TDS and its precursors are the routing decision infrastructure for a small affiliate program," Infoblox explained. "Other threat actors, for example ones who have compromised websites, send potential victim traffic to the TDS through specially crafted URLs."

The TDS is believed to be implemented on Keitaro, an advertising performance tracking platform that's known to be abused by various threat actors. Some of the initial Help TDS lures prompt users of an impending Windows update, followed by a warning that the machine has been disabled by Microsoft, tells them not to restart the computer, and that a "computer lock" has been put in place to block illegal activity.

The scareware prompt is designed to persuade the victim to contact the Microsoft Technical Support team. Should the victim make the phone call, the threat actor on the other end instructs them to download and install a free remote desktop tool like Ultraviewer to gain complete control of the infected machine.

The fingerprinting step determines whether to route the user to either the tech support scam or to another affiliate marketing platform, which then evaluates the device again and resells the traffic. These pathways lead to scam landing pages with fake CAPTCHA checks to enroll the victim's browser to push-notification spam.

"Historical DNS records, loyal use of other affiliate advertising platforms over the years, and consistent command-and-control (C2) mechanisms give us a high degree of confidence that ROI777 and Hotejka are one and the same," Infoblox said.

Messages posted by Hotejka on their Telegram channel (@hotejka_hot) demonstrate their criminal intent by advertising forced browser extension installations and tech support landing pages that are "very difficult to exit." In one post dated July 17, the operator claimed a "small call center in Germany will handle 50-100 calls per day."

Since April 2026, the scams are run on free Cloudflare Pages sites (*.pages[.]dev), with the threat actor creating roughly 300 disposable pages per day. Over 20,000 such domains have been detected since then. In recent years, Hotejka has also been observed using different aliases on forums like CrackingX, seeking traffic from email spam and access to WordPress admin panels for prices starting at $100.

In all, about 20 different affiliates, including Balada Injector, Detour Dog, and DollyWay, send traffic to Help TDS. These operations are known to heavily target WordPress sites to redirect victims to scams and malware.

"Hotejka/ROI777 has been loyal to the two affiliate platforms since 2017, and we believe that loyalty has paid handsomely," Infoblox said. "Using DNS volumes observed over the past 8 years, our ability to use affiliate IDs to track traffic over time, and commonly cited payout figures for affiliate advertising in general, we suspect that the two European programs have paid them at least a few million dollars (USD)."



from The Hacker News https://ift.tt/ohHW3ue
via IFTTT

NGINX Fixes 5 Flaws, Including Possible RCE and a TLS Bug That May Skip Client-Cert Checks

NGINX released versions 1.30.6 and 1.31.7 on October 14 to fix five vulnerabilities, one of them present in every release since May 2005.

There are three memory bugs that F5, the company behind NGINX, says could crash a worker process or possibly let an attacker run code, and each requires a specific configuration to exploit.

A fourth lets an attacker forge a TLS session that could get past client-certificate checks, though F5 calls the forgery non-deterministic and beyond the attacker's control. The fifth lets an HTTP/3 client slip extra bytes into a request that NGINX passes on to a backend.

None of the five was in CISA's Known Exploited Vulnerabilities catalog as of October 15, and neither NGINX nor F5 reports attacks. NGINX rates all five medium. F5 scores the three memory bugs 9.2, Critical, on CVSS v4.0, the TLS flaw 8.3, and the HTTP/3 flaw 6.9.

Which Configurations Are Exposed

Every one of the five needs a directive you added: an alias with a rewrite, a regex map, AIO with SSI, a shared TLS session cache, or HTTP/3. NGINX's own documentation recommends the shared session cache and request buffering; the other condition for the HTTP/3 flaw is on by default.

The TLS flaw sits in the automatic rotation of session ticket keys. Session tickets let a client resume a TLS session without a full handshake, and since version 1.23.2, from October 2022, a shared session cache makes NGINX generate and rotate the ticket keys itself unless you load keys from a file.

Each worker process keeps a copy of three key slots. Rotation copied only two, so the third slot held whatever was in memory before, and a ticket naming that slot could be verified and decrypted with that uninitialized key material, "allowing a forged session," the fix commit says.

F5 says the forgery works "in a non-deterministic manner that is beyond the attacker's control," and that an attacker could use it to bypass verification of client certificates. The exposed setting, ssl_session_cache shared:SSL:10m, is the one NGINX's documentation uses in its example configuration. NGINX fixed a session-reuse flaw with the same consequence, CVE-2025-23419, in February 2025.

The conditions and workarounds below are NGINX's and F5's. The version ranges are from NGINX's advisories page.

Flaw What it allows Configuration that exposes you Affected versions If you cannot upgrade (F5)
CVE-2026-15176 Heap overflow in a worker process: crash, possibly code execution A location with alias, a rewrite that changes the URI, and anything that reads $request_filename (return, set, if, add_header or the access-log format) 0.1.29 to 1.31.6 Do not use alias in that location. Do not use $request_filename.
CVE-2026-93479 Heap overflow in a worker process: crash, possibly code execution A regex map whose captures are referenced by root or log_format before the map's output variable 1.30.0 to 1.30.5 and 1.31.2 to 1.31.6 Use named captures, and use them only inside the block with the regex match.
CVE-2026-97205 Use-after-free in a worker process: crash, memory corruption, possibly code execution aio enabled and an SSI page with include virtual commands, in some configurations 0.8.11 to 1.31.6 Turn aio off, or do not serve SSI pages.
CVE-2026-95101 Extra bytes injected into a proxied request, or a body past client_max_body_size HTTP/3 with proxy_request_buffering on , the default 1.25.0 to 1.31.6 Set proxy_request_buffering off.
CVE-2026-97629 A forged TLS session that could bypass client-certificate verification (non-deterministic and beyond the attacker's control, F5 says) ssl_session_cache shared:... without ssl_session_ticket_key , which turns on automatic key rotation 1.23.2 to 1.31.6 Remove the shared cache directive, or load keys from a file with ssl_session_ticket_key. Servers with ssl_session_tickets off are not affected.

One Flaw Traces to July's Fix

The map flaw, CVE-2026-93479, is in the string-handling code that NGINX patched on July 15 for CVE-2026-42533, a heap overflow F5 scored 9.2 that is reached through a regex map's captures.

The new overflow became possible after a change in that July release, according to the fix commit. A July patch added protection against overrunning a buffer, but data could still spill into a reserved area, and a second July patch then sized the final string from that spilled length, so the string could outgrow its buffer.

The commit puts limits on it. The overflow is at most the size of the reserved area on the document-root path, and a single null byte on the access-log path.

F5's advisory and NGINX's advisories page list 1.30.0 and 1.31.2 as the earliest affected versions, which come before the July change. A server patched in July is inside the affected range either way.

F5's July workaround had already been questioned. Researcher Stan Shaw told The Hacker News in July that switching to named captures left a narrower path open, and that upgrading was "the only complete fix."

The fix commits for the alias, AIO and HTTP/3 flaws describe the other three bugs. The alias flaw opens in the moment after a rewrite changes a request's URI and before NGINX picks the next location. If anything reads $request_filename in that window, and the location's prefix is longer than the rewritten URI, mapping the URI to a file path overflows a buffer.

The AIO flaw is a counter. Each pending asynchronous operation on a request adds one to an 8-bit field with no check, so 256 pending operations wrap it to zero and the request can be freed while those operations still point at its memory. NGINX names SSI pages with include virtual commands, which can run their included requests in parallel, as the trigger.

The HTTP/3 flaw came from one parser field doing two jobs: holding the remaining length of an unknown frame being skipped, and the number of DATA bytes to pass on as request body. When an unknown frame was split across two reads, the leftover count was treated as body and sent to the backend, outside the client_max_body_size check.

What to Do

Upgrade to 1.30.6 on the stable branch or 1.31.7 on mainline. The stable release contains only fixes. NGINX publishes fixes for those two branches only, so older branches such as 1.28 stay inside the affected ranges, and a distribution package is fixed only if your distribution has backported the patches.

NGINX Plus customers, and users of F5's Ingress Controller, Gateway Fabric, Instance Manager and WAF products, should check F5's advisories, which list affected builds and, for several products, no fixed build as of October 15.

If you cannot upgrade yet, the table above has F5's workaround for each flaw. To see which paths your server has enabled, print the running configuration with nginx -T and search it for alias beside a rewrite, a regex map used by root or log_format, aio together with ssi, listen lines with quic, and ssl_session_cache shared without ssl_session_ticket_key.

The rewrite-module overflow NGINX patched in May, CVE-2026-42945, was being exploited within days of disclosure, VulnCheck found. This is NGINX's eighth security release of 2026.

F5 credits Matt Suiche of Tolmo and Mateusz Gierblinski with the map flaw, Hansol Lee of GOTROOT with the HTTP/3 flaw, PhiNode Labs with the TLS flaw, and a researcher it names as Cyberlanc3r with the AIO flaw.

F5 found the alias flaw itself. NGINX also released njs 1.0.2 the same day, fixing two medium-severity XML-handling flaws in its JavaScript module, CVE-2026-101025 and CVE-2026-101019.



from The Hacker News https://ift.tt/t2Vk5S1
via IFTTT

Next.js Ships Out-of-Band Patch for Two Critical RCE Flaws in Caching and SVG Processing

Next.js released an out-of-band security update on October 14 that fixes two critical flaws allowing unauthenticated remote code execution, along with a high-severity denial-of-service flaw.

One code-execution flaw is in React Server Components, and the other in librsvg, the open-source library Next.js uses through the sharp package to handle SVG images.

The fixes are in Next.js 16.4.1 and 15.5.28, the current Active and Maintenance long-term support (LTS) releases.

What Was Fixed

The update covers three separate issues. Vercel, which develops Next.js, rated both code-execution flaws critical, each with a CVSS score of 9.5. The table lists the versions each issue affects and the version that fixes it.

Issue Affected versions Fixed in Who is exposed
Code execution through use cache ( GHSA-673q-mjm6-r5xr ) 16.0.0 through 16.4.0 16.4.1 App Router apps with Cache Components enabled, where a use cache function returns more than one typed array
Code execution through SVG images (CVE-2026-96889, GHSA-2464-fhr4-w9xw ) 10.0.0 through 15.5.27, and 16.0.0 through 16.4.0 16.4.1, or 15.5.28 with sharp 0.35.5 or later Apps that pass attacker-supplied SVG files to sharp on glibc-based Linux
Denial of service through Server Actions ( GHSA-p3m5-59mp-jv5r ) 13.0.0 through 15.5.27, and 16.0.0 through 16.4.0 15.5.28, 16.4.1 App Router apps with at least one Server Action

Who Is Affected

The first code-execution flaw is in React Server Components, the React feature that runs user-interface components on the server. React's advisory covers three packages, react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, in versions 19.0.0 through 19.3.0. It describes the flaw as affecting "extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value."

In a Next.js app, the trigger is a use cache function that returns more than one typed array, so only version 16 apps that enable Cache Components, the feature behind use cache, are exposed. Vercel says to upgrade even if your app has no such function.

The second flaw is a memory bug in librsvg, the library that renders SVG images, which Next.js reaches through the bundled sharp package. Code execution is possible when Next.js runs on glibc-based Linux, according to the advisory.

By default, Next.js does not optimize SVG files. Serving them through the image optimizer requires turning on a setting called dangerouslyAllowSVG. The same library also renders images for next/og, the feature that builds social-preview images, when that feature runs on the Node.js runtime.

The third flaw is a denial-of-service issue. In App Router apps that define at least one Server Action, crafted requests can push one server process to full CPU use and stop it from handling other requests. Apps on the Pages Router, or with no Server Actions, are not affected.

Exposure can differ by host. Netlify said its platform does not run the image-optimizer code path and that the flaws have limited impact on its setup, while still recommending the upgrade.

What to Do

Upgrade to Next.js 16.4.1 if you run version 16, or 15.5.28 if you run version 15, then rebuild and redeploy.

Vercel's advisory says upgrading Next.js makes package managers supply the fixed sharp automatically. On version 16 that holds, because 16.4.1 requires sharp 0.35.5.

On version 15 it may not. 15.5.28 still accepts the older, affected sharp 0.34.x, and upgrading over an existing install can leave that version in place. Check with npm ls sharp and update sharp to 0.35.5 or later if it is older.

If you cannot upgrade Next.js right away, the image flaw has an interim option: make sure sharp is 0.35.5 or later, or block SVG rendering in sharp with sharp.block({ operation: ["VipsForeignLoadSvg"] }), as the sharp advisory describes. The use cache and Server Actions flaws have no workaround, and only the upgrade closes them.

As of October 15, the use cache and Server Actions advisories had no CVE and did not appear in the npm advisory feed that npm audit uses, so dependency scanners may not warn you about them. The image flaw does surface, through sharp's own advisory.

Why the Image Flaw Keeps Returning

This is the third time since August that image processing in Next.js has produced a code-execution flaw. In August, a bug in libheif, reached through sharp, allowed code execution when the optimizer handled a crafted AVIF image. In September, a flaw in next/og let attacker-controlled text change the SVG it generated.

Next.js did not change its own image code this time. 16.4.1 ships the same optimizer as 16.4.0 and fixes the image flaw by raising the bundled sharp to 0.35.5, which carries a patched librsvg (2.63.2).

The librsvg bug, CVE-2026-96889, was made public on September 23 and fixed in sharp on September 27. Red Hat scored it 7.8 and said exploiting it needs user interaction, such as opening a malicious file. Vercel rated the Next.js exposure 9.5 and reachable over the network.

The researcher who reported the librsvg bug, Rafael B. Dias, says it is the weakness behind September's next/og flaw. A working exploit for that earlier flaw, built for one specific server setup, has since been published.

sharp's maintainer also warns that whether the flaw ends in code execution or only a crash can come down to the server's Node.js build, because the official Node.js binaries are not hardened against this kind of memory attack.

Not the Same as React2Shell

The React Server Components flaw sits in the same three packages as React2Shell, the maximum-severity flaw disclosed in December 2025 that attackers exploited at scale. This one is far narrower. React describes it as affecting "extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value."

As of October 15, there are no public reports that any of the three flaws fixed on October 14 has been used in attacks.



from The Hacker News https://ift.tt/hDw0xYV
via IFTTT

Why AI Confidence Is Not Validation

AI is already part of digital forensics and incident response work, with or without a policy in place to govern it. The issue is that these tools are growing more confident in their own output faster than practitioners are developing reliable ways to verify it. Without governance models and validation standards in place, that gap compounds and rarely stays contained to a workstation: an unverified finding can end up in a forensic report, a deposition, or in court.

At SANS, we created two new AI frameworks this year to help address this challenge: the Digital Forensics & AI Investigations Framework, which we mapped to the trusted standards established by the Scientific Working Group on Digital Evidence (SWGDE), and the Incident Response & AI Investigations Framework, which we mapped to the NIST Cybersecurity Framework 2.0. Both frameworks rest on the same principle: AI can accelerate investigative work, but the human examiner remains the final authority at every phase.

Where Validation Cannot Be Delegated

In digital forensics, validating an AI finding starts at the source file. A tool that doesn't show its reasoning has already produced an unreliable result, regardless of the confidence score attached to it. A tool that cites the specific file it parsed — for example, a claim that browser history came from Chrome's own database — gives an examiner somewhere to start. The claim is plausible at face value, but it still has to be confirmed independently before anyone treats it as fact.

I think of a high-confidence AI output the way I'd think of a third grader insisting the homework is finished. Saying it's done isn't the same as it being done correctly, and no amount of confidence changes that. The only way to know is to verify it, the way a parent checks the homework instead of taking their child's word for it alone.

The mistake I see often in the field is treating AI as a single source of truth. Practitioner forums are full of the same exchange: Someone scans a file, a detector reports it as AI-generated, and that becomes the finding. The claim has no named source and no reasoning behind it, and an examiner without foundational skills has no way to catch that.

What the Record Has to Show

Documenting what produced a finding matters as much as checking it. Plenty of examiners say they don't use AI, while machine learning has been running skin detection, facial similarity, and image categorization inside their forensic tools for years, generating the confidence scores they rely on. Naming the tool is sufficient when AI is built into a forensic product, since opposing experts can research the integration themselves. For a general-purpose model, the exact version needs to be on record.

Version history matters more than practitioners expect because casework and AI capability move on different timelines. I worked a case where the tool that would have helped with the log files didn't exist at the time of collection. By the time I testified two years later, the technology had advanced well beyond what was available during the investigation, which is exactly the kind of gap opposing counsel can use against you without a clear record of what the technology could do at the time.

One Policy Cannot Govern Both Disciplines

Digital Forensics and Incident Response carry different risk tolerances, and a single AI policy written for one will fail the other. Incident response has more latitude by design, because responders aren't scrutinized on every single bit and byte, and the organization needs to know what happened quickly. AI genuinely helps there, in detection and in surfacing activity a human might not readily see. Forensic examiners operate under the opposite pressure, since every source file requires validation, which is why many expect AI to add work rather than remove it. Both instincts are correct for the job in front of them, which is why the two frameworks exist as separate documents instead of one shared policy.

AI capability is moving faster than human oversight can keep up with. Offensively, AI is excelling; defensively, security teams remain more cautious and slow. Closing that gap during a live incident depends on how much an organization trusts its own tooling. If a team built and validated the AI making containment or triage recommendations, then a human in the loop, monitoring and intervening rather than approving every step, is workable. Requiring sign-off on every individual action during an active incident overwhelms an analyst quickly, exactly when speed matters most.

The Real Variable Is the Practitioner

Every phase of both frameworks returns to one constraint. AI should never take an action that can't be undone. Evidence collection illustrates why: An investigator gets one opportunity at a sound acquisition, and a flawed one forecloses analysis entirely, no matter how skilled the analyst who comes after. Hash verification can be automated safely. Deciding how to pull cloud data, approach a scene, or deploy tools to capture lateral movement across other systems cannot be, because none of those decisions can be walked back. Legal authority follows the same logic. AI flagging that a subject has a linked cloud account is useful; AI collecting that data on its own crosses a boundary an examiner cannot undo, and some forensic tools can cross it on their own if configured to.

That's the real argument behind both frameworks' operational use cases and their course mappings by phase. Whether an investigation holds up depends on the practitioner running the AI. An examiner who understands the underlying discipline and uses AI on top of it becomes more valuable to their organization. An inexperienced person using AI is the landmine, and it's leadership's job to assess that risk honestly.

Building a Defensible AI Practice in DFIR

Frameworks like these are as dynamic as the technology they address, and they are only effective if practitioners have the most current information and the underlying skills to apply it, knowing where artifacts live before a tool tells you, understanding what a sound acquisition actually requires, and recognizing a wrong answer when a model produces one. SANS courses including FOR498: Digital Acquisition and Rapid Triage, FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics, and FOR608: Enterprise-Class Incident Response & Threat Hunting build that foundation across the phases both frameworks cover.

Join us at SANS Cyber Defense Initiative 2026 in December to attend FOR508: Advanced Incident Response, Threat Hunting, and Digital Forensics in person, taught by Carlos Cajigas.

Learn more about SANS’s DFIR training offerings here.

Note: This article has been expertly written and contributed by Heather Barnhart, SANS VP of Curriculum.

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.



from The Hacker News https://ift.tt/VCLTBY3
via IFTTT