PHP Supply Chain Attack: Backdoor Discovered in Popular Composer Package

A supply chain attack targeting the PHP ecosystem has been discovered this week. Security researchers found a backdoor embedded in a popular Composer package that was downloaded over 100,000 times before discovery. The malicious code was introduced through a compromised maintainer account and remained undetected for approximately three months. This incident highlights the growing threat of supply chain attacks (2026 WordPress Security Threats report) in the PHP ecosystem and the importance of dependency auditing for all WordPress sites that use Composer.

PHP supply chain attack wordpress plugins: Understanding Supply Chain Attacks in the PHP Ecosystem

A supply chain attack targets the software development and distribution pipeline rather than the end application directly. Instead of finding a vulnerability in WordPress itself, attackers compromise a legitimate dependency that WordPress sites rely on. When site owners update their dependencies through normal workflows, they unknowingly pull in the malicious code.

These attacks are particularly dangerous because the malicious code comes from a trusted source. The compromised package is signed by the legitimate maintainer, hosted on the official Packagist repository, and distributed through the standard composer install and composer update commands. There is no obvious warning sign for site owners who are not specifically auditing their dependencies.

The PHP ecosystem has seen an increase in supply chain attacks over the past few years. Attackers target Composer packages because PHP powers approximately 76% of the web, and the Composer dependency manager is used by millions of projects including WordPress sites running on Bedrock, Laravel applications, and custom PHP frameworks. A single compromised package can affect thousands of downstream sites.

PHP supply chain attack wordpress plugins: How Packagist and Composer Work

Packagist is the default package repository for Composer, the PHP dependency manager. When you run composer require vendor/package, Composer queries the Packagist API, downloads the package metadata, and installs the specified version from a Git repository or distribution zip file. Packages on Packagist are maintained by individual developers or organizations who have the ability to push new versions.

The trust model relies on maintainer account security. If an attacker gains access to a maintainer’s Packagist account through phishing, credential theft, or session hijacking, they can push malicious versions of trusted packages. Packagist does not require code review or automated security scanning before new versions are published. The maintainer’s word is the only gatekeeper.

In this attack, the compromised maintainer account belonged to a developer with push access to a widely-used utility package. The attacker waited for a period of dormancy in the package’s development, then pushed a new version that included obfuscated backdoor code alongside legitimate bug fixes and feature updates.

Technical Details of the Backdoor

The backdoor discovered in this attack was hidden inside an obfuscated configuration file that executed PHP code on every request. The malicious code used several techniques to avoid detection:

• Obfuscation: The payload was encoded using multiple layers of base64 encoding, gzip compression, and PHP’s eval() function. The obfuscated code appeared to be legitimate configuration data unless decoded and examined.
• Conditional execution: The backdoor only activated under specific conditions such as a particular HTTP header being present or the request originating from a specific IP range. This made it difficult to detect through automated scanning because the malicious behavior was not visible under normal traffic.
• Data exfiltration: Once activated, the code collected environment variables, database credentials from wp-config.php and similar configuration files, API keys, and authentication salts. The stolen data was sent to an external server via HTTP POST requests disguised as analytics traffic.
• Persistence: The backdoor created a self-renewing cron-like mechanism within PHP that re-infected the site even if the original malicious file was removed, by writing copies to other writable directories.

WordPress sites that use Composer for dependency management were particularly vulnerable. Bedrock-based WordPress installations and custom setups that manage all dependencies through composer.json were affected because the injected code could read wp-config.php and the WordPress database configuration directly from the environment. The backdoor specifically targeted common WordPress constants like DB_NAME, DB_USER, DB_PASSWORD, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY.

Impact on WordPress Sites

For WordPress sites running on Composer-managed stacks, this backdoor posed a severe threat. The attacker gained access to:

• Database credentials: Full read and write access to the WordPress database, including all user data, posts, WooCommerce orders, and configuration settings.
• Authentication salts and keys: With access to the WordPress salts, the attacker could forge authentication cookies and bypass login entirely.
• API keys: Any third-party service API keys stored in wp-config.php or environment files, including payment gateway keys, email service keys, and CDN credentials.
• File system access: The PHP execution context allowed the backdoor to read, write, and execute arbitrary files on the server, enabling complete server compromise in some configurations.

