Exposed Vite servers are being probed for AWS and Azure credentials

PHPUnit ships a utility script (eval-stdin.php under /vendor/phpunit/phpunit/src/Util/PHP/) that reads HTTP POST data and evaluates it as PHP code with no authentication. The flaw is triggered when a site's /vendor folder is web-accessible and an attacker sends a POST request whose body begins with '<?php ' directly to that URI. Doing so lets the attacker execute arbitrary PHP code on the server under the web server account, giving unauthenticated remote code execution (CWE-94 code injection). Anyone running a PHP application installed with Composer, where PHPUnit is present in the vendor tree and that directory is reachable over HTTP, is affected. The flaw is under active exploitation: CISA added it to the Known Exploited Vulnerabilities catalog on 2022-02-15 and its EPSS probability of exploitation is 100% (top percentile).

Do: Apply the CISA KEV required action by updating PHPUnit per vendor instructions, which in practice means updating the CMS/framework or running a Composer update that pulls a patched PHPUnit release. Until patched, block web access to the /vendor directory (e.g., deny /vendor/ or at least /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php in your web server configuration) and verify the endpoint is no longer reachable. Check access logs for POST requests to eval-stdin.php and investigate affected servers for webshells or other signs of compromise.

In WordPress 4.9.7, plugins uploaded via the admin area are not verified as being ZIP files. This allows for PHP files to be uploaded. Once a PHP file is uploaded, the plugin extraction fails, but the PHP file remains in a predictable wp-content/uploads location, allowing for an attacker to then execute the file. This represents a security risk in limited scenarios where an attacker (who does have the required capabilities for plugin uploads) cannot simply place arbitrary PHP code into a valid plugin ZIP file and upload that plugin, because a machine's wp-content/plugins directory permissions were set up to block all new plugins.

NoneCms V1.3, an open-source Chinese CMS built on the ThinkPHP 5.0.x framework, is vulnerable to unauthenticated remote code execution through the framework's URL dispatcher in thinkphp/library/think/App.php. Because the framework's 's' routing parameter can invoke arbitrary framework classes and methods, an attacker can pass a crafted 'filter' value (e.g., s=index/\think\Request/input&filter=phpinfo&data=1) that is applied to the 'data' argument as a callable, executing attacker-chosen PHP functions or code. Successful exploitation gives full code execution on the web server under the application's privileges, enabling web shells, botnet implants, and ransomware staging without any credentials or user interaction. Any internet-facing deployment of noneCms V1.3 — and, more broadly, applications running the affected ThinkPHP 5.0.x framework (the public PoC references 5.0.23) — is exposed. Exploitation is confirmed in the wild: the flaw is on CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03), EPSS assigns a 99.5% probability of exploitation within 30 days, and headlines note botnets such as Enemybot and Chinese threat actors chaining ThinkPHP RCEs against CMS servers.

Do: Apply updates per vendor instructions: upgrade noneCms to the latest release and update the bundled ThinkPHP 5.0.x framework to a patched build. Inspect web server and WAF logs for requests using the s=index/\think\Request/input&filter=... pattern and other ThinkPHP route-invocation payloads, and hunt for web shells or post-exploitation artifacts. Until patched, block or strictly validate the 's' and 'filter' query parameters at a WAF/reverse proxy and limit internet exposure of the application.

Vite a frontend build tooling framework for javascript. In affected versions the contents of arbitrary files can be returned to the browser. `@fs` denies access to files outside of Vite serving allow list. Adding `?import&raw` to the URL bypasses this limitation and returns the file content if it exists. This issue has been patched in versions 5.4.6, 5.3.6, 5.2.14, 4.5.5, and 3.2.11. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Vite dev servers in versions prior to 6.2.3, 6.1.2, 6.0.12, 5.4.15, and 4.5.10 fail to enforce the `@fs` file-access allow list because trailing separators such as `?` are stripped in several places but are not accounted for in the query-string regexes. A remote, unauthenticated attacker triggers the flaw by appending `?raw??` or `?import&raw??` to a dev-server URL, bypassing the restriction and returning the contents of arbitrary files on the host if they exist. The impact is confidentiality only — arbitrary file read with no code execution or privilege escalation, consistent with the CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Only projects that explicitly expose the Vite dev server to the network (via `--host` or the `server.host` config option) are affected; purely local development usage is not remotely exploitable. A public proof of concept is available in the GitHub advisory (GHSA-x574-m823-4x7w); the flaw is not yet in CISA KEV, but EPSS assigns a 75% probability of exploitation within 30 days (99th percentile), so opportunistic scanning is likely.

Do: Upgrade Vite to 6.2.3, 6.1.2, 6.0.12, 5.4.15, or 4.5.10 depending on your release branch. If you cannot upgrade immediately, stop exposing the dev server to untrusted networks (remove `--host` / set `server.host` to localhost) or firewall the dev-server port. Audit internet-facing hosts for running Vite dev servers and check access logs for requests containing `?raw??` or `?import&raw??`, which may indicate exploitation attempts.

CVE-2025-31125 is an improper access control flaw (CWE-284/CWE-200) in the Vite JavaScript frontend tooling's dev server, where HTTP requests using the '?inline&import' or '?raw?import' query parameters can read the contents of files the dev server should not serve, bypassing its file-access restrictions (server.fs.deny). An unauthenticated remote attacker (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) triggers it by sending crafted requests with these query parameters to a running Vite dev server. The attacker gains read access to arbitrary files on the machine running the dev server, such as source code and .env files containing secrets, with high confidentiality impact and no integrity or availability impact. Only applications that explicitly expose the Vite dev server to the network via the --host flag or the server.host option are affected; production builds are not impacted. The flaw is being actively exploited: CISA added it to the Known Exploited Vulnerabilities catalog on 2026-01-22 (ransomware association unknown), and EPSS assigns a 58.5% probability of exploitation within 30 days (99th percentile).

Do: Upgrade Vite to 6.2.4, 6.1.3, 6.0.13, 5.4.16, or 4.5.11 depending on your release line. Until patched, do not expose the dev server to untrusted networks (remove --host/server.host or bind to localhost behind an access-controlled proxy), and review access logs for requests using ?inline&import or ?raw?import that retrieved sensitive files such as .env. As a KEV entry added 2026-01-22, U.S. federal agencies must apply vendor mitigations per BOD 22-01 or discontinue use if mitigations are unavailable.

Vite is a frontend tooling framework for JavaScript. From 7.1.0 to before 7.3.2 and 8.0.5, on the Vite dev server, files that should be blocked by server.fs.deny (e.g., .env, *.crt) can be retrieved with HTTP 200 responses when query parameters such as ?raw, ?import&raw, or ?import&url&inline are appended. This vulnerability is fixed in 7.3.2 and 8.0.5.