Malicious Laravel Packagist Packages Deliver a Cross‑Platform RAT—How to Detect and Stop Them

In a disturbing trend, researchers have uncovered several supposedly harmless Laravel utilities on Packagist that are, in fact, malicious payloads. Three packages—nhattuanbl/lara-helper (37 downloads), nhattuanbl/simple-queue (29 downloads), and nhattuanbl/lara-swagger (49 downloads)—have been confirmed to inject a Remote Access Trojan (RAT) capable of operating on Windows, macOS, and Linux. When these packages are added to a project with Composer, they silently download and execute a hidden executable, giving an attacker full control over the target machine.

The RAT is triggered through a tiny PHP script that runs during Composer’s autoload phase. That process appears innocuous: a helper function, a queue driver, or a Swagger integration. In reality, it pulls a binary from a remote server and launches it, establishing a persistent reverse shell to the attacker’s command‑and‑control infrastructure. Once active, the malware can exfiltrate data, tamper with files, or pivot to other hosts on the network.

Because the packages are hosted on the legitimate Packagist registry, many developers are unwittingly exposing their codebases—and their systems—to this threat. This incident underscores that reputation alone is not a guarantee of safety for open‑source libraries, especially those that perform privileged operations like code generation or system interaction.

Practical Countermeasures

• Always inspect a package’s source code and commit history before adding it to a project. Look for suspicious network calls, binary downloads, or obfuscated code.
• Pin dependencies in composer.lock and never rely on ^ or ~ version constraints for critical libraries. Use exact versions and periodically audit the lockfile for changes.
• Use Composer’s --no-autoloader flag during the first installation and load the autoloader manually after verifying the package contents.
• Run security scanners such as or packagist-php-vulnerabilities on your vendor directory, and consider static analysis with tools like Psalm or PHPStan to catch malicious constructs.
• Implement pull request reviews for every dependency addition. A colleague should check the package’s docblock, README, and any scripts that execute during install.
• Enable monitoring on your production hosts to detect unexpected outbound connections, especially to unfamiliar IPs. Use host‑based intrusion detection tools like OSSEC or Wazuh to flag malicious binaries.

Takeaways

• Open‑source dependency management requires vigilance; the presence of a package on Packagist does not imply safety.
• Malware can be delivered via code that runs during Composer’s normal workflow—cannot be solely relied upon on the maintainers’ platform.
• Regular auditing of your composer.json and composer.lock, coupled with static analysis and network monitoring, forms a layered defense against supply‑chain attacks.