Supply Chain Alert: Cross-Platform RAT via Fake Laravel Packages
Hey everyone, just caught a report about a nasty supply chain attack targeting the PHP/Laravel ecosystem. Researchers identified three malicious packages on Packagist masquerading as legitimate Laravel utilities.
The packages in question are:
nhattuanbl/lara-helpernhattuanbl/simple-queuenhattuanbl/lara-swagger
While the download counts are relatively low so far, the payload is a fully functional Remote Access Trojan (RAT) capable of running on Windows, macOS, and Linux. This makes it particularly dangerous for CI/CD pipelines that might run on varied infrastructure. No CVE has been assigned yet, but the impact is immediate.
I've whipped up a quick Python script to scan your composer.lock files if you manage multiple projects:
import
import sys
malicious_pkgs = [
"nhattuanbl/lara-helper",
"nhattuanbl/simple-queue",
"nhattuanbl/lara-swagger"
]
try:
with open('composer.lock', 'r') as f:
data = .load(f)
for pkg in data['packages']:
if pkg['name'] in malicious_pkgs:
print(f"[!] MALICIOUS PACKAGE FOUND: {pkg['name']}")
sys.exit(1)
print("[+] No malicious packages detected.")
except FileNotFoundError:
print("composer.lock not found.")
The prompt for discussion is: Beyond static analysis, how are you guys validating the integrity of open-source dependencies in your build pipelines? Are you relying on composer audit, or do you have stricter private registry requirements?
Solid catch. We actually block execution of unsigned binaries in our build environments, which would stop the RAT payload even if the package made it through.
For detection, I'd recommend running a simple grep if you don't want to run the Python script:
grep -E "nhattuanbl/(lara-helper|simple-queue|lara-swagger)" composer.lock
It's crude but effective for an immediate IOC sweep across your fleet.
This is exactly why we shifted to using a private Packagist proxy (Satis). We whitelist specific packages and versions; anything else doesn't even resolve for our devs.
For those who can't do that, enabling composer audit in your CI/CD pipeline is the bare minimum now. It won't catch zero-days like this immediately, but it reduces the attack surface significantly.
Interesting that it's cross-platform. Usually, these PHP droppers just target Windows via PowerShell. If this is hitting Linux/macOS too, they're likely embedding a Go or Rust binary in the package.
If you're investigating, check the vendor/ directory for any non-PHP files immediately after a composer install. A Laravel helper package shouldn't contain a compiled binary.
The cross-platform nature strongly suggests a Go or Rust binary packed inside the package. To quickly audit an existing environment for similar threats, check your vendor directory for unexpected binaries. A pure PHP library shouldn't contain executables.
Run this command to hunt for anomalies:
find vendor/ -type f -executable -o -name "*.dll" -o -name "*.so"
Finding executables there usually indicates a supply chain compromise. Has anyone analyzed if the payload is executed immediately upon composer install via scripts?
Expanding on Omar’s suggestion for auditing, enforcing strict file-type checks in CI/CD is vital. Standard libraries shouldn't contain executables. You can quickly scan for anomalies in your environment with:
find ./vendor -type f -executable
If that returns anything, you definitely have a problem.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access