Compare what happens with a shell script either being executed directly or as an argument to /bin/sh:

$ cat script.sh 
  #!/bin/sh
  echo it ran
$ ls -l
  ---------- 1 david david 22 2013-11-11 11:38 script.sh

$ ./script.sh
  bash: ./script.sh: Permission denied
$ sh ./script.sh
  bash: script.sh: Permission denied
[download]

and as root ...

# ./script.sh
  -su: ./script.sh: Permission denied
#  sh script.sh
  it ran
[download]

Now, obviously you don't have permission to do anything with the script if you are an ordinary user, so everything happens as you expect.

However, if you are root, then things get a bit more complicated. When you attempt to execute something using the magic '#!' line, the system only looks for that if the file is marked as being executable by you. Even if you're root, if none of the 'x' bits are set then it won't execute like this

But if you provide the script's name as an argument to an interpreter yourself, then the system looks to see if the interpreter (/bin/sh, or /usr/bin/perl, for example) has an 'x' bit set that applies to you. If it does, then the interpreter gets executed. It looks at its arguments, finds a filename, checks to see if the file is readable and then does its thang with it. Note that if you're root, a file with mode 0 is still readable, so the interpreter successfully opens it, reads the contents, and executes them.

So no, this isn't a security hole. It's just an artifact of what the 'execute' permission bits mean and how they are interpreted.