In PHP versions 8.2. before 8.2.31, 8.3. before 8.3.31, 8.4. before 8.4.21, and 8.5. before 8.5.6, the SOAP extension's object deduplication mechanism stores pointers to PHP objects in a global map without incrementing their reference counts. When an apache:Map node contains duplicate keys, processing the second entry overwrites the first in the temporary result map, freeing the original PHP object while its stale pointer remains in the map. A subsequent href reference to the freed node can copy the dangling pointer into the result. As PHP string allocations can reclaim the freed memory region, an attacker with control over the SOAP request body can exploit this use-after-free to achieve remote code execution.

In PHP versions 8.1. before 8.1.34, 8.2. before 8.2.30, 8.3. before 8.3.29, 8.4. before 8.4.16, 8.5. before 8.5.1 when using the PDO PostgreSQL driver with PDO::ATTREMULATEPREPARES enabled, an invalid character sequence (such as \x99) in a prepared statement parameter may cause the quoting function PQescapeStringConn to return NULL, leading to a null pointer dereference in pdoparseparams() function. This may lead to crashes (segmentation fault) and affect the availability of the target server.

End of life: 12/31/2029, End of support: 12/31/2027, Latest version: 8.5.9

https://blog.quarkslab.com/security-audit-of-php-src.html announces the completion of a security audit of PHP by Quarkslab, thanks to funding provided by Sovereign Tech Fund to The Open Source Technology Improvement Fund.

The blog provides details and a link to the audit report for more. The summary it provides of the findings is: 2 security issues considered as high severity; 6 security issues considered as medium severity; 9 security issues considered as low severity; 10 issues considered informative.

Most vulnerabilities have been shared via security advisories on the PHP-SRC GitHub repository. Other bugs and issues are provided only in this report.

Four CVEs were issued, namely:

CVE-2024-9026 for LOW-2; CVE-2024-8925 for LOW-4; CVE-2024-8928 for HIGH-1; CVE-2024-8929 for HIGH-2. These correspond to the following security advisories from the PHP github repo:

CVE-2024-9026: [PHP-FPM] Logs from childrens may be altered https://github.com/php/php-src/security/advisories/GHSA-865w-9rf3-2wh5 Published Sep 27, 2024 Fixed in 8.1.30, 8.2.24, & 8.3.12

CVE-2024-8925: Erroneous parsing of multipart form data https://github.com/php/php-src/security/advisories/GHSA-9pqp-7h25-4f32 Published Sep 27, 2024 Fixed in 8.1.30, 8.2.24, & 8.3.12

CVE-2024-8929: [Mysqlnd] Leak partial content of the heap through heap buffer over-read https://github.com/php/php-src/security/advisories/GHSA-h35g-vwh6-m678 Published Nov 21, 2024 Fixed in 8.1.31, 8.2.26, & 8.3.14

CVE-2024-8928 is still marked reserved & not yet published, the report lists it as "Details to be shared after fixes are applied".

The Quarkslab blog also points to corresponding blogs from the PHP Foundation and the Open Source Technology Improvement Fund at: https://thephp.foundation/blog/2025/04/10/php-core-security-audit-results/ https://ostif.org/php-audit-complete/

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

End of life: 12/31/2027, End of support: 12/31/2025, Latest version: 8.3.33

End of life: 12/31/2027, End of support: 12/31/2025, Latest version: 8.3.33

End of life: 12/31/2028, End of support: 12/31/2026, Latest version: 8.4.24

End of life: 12/31/2028, End of support: 12/31/2026, Latest version: 8.4.24

End of life: 12/31/2026, End of support: 12/31/2024, Latest version: 8.2.33

End of life: 12/31/2026, End of support: 12/31/2024, Latest version: 8.2.33

End of life: 12/31/2025, End of support: 11/25/2023, Latest version: 8.1.34

End of life: 12/31/2025, End of support: 11/25/2023, Latest version: 8.1.34

According to https://www.php.net/manual/en/security.cgi-bin.force-redirect.php, the configuration directive cgi.forceredirect prevents anyone from calling PHP directly with a URL like http://host.example/cgi-bin/php/secretdir/script.php. The default value of cgi.forceredirect is 1.

But there is a bug that can cause attackers to bypass restrictions and access php-cgi directly.

Erik Auerswald: Hi,

On Mon, May 27, 2024 at 12:31:46PM +0200, Florian Weimer wrote: Although very late, here is a follow up explaining the impact of the vulnerability.

Provided that you can force an application to convert a partially controlled buffer to ISO-2022-CN-EXT, you get an overflow of 1 to 3 bytes whose value you don't control.

This can be triggered in at least two ways in PHP:

- Through direct calls to iconv() - Through the use of PHP filters (i.e. using a "file read" vulnerability)

Due to the way PHP's heap is built, you can use such a memory corruption to alter part of a free list pointer, which can in turn give you an arbitrary write primitive in the program's memory.

With this bug, any person that has a file read vulnerability with a controlled prefix on a PHP application has RCE. Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT while reading it? It's not even an ASCII-transparent charset. According to <https://www.ambionics.io/blog/iconv-cve-2024-2961-p1>, PHP can be told to do so via "php://filter/…", a default behavior of PHP, it seems (I have just skimmed that page and do not know any details). Oh, right:

| Obviously, base64-encoding is not the only thing you can do. Many | filters are available. | […] | | » convert.iconv.X.Y, which converts charset from X to Y | | Let's take a look at the last filter: convert.iconv.X.Y. Say that I need | to convert my file from UTF8 to UTF16. I can use: | | php://filter/convert.iconv.UTF-8.UTF-16/resource=/etc/passwd

