CVE-2025-12253 is a high SQL injection flaw in AMTT Hotel Broadband Operation System 1.0, in /user/portal/get_expiredtime.php through the uid parameter. NVD scores it 7.3. The record names no fixed version and says a public exploit exists, so patch the code with parameterised queries and limit who can reach the app.
What's affected
The NVD record names AMTT Hotel Broadband Operation System version 1.0. The affected code is the file /user/portal/get_expiredtime.php, and the argument that matters is uid. The vector needs no privileges. The file sits under a portal path, which suggests a guest facing page that users reach without a login.
The record says the attack can be launched remotely and that the exploit has been made public. It does not give a patched version. The record does not say whether the maintainer plans a fix, so do not wait for one.
If you run it, treat the code as yours. The fix is a change to the query in that file, and a developer can make it.
How to check if you're exposed
- Find out whether the application runs anywhere in your estate, including test servers, student projects and forgotten demos. A search of your web roots for the file name is quick:
find /var/www -name "get_expiredtime.php". - Open that file in your own copy and look for the uid value being placed directly into a query string. If it is joined into SQL text with a dot or a plus sign and not bound as a parameter, the code has the flaw.
- Check the application's database account. If it connects as a database administrator or owns more tables than it needs, the impact of any injection is larger.
- Search your web server logs for requests to that file with unusual characters in the uid value, which will tell you whether anyone has probed it.
A static analysis scan of the source finds this pattern well. Every injectable query tends to look the same to a code scanner.
What to do now
- If this app is not needed, take it offline. Sample applications rarely belong in production.
- If you need it, change the query in get_expiredtime.php to use a prepared statement, and bind the uid value as a parameter. For example, with mysqli:
$stmt = $conn->prepare("SELECT * FROM items WHERE id = ?");
$stmt->bind_param("s", $value);
$stmt->execute();
- Repeat the change for every other query in the application. A flaw in one file usually has siblings.
- Give the database account only the rights the app needs, and keep it away from other databases.
- Put the app behind a login or an IP allow list, and add a web application firewall rule as a stopgap, not as the fix.
- Check back for a vendor update, since the record lists none.
Why it matters
The weaknesses are CWE-89, SQL injection, and CWE-74, injection in general. They arise when untrusted input becomes part of a command that another system interprets. The database cannot tell the developer's SQL from the attacker's, so it runs both.
A hotel broadband portal holds guest account data and ties usage to rooms and people. The NVD record says the vendor was contacted early about the disclosure but did not respond in any way, so waiting for a patch is not a plan. If you operate this system, treat the code as yours and fix the query or take the portal off the public internet.
The record does not mark this CVE as exploited and it is not in the CISA Known Exploited Vulnerabilities catalog. It does say a public exploit exists. Small applications like this are easy targets for automated scanning because their file names and parameters are public.
Quick check
Is there a patched version of AMTT Hotel Broadband Operation System?
The NVD record names none. Fix the query yourself with a prepared statement, or remove the application.
Does a web application firewall fix SQL injection?
It can block many known attack strings, which buys time. It does not fix the code. Prepared statements are the real fix.
Sources
Last reviewed: 19 October 2026.
