Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

shawon_kamal's avatar

SMTP credentials getting exposed!

I recently had an issue with one of my laravel websites where the smtp credentials got stolen and used for spam. I realized it was due to the debug mode set to true in .env file. I turned that off and set the mode to production, however I am still having the same issue. I checked if my .env file is exposed to the public by setting example.com/.env but it is not. Does anyone have any suggestions? Thanks.

0 likes
11 replies
Sinnbeck's avatar

Any chance you want to share the site url?

Do you have any kinds of file upload on it? Images for instance

Did you change the password for smtp?

1 like
shawon_kamal's avatar

@Sinnbeck Thank you for the response. I think it is best if I don't share the url but yes I am using file upload on it. Validation only allows for images. What issue could arise from it?

And yes, I changed the password for smtp.

Sinnbeck's avatar

@shawon_kamal ok then hire a pen tester to find the security problem :)

My best idea is that you have some problem with your config of the site. But I don't know every single cve in my head. Or that your upload allows images with embedded Phar code and allows the user access to the output somehow. But these are just guesses based on no information

But perhaps concider using environment variables instead of an env file

1 like
jlrdw's avatar

Why are you using a .env file is production. If using, it needs to be out of web folders.

If this is shared hosting, put all of main laravel higher than webroot (out of).

If that's not possible point to public as document root. However if a host does not allow to move certain folders / files above web root, my suggestion is don't use that host.

Also see martinbean answer here https://laracasts.com/discuss/channels/laravel/where-to-keep-env-for-production-environment

https://laracasts.com/discuss/channels/laravel/security-question-for-env-file

1 like
shawon_kamal's avatar

@jlrdw Its not shared hosting. I am hosting it in AWS EC2, using apache and I am pointing to the public directory.

jlrdw's avatar

@shawon_kamal Still a .env file is not a secure file, it's meant for development. Somehow some credentials were read.

And even on AWS (just a server) laravel if not setup with the correct folder structure is insecure.

Did you read over the Deployment chapter.

Edit:

But of course setting debug to false on production was a good first step. Any credentials would need to be changed.

1 like
Snapey's avatar

@jlrdw using .env file in production should not lead to any issues as long as it is not in a public facing folder.

3 likes
shawnveltman's avatar
  1. You said that the .env file is not accessible via the web, which means that it's secure. Good stuff.

  2. You say " I turned that off and set the mode to production, however I am still having the same issue" - what is the issue? Is it still acting as if debug=true even though set it to false?

If that's the case, make sure you run php artisan optimize:clear

  1. If that's not it, then where/how are your credentials being exposed via the web? Without knowing that, there's nothing anybody here will be able to say to help you.
shawon_kamal's avatar

@shawnveltman I worded it poorly. I meant even after turning of debug mode and changing my smtp credentials, it got exposed again. I know that because the SMTP provider shut it down due to spam being sent from the account. None of the spams are sent from my server.

jomisacu's avatar
jomisacu
Best Answer
Level 1

It's impossible that .env files or env var was exposed, at least that you expose them explicitly in some way (print phpinfo or dump env vars in a test controller or putting it in public directory).

In the other hand, you must to change all AWS credentials (inclusive root) because you don't know where is the lack.

Tell about your deployment process, how do you put sensitive values in the server? How to create the .env file?

It will be good review the below:

  • check apache logs to see bad intentioned requests (if the values are exposed by http you could see the responsible requests here)
  • change all credentials
  • review security groups rules
1 like

Please or to participate in this conversation.