Type-Casting Disasters: How loggingredactor Broke Python's Lazy Logging

We all know the drill. You're building a Python application, and your security team (or your paranoia) whispers in your ear: "Don't log PII. Don't log API keys." So, you grab a library like loggingredactor. Its job is simple: intercept log records, scrub the nasty bits using regex or dictionary keys, and pass the clean data along. It's the janitor of your application logs.

But here is the problem with overzealous janitors: sometimes they throw out the furniture while trying to sweep the floor. loggingredactor made a critical architectural error. It assumed that everything passed to a logger is destined to be a string immediately. It forgot that Python logging is designed to be lazy.

When you call logger.info("User ID: %d", user_id), Python doesn't format that string right away. It passes the format string and the integer user_id to the logging handlers. This optimization saves CPU cycles if the log level is set to WARNING, meaning the INFO log never actually gets formatted. loggingredactor inserted itself into this pipeline and decided to forcefully convert user_id to a string ("123") before the formatter got to it. When the formatter finally woke up and saw %d paired with "123", it threw a tantrum—specifically, a TypeError.

The root cause here is a classic case of "Hammer, meet Nail." The developers of loggingredactor needed to run regex substitutions on log data. Regex works on strings. Therefore, the logic went: "Make everything a string."

In versions prior to 0.0.6, the RedactingFilter.redact method contained a recursive loop. If it encountered a dictionary, it dove in. If it encountered a list, it iterated. But for everything else—integers, floats, booleans, custom objects—it executed this ruthless line of code:

content_copy = isinstance(content_copy, str) and content_copy or str(content_copy)

This looks like a clever one-liner, but it's a landmine. It forces a type coercion. If you passed 123 (int), it became '123' (str). If you passed True (bool), it became 'True' (str).

The crash happens downstream in the standard library's logging module. When the LogRecord is processed, the formatting operator % is applied. If the message template is "Value: %d" and the argument has been mutated into a string, Python raises TypeError: %d format: a number is required, not str.

This essentially turns your logging infrastructure into a minefield. Any developer using type-specific formatters (%d, %f, %x) will inadvertently crash the application thread just by trying to write a log message.

Let's look at the "before" and "after" code to understand exactly how this was remediated. This diff is from the critical patch in version 0.0.6.

The Vulnerable Code (v0.0.5):

# Inside RedactingFilter.redact(self, msg)
if isinstance(content_copy, dict):
    # ... handle dicts ...
else:
    # THE BUG: Force everything to string so we can regex it
    content_copy = isinstance(content_copy, str) and content_copy or str(content_copy)
    for pattern in self._mask_patterns:
        content_copy = re.sub(pattern, self._mask, content_copy)

It's that else block that causes the pain. It assumes that if it's not a dict, it must be coercible to a string for regex processing.

The Fixed Code (v0.0.6):

from collections.abc import Mapping
 
# Inside RedactingFilter.redact(self, msg)
if isinstance(content_copy, Mapping):
    # ... handle dicts safely ...
elif isinstance(content_copy, str):
    # ONLY apply regex if it is ALREADY a string
    for pattern in self._mask_patterns:
        content_copy = re.sub(pattern, self._mask, content_copy)
# Note: If it's not a Mapping or a str, it implicitly does nothing and returns the original object.

The fix is subtle but vital. It stops the implicit casting. If content_copy is an integer, it hits the end of the if/elif chain and remains an integer. The logging formatter downstream stays happy because %d receives an integer. However, as we'll discuss later, this fix introduces a new, interesting behavior regarding what actually gets redacted.

Exploiting this isn't about popping a shell; it's about causing chaos in the application's stability and observability. Imagine a scenario where a financial application processes transactions. It logs the transaction ID and the amount using standard logging practices.

import logging
from loggingredactor import RedactingFilter
 
# Vulnerable setup
logger = logging.getLogger('banking_app')
logger.addFilter(RedactingFilter())
 
# The harmless developer writes this:
tx_id = 94821
amount = 500.00
 
# The crash:
# The filter turns tx_id into "94821". 
# The formatter expects an int for %d.
logger.info("Processing TX ID: %d", tx_id)

When this code runs, the application raises an unhandled TypeError. If this logging call is inside the main transaction loop and not wrapped in a specific try/except block for logging errors (which nobody writes), the entire transaction fails.

> [!NOTE] > The Irony: The crash often happens inside the error handling routine.

Consider an app that catches an exception, tries to log it, and then crashes while logging the error. You lose the original error trace and are left with a TypeError from the logging library. This effectively blinds the ops team to the real root cause of production issues.

The patch in version 0.0.6 solves the crash by removing the forced string conversion. However, this introduces a fascinating side-effect that I like to call the "Redaction Bypass via Type confusion."

In the old version (v0.0.5), the library was paranoid. It converted everything to a string and checked it against regex patterns. If you had a credit card number stored as an integer (bad practice, but it happens) or a float, the old version would stringify it and redact it.

The New Behavior (v0.0.6):

# Since we only check `isinstance(x, str)`:
secret_pin = 1234
# Regex pattern is r'\d{4}'
 
# This integer bypasses the redaction logic entirely because it is not a string!
logger.info("User PIN: %s", secret_pin)

Because secret_pin is an integer, the new redact method ignores it. The logging formatter eventually converts it to a string for output, after the redaction filter has already finished its job. The result? Cleartext secrets in logs.

This is a classic trade-off. The maintainers chose application stability (stop crashing on %d) over aggressive, paranoid redaction. It is now the developer's responsibility to ensure that sensitive fields are cast to strings before logging if they rely on regex-based redaction.