What Is SQL Injection in PHP and How Do You Prevent It?

SQL injection in PHP is when an attacker slips database commands into a form, a URL or any other input, and the website's PHP code runs them, which can expose or change your customers' data. You prevent it with prepared statements, a database user with limited rights and an up-to-date PHP.

That last part became urgent on 30 July 2026, when the PHP project fixed a high-severity SQL injection flaw inside PHP itself, in four functions that talk to PostgreSQL databases. Sites that called those functions were exposed even when their own code looked careful. Every version number and date below comes from PHP's advisory and changelog, which we re-checked on 23 October 2026.

How SQL injection works, in plain words

Your website keeps customers, orders and logins in a database and asks for them in a language called SQL. SQL injection happens when the site writes those requests by pasting in whatever a visitor typed. A visitor who types a database command instead of a name gets that command run, with all the permissions your website has.

Think of a restaurant where the waiter writes your order on a slip and the kitchen does whatever the slip says. Now let guests write on the slip themselves. One adds a line under the burger: "also bring me the reservation book". A kitchen that trusts every slip hands over the names and phone numbers of every guest booked this month. It can't tell where the waiter's words stop and the guest's words begin, and that confusion is the whole flaw.

A prepared statement works like a printed order form with fixed boxes. Whatever a guest writes in the dish box is read as the name of a dish and nothing else, whatever the wording.

How bad an attack gets depends on what your website's database account is allowed to do. OWASP, the open web security project, lists what a successful SQL injection attack can do: read sensitive data, insert, change or delete records, run admin operations such as shutting the database down, and in some cases run commands on the server's operating system. OWASP also names PHP and ASP applications as common places to find it, because older ways of talking to databases are still in use there.

For an online shop, that list turns into customer emails and addresses copied out, prices changed to one cent overnight, a month of orders deleted, or a quiet new admin account left behind for later. None of it needs the attacker to guess a password.

What CVE-2026-17543 means for SQL injection in PHP

On 30 July 2026, PHP fixed CVE-2026-17543, a high-severity SQL injection flaw in four of its own PostgreSQL functions: pg_insert(), pg_update(), pg_select() and pg_delete(). The fixed versions are 8.5.9, 8.4.24, 8.3.33 and 8.2.33. On anything older, a site that passes visitor input to those functions can be attacked, no matter how careful its own code is.

PHP published the details in security advisory GHSA-7qpv-r5mr-78m4, and the PHP 8 changelog lists the fix in all four releases, each dated 30 July 2026.

Before sending a value to the database, the affected functions escaped it and then wrapped it in a special PostgreSQL string written as E'...'. Inside that kind of string, a backslash starts an escape sequence, as PostgreSQL's own documentation on string constants explains. A setting called standard_conforming_strings has been on by default since PostgreSQL 9.1. With it on, the escaping step left backslashes untouched, because in an ordinary PostgreSQL string a backslash is harmless. Inside E'...' it is not. A value with a backslash in the right place could end the string early and add SQL of its own.

PHP's fix wraps values in ordinary strings, where a backslash is just a backslash.

The lesson for owners is uncomfortable. A developer could have used these functions exactly as documented and the site was still open, because the weak spot sat inside PHP. Keeping PHP current is part of SQL injection defense rather than a separate IT chore you get to later.

Who is affected, and who is not

The flaw matters only to PHP code that uses a PostgreSQL database through PHP's pgsql extension and calls one of the four functions with visitor input. Sites on MySQL or MariaDB are not affected. That covers most WordPress and WooCommerce sites, because WordPress lists only MySQL and MariaDB in its requirements.

PHP's advisory names only those four functions. Red Hat's page on the CVE adds that applications built on PDO, prepared statements or parameterized queries are not affected. If your PostgreSQL code already runs through pg_query_params() or PDO, this particular flaw passes you by.

The sites that should act now are custom PHP applications on PostgreSQL: booking systems, internal dashboards, member portals and in-house tools written before a framework took over database access. A ten-year-old order system that saves form fields with pg_insert() is the textbook case.

One more group needs a plan rather than a patch: anything still on PHP 8.1 or older. PHP's last 8.1 release came out on 18 December 2025 and 8.1 no longer appears on PHP's supported versions list, so no official 8.1 release carries this fix. PHP 8.2 gets security fixes only until 31 December 2026, which makes this a good moment to move to 8.3 or newer.

Four checks that show where your site stands

Your PHP version, a search of your code, the database logs and the list of admin users tell you whether this flaw, or SQL injection in general, has touched your site. Your developer or hosting company can run all of them without special tools.

Check the PHP version and how PHP was installed. Your hosting panel shows the version, or your developer can run php -v on the server. A release at or above 8.5.9, 8.4.24, 8.3.33 or 8.2.33 in its branch has the fix. If PHP came from your Linux distribution's packages, the number can look older than the fix because some vendors patch their own builds, so read the package changelog for CVE-2026-17543 rather than trusting the number alone.

Search the code for the four function names. A text search for pg_insert, pg_update, pg_select and pg_delete across the whole project, including plugins and third-party folders, shows whether this CVE can reach you. No matches, or no PostgreSQL at all, means this flaw isn't yours to fix, though the next two checks still apply to SQL injection in general.

