x.com/AikidoSecurity/status/2057958510445658144?s=20
1 correction found
If you installed a compromised version, the malware already executed.
This is too absolute. The malicious `helpers.php` was wired into Composer's `autoload.files`, so it executes when `vendor/autoload.php` runs during application/runtime bootstrapping — not merely because the package files were downloaded.
Full reasoning
Composer’s own documentation says autoload.files entries are loaded when vendor/autoload.php is included. It does not say they execute simply because a package was installed. In this incident, the malicious src/helpers.php was added to autoload.files, and security writeups describe execution as happening during normal application runtime / when the Composer autoloader runs.
So the post’s wording overstates certainty: installing a compromised package was not, by itself, universal proof that the payload had already run. A project that downloaded the poisoned package but had not yet bootstrapped Composer’s autoloader would not have hit this specific autoload.files trigger yet. Many real-world Laravel workflows would execute it soon afterward, but installed and already executed are not equivalent here.
3 sources
- The composer.json schema - Composer
Files autoload rules are included whenever vendor/autoload.php is included, right after the autoloader is registered.
- Basic usage - Composer
For libraries that specify autoload information, Composer generates a vendor/autoload.php file. You can include this file and start using the classes that those libraries provide.
- Embedded Malicious Code in laravel-lang/lang | Snyk
The malicious commits introduced a src/helpers.php file that was added to autoload.files in composer.json, causing the code to execute automatically during normal application runtime whenever Composer's autoloader runs.