Safeguard
Application Security•

CWE-455 Non-exit on Failed Initialization: Fail Securely

A product that keeps running after a security-relevant startup error may run less securely than intended. CWE-455 explained with a Perl example.

Safeguard Security Team
2 min read

CWE-455 is the habit of carrying on after a failure that should have stopped everything. The product does not exit or otherwise change its operation when a security-relevant error occurs during initialization, such as a configuration file with a format error or a hardware security module that cannot be activated. It then runs in a less secure way than the administrator intended.

How it happens

Startup code often logs an error and continues, hoping for the best. If the failed step was loading access rules or activating a security device, the product proceeds without them.

MITRE's observed example is CVE-2005-1345: a product did not trigger a fatal error if missing or invalid ACLs were in a configuration file.

The code example in the entry limits certain operations to the administrator:

$username = GetCurrentUser();
$state = GetStateData($username);
if (defined($state)) {
    $uid = ExtractUserID($state);
}
# do stuff
if ($uid == 0) {
    DoAdminThings();
}

If state data cannot be read, for example because of a database timeout, $uid is never set. Perl treats an unset value as equal to 0 here, so the ordinary user passes the admin check. MITRE adds that even without attacker influence, unexpected errors could assign incorrect privileges by accident.

What an attacker gains

The record lists integrity impact, modified application data, and altered execution logic. The application could be placed in an insecure state that lets an attacker modify sensitive data or run unintended logic.

How to find it

The record lists no detection methods. Review startup and configuration loading. Deliberately corrupt each config file, remove each key and make each dependency unavailable, then see whether the product refuses to start or runs open.

How to fix it

MITRE says to follow the principle of failing securely when an error occurs. The system should enter a state where it is not vulnerable and does not show sensitive error messages to a potential attacker.

Fixing the Perl example means checking the failure and denying by default:

my $uid = -1;  # not admin unless proven
if (defined($state)) {
    $uid = ExtractUserID($state);
}
DoAdminThings() if ($uid == 0);

Quick check

What should a product do if its ACL file is invalid?

Stop, or fall back to a state that denies access. Starting without the rules is the weakness described here.

Sources

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.