Environment.Exit called

Vulnerability potential	Low
DDoS potential	Medium

Environment.Exit terminates the process; the surrounding control flow does not continue

Impact

Environment.Exit(code) terminates the whole process immediately. Execution does not return to the caller, so any code that follows the call in the same method — and every method further up the call stack — never runs. finally blocks below the current frame are skipped, using/Dispose cleanup does not happen, and buffered writers that have not been flushed lose their data. The exit code is passed straight to the OS, so a wrong value can mislead a parent shell or supervisor into thinking the run succeeded or failed.

In a library this is especially damaging: a component the caller expected to return instead tears down the entire host. A web request handler, plugin, or unit test runner that calls Environment.Exit kills the server or test process rather than the single operation.

Vulnerability potential

The security relevance is moderate and mostly availability-oriented.

1. If the argument to Environment.Exit is reachable from untrusted input, or if attacker-controlled data can steer execution into a code path that calls it, an attacker can force termination of a long-running service — a denial-of-service primitive. A single request that ends the process drops every other in-flight connection.
2. Because finalizers and Dispose are skipped on an abrupt exit, secrets held in SafeHandle/CryptoStream cleanup, audit-log flushes, or “release the lock file” steps may not execute, which can leave the system in a state an attacker can exploit on the next start.
3. A misleading exit code can cause a supervising process to mis-handle a failure (e.g. not alerting), masking an attack in progress.

Technical details

Environment.Exit ultimately calls into the runtime’s shutdown path (on .NET it raises AppDomain.ProcessExit, runs registered process-exit handlers, then calls the OS exit). Unlike returning from Main or throwing to the top of the stack, it does not unwind the current thread’s frames, so catch/finally blocks in the active call chain are bypassed.

vs. throwing

Throwing an exception unwinds the stack and runs finally blocks, giving callers a chance to handle or clean up. Environment.Exit removes that opportunity entirely.

vs. returning an exit code

The idiomatic way to end a program is to return an int from Main (or set Environment.ExitCode). That lets the normal shutdown sequence — flushing Console, running finalizers under a managed shutdown — complete. Reserve Environment.Exit for the rare case where you genuinely must abort from deep in the stack and you have already flushed critical state yourself.

Finalizers

On a normal managed shutdown the runtime makes a best-effort pass over the finalizer queue (bounded by a timeout). State that depends on Dispose rather than finalizers will still not be cleaned up reliably.

Catching the issue

Code review

Treat any Environment.Exit call outside of top-level Main/entry-point/CLI-bootstrap code as a defect. Library and request-scoped code should signal failure by returning a value or throwing, never by killing the process.

Static analysis

Roslyn analyzers and SonarQube (rule S1147, “Exit methods should not be called”) flag Environment.Exit and Process.GetCurrentProcess().Kill(). Add a banned-API entry (Microsoft.CodeAnalysis.BannedApiAnalyzers) for System.Environment.Exit(System.Int32) in shared libraries.

Testing

Code that calls Environment.Exit is nearly impossible to unit-test, because it ends the test host. Abstract the “stop the program” decision behind an interface so it can be mocked; the presence of such an abstraction is itself a sign the code was written with this hazard in mind.

How to reproduce

Observe that "after" is never printed and the finally block does not run.

using System;

class Program
{
    static void Cleanup()
    {
        try
        {
            Console.WriteLine("before");
            Environment.Exit(0);
            Console.WriteLine("after");   // never reached
        }
        finally
        {
            Console.WriteLine("finally"); // never reached
        }
    }

    static void Main()
    {
        Cleanup();
        Console.WriteLine("Main continues"); // never reached
    }
}