Wait, so how do you escalate this to RCE?
>and due to a valid scenario he theorized involving an administrative feature we are scheduled to deprecate soon, we decided to re-classify the issue as a potential RCE bug.
I imagine it might be some feature that could maybe be triggered internally through a file:// or http://localhost/ URL, and in doing so gain access to an interface that can issue shell commands. That's pure speculation though, and I'm probably way off.
They never protect the systems from within that well because generally it's more effort than it's worth (well, of course, the day a company becomes bankrupt because of an RCE, they'd wish they spent the time - as usual with security).
Of course, it doesn't mean it's always possible. It's just likely.
Random scenario, since /etc/passwd is available, it tells me the php config sucks. you could just write a php shell and run it on the web interface. Or have the code within requests and read the log file (again, its all about config. if php let you read the file and doesn't only execute for .php files, bang. or if you can write a .php, bang again.)
The point really is that I rarely see people caring about protecting anything or following best practices once someone found a bug that affects the system (such as fs access).
remote read access is much more limited than remote write access, but even write access will be limited by file permissions, and doesn't necessarily translate to code execution.
injecting some code into some of the web-app source that gets triggered by an additional request would probably be hte easiest way, but you might also look for system binaries that get called by cron or similar.
Sounds like he didn't use any of these, and it was actually some sort of local web-accessible (but externally firewalled) admin interface that a suitable request could exploit, and I'm very curious how that part of it would work (especially how you'd know/find out about it as an outsider)