Possible SMTP Credentials Leak
Hello everyone,
Recently, I had two serious incidents where our SMTP credentials were used to send unauthorized emails. Even after rotating the credentials and reinforcing security measures, the issue happened again.
Current setup:
* Stack: PHP 8.3, Laravel Framework 11.44, Livewire 3.6.4, FilamentPHP 3.3.36
* Server: AWS Elastic Beanstalk (Linux + Nginx), application pointing to
/public
* Security measures:
* No .env file present on the server or in the repository
* Credentials configured directly in the EB environment
* Private GitHub repository, no credentials stored
* No dumps (dump(), var_dump(), etc.) or debug bar in production
* Access logs reviewed, no explicit credential exposure found
What I’ve done so far:
* Carefully reviewed Nginx access logs — found attempts to access .env and other common attack vectors (WordPress, Drupal, CodeIgniter, etc.), all returning 404.
* Removed any dependencies or configurations that could expose sensitive variables.
The problem:
Even with these precautions, someone recently managed to use new credentials. This suggests there is still some leak point or vulnerability that we haven’t identified yet.
My questions:
* Are there any known attack vectors in Laravel + Filament + Livewire that could expose environment variables, even without a .env file and with a properly configured server?
* Could any third-party extension/package (Laravel, Filament, or Livewire) inadvertently expose sensitive variables under certain conditions?
* Any extra precautions you recommend for this stack beyond the measures already taken?
Any ideas or insights would be greatly appreciated. 🙏16 Replies
Is debugging turned on in the production env?
No
Hmm, that’s the only think I can think of, ie a stacktrace, etc getting exposed to the front end on an exception.
Running on SSH terminal, AWS Linux
That should be fine. Don’t know of any open security issues in any of the frameworks specifically. Could be something in a 3rd party package though.
Does
composer audit show anything?I'm really clueless about what it could be. At first, I thought it was the use of .env on the private S3, where the file was downloaded and used directly in the project root during deployment. When the first issue occurred, I recreated the credentials and changed all the environment variables directly to the EB.
Even then, if the serving path is setup correctly to /public then an .env file still wouldn’t be accessible.
Yea. Really weird.
Exactly, but if by chance, access the files, there is no .env
Based on everything you’ve said my best guess is someone has access to the server, somehow.
Or they have access to your email server.
Actually, I don't know. I'm using AWS SES and will continue investigating to see if I find any vulnerabilities.
@awcodes Thank you very much for your time and your help
Sorry I don’t have a solid answer for you. Sounds like you’re doing everything correctly.
No problem, as soon as I discover or suspect something, I will inform you here in the group for your information.
I would appreciate that. Thank you.
Not sure how much it is or if you have the budget for it, but you might consider contracting Stephen, https://stephenreescarter.net/laravel-security-audits-and-pentesting/