CVE-2025-9749 is a high severity SQL injection flaw (CVSS 7.3) in the HKritesh009 Grocery List Management Web App, commit f491b681eb70d465f445c9a721415c965190f83b and earlier. The ID parameter of /src/update.php reaches a database query without safe handling. I could not confirm a vendor fix, so restrict access, review the code and check the advisory for updates.
What's affected
The record lists HKritesh009 Grocery List Management Web App commit f491b681eb70d465f445c9a721415c965190f83b and earlier as affected. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, which describes a network attack with low complexity that needs no privileges and no user interaction.
The record notes that this project uses a rolling release, so no version numbers for affected or fixed releases exist. The only reference point is the commit hash given above. If you run a copy of this app, compare your checkout against that commit and treat anything at or before it as affected.
Source conflict to note: the record gives the affected range as every commit up to f491b681eb70d465f445c9a721415c965190f83b, while the reporter's write-up says it tested v1.0 and calls all versions up to its 23 August 2025 test date affected. The write-up also mentions a different application name in one place, which looks like a copy error. Use the record's commit as the reference and verify against your own checkout.
How to check if you're exposed
Start by finding out whether you run this software at all. It is a downloadable PHP sample project, often installed for learning or as a quick internal tool, so it may sit on a forgotten server.
On the web server, search the application folder for the file and the parameter named in the record.
find /var/www -name "update.php" 2>/dev/null
grep -rnE "\$_(GET|POST|REQUEST)" /var/www/path/to/app | grep -i "ID"
Replace the path with your install folder. In the hits, look for the ID value being placed straight into an SQL string. That is the weakness class, and a prepared statement with bound parameters is the fix pattern.
Then check the access log for requests to /src/update.php from addresses you do not recognise, and for unusual characters such as quotes in the ID value.
grep "update.php" /var/log/apache2/access.log | tail -n 50
Adjust the log path for your server. A clean log does not prove safety, since public tooling probes these pages quickly, but it tells you whether anyone has been looking.
For application code you build or deploy, the free in-browser dependency scan at gold.safeguard.sh/scan covers your third party packages, and the Gold directory lets you look up a CVE like this one by id. Neither replaces reading hand written code, so pair them with a code review of query and upload handling.
What to do now
- Take /src/update.php off the public internet, or put the whole application behind a VPN or an allow list of known addresses.
- Review every query in the application that uses a request value. Rewrite them as prepared statements with bound parameters, starting with the ID handling in /src/update.php.
- Run the database account with the fewest rights the app needs. It should not own other schemas or hold file write rights.
- Add a web application firewall rule for SQL metacharacters as a stopgap. It is a delay, not a fix.
- Check the vendor page and the project listing for a patched release, and read the advisory again before you assume none exists.
- If this app holds real personal or financial data, treat it as potentially exposed, rotate credentials stored in its database and review backups.
- If you cannot fix it, retire it. A sample project with no maintainer is a poor home for production data.
Why it matters
The cause is a familiar one. The application takes the ID value from the request and builds an SQL statement by joining strings. The database cannot tell the developer's query from the attacker's text. This is CWE-74 (Injection) and CWE-89 (SQL Injection). NVD lists the broader injection class together with the specific SQL form.
The fix is not clever. Prepared statements keep the query shape fixed and send values separately. The same pattern, repeated across many sample projects, explains why this CVE is one of a long run of near identical records.
The page handles an update to stored data. A flaw in an edit path can matter for integrity as well as confidentiality, because the same query that reads a row may also change it.
The record says an exploit has been made public. That is not the same as exploitation in the wild. This CVE is not in CISA's Known Exploited Vulnerabilities catalog, and nothing I fetched claims active attacks. Still, public details lower the effort for anyone who goes looking for installs.
Quick check
Is CVE-2025-9749 exploited in the wild?
The record does not say so and the CVE is not in the CISA Known Exploited Vulnerabilities catalog. It does say an exploit has been made public, so treat exposure as real.
Is there a patched version of Grocery List Management Web App?
I could not confirm one. Check the vendor page and project listing, and fix the query handling yourself if you must keep running the app.
Sources
- Gold page for CVE-2025-9749
- NVD record data for CVE-2025-9749, as held in the Safeguard content batch
- Reporter write-up: https://gist.github.com/0xSebin/a163239e0132d7d58ef1300f321da819
Source note: the only advisory material I could read for this CVE is a public write-up on GitHub Gist from the reporter, which I fetched. It is a researcher report, not a vendor advisory, and it does not name a fixed version.
Last reviewed: 18 October 2026.
