CWE-698, Execution After Redirect, often shortened to EAR, is a web application bug. The application sends a redirect to another location but, instead of stopping, keeps executing additional code. MITRE lists web based products and web servers as the platforms.
The redirect looks like protection. The user in a browser lands on the login page and sees nothing sensitive. Meanwhile the server has already done the work.
How it happens
In many frameworks, calling a redirect function sets a header and does not end the request. Code on the next line still runs. MITRE's example is PHP that shows a server status only for authorized IP addresses:
// Vulnerable: redirect is issued, execution continues
$requestingIP = $_SERVER['REMOTE_ADDR'];
if (!in_array($requestingIP, $ipAllowList)) {
echo "You are not authorized to view this page";
http_redirect($errorPageURL);
}
$status = getServerStatus();
echo $status;
Unauthorized users are redirected, but getServerStatus() still runs and its output is still written into the response. MITRE notes that this lets unauthorized users reach the page contents or trigger a denial of service against the server being queried. It also points out that the code is vulnerable to IP address spoofing.
The record's observed CVEs show how it plays out:
- CVE-2013-1402: execution after redirect allows access to application configuration details.
- CVE-2007-2713: remote attackers obtain access to administrator functionality. It is also listed as a chain where the flaw triggers eval injection.
- CVE-2007-4932: remote attackers obtain access to administrator functionality.
- CVE-2009-1936: a library file sends a redirect if directly requested but continues to execute, allowing remote file inclusion and path traversal.
What an attacker gains
MITRE lists altered execution logic and the possibility of executing untrusted code, with confidentiality, integrity and availability all in scope. In practice: reading data meant for admins, running admin actions, or reaching code paths that were meant to be gated.
How to find it
MITRE has a specific warning for testers. Black box testing in a web browser may miss this, because the browser obeys the redirect and moves the user to another page, hiding the body of the original response. The fix for the tester is to stop following redirects.
Practical checks:
- Request protected URLs with a client that does not follow redirects, such as
curl -iwithout-L, and read the body of the 302 response. - Search code for redirect calls that are not followed by an exit, return or thrown exception.
- Test with side effects in mind. Does the action still happen after you are redirected?
How to fix it
Stop executing after you redirect. Every time.
// Fixed: redirect, then end the request
if (!in_array($requestingIP, $ipAllowList)) {
http_redirect($errorPageURL);
exit();
}
$status = getServerStatus();
echo $status;
Better, structure the code so the check is central. Put authorization in middleware that returns or throws, so handlers never run for unauthorized requests. And do not rely on the client IP address alone to decide access.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why can a browser hide this bug?
The browser follows the redirect automatically, so the tester never sees the response body that the server sent along with it.
What is the minimal fix?
End the request immediately after issuing the redirect, with exit, return or an exception, so no code after it runs.
