Malicious Laravel packages on Packagist deploy PHP RAT and give attackers remote access

A new software supply chain campaign is targeting PHP and Laravel developers through malicious packages published on Packagist. Socket says three packages tied to the nhattuanbl account were designed to install or pull in an encrypted PHP remote access trojan, giving the attacker persistent access to affected Windows, macOS, and Linux systems.

The most important detail is that not every package looked obviously malicious. Socket says nhattuanbl/lara-helper and nhattuanbl/simple-queue directly contained the RAT in src/helper.php, while nhattuanbl/lara-swagger looked clean but declared nhattuanbl/lara-helper as a Composer dependency, which meant installing it silently pulled in the payload. Packagist’s own package page for lara-swagger currently shows that dependency on nhattuanbl/lara-helper: dev-master, which supports Socket’s finding.

That dependency choice matters because dev-master is a moving target. Socket says it always pulls the latest commit from the default branch, so an attacker can update the malicious payload without changing the clean-looking carrier package itself. That makes review harder and raises the risk for teams that allow unpinned development branches in production workflows.

Socket also says the Packagist account behind the campaign dates back to December 2015, but the six relevant packages were published between June and December 2024. Three were clean and likely helped build credibility first, while the RAT-carrying packages appeared later. That sequencing suggests the attacker wanted developers to see a normal-looking package history before the malicious packages arrived.

What the malicious packages do

According to Socket, once the payload loads, it connects to helper[.]leuleu[.]net on port 2096, sends system reconnaissance data, and waits for commands from the operator. The reported capabilities include remote shell execution, file upload and download, screenshot capture, and ongoing system profiling. Socket says the malware communicates over an encrypted C2 channel and retries the connection every 15 seconds.

That makes the impact much bigger than a bad dependency warning. If the infected package runs inside a Laravel app, the RAT runs in the same process and with the same permissions as the application itself. Socket says that means attackers may be able to access .env contents, database credentials, API keys, and any files the web app can reach.

Confirmed malicious packages

Socket also identified three additional packages by the same publisher that appeared clean in its review: nhattuanbl/lara-media, nhattuanbl/snooze, and nhattuanbl/syslog. The clean packages appear to have helped the author look legitimate before the RAT-bearing packages were introduced.

Why this attack is hard to spot

Socket says the payload in helper.php used multiple layers of obfuscation. Those included heavy control-flow distortion, encoded strings for domains and commands, and randomized identifiers for variables and functions. In plain terms, the code was built to resist quick visual review and frustrate static analysis.

The activation method also depends on how the package is used. Socket says lara-helper registers through Laravel’s Composer auto-discovery and loads on application boot, while simple-queue can trigger at file scope when PHP autoloads the class. That means a compromised app may show no visible errors while the RAT starts quietly in the background.

Current status of the packages

At the time Socket published its March 3 report, the company said it had submitted takedown requests and that the packages were still live. As of the latest Packagist result I checked, nhattuanbl/lara-swagger remained publicly listed, with 49 installs shown on the package page. I did not independently confirm the live status of every malicious package page, so the safest wording is that at least some of the related packages were still publicly visible when the reporting was published and at least one remained indexed afterward.

One other limitation is worth noting. Packagist’s public security advisory system aggregates advisories from sources such as GitHub Security Advisories and FriendsOfPHP, but the lara-swagger package page still showed “Advisories: 0” in the indexed result I found. That suggests this case was being tracked through external research before it showed up as a standard Packagist advisory entry.

What developers should do right now

• Remove nhattuanbl/lara-helper, nhattuanbl/simple-queue, and nhattuanbl/lara-swagger from affected projects immediately.
• Assume the affected host is compromised if any of those packages were installed.
• Rotate all secrets the app could access, including .env values, database passwords, cloud keys, and API tokens.
• Check outbound traffic for attempts to reach helper[.]leuleu[.]net:2096.
• Review composer.json and composer.lock for transitive pulls from suspicious packages, especially any use of dev-master.
• Add dependency scanning to CI. Packagist’s own ecosystem supports security monitoring through advisory feeds and monitoring services, though this case shows that malicious packages can appear before standard advisory coverage catches up.

Why this matters beyond Laravel

This is not just a Laravel story. It is another example of attackers using trusted open-source workflows to place malware where developers expect convenience libraries. Because Composer resolves dependencies automatically, a package that looks clean on first inspection can still install malicious code through a transitive dependency. That is the same trust gap attackers keep exploiting across npm, PyPI, and now Packagist.

FAQ