Unfortunately, that exposes all installed iconv converters in all directions (unlike glibc's ,ccs= parameter for fopen), once there is an arbitrary URL read injection vulnerability in a PHP application.

Thanks, Florian

On Mon, May 27, 2024 at 11:16:53AM +0200, Charles Fol wrote: Although very late, here is a follow up explaining the impact of the vulnerability.

Provided that you can force an application to convert a partially controlled buffer to ISO-2022-CN-EXT, you get an overflow of 1 to 3 bytes whose value you don't control.

This can be triggered in at least two ways in PHP:

- Through direct calls to iconv() - Through the use of PHP filters (i.e. using a "file read" vulnerability)

Due to the way PHP's heap is built, you can use such a memory corruption to alter part of a free list pointer, which can in turn give you an arbitrary write primitive in the program's memory.

With this bug, any person that has a file read vulnerability with a controlled prefix on a PHP application has RCE. Any person that can force PHP into calling iconv() with controlled parameters has RCE.

We have provided more explanations on a blogpost of ours (I do not think that I can post it here, it shouldn't be too hard to find if you're interested). Surely you can post a link to a blog post, although we strongly prefer that besides the link you also post a plain text copy of most content, for archival.

I assume you refer to:

https://www.ambionics.io/blog/iconv-cve-2024-2961-p1

This ends with: This concludes the first part of the series on CNEXT (CVE-2024-2961). The exploit is now available on our GitHub. There is still much more to explore: what about direct calls to iconv() ? What happens the file read is blind?

In part 2, we'll dive deeper in the PHP engine to target an iconv() call found in a very popular PHP webmail. I'll describe the impact of such direct calls on the PHP ecosystem, and show you some unexpected sinks. Finally, in part 3, we'll cover blind file read exploitation. The GitHub link is:

https://github.com/ambionics/cnext-exploits/

I understand it'd be difficult to convert a so nicely formatted blog post into a plain text posting, but perhaps you can now post the plain text description you had shared with the distros list?

Are your OffensiveCon slides online or will be soon? A link to them can also be shared.

Thanks,

Alexander

Hi,

On Mon, May 27, 2024 at 12:31:46PM +0200, Florian Weimer wrote: Although very late, here is a follow up explaining the impact of the vulnerability.

Provided that you can force an application to convert a partially controlled buffer to ISO-2022-CN-EXT, you get an overflow of 1 to 3 bytes whose value you don't control.

This can be triggered in at least two ways in PHP:

- Through direct calls to iconv() - Through the use of PHP filters (i.e. using a "file read" vulnerability)

Due to the way PHP's heap is built, you can use such a memory corruption to alter part of a free list pointer, which can in turn give you an arbitrary write primitive in the program's memory.

With this bug, any person that has a file read vulnerability with a controlled prefix on a PHP application has RCE. Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT while reading it? It's not even an ASCII-transparent charset. According to <https://www.ambionics.io/blog/iconv-cve-2024-2961-p1>, PHP can be told to do so via "php://filter/…", a default behavior of PHP, it seems (I have just skimmed that page and do not know any details).

HTH, Erik

Charles Fol: Hello all,

Although very late, here is a follow up explaining the impact of the vulnerability.

Provided that you can force an application to convert a partially controlled buffer to ISO-2022-CN-EXT, you get an overflow of 1 to 3 bytes whose value you don't control.

This can be triggered in at least two ways in PHP:

- Through direct calls to iconv() - Through the use of PHP filters (i.e. using a "file read" vulnerability)

Due to the way PHP's heap is built, you can use such a memory corruption to alter part of a free list pointer, which can in turn give you an arbitrary write primitive in the program's memory.

With this bug, any person that has a file read vulnerability with a controlled prefix on a PHP application has RCE. Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT while reading it? It's not even an ASCII-transparent charset.

Thanks, Florian

End of life: 11/26/2023, End of support: 11/26/2022, Latest version: 8.0.30

End of life: 11/26/2023, End of support: 11/26/2022, Latest version: 8.0.30

In PHP versions 7.2.x below 7.2.28, 7.3.x below 7.3.15 and 7.4.x below 7.4.3, when creating PHAR archive using PharData::buildFromIterator() function, the files are added with default permissions (0666, or all access) even if the original files on the filesystem were with more restrictive permissions. This may result in files having more lax permissions than intended when such archive is extracted.

Reference: https://bugs.php.net/bug.php?id=79082

End of life: 11/28/2022, End of support: 11/28/2021, Latest version: 7.4.33

End of life: 11/28/2022, End of support: 11/28/2021, Latest version: 7.4.33

USN-3953-1 fixed several vulnerabilities in PHP. This update provides the corresponding update for Ubuntu 12.04 ESM and Ubuntu 14.04 ESM. Original advisory details: It was discovered that PHP incorrectly handled certain exif tags in JPEG images. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code.

End of life: 12/6/2021, End of support: 12/6/2020, Latest version: 7.3.33

End of life: 12/6/2021, End of support: 12/6/2020, Latest version: 7.3.33

PHP is vulnerable to an integer overflow in the mysqliapi.c:mysqlirealescapestring() function. An attacker could exploit this by performing a crafted query to cause a crash.

Upstream Bug:

https://bugs.php.net/bug.php?id=74544

PHP through is vulnerable to an out of bounds access in the phppcre.c:phppcrereplaceimpl() function. An attacker could exploit this by calling pregreplace() with crafted arguments.

Upstream Bug:

https://bugs.php.net/bug.php?id=74604

End of life: 11/30/2020, End of support: 11/30/2019, Latest version: 7.2.34

End of life: 11/30/2020, End of support: 11/30/2019, Latest version: 7.2.34