CVE-2024-57328 is a critical severity SQL injection flaw (CVSS 9.8) in the login form of ProjectWorlds Online Food Ordering System v1.0. The username and password fields are not sanitized, which lets someone bypass authentication. The researcher lists no fixed version, so treat the code as unsafe for production use.
What's affected
The record describes a SQL injection vulnerability in the login form of Online Food Ordering System v1.0, from the ProjectWorlds collection of sample projects. It says the username and password fields are not properly sanitized, allowing attackers to inject SQL queries to bypass authentication and gain unauthorized access.
The researcher's write-up on GitHub lists the affected version as 1.0.0 and the fixed version as NULL, meaning none exists. It adds that the login code in login.php embeds the username and password directly in the SQL query, without parameterized queries.
ProjectWorlds publishes source code for learning and student projects. That matters, because copies of this code get deployed in small businesses and as demos, and nobody tracks them. If you or a client ever installed this system, you have an affected component with no upstream fix.
How to check if you're exposed
Start by finding out whether you run it at all. Search your web servers and hosting accounts for the project, using its name or the file names in the write-up:
grep -rl "Online Food Ordering System" /var/www 2>/dev/null
find /var/www -name login.php -path "*food*"
If you find a copy, open login.php and see how it builds its query. Code that joins the username and password into a string is the pattern the record describes.
Check how it is exposed. A copy on a public website with real customer or order data is the worst case. A copy on a developer laptop used for a class is a low concern. Also check whether the database account the application uses has more rights than it needs.
What to do now
- Find every copy of this application in your hosting, repositories and client sites.
- Take internet facing copies offline until the login code is fixed.
- Rewrite the login to use prepared statements with bound parameters and store passwords with a proper password hashing function.
- Change the database account to one with only the rights the application needs.
- Reset the admin password and review the order and customer data for tampering.
- Before reusing any sample project, run a code scan, since sample code is written to teach, not to defend.
Why it matters
This is a textbook CWE-89 case. The login code builds a query by pasting the typed username and password into the SQL text. Because the database reads the whole string as one statement, a value that contains SQL syntax can change the logic of the statement. The check that was meant to ask for a user with this name and this password can be made to succeed without either.
The vector in the record shows network access, low complexity and no privileges, so the score is 9.8. There is no fix to wait for, so the response is to retire or rewrite the code. This kind of finding is also an easy one for static analysis, which spots string concatenation in queries. The KEV flag in the record is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a patch for CVE-2024-57328?
The researcher lists the fixed version as none. The remedy is to rewrite the login with parameterized queries or stop using the code.
Why does sample code end up in production?
Free source code is easy to find and quick to deploy. Treat anything from a learning site as untrusted until reviewed.
Sources
Last reviewed: 19 October 2026.
