eval is not a function but language construct
http://php.net/eval so it cannot be disabled by adding it to disable_functions

eval is not a function, if you want to disable it, you may refer to Suhosin 
thanks

A reason why a bug exists is not a reason why it is not a bug.

as I said,  eval is not a *function*,  so disable_*functions* has no effect to 
eval..

Why can't you simply add a new core directive for disabling this language construct?

"eval is not a function but language construct" - that might be the reason why 
disable_functions don't work on it now but that does not mean it could not or 
should not.

I would not dismiss this isssue so easily. Eval problem caused that php is 
currently (almost) only one language is so often infected. It allows for 
attacker to hide code, purpose, use ecodings (like base64) to diminish any hope 
of detection by searching for common traits (like antivirus software does).

Eval is a functionality of php and could be disabled if apropriate modifications 
to php source code were made.

treat it as feature request if it helps you sleep at night. However this issue is 
critical in face of current mailicous code boom. Eval (by base64_encode etc) does 
not allow for any scanning and detection. This funcionality of php had begun its 
downfall really. People are migrating to other languages just because infections 
there are rare and code cannot be just like that obfucated!

feature request then

I think that that not only should be done but also made default php behavior, to 
stop widespread madness of php code infection. Eval should be by default disabled 
in php like 5.5 ...

okey, change to FR makes sense to me.

Irregardless of the FR, I'd like to point out that eval() is a useful and legitimate language construct. It *definitely* will not be disabled by default. I won't argue with the fact that it is commonly misused by ignorant developers, but this does not mean that eval() itself is in any way fundamentally "evil".

Also, I completely do not understand your arguments that people are migrating to other languages, because PHP has an eval() construct. All dynamic languages have an eval() function, including JS, Python and Ruby.

Furthermore you should realize that disabling eval() will not likely improve the security of your application. There are just to many other ways to execute code. E.g. the assert() function can be used to evaluate arbitrary code. Or the preg_replace /e modifier.

But in any case, I don't really see why eval() is a language construct. In my eyes it could just as well be a function. This would make it disableable and would also provide other advantages, like allowing its use as a callback function.

good point about assert and preg_replace /e - there also should be option to 
disable it then (especialy this /e in preg_replace). Writers of malicious code 
so far did not had to use it because eval is enabled in every php version...
As for eval etc. documentation states that it sould be avoided by developers - 
and it is actualy. However it used to mask infected, malicious code by those 
that hacked php software. eval is commonly used to evaluate base64_encoded 
string and that makes very hard to see what code is doing and to detect it 
automaticly (by something like antivirus software).
Change on magic_quotes_gpc in php 5.4 is much greater change then turning off 
eval by default would be. Since most legitimate software don't use it (since 
documentation says its bad)would affect only very few. This also would not 
increase security. However it would make code infections so much easier to 
detect and analize its nature.

I run a website with 10k uniques per day and eval() is CRUCIAL to my business

example:
$page = file_get_contents($_GET['path'].".php");
eval("echo ".$page.";");

I also use it for user auth and access to exec() since my host blocks it

As you can see, eval() is a very good thing to use and I don't want it gone, kk??

@e756937

(1) haven't you heard of include()?
(2) $_GET['path'] not validated
(3) no apparent rhyme or reason to mix of single and double quoting
(4) echo parameter neither quoted nor escaped
(5) echo within eval?
(6) why do you need eval for that at all?
(7) "I also use it for user auth" -- I completely doubt you need to.
(8) exec() is unrelated.
(9) The mere existence of an easy way to disable eval does not mean your host will do that. Your host can already disable it if they want to. Hosts often let you specify a custom php.ini or other configuration anyway, and this is certainly true on a server plan that serves 10k daily uniques for you.
(10) Using a 10minutemail.com address with a commenting system that doesn't verify the email.

Conclusion => magic_quotes level of IQ

@anon: pretty sure you just got trolled

Considering how prolific the use of eval() is in malicious code I cannot believe it can't be turned off without installing something like suhosin. Arguing what it is is beside the point. It is a gaping hole in the security and stability of php servers that cannot be closed without 3'rd party software.

"If eval() is the answer, you're almost certainly asking the
wrong question. -- Rasmus Lerdorf, BDFL of PHP"

And if you're going to argue that a function is not evil and should not be used for evil things, tell that to all the 'hackers' using it. I want to install a gate at my door by turning this off. Telling me I can't because I should not break into my own house is pointless

Re-opened bug and we're back at the beginning via above revert so when that will be more properly fixed we can move forward here I guess.

There is no implementation of this that can provide any security. 

There is no difference between eval and include, if a malicious hacker finds themselves on a system where eval is disabled, they can just dump what they would eval and include it.

By the time a hacker has permission to execute unsafe code via eval or by any other means, it is too late.

@krakjoe

> There is no difference between eval and include

This is not true.  If malicious code were required to write a file to be `!include`d, this could be monitored and potentially blocked by a separate tool running at the filesystem level.

> By the time a hacker has permission to execute unsafe code via eval or by any other means, it is too late.

Isn't that a bit like saying 2FA is pointless because by the time your password has been cracked it's too late?

Re-opening as single developer cannot make this decision. This needs to come from RFC and I believe there are some good arguments for disabling eval.