Git feature branching strategy allows unapproved 'tag along' features
Technically I guess something like this would print out any branchs between any particular branch and your master branch:
for hash in $(git log --format=%h master..); do if git branch --contains=$hash | grep -qv $(git name-rev HEAD | sed -e 's#HEAD ##g'); then git branch --contains=$hash | grep -v $(git name-rev HEAD | sed -e 's#HEAD ##g'); fi; done

But fundamentally there is probably an underlying problem here, I'm not intimate with your work flow or the teams you work with, but it seems unlikely to me that developers would accidentally create a new feature branch rooted on another feature branch unless they actually wanted some of the code in that other feature branch, perhaps to reuse in delivering whatever the new feature might be.
It seems that you might make a lot of improvement to your process quite quickly and easily by simply ensuring that the all features that are currently being worked on to completion are included in the next release and thus cN be merged into a pre-release branch as soon as they are approved. From there any branch taken from that pre-release branch should only contain features intended to be released,but it would mean that if a developer wrote code they thought was applicable to more than one problem,then they would almost immediately be able to reuse it once merged.
Although I'm not entirely sure that I've understood the issue you are facing, it seems to me that the existence of code in two branches isn't actually a problem, it's just code reuse. If one of those branches is pulled from the release then that's fine, the code that is being reused would still need to stay?