The use of Python exception statements becomes a critical security weakness when pass or continue is used for exception handling. This pattern is inherently dangerous as it creates silent failure conditions that can mask security vulnerabilities and enable attacks.

The Python pattern:

try:
    do_some_stuff()
except Exception:
    pass

presents severe security risks due to:

• Overly broad exception handling – catching Exception masks virtually all errors, including security-critical ones
• Silent failure – using pass suppresses all evidence that something went wrong
• Arbitrary Code Execution Risk – If do_some_stuff() involves deserialization (e.g., pickle.loads()), catching and ignoring exceptions could hide successful exploitation of deserialization vulnerabilities that lead to arbitrary code execution
• Attack Vector Concealment – Attackers can deliberately trigger exceptions as part of reconnaissance or exploitation, and the silenced errors provide no defensive alerts

This pattern often appears due to:

• Use of AI coding tools :Many AI vibe coding tools will produce pass in exception handling functions by default.
• Developer convenience: Quick "fix" to prevent crashes without addressing root causes
• Misguided stability attempts : Belief that catching all errors ensures application stability
• Lack of security awareness: Developers unaware of the security implications

1. Masking of Critical Errors and Vulnerabilities:

   • Hiding Bugs: Any exception, from a simple TypeError to a critical MemoryError or a security-related issue like an InjectionError (if do_some_stuff() interacts with databases or external systems), will be silently caught and ignored
   • Undetected Attacks: If an attacker triggers an exception as part of an exploit (e.g., a buffer overflow causing specific exceptions, invalid input leading to unhandled conditions), the except Exception: pass block swallows it. The attack might succeed without any indication
   • Resource Leaks: If do_some_stuff() involves opening files, network connections, or acquiring locks, exceptions occurring before proper cleanup can lead to resource exhaustion, denial-of-service (DoS), or data corruption

2. Denial of Service (DoS) Vulnerabilities:

   • Infinite Loops/Stuck Processes: An error within do_some_stuff() leading to infinite loops or stuck processes won't be reported, potentially making the application unresponsive and vulnerable to DoS attacks
   • Resource Exhaustion: Silenced exceptions prevent proper cleanup, allowing resource leaks to accumulate over time

3. Compromised Data Integrity and Consistency:

   • If do_some_stuff() performs data-modifying operations (database writes, file manipulations), exceptions can leave data in inconsistent or corrupted states. Silently ignoring these means the program continues, potentially propagating bad data

4. Lack of Forensic Information:

   • No logging, no traceback, no indication of what went wrong severely hinders post-mortem analysis and incident investigation

5. Compliance Failures:

   • For security audits and compliance requirements (GDPR, HIPAA, PCI DSS), robust error handling is a necessity. Silenced exceptions make it impossible to demonstrate appropriate error management

1. Be Specific – Catch Only Expected Exceptions: Always catch specific exceptions you anticipate and know how to handle:

try:
    do_some_stuff()
except ValueError:
    handle_value_error()
except FileNotFoundError:
    handle_missing_file()

2. Log Exceptions Properly: Even if choosing not to crash, always log the exception with full traceback:

import logging

logging.basicConfig(level=logging.ERROR)

try:
    do_some_stuff()
except Exception as e:
    logging.error("Unexpected error in do_some_stuff()", exc_info=True)
    # Optionally re-raise if program cannot continue meaningfully
    # raise

3. Use finally or Context Managers for Cleanup: Ensure resource cleanup regardless of exceptions:

try:
    f = open("my_file.txt", "r")
    # ... do stuff with f ...
except FileNotFoundError:
    print("File not found!")
finally:
    if 'f' in locals() and not f.closed:
        f.close()        

Even better using with :

try:
    with open("my_file.txt", "r") as f:
        # ... do stuff with f ...
        pass
except FileNotFoundError:
    print("File not found!")

4. Implement Graceful Degradation: Rather than failing silently, provide meaningful fallback behavior:

try:
    result = fetch_from_external_service()
except ExternalServiceError as e:
    logging.critical("External service unavailable", exc_info=True)
    result = get_cached_data()  # Fallback

5. Use Cryptographic Signing for Validation: For deserialization operations, consider using hmac or safetensors:

import hmac
import hashlib
import pickle

def secure_load(data, key):
    """Load pickled data only if signature is valid."""
    signature = data[:32]  # Prepend signature
    payload = data[32:]
    
    expected = hmac.new(key, payload, hashlib.sha256).digest()
    if not hmac.compare_digest(signature, expected):
        raise ValueError("Invalid signature - possible tampering")
    
    return pickle.loads(payload)

Rarely. Some valid but limited scenarios include:

• Cleanup operations where failure is non-critical (but still log)
• Context managers where the only purpose is resource management
• Hook functions where exceptions from one handler shouldn't affect others (but log each)

Always document why an exception is being ignored.

Using continue within a loop's exception handler similarly bypasses error reporting:

for item in data:
    try:
        process(item)
    except Exception:
        continue  # Just as dangerous as pass

The presence of pass or continue in an except block is an indicator that an exception is being suppressed.

A good SAST Python scanner does this. However many SAST scanners try to suppress so called 'false positives' with complex logic or use a scoring approach. This has a very high risk, no method is solid and when findings within exception clauses have a low score, you might think that your code is secure. But the risk of a false sense of security is enormous.

Use of pass or continue in an except block does not, by itself, imply a directly security weakness. There are many cases, suppressing an expected exception is intentional and forms part of the function's documented behavior (for example, converting a ValueError into False during input validation).

Determining whether suppressing an exception is appropriate requires understanding the program's intent, the expected behavior of the API, and the effect on the remainder of the program. These properties cannot be inferred from the syntax of the exception handler alone.

Static analysis can identify suspicious patterns, such as except: pass or except Exception: continue, but it cannot determine with certainty whether the suppression is correct or harmful. As a result, these patterns should be treated as potential findings that require further review rather than definitive security weakness finding.

Even sophisticated analyses, such as taint analysis, cannot achieve 100% accuracy. Taint analysis tracks the flow of data through a program but does not capture the developer's intent or the full semantics of Python's runtime behavior.

Python's dynamic features—including dynamic typing, reflection, monkey patching, runtime code generation (exec and eval), dynamic imports, and polymorphic dispatch—prevent any static analysis from precisely modeling every possible execution path. Furthermore, determining all possible behaviors of an arbitrary program is fundamentally undecidable in the general case.

Consequently, no analysis tool can determine with complete certainty whether the use of pass or continue in an exception handler constitutes a genuine security weakness.

:::{hint} The best approach is to identify suspicious constructs and rely on human review to determine whether the exception suppression is appropriate in its specific context. Using heuristics to identify suspicious constructs can be dangerous and error prone. :::

• CWE-248: Uncaught Exception
• CWE-703: Improper Check or Handling of Exceptional Conditions
• CWE-456: Missing Initialization of a Variable
• CWE-391: Unchecked Error Condition
• Python Exception Handling Best Practices
• OWASP Error Handling Cheat Sheet