A Next.js project sent to a freelancer by a supposed Fiverr client included an npm token that allowed a private dependency invisible in the public registry to be downloaded. The code activated later, when the developer started the development server: a Tailwind configuration loaded a plugin, which then required the hidden package within the Node.js process.
The developer who described the case on DEV Community did not run the project on their computer. They examined it in an isolated, read-only environment and reported the package to npm. The maneuver did not rely on an overtly malicious installer or code that was obviously obfuscated. Its decisive component was an .npmrc token, included with the project and capable of granting access to a package that returned a 404 error to anyone without credentials.
The scope extends beyond that assignment: Corgea documented a campaign involving public packages that imitated Animate.css plugins for Tailwind, while pkgwarden described a network of 29 packages and a job assessment repository prepared to deliver the token. The reports do not present exactly the same inventory or the same date of verification; together, they show a tactic that adapted after takedowns.
A chain that waited for the development server
In the project received by the freelancer, the frontend/package.json file declared tailwind-animationlab as a development dependency. The plugin had been published on npm on September 28, the same date on which, according to the DEV Community post, the Tailwind configuration was last modified. No application component used its classes: it was enough for Tailwind to load it.
Inside the plugin, src/motion.js required @jasperquinn/postcss-motion-helpers. That package was not publicly available. However, the frontend/.npmrc file contained an npm access token. When installing dependencies, npm could use it to download the private package; then, when running npm run dev, Next.js loaded the Tailwind configuration, which in turn loaded the plugin and its dependency.
The sequence matters: downloading the package and running its code were separate events. Corgea and pkgwarden explain that the versions they examined did not need installation scripts; the code was loaded when the server or build process read the configuration. That is why the --ignore-scripts option would not have stopped this chain: it prevented lifecycle scripts from running, but did not stop the configuration from requiring the plugin at startup.
flowchart TD A["Proyecto con .npmrc"] --> B["npm install usa el token"] B --> C["Descarga el paquete privado"] C --> D["npm run dev inicia Next.js"] D --> E["Tailwind carga su configuración"] E --> F["El plugin requiere el paquete oculto"] F --> G["Código dentro del proceso Node.js"]
The chain explains why a review limited to the application code might find nothing. The freelancer said the backend, MongoDB models, Gemini calls, and components all appeared clean. The dangerous dependency came from outside the code visible in those files and ran when the configuration was loaded.
A job offer as a delivery mechanism
The Fiverr assignment had signs that, taken together, were suspicious: it included no screenshots or logs of the errors that supposedly needed fixing, the first file was a presentation for internal and investor review, and the code arrived in a ZIP shared through Google Drive, not from a GitHub repository. In addition, the README described a React application with Vite and Clerk, while the project contained Next.js 16 and a JWT-based login. Even so, the instructions repeatedly said to install and start the application.
Pkgwarden documented another version of the lure: a technical assessment attributed to “Nodveta,” posted on Torre.ai, that led to a private GitHub repository. There, the web/.npmrc file stored the token, and the project included files aimed at coding agents. According to pkgwarden, AGENTS.md and CLAUDE.md instructed the agent to consult documentation inside node_modules, pushing it to install dependencies. The target, therefore, could be either the candidate or the agent working in their environment.
The resemblance between the assignment described on DEV Community and the fake-interview pattern identified by pkgwarden does not prove who was behind the Fiverr case. The author of the post explicitly said they could not attribute the campaign to an actor. Pkgwarden also avoided attributing it to a group and described it as consistent with the method known as “Contagious Interview.”
Fast takedowns, replacements, and differing figures
According to the DEV Community timeline, the author reported tailwind-animationlab to npm on October 29, around midday in Sri Lanka. That night, npm replaced that package and tailwind-keyframes with security versions, and removed the private helper @jasperquinn/postcss-motion-helpers. A few hours later, another private helper appeared; npm removed it too on October 30. GitHub Trust & Safety told the author that “one or more violations of npm's Open-source Terms have occurred.”
one or more violations of npm's Open-source Terms have occurred
— GitHub Trust & Safety
The takedown did not stop the activity. On November 2, the DEV Community author found version 2.0.10 of tailwind-kinetics, which depended on a different helper, as well as two other private packages that could not be seen in the public registry. In its October 30 update, Corgea also recorded a switch to new private scopes and public packages published or updated after npm's initial actions.
The counts depend on the scope and timing of each investigation. DEV Community identified at least 19 additional packages with code based on the same template, beyond those described in its case. Corgea expanded its inventory to 43 public packages and seven private dependencies associated with the pattern. Pkgwarden, by contrast, tracked a cluster of 29 plugins and 40 versions, and noted that 26 of those packages were still installable on October 16. These figures are not interchangeable: the posts cover different dates, packages, and subgroups.
What could be verified about the payload also varied. The public packages examined by Corgea and pkgwarden appeared to be functional plugins and contained neither installation scripts nor obfuscated code; the private component was the one that could not be inspected through the public registry. When evaluating [email protected], LPM Firewall said the available code showed a CSS generation path, but the behavior of the imported helper remained unresolved because its code was unavailable. Therefore, the reports describe a chain designed to load hidden code; they do not verify what specific actions that code performed on the computer.
The cost of trusting someone else's project
The situation is especially delicate for people taking freelance jobs or technical assessments. To evaluate the assignment, they need to run an application they do not control; here, doing so on their usual computer would have given the code the same access to files as the user had. The DEV Community author warned that similar campaigns had sought saved passwords, API tokens, and cryptocurrency wallets, but did not claim to have observed those actions in this case's private payload.
For companies, the risk also extends to development environments and coding agents. Pkgwarden noted that the documentation added to the repository was intended to steer AI tools toward installing and starting the application. An agent with access to a candidate's environment does not make a dubious repository trustworthy: it may follow instructions that trigger the same payload a person would run.
The pattern creates a practical tension: controls focused on installation scripts do not cover code that runs when a tool loads a configuration. Nor is it enough for the public package to appear small, functional, and readable if it depends on a private package that external analysis cannot retrieve. In this case, authenticated installation concealed the relationship between the two components, and starting Next.js completed the execution.
The author of the case avoided installing the project on their computer and used an isolated environment to read the files without running commands. DEV Community recommended carefully reviewing configuration files loaded during development, treating a token in a .npmrc received with someone else's project as a warning sign, and checking unfamiliar dependencies. For anyone who had already run an affected assessment, pkgwarden advised treating the computer as compromised and rotating any credentials it could access.
The point of control was not a visible application feature or an installer that ran immediately: it was the combination of a credential included in the project, a private package inaccessible to third parties, and a configuration that loaded it at startup.
Sources: DEV Community, Corgea, pkgwarden, LPM Firewall
