CVE-2025-6267 is a medium severity (CVSS 6.3) SQL injection (CWE-89) in zhilink ADP Application Developer Platform 1.0.0. The flaw is in /adpweb/a/base/barcodeDetail/, where the barcodeNo, barcode and itemNo parameters reaches a database query unsafely. The record lists no fixed version, so fix the query in your copy or retire the application.
What's affected
The record lists zhilink ADP Application Developer Platform, version 1.0.0, as affected. The vulnerable file is /adpweb/a/base/barcodeDetail/ and the injectable input is the barcodeNo, barcode and itemNo parameters. The classification includes CWE-74 (improper neutralization of special elements in output used by a downstream component) and CWE-89 (SQL injection).
Nothing in the record points to a vendor patch, so the safest assumption is that you have to fix the query yourself or retire the app. The record says the vendor was contacted early about the disclosure but did not respond in any way. The CVSS vector requires a low privilege account and no user interaction, which is why the score is medium and not high. The record also states that the exploit has been disclosed publicly and may be used. It is not marked CISA Known Exploited, so I make no claim of attacks in the wild.
How to check if you're exposed
You can confirm exposure in your own copy without sending anything to a live system. Search the code for the file and the parameter:
find . -path "*adpweb/a/base/barcodeDetail/" -type f
grep -n "barcodeNo," ./adpweb/a/base/barcodeDetail/
Read how the value reaches the database call. If it is joined into the query text with string concatenation or interpolation, and not bound as a parameter, the page has the flaw. Also check your web server access log for requests to /adpweb/a/base/barcodeDetail/ that carry quotes, comment markers or SQL keywords in the barcodeNo, barcode and itemNo parameters:
grep "adpweb/a/base/barcodeDetail/" /var/log/apache2/access.log | grep -iE "%27|union|sleep|--"
Log lines like that point to probing, not proof of a breach. Look at your database logs and data for changes you cannot explain, and confirm that the application account holds only the rights it needs. A scan that crawls and tests your pages can help find sibling pages with the same pattern.
What to do now
- Find every copy of zhilink ADP Application Developer Platform in your environment, including demo and staging installs.
- Change the query in
/adpweb/a/base/barcodeDetail/to use a prepared statement, and bind the barcodeNo, barcode and itemNo parameters as data. Do the same for every other page that builds queries from input. - Give the database account used by the application the minimum rights it needs, with no administrative or file privileges.
- If you cannot patch the code today, take the application off the public internet or put it behind a login or VPN.
- Review access and database logs for probing, and rotate stored credentials if you see signs of misuse.
- Watch the vendor or project site for an official update, and read it before relying on a patched build.
Why it matters
SQL injection (CWE-89) is what happens when input is treated as part of the query. The database follows whatever the string says, so a visitor can read other rows, change data or, depending on the setup, go further. The fix is old and well understood: parameterised queries, where the query shape is fixed and values are passed separately.
Small PHP applications like this are widely downloaded for learning and for quick internal tools, then left running for years. That combination is what makes a public report matter: the code is easy to read, easy to copy, and rarely updated. The record gives 6.3 on the CVSS scale and a public disclosure, so the question is not whether the bug is real but whether your copy is reachable.
Quick check
Is there a patch for CVE-2025-6267?
The record does not name a fixed version, and I did not find one in the sources I read. Fix the query in your own copy, or retire the application, and check the project site for news.
How do I stop SQL injection in PHP code?
Use prepared statements with bound parameters in PDO or mysqli for every query that includes input. Escaping strings by hand is fragile and easy to miss on one page.
Sources
Last reviewed: 18 October 2026.