Detection and Auditing Methods

Detecting supply chain compromises requires proactive auditing of your dependencies. Here are the key methods for identifying compromised packages:

Audit composer.lock for Unexpected Dependencies

The composer.lock file is your most valuable tool for supply chain auditing. It contains the exact version of every installed package along with its hash and source URL. Run this command to review your dependencies:

# Show all direct dependencies
composer show --tree

# Show all packages with their versions
composer show --latest

# Check for known security vulnerabilities
composer audit

Look for packages that seem unfamiliar, packages with unusual version numbers that do not follow semantic versioning, and packages from unknown or suspicious sources. The composer audit command checks installed packages against the FriendsOfPHP/security-advisories database, which catalogues known vulnerabilities.

Compare composer.lock Checksums

If you have a known-good backup of composer.lock, compare the checksums and hashes to detect unexpected changes. Use diff to compare lock files:

diff known-good.lock current.lock

# Or check for unexpected package additions
cat current.lock | jq '.packages[] | .name' | sort > packages_current.txt
cat known-good.lock | jq '.packages[] | .name' | sort > packages_known.txt
diff packages_known.txt packages_current.txt

File Integrity Checking

Scan your vendor directory for unexpected file modifications. Look for files that contain eval(), base64_decode(), or system() calls outside of legitimate libraries:

# Find files with suspicious PHP functions in vendor directory
grep -r 'base64_decode' vendor/ | grep -v 'test' | grep -v 'Test'
grep -r 'eval(' vendor/ | grep -v 'test' | grep -v 'Test'

Immediate Actions for WordPress Site Owners

If you manage WordPress sites with Composer, take these steps immediately:

• Run composer update: Update all packages to the latest versions and check for any security advisories with composer audit.
• Review composer.lock: Look for any packages you do not recognize or that have been added without your knowledge.
• Scan with a file integrity checker: Use Trusti Security’s Core Integrity Scanner or a similar tool to detect unauthorized file changes.
• Rotate all credentials: Change database passwords, API keys, authentication salts, and any other secrets stored in environment files or wp-config.php. Assume they may have been compromised.
• Enable outbound traffic monitoring: Use Trusti Security’s Firewall module or a web application firewall that can detect and block data exfiltration attempts to unknown external servers.
• Pin specific versions: Consider pinning your dependencies to specific known-good versions rather than using version ranges in composer.json. This prevents automatic updates from introducing compromised code.

Long-Term Prevention Strategies

Supply chain attacks are becoming more common across all ecosystems including PHP, JavaScript (npm), Python (PyPI), and Ruby (RubyGems). To protect your WordPress site long term:

• Lock your dependencies: Always commit composer.lock to version control and use exact version pins in composer.json for production deployments.
• Audit regularly: Schedule monthly reviews of your dependencies, checking for abandoned packages, new maintainers, and suspicious version bumps.
• Use mirrors with security scanning: Consider using a private Composer mirror that scans packages for malicious code before serving them to your build pipeline.
• Monitor for unusual outbound traffic: Set up alerts for unexpected outbound connections from your web server, especially to unrecognized IP addresses or domains.

Trusti Security’s Core Integrity Scanner verifies WordPress core files against official checksums. While it does not scan PHP vendor directories directly, its Activity Logging module tracks file modifications and can alert you when files in sensitive directories change unexpectedly. Combined with the Firewall module’s outbound request monitoring, you have a better chance of detecting supply chain attacks early.

This incident is a reminder that supply chain attacks are becoming more common across all ecosystems. Verify your dependencies, pin specific versions in composer.lock, and never trust package updates without reviewing what changed. The PHP ecosystem’s reliance on community-maintained packages means that everyone shares responsibility for security. Stay informed, stay vigilant, and keep your dependencies up to date through controlled, audited processes rather than blind automatic updates.