Thanks for the report. Apache under Windows is always thread safe, mod_winnt. Since you're doing a sub request to another file  - the request will be served in another thread, but still in the same process. putenv() modifies the environment of the whole process. At the end of the first request, the environment will be reset. But since the first request is still running, while the sub request is issued - the environment is not yet cleared.

Furthermore - it is no difference on Linux, putenv() is not thread safe. Were you using a thread safe Apache module like mpm_worker while testing? Generally, any NTS SAPI will be safe in this regard, and any TS SAPI will have this issue as long as we rely on the C runtime (and i guess that won't change).

If you need to use such mechanics in your programs, it would make full sense to choose some NTS SAPI. So I'd tend to mark this ticket as won't fix therefore.

Thanks.

Hello, 
Yes, on windows I have mpm_winnt, on linux = prefork. Not sure if it works with mpm=worker.

I don't need such feature in our program, problem is that frameworks are currently starting to use .env files which pushes sensitive information to environment variables. This includes Laravel and Lumen frameworks, at least. 

This means that in some situations, on shared hostings, you can get access to information about other client's database. 

However, I understand your point. I think it is needed to at least put information about this behaviour to documentation.

Usually Linux distros deliver NTS builds based on mpm_prefork, that's what I assumed you were using for the tests. Still several people work with TS builds, though in most cases they build them manually.

I haven't worked with Laravel, but it seems that it's being done there for years already https://laracasts.com/forum/?p=460-env-variables-in-shared-hosting-like-hostgator/0 . As for me, it is quite a sub optimal design approach and actually i'm really surprise it's about some framework aiming web :)

Normally hosters would disable the functions they don't support or that are dangerous. There are many places that can potentially be seen as such in the shared hosting environment. 

With documentation - yep, probably this should be documented better. If there are no other comments, I'm going to set the status to "documentation issue" and open the ticket at least for the educational purposes.

Thanks.

Ok, so as it turns out with a member of the Laravel team, with the cached configuration only the first request will be sensitive to this issue. putenv is still not safe in other aspects, but it is out of the scope here. These impacts should be better documented based on the info from this ticket, given it is now open. 

Thanks

It is enough that there will be information in documentation about that.

Thank you! :)