php main stable versions 7.1.33, 7.2.24, 7.3.11 are all affected.

stack trace are below

gdb-peda$ bt
#0  0x000000000073bc05 in _zval_get_string_func (op=0x7ffff4460200)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.c:875
#1  0x000000000069f3f9 in _zval_get_string (op=<optimized out>)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.h:273
#2  php_str_replace_in_subject (search=search@entry=0x7ffff441d3e0, 
    replace=replace@entry=0x7ffff441d3f0, subject=<optimized out>, result=result@entry=0x7fffffffa3e0, 
    case_sensitivity=case_sensitivity@entry=0x1)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:3950
#3  0x000000000069fc61 in php_str_replace_common (execute_data=0x7ffff441d390, 
    return_value=0x7ffff441d2f0, case_sensitivity=0x1)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:4130
#4  0x00000000007f3837 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER ()
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:621
#5  execute_ex (ex=0x7ffff4460200) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:59754
#6  0x00000000007f714e in zend_execute (op_array=0x7ffff447f2a0, op_array@entry=0x7ffff44910e0, 
    return_value=0x0, return_value@entry=0x7ffff441d240)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:63780
#7  0x0000000000745633 in zend_execute_scripts (type=type@entry=0x8, retval=0x7ffff441d240, 
    retval@entry=0x0, file_count=file_count@entry=0x3)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend.c:1498
#8  0x00000000006e0880 in php_execute_script (primary_file=primary_file@entry=0x7fffffffca90)
    at /home/zwjj/Downloads/php-7.2.24/main/main.c:2599
#9  0x00000000007f9529 in do_cli (argc=0x2, argv=0x115a220)
    at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1011
#10 0x000000000042e49c in main (argc=argc@entry=0x2, argv=0x115a220, argv@entry=0x7fffffffde88)
    at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1403
#11 0x00007ffff6f4a830 in __libc_start_main (main=0x42e020 <main>, argc=0x2, argv=0x7fffffffde88, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde78)
    at ../csu/libc-start.c:291
#12 0x000000000042e5b9 in _start ()

sorry, the correct stacktrace should be

gdb-peda$ bt
#0  0x000000000073bc05 in _zval_get_string_func (op=op@entry=0x7ffff4460200)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.c:875
#1  0x000000000069df78 in _zval_get_string (op=0x7ffff4460200)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.h:273
#2  php_implode (glue=glue@entry=0x11636f0, pieces=<optimized out>, 
    return_value=return_value@entry=0x7ffff441d0a0)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:1246
#3  0x000000000069e3da in zif_implode (execute_data=<optimized out>, return_value=0x7ffff441d0a0)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:1321
#4  0x00000000007f3837 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER ()
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:621
#5  execute_ex (ex=0x7ffff4460200) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:59754
#6  0x00000000007f714e in zend_execute (op_array=0x7ffff447f2a0, op_array@entry=0x7ffff447f400, 
    return_value=0x0, return_value@entry=0x7ffff441d030)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:63780
#7  0x0000000000745633 in zend_execute_scripts (type=type@entry=0x8, retval=0x7ffff441d030, 
    retval@entry=0x0, file_count=file_count@entry=0x3)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend.c:1498
#8  0x00000000006e0880 in php_execute_script (primary_file=primary_file@entry=0x7fffffffca90)
    at /home/zwjj/Downloads/php-7.2.24/main/main.c:2599
#9  0x00000000007f9529 in do_cli (argc=0x2, argv=0x115a220)
    at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1011
#10 0x000000000042e49c in main (argc=argc@entry=0x2, argv=0x115a220, argv@entry=0x7fffffffde88)
    at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1403
#11 0x00007ffff6f4a830 in __libc_start_main (main=0x42e020 <main>, argc=0x2, argv=0x7fffffffde88, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde78)
    at ../csu/libc-start.c:291
#12 0x000000000042e5b9 in _start ()

I'm confused about what kind of issue do you think are security issue ? ? ? Even the buffer overlow are not security issue in your eyes ?

> I'm confused about what kind of issue do you think are security
> issue

See <https://wiki.php.net/security>.

Anyhow, at least one problem is that zval_get_string_func()
doesn't expect an IS_INDIRECT op, causing it to return NULL, which
php_implode() doesn't handle, leading to a NULL pointer
dereference.

I don't think so. From my perspective, you just don't want to admit the vulnerability.

Firstly, the crash shows that it's not an easy null pointer deference, the crash point doesn't read/write/execute any data from zero address. And the $pc register point to an unknow address, which probably can lead to code execution and bypass any php security settings.

Sencondly, even if this issue can't lead to any code execution, from the cvedetails, there're many issues which related to null pointer deference with security tag, and they all don't fit for https://wiki.php.net/security , then why you still assign cve for these issues ?

Thirdly, please check https://bugs.php.net/bug.php?id=78833 and https://bugs.php.net/bug.php?id=78819, these two issues are have buffer overflow potential, which can let attacker to read/write to any address in the process. Even these issues are not security issues? The first issue even don't need any extensions of the php engine, which is more universial, Remember there're many security settings like safe_mode, open_basedir in the php, with these vulnerabilities the attacker can easily bypass these security settings. If these issues are not security issues, then can I understand that the php engine is a vulnerable engine? Because it doesn't provide any usefull security settings for the user environment and it already become a juicy target for the ctfer :)

To clarify, the security classification is not so much about whether the issue is "exploitable" (we generally do not care much whether something is a "benign" null pointer dereference or may allow arbitrary code execution, as long as there's some memory unsafety going on). The relevant question is whether it is *remotely* exploitable, which this issue clearly isn't. There needs to be some reasonably realistic pathway leading for a remote attacker that *cannot* already execute PHP code on the server.