We discovered a highly dangerous new attack vector in the Rspack repository. An attacker may reply to an issue claiming that they encountered a similar problem and provide a “reproduction” project, such as this example:
However, the reproduction project itself may contain malicious code. This means that if you use an AI agent to fix the issue, the agent may clone the project from the issue and execute it. For example, if the attack payload is hidden in an install or postinstall script of one of the project’s dependencies, the environment could be compromised as soon as the agent runs the install command. 🤡
Show more
This is a very clever architecture. We use a similar approach in Rspack by running CPU-bound tasks directly on Tokio. We don’t even need a separate I/O runtime, because the priority in compiler workloads is maximizing CPU utilization, not minimizing I/O latency.
One of the reasons we chose Tokio over Rayon is that Rspack exposes a large number of JavaScript hooks. These hooks are asynchronous and are frequently interleaved with CPU-bound work, so keeping everything on the same runtime greatly simplifies the execution model.
The discussion in is excellent. I’d also love to see Tokio provide more Rayon-like APIs (such as par_iter) to make scheduling CPU-bound workloads more ergonomic.
Show more
