Clarified summary

Seems like this is a much bigger issue. We discovered that disabling the loader does not only affect the current thread but obviously changes the setting globally on the entire server. Plus, it seems to be persisted in a way that only restarting the server got us back to normal.

Planning to do some more tests tomorrow to eliminate any kind of caching that might have been involved.

We're on PHP 5.3.3 on CentOS, strictly single-threaded.

Sorry, but I would like to ask for clarification:
For php-cgi I see the following behaviour:
1. I issue a request that has a call of libxml_disable_entity_loader()
2. A subsequent request to a different script that is NOT calling libxml_disable_entity_loader is affected by the first request because the setting is shared between subsequent requests on the same process.

Is this a bug or working as intended?

PHP 5.4.39 with libxml 2.9.2

Any suggested workarounds for this issue? This bug is pretty critical because it can basically take down sites running something like Magento. It appears to only be fixed in PHP 5.6, which a lot of codebases aren't ready for yet.

Also fixed in 5.5.22 (per the commits above).

I'm using 5.5.30 and php-fpm and can reproduce the problem by using the inverse of the script:

Test script:
---------------
<?php

die(var_dump(libxml_disable_entity_loader(true)));

---------------

The default seems to be false for me. After a few hits the results all end up true, so somehow this value is persisting within php-fpm children.

For mark at netalico dot com:

The workaround for something like Magento (not required for CE>1.9.2.0 when a workaround was added) is to add this line to the start of your script:

if (function_exists('libxml_disable_entity_loader')) {
    libxml_disable_entity_loader(false);
}

I can confirm that I still get the issue with 7.0.11. I run my above checking script and after a few runs all entries come out as true, so this is still not thread safe.

The problem is still present in php-fpm 5.6.26 (debian 8.6).

Commit c1eb87ab1a2e2df1868b70cd7b8016c6147092c5 was pushed 20 months ago, so I suppose it did not fix the problem.

Re-opened according to recent user comments (thanks!)

Can someone test this simple fix proposal

diff --git a/ext/libxml/libxml.c b/ext/libxml/libxml.c
index d88860c..bfc1224 100644
--- a/ext/libxml/libxml.c
+++ b/ext/libxml/libxml.c
@@ -848,7 +848,6 @@ static PHP_MINIT_FUNCTION(libxml)
        if (sapi_module.name) {
                static const char * const supported_sapis[] = {
                        "cgi-fcgi",
-                       "fpm-fcgi",
                        "litespeed",
                        NULL
                };

@remi

Just noticed that there's a bug report for this. We're shipping the following patch since noticing the issue ourself:

diff -Naur php-7.2.0.orig/ext/libxml/libxml.c php-7.2.0/ext/libxml/libxml.c
--- php-7.2.0.orig/ext/libxml/libxml.c  2017-11-12 19:03:42.890478753 +0100
+++ php-7.2.0/ext/libxml/libxml.c       2017-11-12 19:03:58.510298201 +0100
@@ -880,13 +880,14 @@
                xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);
                xmlParserInputBufferCreateFilenameDefault(php_libxml_input_buffer_create_filename);
                xmlOutputBufferCreateFilenameDefault(php_libxml_output_buffer_create_filename);
-
-               /* Enable the entity loader by default. This ensures that
-                * other threads/requests that might have disabled the loader
-                * do not affect the current request.
-                */
-               LIBXML(entity_loader_disabled) = 0;
        }
+
+       /* Enable the entity loader by default. This ensures that
+        * other threads/requests that might have disabled the loader
+        * do not affect the current request.
+        */
+       LIBXML(entity_loader_disabled) = 0;
+
        return SUCCESS;
 }

No idea which one is better. Just wanted to share this.