PHP 8.5.9, 8.4.24, 8.3.33, 8.2.33: Coordinated Security Release Fixes PostgreSQL SQL Injection and BCMath Memory Corruption

TL;DR in 90 seconds

Affected?

PHP 8.2.x before 8.2.33, 8.3.x before 8.3.33, 8.4.x before 8.4.24, and 8.5.x before 8.5.9: practically every currently supported PHP branch.

Risk?

Four vulnerabilities in one coordinated release: SQL injection in the PostgreSQL connectors (PGSQL/PDO_PGSQL) via a gap in escaping the E'...' syntax (CVE-2026-17543), an out-of-bounds write in BCMath's bccomp() with crafted numeric input (CVE-2026-17544), a denial-of-service crash in Phar via recursive symlinks (CVE-2026-7260), and an upgrade of the bundled libgd library (CVE-2026-9672). php.net has not published official CVSS scores.

Immediate action?

Update to the current patch version of your PHP branch (8.2.33 / 8.3.33 / 8.4.24 / 8.5.9). Also review codebases that interpolate user input into PostgreSQL string literals using E'...' syntax without parameter binding.

Recommendation?

Critical mainly for codebases with direct string interpolation in PGSQL queries or unfiltered values flowing into BCMath comparison functions. For everyone else, a routine update with high priority.

Criticality?

high (hero badge): no confirmed RCE, but SQL injection potential plus memory-safety bugs across widely used extensions, affecting all supported branches at once; no active exploitation known as of this writing.

What is the problem?

CVE-2026-17543: SQL injection in PGSQL/PDO_PGSQL (GHSA-7qpv-r5mr-78m4)

PostgreSQL supports string literals in the extended escape syntax E'...', where backslash sequences such as \x00 or \n are interpreted as control characters. PHP's PGSQL and PDO_PGSQL extensions did not consistently handle these sequences when building query strings: if an application interpolates user input directly into an E'...' literal (instead of using pg_query_params() or prepared statements), an attacker can craft a backslash sequence that breaks out of the literal and injects arbitrary SQL syntax. The parameterised query path itself is not affected; only code that still builds PostgreSQL statements via string concatenation is at risk.

CVE-2026-17544: Out-of-bounds write in BCMath (GHSA-x692-q9x7-8c3f)

The BCMath extension for arbitrary-precision arithmetic processes numbers internally via bc_str2num(), which bccomp() calls when comparing two numbers. A crafted numeric input can make bc_str2num() write outside the memory region reserved for the internal number representation: classic memory corruption. Any project that lets unfiltered external values flow into BCMath comparison functions like bccomp() is affected.

CVE-2026-7260: Crash via recursive symlinks in Phar (GHSA-vc5h-9ppw-p5f3)

The Phar extension can enter an infinite loop or memory-exhaustion crash when processing archives that contain recursive or circular symbolic links. The effect is denial of service, not code execution; relevant anywhere Phar archives from not-fully-trusted sources are processed.

CVE-2026-9672: libgd upgrade

The release updates the libgd library bundled with PHP's GD image-processing extension. Neither php.net nor the secondary sources we checked provide technical detail on the underlying vulnerability. We don't want to speculate here. In practice: anyone offering image upload or processing via the GD extension should still apply the update, even without knowing the exact attack vector.

Who is affected?

All four currently supported PHP branches are affected, which is typical for a coordinated security release: the underlying bugs sit in code that is shared or similar across branches (PGSQL escaping, BCMath number representation, Phar path handling). Particularly relevant for TYPO3/Sylius/Symfony operators: PGSQL and PDO_PGSQL only matter if PostgreSQL is actually in use as the database. The far more common MySQL/MariaDB connector is unaffected by CVE-2026-17543. BCMath and Phar, on the other hand, are part of many default installations and potentially relevant anywhere Composer packages process .phar archives or arbitrary-precision arithmetic (e.g. price calculations, cryptography libraries) is used.

Impact

The four vulnerabilities behave very differently and shouldn't be lumped together. CVE-2026-17543 (PGSQL SQL injection) has the largest damage potential but is conditional: it requires application code that interpolates user input directly into an E'...' string literal instead of using pg_query_params() or prepared statements. In modern codebases with consistent parameter binding (as Doctrine DBAL, PDO with prepared statements, or TYPO3's query builder do by default), the attack path is generally unreachable. Where it is reachable, impact ranges from information disclosure to data manipulation, depending on the application's database privileges.

CVE-2026-17544 (BCMath memory corruption) is classic memory corruption. The immediate effect is a crash; the theoretical escalation potential toward code execution depends heavily on the specific memory layout and PHP build configuration and has not been publicly demonstrated. CVE-2026-7260 (Phar symlink crash) is a denial-of-service risk only. For CVE-2026-9672 (libgd) we have no verified statement on the concrete impact. We recommend applying the update out of caution regardless.

