Laravel-Lang Compromise: Supply Chain Attack Delivers Cross-Platform Stealer
Just spotted a troubling report regarding a fresh software supply chain attack hitting the PHP ecosystem. It looks like several popular packages under the laravel-lang organization have been compromised to push a credential-stealing framework.
The affected packages include:
laravel-lang/langlaravel-lang/http-statuseslaravel-lang/attributeslaravel-lang/actions
According to researchers, attackers pushed malicious tags (around the May 2026 timeframe) containing a cross-platform stealer. Since these packages are often used for localization in Laravel apps, the blast radius could be significant. The campaign is being tracked as CVE-2026-28901 for the malicious artifact injection.
If you are running Laravel environments, you need to audit your dependencies immediately. The attackers managed to publish valid tags, so simple version constraints might not protect you if you aren't pinning strictly.
Here is a quick command to check your composer.lock file for these specific packages:
grep -E 'laravel-lang/(lang|http-statuses|attributes|actions)' composer.lock
I'm also recommending checking for unusual processes or outbound connections from your build agents, as the stealer appears designed to exfiltrate .env files and git credentials.
Has anyone seen indicators of compromise (IOCs) related to this in their SIEM yet? Specifically, looking for odd PHP user agents or connections to unknown IPs post-deployment?
Good catch on this. We use laravel-lang/lang in almost every project. I immediately froze our CI/CD pipelines.
For those using Dependabot or similar tools, don't rely solely on them right now; the compromised tags looked legitimate. I recommend verifying the integrity of your vendor/ directory. You can use this quick Python script to scan for the known malicious hashes if you have them:
import hashlib
import os
def scan_directory(path):
for root, dirs, files in os.walk(path):
for file in files:
if file.endswith('.php'):
# Add hash comparison logic here
pass
We are currently locking our composer files to commit hashes from before the breach dates.
This is exactly why we moved dependency installation to isolated, ephemeral containers.
From a SOC perspective, be on the lookout for the stealer's C2 traffic. It doesn't just hit HTTP ports; we've seen reports it tries to tunnel out over DNS in some variants to bypass firewalls. Check your DNS logs for long random subdomains resolving to suspicious IPs.
Oof. We just updated laravel-lang/attributes last week.
Running composer audit didn't flag it initially because the signature was valid (the maintainer's key was likely compromised). I had to manually downgrade using:
composer remove laravel-lang/attributes
composer require laravel-lang/attributes:v1.0.0 --prefer-dist
Always verify the commit hash on GitHub before running composer update on critical infrastructure.
Since composer audit failed here, manual integrity checks are vital. Without a clean backup to diff against, scan your vendor directory for common obfuscation patterns used in these stealers.
Run this grep to flag potential payloads in the affected packages:
grep -rn "eval\|base64_decode" vendor/laravel-lang/
If found, quarantine the host and rotate credentials. Given the cross-platform capability, pay close attention to `.env` file access logs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access