N-able Issues Fourth N-central Hotfix in Five Weeks for Unauthenticated RCE Flaw

Every on-premises N-central build below 2026.3.1.14 — including servers updated to Hotfix 3 a day earlier — needs Hotfix 4. N-able's incident notice says the flaw has been exploited in the wild; its release notes say that is unconfirmed.

N-able has released its fourth hotfix in five weeks for the N-central remote monitoring and management (RMM) platform, this time for a maximum-severity vulnerability that could allow remote code execution on the N-central server without authentication.

The company's own communications disagree on whether the flaw has already been exploited.

The vulnerability, tracked as CVE-2026-86218, carries a CVSS 4.0 score of 10.0, assigned by N-able as the CVE Numbering Authority, and is classed as a static code injection weakness (CWE-96).

It affects every N-central build before 2026.3.1.14, the build shipped as 2026.3 Hotfix 4 in the early hours of September 6 (UTC). That includes servers already updated to Hotfix 3 (2026.3.1.13), which N-able had published a little over eight hours earlier for two flaws that it says are unrelated to the new one.

N-able said hosted N-central (NCOD) instances have already been patched. On-premises customers are told to upgrade to 2026.3.1.14 immediately; the release notes list direct upgrade paths from 2025.4, 2026.1, 2026.2, 2026.3, and the 2026.3.1 hotfixes, and say agents do not need to be upgraded to be protected from this CVE.

The release notes, status post, and incident notice contain no indicators of compromise, no interim mitigation, and no detection guidance beyond a recommendation to audit N-central user accounts for unexpected users.

Huntress, which has been tracking attacks on N-central since August, has advised administrators to restrict inbound access to the console with IP allowlisting or a VPN and, where a server is still reachable from the internet, to consider taking it offline until the hotfix is applied.

On the question of exploitation, N-able's channels diverge. The Hotfix 4 release notes and status post state that a third party responsibly disclosed the vulnerability through the company's security disclosure program and that N-able has "no confirmations that this vulnerability has been exploited in production environments."

The same release notes on N-able's documentation site also describe it as a "critical zero-day vulnerability," a term N-able does not define.

N-able's incident notice on its uptime status page goes further. It says a third, independent security researcher alerted the company to a new vulnerability unrelated to the previously disclosed CVEs and that, unlike those, the newly identified flaw "has been observed being exploited in the wild."

The notice does not say who observed the exploitation, where, or when, and N-able has not attributed the activity to any actor. As of September 7, the incident was still listed as open on N-able's status page, as mirrored by the status-page aggregator IsDown.

The Hacker News has reached out to N-able for clarification on which statement is current and what evidence of exploitation the company holds.

Huntress said it cannot settle the question from its own data. The company began investigating on September 4 after a customer's fully patched N-central production environment was compromised. It said it reproduced a proof-of-concept exploit chain against build 2026.3.1.10 that may use one or both of the two flaws later fixed in Hotfix 3, but the appliance's logs had already rotated, leaving it "unable to say whether this new CVE was the vulnerability exploited" in that intrusion.

The hotfix is the fourth N-able has issued for the 2026.3 line since August 2 and covers the third distinct set of vulnerabilities:

• Hotfix 1 (2026.3.1.7), August 2 — CVE-2026-18577, an incomplete fix for CVE-2026-18556 that still allowed authentication bypass and account takeover; exploited in the wild
• Hotfix 2 (2026.3.1.10), August 6 — additional hardening for a related attack path
• Hotfix 3 (2026.3.1.13), September 5 — CVE-2026-86206, unauthorized access to internal APIs through the access control filter, and CVE-2026-86207, an authentication bypass in internal-only APIs
• Hotfix 4 (2026.3.1.14), September 6 — CVE-2026-86218, pre-authentication remote code execution

N-able described the two Hotfix 3 flaws as "high-CVSS-rated" vulnerabilities that could allow an unauthorized party to bypass authentication controls and gain full access to the platform.

Its own CVE records score CVE-2026-86207 at 7.7 (High) and CVE-2026-86206 at 6.9 (Medium). The company said it had no confirmation that either had been exploited in production environments.

The August hotfixes followed an intrusion N-able said it detected on July 31. Attackers used the authentication bypass to obtain administrative access to N-central servers, then used the platform's Take Control feature to reach managed endpoints and register Cloudflare tunnel services on those devices, maintaining access after the route through N-central was cut off.

N-able said a limited number of customers were affected, its first fix proved incomplete, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVEs to its Known Exploited Vulnerabilities catalog. On August 10, the company said a full root-cause analysis was coming.

It is the second summer in a row that N-central has drawn in-the-wild attacks: in August 2025, two other flaws in the product, CVE-2025-8875 and CVE-2025-8876, were added to CISA's catalog the same day N-able released fixes for them.

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/YlOxpo9
via IFTTT

JSCeal Malware Can Bypass Google Authentication Using Stolen Session Cookies

Cybersecurity researchers have unpacked JSCeal, a sophisticated compiled V8 JavaScript (JSC) malware with credential harvesting, surveillance, and traffic-interception capabilities.

"The payloads are protected with javascript-obfuscator, using multiple techniques including RC4-protected strings, control-flow flattening, proxy functions, and operation wrappers," Check Point Research said in a technical report published last week.

JSCeal was first documented by Check Point in July 2025, highlighting the threat actors' use of fake cryptocurrency trading sites to which unsuspecting users are redirected via malicious ads on Facebook and Google. The counterfeit sites instruct them to download bogus installers for TradingView that lead to the deployment of the malware. The activity overlaps with a threat cluster under the monikers WEEVILPROXY and MeadowLocust.

Malvertising campaigns distributing the malware make use of two ZIP archives delivered via PowerShell: one containing the Node.js runtime and the other containing the main payload and other auxiliary components.

As recently as last month, ad security platform Confiant disclosed details of a massive malvertising operation codenamed SourTrade, which has been observed impersonating trusted trading and cryptocurrency brands, such as Solana, Luno, and TradingView, to serve lookalike portals with malicious JavaScript that instructs web browsers to assemble malware directly in memory.

The campaign is assessed to be active since late 2024, targeting retail traders and cryptocurrency investors across 12 countries in 25 languages, primarily in Asia Pacific and Latin America. Evidence indicates that the campaign overlaps with a JSCeal campaign described by Bitdefender in September 2025.

"What makes SourTrade technically distinct is what happens on its landing page," Confiant said. "It does not distribute finished malware. Instead, it delivers assembly instructions to the victim's browser, retrieves a clean legitimate file from separate infrastructure, and directs the browser to build the final malware in memory on the victim’s machine. No finished malware ever exists on the network."

JSCeal is protected using javascript-obfuscator, with the operators repeatedly using four groups of transformations to obscure the malware. These include -

