I'm not much of a sysadmin but this intimidates me. I've always known that allowing PHP/.htaccess uploads are dangerous, if not fatal, and have done everything I know how to prevent them.
Oh, and if you've never thought about this before, odds are about 48% that you've got a JS injection on your file, too. Go upload a file called <script>alert("Hi")</script> and see what happens. The other 48% is that the shell you shouldn't be passing this filename directly to will go crazy because of the angle brackets being syntactically invalid. Oh, and if you can request files by name, can you request ../../../../../../../etc/passwd? Statistically speaking, probably yes.
It's theoretically possible to safely manipulate the filesystem from within a web server but it's a great deal harder than it appears at first; there's a lot more than just learning the parameters to the "open" call.
As jerf (+1, great answer), stepping back a little... it has been ~fifteen years since we started noticing problems with htaccess. It filled a niche when webserver configuration was hard and when CRUD admin interfaces were significant work. Htaccess (and friends) should go now. I don't just mean "use the palliative above": I mean any time a remote client can potentially download or overwrite the ACL then the design is probably broken. (Apache is not alone here).
With the myriad of possible use cases and massive deployed base apache is probably stuck with htaccess until extinction. Forever more, we will see this comment in httpd.conf:
# The following lines prevent .htaccess and .htpasswd
# files from being viewed by Web clients.
Worse, there is certainly other "best of breed" security stuff that we are doing right now that will be incontestably bad from a future viewpoint. What is that stuff?
'AllowOverride AuthConfig Indexes' is generally relatively safe (in my humble experience) - i'd be scared to see an htshell like these with just those.