Read the database logs. Look for queries your application never makes, such as requests for system tables, a burst of syntax errors from one form, or a run of failed queries from one IP address. Probing for SQL injection produces broken queries before it produces a working one, so errors are a useful early sign.

Look for admin users nobody created. A new administrator account, a changed admin email address or a new database role lets an attacker come back after the hole is closed. Check prices, payment details and redirect settings while you're there.

How to prevent SQL injection in PHP

The defense that matters most is sending visitor input to the database as data and never as part of the command, which is exactly what prepared statements do. Back that up with input validation, a database user with only the rights it needs, a web application firewall, and regular updates to PHP, your CMS and its plugins.

• Use prepared statements for every query that includes input. PDO works with MySQL, MariaDB and PostgreSQL, mysqli covers MySQL and MariaDB, and pg_query_params() does the job in PHP's PostgreSQL extension. The OWASP SQL Injection Prevention Cheat Sheet puts them first because with them "the database will always distinguish between code and data, regardless of what user input is supplied."
• Never build SQL by pasting raw input into a query, and that includes the quick admin report or search page that only staff use.
• Validate input as a second layer. An order ID should be a number, and a country should come from your own list of countries. Validation catches junk early, but it can't replace prepared statements.
• Give the website a database user with only the rights it needs, so it reads and writes its own tables and nothing else. OWASP's cheat sheet says plainly not to give application accounts DBA or admin access, and on PostgreSQL that means the site never connects as a superuser.
• Put a web application firewall (WAF) in front of the site to block common attack patterns before they reach PHP. It buys time. It does not repair the code underneath.
• Update PHP, the CMS, themes and plugins on a schedule rather than after a scare. For sites that kept using the affected functions, a PHP update was the only fix for CVE-2026-17543.

Least privilege is the control that limits damage when everything else fails. Take a shop whose database user can only read and write the shop's tables: an attacker who finds a hole can copy those tables, which is bad enough, but can't create new database users or open other databases on the same server. Give that user superuser rights and the same hole reaches every database the server holds.

Prepared statements in PHP, for developers

A prepared statement sends the SQL with placeholders first and the values separately, so the database never reads a value as code. In PHP that means PDO's prepare() and execute(), mysqli's prepare() with bind_param(), or pg_query_params() for PostgreSQL. String escaping is the fallback, and CVE-2026-17543 shows why it should stay one.

• Replace pg_insert(), pg_update(), pg_select() and pg_delete() calls that take request data with pg_query_params() and numbered placeholders such as $1 and $2. The PHP manual gives the reason: values stay apart from the command, "avoiding the need for tedious and error-prone quoting and escaping." Updating PHP repairs pg_insert() and its three siblings, while moving off them stops your code depending on PHP's escaping being right.
• Stop treating pg_escape_string(), addslashes() or mysqli_real_escape_string() as the main defense. OWASP calls escaping fragile compared with the other defenses, and this CVE is PHP's own escape-and-quote step going wrong.
• Placeholders can't stand in for table names, column names or sort direction. Map those to an allow-list in code, as the OWASP cheat sheet recommends, rather than passing request values through.
• Run the app on a database role with only the grants it uses, and keep schema migrations on a separate account that holds the extra rights.
• After any PHP upgrade, restart PHP-FPM, Apache or whatever runs PHP, because a long-running worker keeps the old code in memory until it restarts.

How to fix it, step by step

Six steps close this hole, in this order: back up, update PHP, restart PHP, fix the risky code, check the logs, then change passwords if anything looks wrong. The order matters. Changing passwords while the hole is still open wastes the effort, because the attacker can still get in the same way.

1. Back up the database and the site files, then restore that backup on a test copy to prove it works.
2. Update PHP to 8.5.9, 8.4.24, 8.3.33, 8.2.33 or any later release in the same branch, or install your vendor's patched package. PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 22 October 2026, so the newest release in each of those branches includes the fix. On PHP 8.1 or older, this step becomes a move to a supported branch, which needs testing on a copy first.
3. Restart the PHP workers: PHP-FPM pools, Apache with mod_php and any queue workers. Then confirm the version the live site reports, because the command line and the web server can run different PHP builds.
4. Fix code that sends visitor input through the affected functions, and any query built by pasting input into SQL, using prepared statements.
5. Check the database and web server logs as far back as they go, since the flaw was present in releases before the 30 July 2026 fixes. Look for the signs described in the checks above.
6. If anything looks wrong, change the database password, admin passwords and any API secrets stored in the database, and delete admin accounts nobody recognises.

How Techno Mantraa can fix this for you

Once we have hosting or server access, Techno Mantraa resolves this vulnerability on your website. The work follows the same order as the steps above, and you get a short written report at the end that lists exactly what changed.

1. Check the PHP version and how PHP is installed on your server.
2. Apply the fixed PHP release, or your vendor's patched package where PHP comes from the operating system.
3. Find and fix code that builds SQL from visitor input.
4. Restart the PHP workers so the fix is live.
5. Test the site, including its forms, logins and admin area.
6. Review the logs for signs of an attack.
7. Send you a short report of what changed and what we found.

Nobody can honestly promise that a site will never be hacked, and this work doesn't claim to. It closes this hole and fixes the SQL injection patterns it finds in your code, and the report shows you where each change was made.

To get this done on your PHP site, contact the Techno Mantraa team with your website address.