|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #62397 disable_functions = eval does not work
Submitted: 2012-06-23 00:24 UTC Modified: 2024-02-09 09:44 UTC
Avg. Score:4.8 ± 0.5
Reproduced:36 of 36 (100.0%)
Same Version:11 (30.6%)
Same OS:13 (36.1%)
From: spamik at yum dot pl Assigned:
Status: Re-Opened Package: *General Issues
PHP Version: 5.3.14 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: spamik at yum dot pl
New email:
PHP Version: OS:


 [2012-06-23 00:24 UTC] spamik at yum dot pl
disable_functions = eval does not work.

eval is often used to obfucate code by malicious viruses. I see no reason why 
blocking access to eval() is not doable.


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-23 07:28 UTC] reeze dot xia at gmail dot com
eval is not a function but language construct so it cannot be disabled by adding it to disable_functions
 [2012-06-23 09:14 UTC]
-Status: Open +Status: Not a bug
 [2012-06-23 09:14 UTC]
eval is not a function, if you want to disable it, you may refer to Suhosin 
 [2012-06-23 10:56 UTC] anon at anon dot anon
A reason why a bug exists is not a reason why it is not a bug.
 [2012-06-23 12:29 UTC]
as I said,  eval is not a *function*,  so disable_*functions* has no effect to 
 [2012-06-23 12:52 UTC] bobwei9 at hotmail dot com
Why can't you simply add a new core directive for disabling this language construct?
 [2012-06-24 03:56 UTC] krzf83 at gmail dot com
"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.
 [2012-06-24 03:59 UTC] krzf83 at gmail dot com
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!
 [2012-06-24 04:02 UTC] spamik at yum dot pl
feature request then
 [2012-06-24 04:08 UTC] spamik at yum dot pl
-Type: Bug +Type: Feature/Change Request
 [2012-06-24 04:08 UTC] spamik at yum dot pl
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 ...
 [2012-06-24 10:05 UTC]
okey, change to FR makes sense to me.
 [2012-06-24 10:05 UTC]
-Status: Not a bug +Status: Re-Opened
 [2012-06-24 11:25 UTC]
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.
 [2012-06-24 13:58 UTC] spamik at yum dot pl
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.
 [2012-06-26 17:59 UTC] e756937 at rtrtr dot com
I run a website with 10k uniques per day and eval() is CRUCIAL to my business

$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??
 [2012-06-28 17:37 UTC] anon at anon dot anon

(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 address with a commenting system that doesn't verify the email.

Conclusion => magic_quotes level of IQ
 [2012-06-29 16:31 UTC] isee at a dot troll
@anon: pretty sure you just got trolled
 [2015-03-24 12:12 UTC] phpbugs at notmyaddie dot com
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
 [2019-04-28 15:57 UTC]
The following pull request has been associated:

Patch Name: Fix bug #62397 - disable_functions does not work with eval.
On GitHub:
 [2019-05-14 22:00 UTC]
Automatic comment on behalf of
Log: Fix bug #62397 - disable_functions does not work with eval.
 [2019-05-14 22:00 UTC]
-Status: Re-Opened +Status: Closed
 [2019-06-03 09:20 UTC]
Automatic comment on behalf of krakjoe
Log: Revert "Fix bug #62397 - disable_functions does not work with eval."
 [2019-06-03 09:24 UTC]
-Status: Closed +Status: Re-Opened
 [2019-06-03 09:24 UTC]
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.
 [2019-06-03 09:30 UTC]
-Status: Re-Opened +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2019-06-03 09:30 UTC]
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.
 [2021-09-09 01:22 UTC] jake at qzdesign dot co dot uk

> 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?
 [2024-02-09 09:44 UTC]
-Status: Closed +Status: Re-Opened -Assigned To: krakjoe +Assigned To:
 [2024-02-09 09:44 UTC]
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.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jun 23 15:01:29 2024 UTC