CVE-2024-3376 is a high severity (CVSS 7.3) execution after redirect flaw in SourceCodester Computer Laboratory Management System 1.0, through the url argument in config.php. A public exploit is reported and the record lists no fix. Restrict access and correct the redirect handling.
What's affected
The record names one product and version: Computer Laboratory Management System 1.0, published under the oretnom23 vendor name in the CPE data and distributed through SourceCodester. The affected file is config.php, and the manipulated input is the url argument. The record says the attack can be launched remotely and that the exploit has been disclosed publicly.
The weaknesses are CWE-698, execution after redirect, and CWE-670, always incorrect control flow implementation. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L: network reachable, low complexity, no account and no user interaction, with low impacts on all three properties. That gives 7.3.
Execution after redirect means the code sends a redirect response to send an unauthorized visitor elsewhere, but does not stop running. The rest of the page logic still executes and its output can still be returned to the client. The record says no more than that, and I could not confirm details from a vendor advisory, because none is listed. The only references are a third party write up and the VulDB entry. The record names no fixed version. It is not marked as exploited in the wild and is not in the CISA KEV list.
How to check if you're exposed
- Find deployed copies. A command such as
grep -rl "Computer Laboratory" /var/wwwis a starting point. - Confirm the version is 1.0.
- Read
config.phpand look at how it handles the redirect. Any place that sends a redirect header without ending the script straight afterwards is the pattern to look for. - Check whether the application is reachable from the internet.
- Review access logs for requests to protected pages that return a redirect status but a large response body. That mismatch is a sign the page content is still being sent.
What to do now
- Remove public access or place the application behind a VPN or allow list.
- In every place that redirects, end the script immediately after the redirect header, for example with an exit call in PHP, and return only the redirect.
- Move authorization checks into one function that runs before any output is produced, so a missed exit cannot leak page content.
- Validate the
urlvalue against a fixed list of allowed destinations instead of accepting arbitrary values. - Review the same codebase for the SQL injection flaws that were published against it in April 2024, since the same application has several.
- Check for a patched release and record the result.
Why it matters
A redirect is a message to the browser, not a barrier. If the server keeps working after it sends the redirect, a client that ignores the instruction can read whatever the server produced. This is why access control has to stop execution, not just point the visitor elsewhere.
Small PHP applications often use this pattern for login checks. One missed exit can open every protected page. A high severity score with no account needed is a good reason to treat even a teaching application as exposed when it faces the internet.
Quick check
What is execution after redirect?
It is a flaw where the code issues a redirect but keeps running, so the response can still contain content the visitor should not see. The fix is to stop execution right after the redirect.
Is there a patched version?
The record lists none. Fix the redirect handling in your own copy and check the vendor page for a release.
Sources
Last reviewed: 19 October 2026.