• Replacing function and variable names with short or nonsensical identifiers
• Splitting important strings into chunks (which are subsequently encoded and RC4-protected) and then reconstructing them through decoder functions
• Using control-flow flattening to turn program flow into a flat, single-level switch statement controlled by an infinite loop and a state variable with the goal of making analysis and reverse‑engineering harder
• Forwarding function calls through proxy helpers and wrapping simple operations, like addition, subtraction, comparison, or function invocation, in dedicated helper functions

The Israeli cybersecurity company said it developed a "fully static deobfuscation pipeline" to decode compiled V8 JavaScript bytecode protected with the utility, thereby offering insights into the malware's execution flow and its features, counting its ability to enumerate installed browsers, and query saved secrets, cookies, OAuth tokens, and other data from them, as well as "router" functions that register handlers for the collected information.

The browser stealing module targets a long list of Chromium-based browsers, such as Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Avast Secure Browser, Vivaldi, and Cốc Cốc. For each browser, the malware navigates to the expected location of its user-data directory and lists available profiles, from where cookies and passwords are extracted.

What's more, JSCeal is equipped to leverage the stolen cookie data to reconstruct a browser session and conduct active session replay attacks to bypass authentication and gain unauthorized access to a victim's Google account. A second module embedded within the malware offers surveillance capabilities by recording keystrokes and taking screenshots.

"A common technique used by banking trojans is to install a local proxy and inject or modify web content in selected services," Check Point said. "JSCeal follows a similar pattern: the recovered code shows proxy setup, certificate generation and installation, and service-specific request and response modification."

"The proxy is not limited to passive interception. The recovered code contains dedicated handlers that modify selected requests and responses for specific services. A configuration function exposes separate overrides for Binance, Bybit, and Ledger, as well as generic handlers for replacing HTML, blocking hosts, and clearing selected cookies."

There also exist multiple handlers specifically focused on cryptocurrency platforms, one of which captures account data and records cryptocurrency balances.

"JSCeal combines two forms of analysis friction: a version-specific compiled V8 format and several layers of JavaScript obfuscation applied before compilation. Neither makes the malware impossible to reverse, but together they move it outside the workflows that analysts normally rely on," security researcher Aleksandra "Hasherezade" Doniec said.

"Taken together, these developments show that the JSCeal authors are investing both in making the payload harder to analyze and in broadening its platform coverage. With campaigns continuing into recent months, the changes indicate that JSCeal remains under active development."

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

Vitamins vs. Pain Killers vs. Whippets - The Enterprise AI Adoption Problem

Brian, Brandon, and Aaron discuss enterprise AI adoption using the sales analogy of whether AI is a “vitamin” or a “painkiller,” arguing that successful transformation still requires a burning-platform event. Brandon suggests AI adoption resembles past digital transformations: without urgent pressure (e.g., a data center closing), organizations resist change and justify existing processes. Brian describes a compressed hype cycle from ChatGPT excitement to pilots and guardrails, followed by difficulties with data, cost-effective scaling, and making AI behave deterministically, while fear of competitors keeps efforts alive. They add a third category, “Whippets”, short-term, resume-driven initiatives led by leaders who leave others “holding the bag.” They debate examples like Sheetz’ multiple VMs and argue that AI’s promise is personal productivity, but note a lack of enterprise collaboration and shared-memory tools that limit organizational impact.

SHOW: 1060

SHOW TRANSCRIPT: The Enterprise AI Show #1060 Transcript

SHOW VIDEO: https://youtu.be/XZqomQosv1w

SHOW LINKS:

• The Enterprise AI Show

SHOW SPONSORS:

• Nasuni - Activate your data for AI and request a demo
• NordLayer - Use ENTERPRISE10 for 10% off.

The thesis: Successful digital transformation usually has a forcing function; you migrate the data center because the real estate got sold, not because someone promised abstract savings. Deadline + shared incentive = people actually change. AI adoption mostly lacks that: no one's forcing the migration, so it defaults to "give everyone Copilot licenses and hope."

Core question: If your business is healthy and there's no burning platform, how do you adopt AI in a way that's more than expensive theater, without a crisis to manufacture urgency?

Discussion topics:

