Safeguard
Vulnerability Analysis•

CVE-2025-1963: High SQL Injection in projectworlds Online Hotel Booking

CVE-2025-1963 is a high SQL injection in projectworlds Online Hotel Booking. No fix is named; use prepared statements and limit access to the page.

Safeguard Security Team
4 min read

CVE-2025-1963 is a high severity SQL injection flaw (7.3) in projectworlds Online Hotel Booking 1.0, in the checkin input of /reservation.php. The record names no fixed release, so confirm with the vendor, rewrite the query with bound parameters, and restrict access to the page.

What's affected

The CVE record lists projectworlds Online Hotel Booking, version 1.0. The weakness is classed as CWE-74, CWE-89. The vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) reads as reachable over the network, low attack complexity, no privileges required and no user interaction. Impact is rated low for confidentiality, low for integrity and low for availability. The page is normally reachable without signing in.

The description says the exploit has been disclosed to the public and may be used. The record is not on the CISA Known Exploited Vulnerabilities list, and nothing I fetched says it is being exploited in the wild.

Fixed versions: none are named in the record. I could not confirm a vendor patch, so check the vendor's download page and the public report before assuming a newer release exists. Treat every copy of version 1.0 as exposed until you have changed the query yourself or upgraded to a release the vendor confirms.

How to check if you're exposed

Start with an inventory. Find every copy of the application on your servers, including old test installs and backups that still answer web requests.

find /var/www -name "reservation.php" 2>/dev/null
grep -n "checkin" /var/www/path/to/reservation.php

Open the match and look at how the value reaches the database. If the request value is joined into the SQL string, the code is vulnerable. If it is passed as a bound parameter to a prepared statement, that line is not the problem.

Then read your web server logs for requests to that path from addresses you do not recognize, and look for long values or unusual quote characters in that parameter.

grep "reservation.php" /var/log/apache2/access.log | less

Finally, confirm the version against the one in your download or documentation. If you cannot tell which version you run, assume version 1.0.

What to do now

  1. Find every deployment of Online Hotel Booking and note its version.
  2. If the app does not need to be public, take it offline or put it behind a VPN or an IP allowlist today.
  3. Rewrite the vulnerable query in /reservation.php to use prepared statements with bound parameters, using mysqli or PDO in PHP or the equivalent in your stack. Apply the same change to every other query in the file.
  4. Require a valid session at the top of any admin page and check the user role before the query runs.
  5. Give the database account used by the app only the rights it needs, so a flaw cannot drop tables or read unrelated schemas.
  6. Check the vendor page for an updated release and read its notes before you upgrade.
  7. Review logs for the period since the version went live, and rotate any passwords stored in the affected database if you find signs of misuse.

Why it matters

SQL injection happens when user input is placed into a database query as text instead of as a value. The database then cannot tell the developer's instructions from the visitor's input. It sits under CWE-74 and the broader injection family, a long-standing and well documented weakness class.

Reservation pages take dates, and dates are easy to treat as safe text. A check in value that reaches a query unescaped can read or alter bookings and guest records.

Small PHP and Java applications are often copied, customized and left running for years without updates. That is why the fix is rarely a patch you install. It is usually a code change you make yourself, and the same pattern often exists in other files of the same project.

Quick check

How should a date field be handled?

Parse it on the server as a date and reject anything that does not parse, then bind the parsed value. Never place the raw string in the query.

Is there an official patch I can install?

The record does not name a fixed version, and I could not confirm one. Check the vendor's page. Until then, the safe path is to change the query to use bound parameters and limit who can reach the page.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.