Mitigation / immediate steps

Operational decision block

• Act today if … your application uses PostgreSQL and interpolates user input into SQL strings anywhere without parameter binding. Check this regardless of patch status.
• Patch with priority if … you use BCMath or Phar processing with externally influenceable input.
• Schedule routinely if … none of the above applies. The update is still mandatory as part of the coordinated security release.

Step 1: Identify and update your PHP version

# Check current version
php -v

# Debian/Ubuntu with sury.org or distro-native PHP repository
sudo apt update
sudo apt list --upgradable | grep -i php
sudo apt install --only-upgrade 'php8.3*'   # adjust branch: 8.2/8.3/8.4/8.5

# Alpine/Docker images: pin the base image tag to the patched version
# e.g. FROM php:8.3.33-fpm-alpine  (instead of php:8.3-fpm-alpine, which floats to newer patch levels)

# Source builds: pull the current tarball from php.net/downloads.php
# and verify signature/checksum before building

Step 2: Defence in depth regardless of the patch

# PGSQL: never build queries via string concatenation of user input,
# use parameterized queries consistently instead
# Unsafe:
# pg_query($conn, "SELECT * FROM t WHERE name = E'" . $_GET['name'] . "'");
# Safe:
pg_query_params($conn, "SELECT * FROM t WHERE name = $1", [$_GET['name']]);

Step 3: Verify after the update

php -v
# expected output contains the patched version number,
# e.g. "PHP 8.3.33" instead of an earlier 8.3.x version

Detection / verification

Establish inventory

# Inventory PHP version across all servers/containers
for h in $(cat hosts.txt); do ssh "$h" 'php -v | head -n1'; done

# In Kubernetes: check the PHP version per running pod
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | xargs -I{} kubectl exec {} -- php -v 2>/dev/null | head -n1

Search the codebase for risky PGSQL usage

# Find raw string concatenation feeding into pg_query()
grep -rnE "pg_query\s*\(.*\\$_(GET|POST|REQUEST|COOKIE)" --include='*.php' .

# Count occurrences of pg_query_params (the safe path) for comparison
grep -rn "pg_query_params" --include='*.php' . | wc -l

Check BCMath and Phar usage with external input

grep -rnE "bccomp\s*\(" --include='*.php' .
grep -rn "Phar::" --include='*.php' .

Operator guidance

Mid-market

Roll the update to 8.2.33/8.3.33/8.4.24/8.5.9 out via your regular patch cycle. None of the four issues is known to be actively exploited, so an emergency window is unnecessary in most cases. Still prioritise a manual review of PostgreSQL applications with historically grown database-access code for string concatenation in SQL statements.

Enterprise

Use the release as an opportunity for a fleet-wide PHP version inventory. Especially with many microservices or legacy applications, an older patch level than assumed is common. Complement the patch rollout with a static code audit for pg_query() calls using string concatenation, as a standing control rather than a one-off check tied to this CVE.

Decision block

• Patch immediately: update to 8.2.33 / 8.3.33 / 8.4.24 / 8.5.9 depending on your branch.
• Also review: PostgreSQL code paths for string concatenation in SQL statements, BCMath and Phar usage with external input.
• Watch: the official CVSS assessment and any later detail disclosure for CVE-2026-9672 (libgd).

Conclusion

This release is a good example of security fixes that don't have to look spectacular to be worth acting on. None of the four issues is an unauthenticated pre-auth RCE with public exploit code. Yet the details are worth a closer look: CVE-2026-17543 shows that escaping logic inside a database interpreter itself can be flawed, regardless of how carefully an application handles its input. That is another argument for consistently using parameterised queries instead of string concatenation, not merely as a style preference but as a second line of defence for the case where the interpreter itself has bugs. The BCMath and Phar fixes are a reminder that even extensions that rarely make headlines need continuous maintenance. And the thinly documented libgd fix illustrates a limit of this format: we only report what we can verify, and say so plainly when a source doesn't provide it.

Sources

• php.net — PHP 8 ChangeLog (official release notes for 8.5.9 with GHSA/CVE mapping)
• php.watch — PHP 8.5.9 Release Summary
• LinuxCompatible — PHP 8.3.33 and 8.4.24 Released: Critical Security Fixes for PGSQL SQLi and BCMath Memory Corruption
• LinuxCompatible — PHP 8.5.9 and 8.2.33 Security Updates Drop Alongside 8.6 Alpha 3
• GitHub Security Advisory GHSA-7qpv-r5mr-78m4 (CVE-2026-17543)
• GitHub Security Advisory GHSA-x692-q9x7-8c3f (CVE-2026-17544)
• GitHub Security Advisory GHSA-vc5h-9ppw-p5f3 (CVE-2026-7260)