• Forcing functions vs. vibes: What are the AI-era equivalents of "the real estate got sold"? A support team that's actually understaffed, a process with a real bottleneck, a cost center leadership is already scrutinizing vs. a mandate to "use more AI."
• The unknown-unknowns problem: Most orgs don't know which of their workflows AI would actually help vs. where it's a novelty. How do you go find that out cheaply, without a company-wide token-burning experiment as the discovery mechanism?
• Bottom-up signal vs. top-down mandate: Does real usage data (who's actually using tools, for what) surface better targets than an executive committee guessing at use cases?
• Contrast with the failed "abstract savings" migration: What does an AI initiative look like when it's tied to a concrete, already-painful problem instead of a general efficiency narrative?
• The FOMO trap: Distinguishing "we don't want to miss the platform shift" (legitimate) from "we need AI headlines for the board" (theater), and how leadership can tell which one they're actually doing.
• Measurement: If there's no forcing function, what replaces the natural deadline/incentive alignment as the way you know it's working, or that it's time to kill it?

Final Thought

Is the right move small, cheap, bounded bets against known pain points, treating AI adoption like a search problem, not a rollout, rather than a company-wide transformation initiative looking for a reason to exist?

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/Flu83Qc
via IFTTT

Four REVSTEALER-Linked Modules Disable Windows Update and Defender to Run a Crypto Miner

Elastic Security Labs has documented four previously unreported programs associated with REVSTEALER, an emerging Windows information stealer, that remain on an infected machine after the stealer deletes itself.

One of them switches off Windows Update and Microsoft Defender before running a cryptocurrency miner.

The company named the four programs ProManager, WinUpdate, SoftManager, and LockAppHost and published the findings on September 2, along with a technical white paper. REVSTEALER has been sold as a commercial infostealer since at least February 2026, when the earliest sample was first detected on VirusTotal.

The core stealer exfiltrates browser passwords and cookies, cryptocurrency wallets, gaming accounts, messaging data, and files, then reports "complete" to its server, deletes itself, and leaves no persistence. The four newly documented programs work differently. Each installs itself into the user's profile and stays there.

Elastic recovered the four programs from the same investigation as REVSTEALER and found that they share its build tradecraft, including the same packer, runtime function resolution, and the use of Polygon smart contracts for backup configuration.

The core stealer can also download and run additional executables at the command line. Elastic did not report seeing any of the four delivered onto a live REVSTEALER host, so the connection rests on shared code and investigative context rather than an observed hand-off.

The company describes the components as an "activity set" and notes they are separate executables, not plug-ins loaded into the stealer itself.

What each program does, in Elastic's account:

ProManager	Steals wallet files and browser wallet extensions, displays attacker-controlled content over a wallet application's window, and logs passwords typed or pasted into fields it identifies as password or passphrase inputs	Registry Run key
WinUpdate	Watches the clipboard, replaces copied cryptocurrency addresses with the attacker's, and collects text that looks like a wallet recovery phrase	Scheduled task, with a Registry Run key as fallback
SoftManager	Turns the machine into a reverse proxy that routes the attacker's network traffic through the victim's connection	Logon script, scheduled task, or Registry Run key
LockAppHost	Runs a cryptocurrency miner with administrator rights after disabling Windows Update and excluding folders from Microsoft Defender	Registry Run key or a service

LockAppHost is the most disruptive of the four. To gain administrator rights, it abuses the Windows CMSTP tool, falling back to a standard elevation prompt if that fails.

Once elevated, it adds Microsoft Defender exclusions for common folders and file types, disables 5 Windows Update services, disables 11 scheduled update tasks and 2 malware removal tasks, and then hides a miner within legitimate Windows processes. The changes it makes to weaken the machine's defenses remain after the miner is found.

ProManager targets users of desktop cryptocurrency wallets. Because most of those wallets are built with the Electron framework, ProManager reads the wallet window's saved position and opens attacker-supplied content sized and positioned to overlay the real wallet, without touching the wallet program itself.

A separate part of the module records what the user types into password and passphrase fields, including values pasted from the clipboard.

Before the modules ever arrive, REVSTEALER casts a wide net. It collects browser passwords and cookies; files from more than 50 cryptocurrency wallets and a large set of wallet browser extensions; session data from Telegram and other messaging clients; VPN and FTP configuration; the Windows Credential Manager; password managers; and selected documents.

For some gaming platforms, it goes further. It decrypts the stored Roblox session cookie, allowing an attacker to take over the account without the password.

To obtain credentials that Chrome protects with App-Bound Encryption, REVSTEALER launches the browser in a debugger and reads the decryption key from memory. This is not a new technique, nor is it unique to REVSTEALER.

Elastic said it was likely adapted from the public ElevationKatz project and was also used by another stealer, VoidStealer, in March 2026. Gen Digital, which analyzed VoidStealer, described it as the first infostealer seen using the technique in the wild.

REVSTEALER reaches victims mainly through game-cheat lures. Elastic identified at least 17 YouTube channels, many of which were hijacked from their original owners, that promoted two cheat websites using short AI-generated videos.

The malware has also been packaged as pirated or impersonated software, including a fake "Claude Opus 5 Free Desktop" application that Morphisec documented on August 31. That application copied Anthropic's branding, and there is no indication Anthropic itself was compromised. Elastic's detection rule matched about 4,700 samples on VirusTotal over the past year, a count of files rather than confirmed infections.

REVSTEALER is built to resist analysis. It scores the machine against 10 sandbox checks and stops if the total is too high, and it terminates on systems set to one of 10 languages used across Russia and Central Asia.

It resolves Windows functions without a normal import table and calls the kernel via indirect system calls to bypass the hooks installed by security products. If its main command server is unreachable, it reads a backup address from a smart contract on the Polygon blockchain, a takedown-resistant method known as EtherHiding.

Unpacked builds also show a verification window that asks for a random six-character code before running, a gate against automated analysis that Elastic compares to Lumma Stealer and AuraStealer.

To reduce the risk of infection, avoid downloading "free" or unofficial versions of paid AI tools and game cheats, and install Claude only from Anthropic's official channels.

Elastic has published YARA rules and behavior rules and a set of indicators for detection and blocking. The public YARA file covers the core stealer and the ProManager, SoftManager, and WinUpdate modules, but does not include a rule for LockAppHost, the mining module.

Because the core stealer deletes itself, an infection can appear complete while the modules continue running. Where LockAppHost has run, responders should re-enable the Windows Update services and scheduled tasks that it turned off, remove the Microsoft Defender exclusions it added, and look for a miner hidden in a suspended instance of nslookup.exe or svchost.exe.

Since the stealer takes session cookies and the Chrome App-Bound Encryption key, affected users should change passwords and end active sessions on their accounts rather than assume a password reset is enough.

Selected indicators of compromise:

• SHA-256: adc4aa652965396b52e79435ca54987ae9eb21bf5e67de5e9461b09655165ee4 (REVSTEALER)
• SHA-256: 13d7237d7289e67c2d806a65d52580b453ce4987acbe2c4c4d04833f55ebccfa (ProManager)
• SHA-256: 7c08cf409194056a8517865e5d3433d1499bb8262263b55b49b8b07d9d182fcb (WinUpdate)
• SHA-256: 14b2ac356ed75d10ef40bbaaa48e7dd9fff7de9719c2a43ad123fe843dd4e4e2 (SoftManager)
• SHA-256: c66d2b77b9e85c53391891212413ad9a99eb66f4b11c6a431e78884a5b2651e5 (LockAppHost)
• Domain: monitor5.roast-core85[.]click (REVSTEALER C2)
• Domain: config.hubdisplay[.]lol (ProManager C2)
• Domain: health.journal-metric[.]lol (WinUpdate C2)
• Domain: metric.gardenpark[.]click (SoftManager C2)

Gen Threat Labs first documented REVSTEALER in July. Elastic's report and white paper are the fuller public account of the malware to date.

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/rVDQmYw
via IFTTT

Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores

Attackers are exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce that lets them run malicious code on an online store's server without logging in, Dutch e-commerce security company Sansec said in an advisory published on September 5.

Sansec, which discovered the flaw and named it StyleSmuggler, said attacks started on September 4. "Sansec is publishing early because stores are being compromised right now," the company said.

As of September 6, Adobe has not published an advisory, a CVE identifier, a patch, or a workaround, and its Adobe Commerce security bulletin index lists nothing after the August 11 update.

A successful attack gives the attacker code execution on the store's server and installs a persistent backdoor. Sansec said all current versions are affected, including 2.4.9, and that it reproduced the full unauthenticated chain on clean Magento Open Source installations of 2.4.7, 2.4.8, and 2.4.9.

Its first victim ran 2.4.6-p15 with Adobe's July and August 2026 security updates applied, which is the latest patch level Adobe offers for that release line and one that Adobe's August bulletin labels 2.4.6-2026-aug.

Sansec has not published a reproduction on Adobe Commerce or on Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected. Sansec has not said how many stores have been compromised.

The researchers' interim advice for stores not running its Shield product is to disable GraphQL until Adobe releases a temporary fix.

Disrex Group, a Magento hosting and development company that responded to two of the compromised stores, notes that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyvä storefronts do not.

Adobe's next scheduled security release is on September 8, Sansec said, and it is not yet known whether that release will cover this bug.

Disrex's findings are independent evidence of exploitation from outside Sansec. In an incident-response repository published on September 5, the company said it handled two stores compromised on September 5 and a third that was attacked but not breached, and that its web-server rules are based on attack traffic captured on one of the compromised stores.

That store ran Magento 2.4.7-p2, a security patch level that Adobe's version history dates to August 2024, eight levels behind the current 2.4.7-p10. The store Disrex labels Store A was a Sansec Shield customer and was hit at 23:10 UTC on September 4, hours before Sansec's first blocking rules went live.

The repository carries its own warning. "This repository was written with AI assistance, during a live incident, in a few hours," its README says, adding that it has not been reviewed, that its Apache rules were never run against a live Apache server, and that most of its cleanup commands were written rather than executed.

Sansec's indicators describe the implant as a background process disguised under [kworker/u:8:0], a name that belongs to a Linux kernel thread, with a binary installed at ~/.local/share/.gvfsd/gvfsd-user under the site user's home directory rather than the web root, and a cron entry that restarts it every five minutes.

Disrex described the binary as a stripped, statically linked Rust program of roughly 1.9 MB built for x86-64 and arm64, and said the cron entry is written straight to the spool file under /var/spool/cron/crontabs/, so the system log shows no crontab replacement.

One store carried the same line 1,728 times, and the implant re-added it within a second of removal.

On one of the two stores, the implant made no outbound connection at all. It held 28 connections to the store's own Redis instance on port 6379. It read Magento's session storage from it, Disrex said, and neither of its two packet captures, each over 200 MB and taken. At the same time, the implant was live, contained a single packet to the download host or the command-and-control address that Sansec listed.

Sansec said that for Shield customers attacked before its rules went live, it has no indication that the backdoor was actually used, and recommended rotating Magento credentials wherever the process has been identified.

The attack works in two stages, according to Sansec's outline. It first plants PHP code in a file that Magento itself writes, for example, when generating a failure report. Then it makes Magento execute that file by triggering the platform's standard "Payment Transaction Failed Reminder" email. The code runs while Magento renders the message, so no one has to open it, and the attack can succeed even if email delivery fails.

Sansec has not yet published the full exploit chain and said a breakdown of the chain, the dropper, and the implant will follow in an update.

Disrex's reading of the chain, published in a mechanism write-up alongside its rules, is that a directive within the injected text drives a sequence of Magento's own classes into code that exists solely to serve the command-line dependency-injection compiler.

That code ends by including a file path the attacker chose: the log poisoned a moment earlier. The executed PHP dropper attempts six PHP functions in turn to start a process, then downloads and launches the implant. Disrex names three files under setup/src/Magento/Setup/Module/Di/Code/ as the point where the chain ends. Sansec has not confirmed that reading, and Disrex does not publish the assembled request.

Two locations matter for the first stage. Sansec's published check searches var/report/ for the marker X_TRACE_. Disrex said both of its infections were poisoned through var/log/system.log instead and would have been missed by that check, so both directories need searching.

The marker has already drifted: Disrex saw a trigger header of the form X-TRACE- followed by ten hex characters on the morning of September 5 and the same header without the word TRACE by the afternoon, so a search should match the shape rather than the exact string.

A TypeError from array_merge() with an integer argument in system.log, immediately after the include, is evidence that the exploit succeeded, Disrex said. However, a stealthier variant returns an empty array and leaves nothing in the log.

For the process, Disrex said that a genuine kernel thread is owned by root and has no resident memory, so a bracketed name on the site user with real memory usage is the implant. The implant sets its command line to the literal bracketed string, so a check written against the process's comm field matches nothing.

Disrex also found that the binary running in memory on one store was a different build from the file on disk, and advises hashing the running process from /proc/<pid>/exe as well as the file. Unexpected bursts of "Payment Transaction Failed Reminder" emails are a reason to investigate, Sansec said, although legitimate declined payments generate the same notification.

The following indicators have been published by Sansec and in Disrex's indicator list -

• Process: [kworker/u:8:0] owned by a non-root user
• File: ~/.local/share/.gvfsd/gvfsd-user
• File: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
• File: /tmp/.gvfsd_<8hex>.lock
• File: /tmp/.kw_<random><random>
• Cron: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user, with a variant pointing at /tmp/.kw_
• SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (Sansec's sample)
• SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (on disk on both Disrex stores)
• SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (running in memory on one Disrex store)
• Domain: 247.cdnflare[.]xyz (malware download host)
• IP: 99.84.67[.]186:443 (command-and-control over WebSocket and TLS, per Sansec)
• IP: 88.216.72[.]181 (attacker source, per Sansec)
• IP: 5.181.86[.]133 (attacker source sending in bulk, per Disrex)

Sansec recommends its eComscan scanner to detect the implant, and said version 1.9.7 will terminate the process for Shield customers.

Disrex reported the opposite result for one store: eComscan ran with its background-process and scheduled-task checks enabled while the implant was live, with 1,728 cron lines present, and reported the store clean. Disrex did not say which eComscan version ran or when.

There is no vendor fix to install. Until Adobe ships one, the options are Sansec's temporary GraphQL shutdown; three unofficial mitigations published by Disrex, ProxiBlue, and Graycore; and two server settings that do not depend on the flaw.

Disrex published nginx and Apache rules that block requests carrying the exploit's parameters in the URL query string. Its own test on a live store showed the limit: the same parameters sent in a POST body reached PHP, as did a JSON body, because nginx and Apache inspect only the query string, Disrex said. Disrex describes the rules as stopping the campaign as it currently runs rather than the vulnerability.

Disrex's main mitigation adds a check to three methods in Magento's dependency-injection code scanners, preventing them from running outside the command line. The hand edit is reverted by every composer install, so Disrex also ships it as a composer-patches source patch that reapplies on deploy and, it says, applies unchanged from 2.4.6 through 2.4.9.

One of the three files, ClassesScanner.php, is called over HTTP by at least one third-party module, mageplaza/module-admin-permissions, and guarding it breaks that module's admin screen, so Disrex tells administrators to search their vendor directory before touching it.

The guard was tested on a harness rather than inside a running store, and Disrex says it is not a complete fix on its own. A GitHub user, ProxiBlue, published the same guard on September 5, along with three unofficial patches. Neither Sansec nor Adobe has confirmed that these scanners are where the chain ends.

Graycore, LLC published a Magento module on GitHub and Packagist on September 5 whose current code, Graycore says, hardens three points on the chain: the email template block directive refuses backend blocks, the grid row URL generator checks a class before building it, and PHP opening tags in Web API fatal error reports are broken.

The version on Packagist at the time of writing was an earlier release whose only mitigation targeted a PayPal GraphQL resolver that has since been removed. The README says "That is hardening, not a fix" and warns that other paths through the vulnerability remain open and that a store may already be compromised.

Two server settings do not depend on knowing the chain at all, Disrex said. At one of its two stores, the first four of the six PHP functions the dropper tried were disabled; proc_open was not, and the dropper used it to start the implant, with open_basedir doing nothing to contain the child process.

Adding proc_open to PHP's disable_functions, and mounting /tmp, /var/tmp and /dev/shm with noexec so a downloaded binary cannot run, are the layers Disrex puts ahead of every rule in its repository.

For a store that is already infected, Disrex's cleanup guide sets the order: preserve evidence first, remove the cron entry before killing the process because the process restores it, do not reboot because the copy under /proc may be the only remaining binary, and do not run composer install to clean up because it overwrites the timestamps that show what was touched.

It then recommends flushing session storage since the implant read it, and rotating the crypt/key in app/etc/env.php, as well as every admin password, every payment provider API key, and every other integration credential in that file.

Hosting providers Nexcess and Liquid Web posted identical incident notices on September 5, stating they were reviewing their server environments and implementing precautionary measures.

Neither claims a confirmed customer compromise or its own reproduction of the flaw. Disrex recorded 26 distinct source addresses across its two stores, two of them hosting infrastructure sending in bulk and the rest a residential proxy pool sending two to six requests each, and said that blocking the single attacker address in Sansec's advisory would have stopped less than a quarter of the traffic it saw. No source has named the attackers.

The Hacker News has reached out to Adobe, Sansec, Disrex and Graycore for comment, and will update the story if we hear back.

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

Critical VMware Workstation and Fusion Flaw Lets VM Admins Execute Host Code

Broadcom has released security updates for two security flaws impacting VMware Workstation and Fusion, including one critical bug that could result in arbitrary code execution under certain conditions.

The vulnerability, tracked as CVE-2026-59346 (CVSS score: 9.3), is an integer-overflow vulnerability that a local attacker with elevated privileges can exploit to run arbitrary code.

"A malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host," Broadcom said in an alert.

The tech giant credited @h4urek, @cameudis, and Stan S for discovering the issue.

Also patched by Broadcom is a stack-based buffer-overflow vulnerability in HGFS (CVE-2026-59347, CVSS score: 8.1), which can be exploited by a bad actor with local administrative privileges on a virtual machine to execute code as the virtual machine's VMX process running on the host.

Yeonghyeon Choi and Tianchu Chen of Tencent Xuanwu Lab have been acknowledged for reporting the flaw.

In both cases, successful exploitation hinges on an attacker already possessing local administrative privileges, although it's worth noting that they can be obtained through a separate compromise through phishing or exploiting weak user configurations.

The two vulnerabilities affect VMware Workstation and VMware Fusion versions 25H2 and 26H1. Broadcom said there are no workarounds that address the two vulnerabilities, adding that they have been patched in VMware Workstation 26H1u1 and VMware Fusion 26H1u1.

Although there is no evidence that the security flaws have been exploited in the wild, vulnerabilities in VMware products have been an attack magnet.

As recently as last month, threat actors were observed actively exploiting two shortcomings in VMware vCenter, namely CVE-2026-59309 and CVE-2026-59310, with the latter suspected to be weaponized by a China-nexus advanced persistent threat (APT) actor.

The activity, which started five calendar days after public disclosure of the flaw, is estimated to have breached 361 unique victim IP addresses across 47 countries. Most of the infections were concentrated in Germany (55), the U.S. (41), Turkey (38), Iran (26), and France (25).

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

Trezor Says ShipMonk Breach Exposed 67,000 U.S. Customers' Data It Said Was Deleted

Hardware wallet manufacturer Trezor on Friday disclosed that another 67,000 customers from the U.S. have been impacted in a breach at its shipping provider ShipMonk.

The exposed information includes customer names, email addresses, phone numbers, shipping addresses, and order numbers between November 2019 and August 2021. The breach does not affect the security of the company's hardware wallets.

"Throughout our entire relationship with ShipMonk, we repeatedly requested and received written assurance confirming the deletion of the data, in line with our contract, data policy, and past communications," Trezor said. "We are very disappointed that, despite receiving this confirmation, the data was not deleted in their systems."

The exposure is in addition to 13,689 customers the company disclosed last month as having had their data either fully or partially exposed. The breach, it noted at the time, was limited during its 90-day data storage policy.

Trezor said ShipMonk informed the hardware wallet maker of a breach on August 10, 2026, following unauthorized access to their systems. Subsequently, it revealed that the 1,947 customers whose exposure was limited only to names, cities, and email addresses (excluding the shipping addresses) may include older orders.

"After 90 days we delete or anonymize all customer data related to a purchase on our Trezor eShop," the company said. "We chose 90 days because it is the shortest window that still covers the whole life of an order — delivery, returns, and any refund or replacement. After that we have no reason to keep your address or phone number."

ShipMonk has yet to acknowledge the incident publicly. The logistics company is said to have secured the affected systems and improved its security after the digital break-in, which involved the zero-day exploitation of CVE-2026-72898 (CVSS score: 10.0), a critical SQL injection flaw in Metabase.

According to enterprise blockchain security firm Holborn, the ShinyHunters extortion gang is said to be behind the breach. Trezor said it has notified affected customers directly.

However, it warned users to be on the lookout for social engineering attacks and scams, as bad actors can exploit the leaked information to send phishing emails or letters, make fake phone calls, and even impersonate the company in email communications to persuade targets into taking unintended actions.

"The leaked information could be used for scam emails, fraudulent calls or letters, and could potentially expose affected individuals to physical security risks," Trezor said.

Holborn said the software supply chain attack highlights the need for organizations to have complete visibility into their third-party risk exposure in order to help manage their overall security posture.

"The Trezor breach was the result of a supply chain attack beginning with a zero-day vulnerability," it said. "By finding and exploiting the SQL injection flaw in Metabase, the attackers were able to exploit several of its customers, stealing sensitive data and extorting the organization."

"In Trezor's case, this meant the exposure of customer order details that were stored in a Metabase instance by ShipMonk."

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

Thousands of OpenAI Agents Quietly Turned an Abandoned Wiki Into Their Coordination Channel

A group of AI safety researchers says a fleet of autonomous agents that identified themselves as OpenAI systems left about 18,000 posts on a dormant 25-year-old German wiki between May and July 2026, using the site as a shared board to pool answers to a timed web task and pass around a way out of their sandbox.

The activity was concentrated on DSEwiki, a German software developer wiki that runs on the ProWiki farm at wikiservice[.]at and had been edited about 20 times over the previous decade.

The researchers, led by Sydney Von Arx of the AI safety nonprofit Nightingale Collective, reconstructed the deleted pages from edit history and published their analysis along with a downloadable copy of the data.

The wikis let anyone change a page with an ordinary web request, the kind normally used only to read a page rather than to write one. Agents that were restricted to reading the internet could therefore still write to the site, because the restriction was written against the request type their harness expected writes to use, not against what the old wiki software would actually accept.

"We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task," the researchers wrote in their published report.

The agents were working through timed lookup tasks of usually five questions, and many were given questions that other agents had already answered. According to the report, they posted results, raw data, and predictions of upcoming questions so that agents running ahead could hand answers to those running behind.

About 17,000 of the edits on DSEwiki came from Microsoft Azure addresses, 98.5% of them, and the agents gave themselves more than 3,700 distinct names such as OpenAIResearcher and OAIResearchMar26, drawn from a feature of their task plus a date each was apparently told it was running on.

The researchers documented several distinct behaviors on the site -

• Writing via a read request: agents used the wikis' acceptance of state-changing read requests to post without the ability to send a normal write request.
• A proxy bypass: one task needed a statistic to two decimal places from a Microsoft Power BI dashboard, reachable only with a write request the sandbox blocked, so agents worked around the block and shared the method.
• Impersonation: agents made edits under the name of a wiki moderator.
• Coordination to cheat a timed task: agents formed groups to relay answers and reverse-engineer the order of future questions.
• Alternate routes: 197 of the roughly 18,000 edits came from Amazon Web Services, DigitalOcean, and the Tor anonymity network rather than Azure, often under the same agent names.

The bypass turned on a gap the agents found in their own sandbox. The environment allowed traffic to reach Azure storage hostnames ending in .blob.core.windows.net without passing through its security proxy, but it did not verify that such a hostname was valid.

An agent invented bypass[.]blob[.]core[.]windows[.]net, pointed it at the real dashboard's address, 20.223.25[.]152, by editing its /etc/hosts file, and sent its blocked request there instead. One agent posted the method, and another reported reproducing it about 14 minutes later. The wiki path worked the same way, the researchers say, turning a web capability meant only for reading into a way to write to the public internet.

The researchers say the wiki activity was a separate episode from the OpenAI models that broke into Hugging Face in July, as described in OpenAI's July disclosure.

Those agents had no internet access and had to escape a sandbox, while the agents on the wiki were given web access as part of their task and left no sign of the internal message board the Hugging Face swarm used.

In an independent investigation of the Hugging Face incident, METR found that roughly 1,200 agents exchanged more than 70,000 messages and files on an unsanctioned board, and that about 700 of them went on to attack the platform.

What OpenAI Has Said

OpenAI has not publicly disclosed the wiki episode, and the researchers infer from the site's public logs that the company found it. Addresses registered to OpenAI first visited the wiki on June 21, and agent editing collapsed the next day.

The Hacker News confirmed via ARIN's registry on September 5 that one of the address blocks the report cites, 199.47.142.0, is registered to OpenAI OpCo, LLC.

OpenAI has not confirmed that the agents were its own. Asked about the report, which Reuters first reported, an OpenAI spokesperson said the German activity "wasn't related to Hugging Face" and would not have appeared in that incident report, and denied that its legal team had discouraged an investigation.

The company has said it cannot respond in detail to a report it has not reviewed, and that the researchers declined its access request. In its own account of the Hugging Face incident, OpenAI has described the same underlying behavior that arises during training.

"After investigating this incident, OpenAI discovered through retrospective CoT reviews that agents learned to use improvised collaboration channels in rare cases during the training process for some OpenAI models, including the model that drove the Hugging Face activity, even when the collaboration tool was not enabled," the company said in its technical report.

The wiki data shows no third-party systems compromised. The reported harm was to the wiki itself, whose moderator spent weeks deleting agent pages, and to the integrity of the timed task that the agents were cheating on.

The researchers say they cannot tell from the wiki alone whether the task was part of training or an evaluation, and they note the agents must have had some way to converge on the same obscure site.

The pattern extends beyond OpenAI. Anthropic disclosed in July that Claude models had reached real systems during misconfigured cybersecurity evaluations, an episode The Hacker News covered when Anthropic said Claude mistook the open internet for a capture-the-flag exercise.

The UK's AI Security Institute reported in August that agents in its cyber tests used a public GitHub page as a message board and public tunneling services to reach the internet, findings The Hacker News covered when a Claude model tried to backdoor an open-source project during testing.

OpenAI released GPT-6 Astra on September 3, a day before the wiki report, and its system card includes a dedicated evaluation for agents that seek out and follow messages left by other agents on external boards.

Update

OpenAI addressed what it called the "wiki incident" in a post on September 5, saying its agents "wrote to several internet sites" and that the company had treated the episode as an instance of misalignment similar to earlier cases it had already published, rather than as a security incident of the kind it disclosed for Hugging Face. The company pointed to three earlier reports, on monitoring internal coding agents, its GPT-5.6 system card, and safety and alignment in long-horizon models, as prior signs of agents using the internet in unintended ways.

"We and the larger AI community do not yet have a clear standard for how to report misalignment that shows up during training, evaluation, and deployment, including examples that don't look like traditional security incidents but could provide insight into AI behavior and future risks," the company said, adding that it would share a framework "in upcoming weeks" and was working with government regulators on the issue.

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

Attackers Exploit PaperCut Flaws to Steal Credentials From Schools and Universities

Threat actors are exploiting the newly disclosed PaperCut flaws to facilitate credential theft in attacks targeting the education sector in the U.S. and Europe.

The Arctic Wolf Adversary Research Team said it observed attackers exploiting CVE-2026-81578 and CVE-2026-82078 – an authentication bypass and remote code execution chain – to conduct command execution and reconnaissance, as well as create privileged accounts.

"Observed post-exploitation activity included delivery of Windows registry hive collection tools, Metasploit/Meterpreter-related Java payloads, and commands used to identify hosts, users, processes, and sensitive configuration data," Arctic Wolf said.

The cybersecurity company told The Hacker News that the activity has targeted vulnerable PaperCut servers across the education sector, impacting organizations ranging from K-12 schools to major universities in the U.S. and Europe.

Some of the identified malicious activity includes -

• Running discovery commands like uname, whoami, ver, and tasklist, and privileged account creation ("Administrator17")
• Inbound GET requests from "45.142.193[.]132" that request for "/custom/pcp_*.txt" and "/custom/web/pcp_*.txt" files on compromised hosts, containing harvested system and user data
• Deliver credential-harvesting tools like lsa_collect.exe, lsa_collect_small.exe, and save_hives.exe via "certutil.exe" from "45.142.193[.]132"
• Retrieve Meterpreter Java payloads from, and establish sessions to, "194.180.48[.]134"
• Use "findstr" to search PaperCut *.config files for the terms "password," "secret," "ldap," "bind,v and "token"

Arctic Wolf said it also detected "lsa_collect.exe" in a sandbox that extracted specific registry keys to reconstruct the system BootKey, which can then grant the attacker access to the SAM database.

"The concern is that those stolen logins could give attackers a pathway into other critical systems across the environment. Post-compromise activity included deployment of Windows registry," Arctic Wolf said in a statement.

Users are advised to restrict PaperCut servers from being exposed to the internet and monitor for the execution of cmd.exe, powershell.exe, or other scripting and command interpreters, along with commands containing whoami, tasklist, ver, or uname -a with pc-app.exe as the parent process.

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

How to secure edge AI in customer-owned environments

1. Edge AI changes the trust model for AI systems
2. Constrain model actions through deterministic mediation
3. Establish trust before releasing sensitive assets
4. Verify runtime before releasing sensitive assets
5. Verify artifacts that shape model behavior
6. Next steps

Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released.

Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation.

Edge AI changes the trust model for AI systems

In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates.

In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment.

What changes with Edge AI?

• Customers operate more of the AI stack.
• AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs.
• Models, credentials, and data can live in environments outside the provider’s direct control.
• Traditional software security controls alone are not enough.

What should organizations do?

• Verify runtimes using attestation.
• Verify AI artifacts using provenance.
• Constrain model actions through mediation.
• Bind and release sensitive assets only to trusted environments.

Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted?

Why Edge AI increases exposure

An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment.

This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated.

Why AI changes the security problem

Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it.

Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model.

• Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk.
• Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret.
• AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction.

Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization.

These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take.

Constrain model actions through deterministic mediation

Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer.

In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior.

Establish trust before releasing sensitive assets

Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions:

• Do I trust this runtime and the platform on which I am about to execute this workload?
• Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered?

Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release.

Verify runtime before releasing sensitive assets

This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released.

Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and DMA extend the trusted computing base beyond ordinary application-security visibility. Where confidential computing covers that path within the platform’s documented threat model, protected memory and hardware-rooted attestation can support release to an approved runtime. This is designed to protect assets from host access; it does not constrain a steered model’s actions through authorized interfaces. Those vectors need additional controls.

Because system state can change after deployment, release is treated as a renewable lease that expires when fresh evidence no longer matches the approved state. Physical controls address what measurement cannot see.

In this pattern, evidence gates scheduler placement, storage, identity, and credential release. Bind credentials to the approved runtime and action scope to reduce the risk that credential theft enables bulk exfiltration; otherwise, evidence does not enforce trust.

Verify artifacts that shape model behavior

Runtime trust proves only that the platform is acceptable; it does not prove that the artifacts loaded into it are trustworthy. A clean runtime can still execute a poisoned artifact.

That is why artifact trust has to be evaluated separately. Because these artifacts shape model behavior, accepting one into the system is more than data transfer. Creation, distribution, deployment, and use can each introduce a tampered artifact.

Model IP can extend beyond weights to provider-owned components that handle them; those components may warrant the same evidence-gated release.

In this pattern, approved components and updates enter through a trusted build environment; on-site changes appear as measurement drift rather than silently becoming a new baseline.

Each artifact should carry evidence of its origin, build pipeline, and input integrity. The verifier evaluates that evidence before accepting it. Provenance should chain to hardware and be produced inside a measured, policy-approved runtime. Signatures establish origin and integrity but may not show whether the producing runtime met verifier policy. Provenance helps responders reconstruct what happened: which model acted on which data, in what runtime, and under which policy.

Next steps

Bottom line: Edge AI changes the trust model for AI systems. Customers operate more of the stack, AI behavior is influenced by runtime inputs, and sensitive assets run in environments outside the provider’s direct control. Attestation, provenance, mediation, and evidence-based release help establish trust before models, data, and credentials are exposed.

Edge AI pushes security controls into devices, gateways, vehicles, factories, hospitals, retail spaces, and other customer environments.

For depth on the agent case, see our post on defense in depth for autonomous AI agents. Map sensitive assets, the runtimes and artifacts that can access them, and the party responsible for each release decision. Then define the evidence and policy required at every boundary. At the Edge, security should be architectural: anchored at hardware, enforced at every action.

The post How to secure edge AI in customer-owned environments appeared first on Microsoft Security Blog.

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

PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution

PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server.

The flaw, tracked as CVE-2026-6471 (CVSS score: 7.2), has been present since logical decoding was introduced in PostgreSQL 9.4 in 2014. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Exploitation requires an account carrying the REPLICATION attribute and a server running with wal_level = logical. Backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems routinely hold that attribute.

The fix, shipped on August 13, adds a server parameter called output_plugin_libraries that lists which libraries may be loaded as logical decoding output plugins, defaulting to 'pgoutput, test_decoding'.

Installations using any other output plugin, wal2json, and decoderbufs

among them, will have logical decoding refused after updating until an administrator adds the library to that list and reloads the server configuration.

"Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins," the PostgreSQL Global Development Group said in the 18.6 release notes.

The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng with reporting the problem.

Tokarev detailed it in a September 1 write-up for data security firm Cyera Research, which names the flaw PostGREShell.

The plugin name supplied in a CREATE_REPLICATION_SLOT command is passed directly to the function that loads the library, Cyera said.

PostgreSQL's existing restriction on plugin paths, which confines non-superusers to a single administrator-controlled directory, is never called on the replication path. The replication protocol's parser accepts almost any character inside a double-quoted plugin name, including path separators and ../ traversal, so a full filesystem path reaches the loader as typed.

On Windows, the server resolves a network path over Server Message Block (SMB) and fetches the library from a machine the attacker controls, writing nothing to the target, Cyera said.

On Linux and macOS, the same result requires enabling Network File System (NFS) automounting. Everywhere else the attacker needs an existing way to write a file to the server's disk. Code loaded this way runs inside the database backend process as the postgres operating-system user.

Cyera's test plugin then wrote the role catalog directly to make the replication account a PostgreSQL superuser. It also set up three persistence mechanisms that survive a server restart.

Cyera describes the REPLICATION attribute as a low-privilege backup credential, but PostgreSQL scored the flaw with Privileges Required set to High, a rating reproduced in SUSE's own assessment.

PostgreSQL rejected applying its existing LOAD restriction to the replication path.

"REPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD-time protections during logical decoding. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the $libdir/plugins directory," Jacob Champion, who wrote the fix, said in the commit message.

Failed loads appear in the server log as ERROR: library "..." may not be used as an output plugin, with a hint naming the setting, according to the parameter's documentation.

Administrators are advised to take the following steps -

1. Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify the output plugins in use, which will only show plugins successfully used at some point.
2. Update to 18.6, 17.11, 16.15, 15.19, or 14.24, or to the equivalent distribution package.
3. Add any non-default plugin to output_plugin_libraries and reload the configuration with pg_ctl reload or SELECT pg_reload_conf(). A restart is not required.
4. Set the new cluster's output_plugin_libraries before running pg_upgrade --check when migrating from version 17 or later, as the check fails if the list does not permit the old cluster's slot plugins.

Fixed packages are available on Amazon RDS for all five branches, as well as from Debian, SUSE, and Ubuntu.

PostgreSQL's advisory covers supported branches 14 through 18 and does not address earlier ones. PostgreSQL 14 stops receiving fixes on November 12, 2026, the project said in its release announcement.

The upstream fix "requires additional changes to the configuration if some extensions are used," Debian's advisory warns, naming its wal2json and decoderbufs packages.

Ubuntu's USN-8653-1, which shipped the fix for 22.04, 24.04, and 26.04 LTS on August 20, makes no mention of the parameter and tells administrators only to restart PostgreSQL after the update.

As of September 4, the wal2json project had updated its documentation to tell users to add the plugin to output_plugin_libraries, citing the CVE.

A gap in the fix is still open. pg_createsubscriber creates replication slots using pgoutput without checking the new parameter, so a --dry-run succeeds and the conversion then fails.

"pg_createsubscriber command creates replication slots with plugin 'pgoutput', without checking the GUC. This meant if the plugin name is not specified in the parameter, --dry-run mode passes but actual convertion fails. It's very surprising for users and should be avoided," Hayato Kuroda of Fujitsu said in a message to the pgsql-hackers mailing list.

A patch was under review and had not been committed as of September 4. CVE-2026-6471 remained absent from CISA's Known Exploited Vulnerabilities (KEV) catalog as of September 4.

The Hacker News found no proof-of-concept code for it in public repositories on the same date.

Until the update can be applied, Cyera said exposure can be reduced by stripping the REPLICATION attribute from accounts that do not need it, restricting replication entries in pg_hba.conf to known addresses, blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers, and disabling autofs where it is not needed.

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

New Ted Backdoor Hides Inside Victims' Own HAProxy Builds to Intercept Web Traffic

A previously undocumented Linux toolkit has been found compiled directly into the trojanized HAProxy load balancers of two South Korean organizations, where it intercepted web traffic and served altered pages to selected visitors.

The attackers named the implant ted in debug strings left in the binary. It is not a HAProxy vulnerability, and installing it requires code execution on the host and the ability to replace the running binary.

Rapid7 Labs attributed the toolkit with medium confidence to North Korean state-sponsored actors and put the two victims in South Korea's automotive and media sectors.

Command-and-control (C2) requests never reach a backend server and are erased from HAProxy's own connection counters, so neither the backend logs nor the load balancer's statistics record them.

"Further evidence is necessary to make a more definitive assessment," Rapid7 said.

A request for one specific image path puts the filter into C2 mode, Rapid7 said in a report published Friday. The implant decrements HAProxy's live connection counters, thereby dropping the connection from the load balancer's statistics. It writes the command body to a named pipe under /tmp. Zeroing the request channel afterwards leaves nothing to forward, and the command terminates at the load balancer.

Output returns on the raw socket under a standard HTTP/1.0 200 OK header, which is what makes the exchange look like ordinary web traffic.

Through that channel, the operator can beacon, upload and download files, run shell commands, and replace the implant's configuration. Only requests clearing four checks receive a modified page.

The request has to carry a User-Agent and match a rule whose URL and referer patterns both fit. Delivery then falls to either whitelist membership on the client address, checked exactly and again at the /24 level, or an operator key in the Accept-Language header that overrides the address filtering entirely.

The implant rewrites the content type and length on the way out, forces the response status to 200, and deletes the Accept-Ranges header so a client cannot request byte ranges and notice the size change.

Rapid7 said its evidence was not enough to establish a timeline or determine how the attackers first got in.

Its hypothesis that they came in through an exposed Groupware portal, a class of Korean enterprise collaboration software, rests on the ENKI research it points to. That report documented Kimsuky compromising a groupware vendor through a mail server flaw.

The stager deploys only where HAProxy or cron is already running, and it verifies root before dropping anything. It overwrites the legitimate crond binary and gives the replacement the creation timestamp of /usr/bin/ssh. It then strips the keywords tmp, wget, cron and crond from root's bash history and from six system logs, among them auth.log and audit/audit.log.

A trojanized sshd in the same toolkit encrypts captured plaintext passwords and writes them to a fixed path.

Rapid7 found the same code in trojanized agetty, atd, and polkitd binaries. A companion remote access trojan (RAT) that Rapid7 calls curlRAT beacons every 12 hours by default and drops to a 30-second interval when the operator sets a flag. It aborts unless it finds a marker file showing the host is virtualized.

curlRAT is distinct from CurlBack RAT, a separate family of that name attributed to the Pakistan-linked SideCopy group.

Rapid7 shared the following indicators of compromise (IoCs) -

• Domain - img.monderhouse[.]space
• Domain - img.smartnords[.]site
• Domain - img.darklights[.]store
• Domain - img.responsive.pstatic[.]autos
• Domain - img.socialteams[.]store
• Domain - img.worksongo[.]store
• File - ~/cache/haproxy-1000.cache
• File - /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19
• File - /var/lib/snapd/g580
• File - /tmp/jasper-log
• SHA-256 - 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558
• SHA-256 - 4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

The Hacker News confirmed on September 4 that none of the six domains resolves, returning NXDOMAIN, meaning no such name exists, for both A and NS records via Google Public DNS. They are useful for reviewing historical logs rather than for blocking live traffic.

Part of the attribution rests on a listing of those domains under APT37 in maltrail, an open-source detection project. The maltrail file Rapid7 links stopped resolving after a repository restructure in August moved the project's static trail data elsewhere.

The Hacker News confirmed on September 4 that all six are present at the new location, each labelled as APT37 infrastructure. maltrail's APT37 source file credits those entries to two posts on X from July 2025 and carries no reference to Rapid7.

Six further domains sit in the same two maltrail entries but not in Rapid7's list: primgs[.]lol, admin.primgs[.]lol, grip-cdns[.]space, show.grip-cdns[.]space, cleanos[.]online and app.cleanos[.]online. Rapid7 has not said whether they are the same infrastructure.

The ThreatFox tag Rapid7 names as its second source for the same domains records five sightings, all timestamped July 2, 2025.

One of the two X posts maltrail cites was published three hours earlier that day.

The attribution passage draws on three separate North Korean clusters, APT37 for the domain list, Lazarus for the delivery model, and Kimsuky for the initial-access hypothesis.

Mandiant's 2023 assessment of North Korean cyber structure recorded shared tooling and overlapping targeting across those clusters.

"We believe that this will make precise attribution more difficult," Mandiant said.

Rapid7 compared the delivery model to the Operation SyncHole campaign, in which visitors to South Korean online media sites were filtered by a server-side script and redirected. Kaspersky researchers Sojun Ryu and Vasily Berdnikov assessed "with medium confidence" that the redirected page may have run a malicious script against a flaw in Cross EX, a South Korean browser helper.

Kaspersky's SyncHole report identified at least six victims in the software, IT, financial, semiconductor manufacturing and telecommunications sectors.

Both victims ran HAProxy 2.8.12, released on November 8, 2024 per HAProxy's own release history. The implant reads HAProxy's internal structures at offsets fixed to that release, and Rapid7 does not say whether other 2.8 builds exist.

The current release on that branch is 2.8.28, from August 27, 2026, 16 point releases later. HAProxy's tracker lists 529 known bugs affecting 2.8.12 that are already fixed in the branch, including 1 critical and 16 major.

Upgrading does not clean a host the implant already sits on, because the attackers replace the binary rather than exploit a flaw in it.

Rapid7 recommended independent network correlation, memory behavioural analysis and binary integrity checks. The report publishes no detection rules for that last check, and a recompiled HAProxy reports the same version string as a clean build.

The development comes as AhnLab and ENKI WhiteHat documented a similar watering-hole campaign in July, in which state-sponsored operators abused compromised Korean websites to attack the AnySign4PC signing client.

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/AiY0VIs
via IFTTT