Attackers spent a month quietly reading developer machines.
They did not need a network breach. They needed one open port and a flag somebody typed for convenience.
For a month, F5's honeypot sensors watched a mass scanning campaign aimed at internet exposed Vite development servers, logging more than 800 attacks and roughly 32,000 raw events.
The targets were not production systems. They were the laptops and workstations where people write code.
The exposure was never clever. It was convenient, and convenience has never appeared in an asset inventory.
What the scanners were actually after
The campaign leaned on CVE-2026-39364, a high severity flaw affecting Vite versions 7.1.0 through 7.3.2 and the 8.x branch before 8.0.5.
An unauthenticated attacker could append a query parameter such as ?raw or ?import&raw to a request and read files that access controls were meant to protect, served back in plaintext with an HTTP 200 response.
The vulnerability itself is unremarkable. The file list is the part worth sitting with. The scanning used long wordlists aimed at:
- .env, .env.production and .env.local
- AWS credential files and credential backups
- Azure credentials and access tokens
- Terraform state and variable files
- Serverless configuration and state
- /proc/self/environ and /etc/passwd
None of that is source code. It is the material you need in order to become the application.
Vite already binds to localhost by default, so exposure is always a decision somebody made. The --host flag, a server.host value in the config, or a container port mapping that quietly publishes 5173 to the wider network.
The same actors also chained three older Vite access control flaws, including one CISA has already flagged as actively exploited, and used double encoded traversal paths to slip past proxies and web application firewalls that normalise requests differently from the server behind them.
Most of the traffic came from the United States, Belgium and the Netherlands, with Google Cloud address ranges used to blend into ordinary hosting traffic. The F5 Labs analysis of the Vite scanning campaign sets out the full request patterns and the wordlists in more detail than any summary can.
The toolchain answered before the ticket queue did
On 13 September, Homebrew shipped version 7.0.0, and its security section reads like a direct reply to the month before.
The headline addition is brew vulns, a built in vulnerability scanner that checks installed formulae against OSV.dev without requiring an extra tap or gem.
Homebrew now also publishes its own advisory database, recording vulnerabilities against the exact formula versions and revisions it ships, including fixes that were backported without changing an upstream version number. The records are in OSV format and released under CC0, so any other tool can reuse them for free.
But there is a smaller detail that ties the two stories together. Homebrew now blocks sandboxed reads of the home directory by default.
Think about which directory that is. It is the same one holding the .env files and the cloud credential files the Vite scanners were reaching for.
Two unconnected teams looked at the same folder in the same week and reached the same conclusion. A home directory is a secrets store, and nothing that installs software should be able to read it.
Homebrew is refreshingly honest about the limit here. Sandboxing mainly reduces accidental damage, and tap trust remains the real control for untrusted packages.
The release also brings BrewUI, the project's first official graphical interface, which makes package inventory visible without opening a terminal. You can read the Homebrew 7.0.0 release notes for the full list of security fixes.
Three changes worth making this week
- Find the dev servers you exposed on purpose. The default is localhost, so every exposed server is a deliberate change somebody can point to. Search your repositories for the --host flag, server.host values and published container ports, then bind development servers to 127.0.0.1 and block the port at the edge. F5 also recommends rejecting suspicious /@fs/ requests instead of trusting crawler user agent strings, which is really a request validation problem and belongs in the same review as the rest of your surface, as our request validation and API security assessment walks through.
- Treat the credentials in that directory as already gone. If a server was exposed, patch it and rotate everything it could reach, and do not stop at the .env file. The wordlists reached into cloud credential files, Terraform state and serverless state. Then shorten the life of whatever you put back, because a narrowly scoped credential that rotates turns a month of quiet reading into a wasted month. Teams rebuilding that baseline often start with where secrets physically live and how file permissions and process environments behave, which is exactly what the Linux fundamentals course covers.
- Let the toolchain produce the inventory. brew vulns is a small command with a large implication, because the package manager now emits structured security data about the machine it runs on, in a format other tools can consume. Feed that output, and the CC0 advisory data behind it, into the same pipeline that builds your software, and treat the result as a source of truth rather than a report. If your cloud credentials are the blast radius you care about, the cloud security skill check is a fast way to find the gaps in that thinking.
The short version
The old assumption was that the perimeter was the network and developer machines were a convenience.
The new reality is that the credentials reaching production now sit in home directories on those machines, and the scanners found them long before anyone wrote them down.
We have already argued that attackers are breaking in through the tools that ship your software. This is the same shift seen from the laptop outward, and it is why a package manager quietly shipping a scanner matters more than it looks.
The part I cannot work out from the outside is the decision itself. Somewhere, a development server got moved onto the network because a phone needed to load a page, or because a colleague was working from another building.
So I am genuinely curious how other teams handle that moment. Who gets to make that call, and where does it get written down?