mutated × unstructured — blows up live on input you didn't expect

Unexpected-Type Element in a Heterogeneous Collection

A collection assumed to hold one shape gains an element of another type -- directly or because a method mutated one item -- and the consumer crashes when it reaches the odd one.

01the recipe

In the wild

compound ofthis MutationCWE-471 MAID (Modification of Immutable Data)Duck Typing Without ContractsCWE-1287 Improper Type ValidationcompoundCWE-241 Unexpected Data Type

example.py

# SMELL: a list assumed to be all numbers; one path appends a string.
# (this-mutation x duck typing without contracts)
def total(items):
    return sum(x * 2 for x in items)    # assumes every x is numeric

items.append(row["qty"])                # row["qty"] is "3" from a CSV -> str
total(items)                            # TypeError on the one string element

# RIGHT: validate the element's type at the boundary; coerce or reject.
def add_qty(items, raw):
    try:
        items.append(int(raw))          # parse into the expected type
    except (TypeError, ValueError):
        raise BadRow(f"qty not an int: {raw!r}")

Duck typing with no element contract (CWE-1287) lets a wrong-typed item slip into a collection the consumer treats as uniform; the code then mishandles the unexpected type (CWE-241) and crashes on the one odd element -- a shape failure, not arithmetic or timing. Validate or coerce each element where it enters, so the collection's type is an invariant.

// observed

mixed: TypeError: can't multiply sequence by non-int (one bad row)
right: each element parsed at entry -> the collection stays homogeneous

02weakness catalog

Mapped weaknesses (CWE)

On its own, this defect is catalogued by MITRE as one or more of these weaknesses. The exploitable vulnerability usually appears only when it chains or combines with another.