Cybersecurity glossary
What is Type Confusion?
Learn what type confusion is, how treating an object as the wrong type corrupts memory access, how attackers exploit type confusion in C++ and VMs, and how to prevent unsafe casts.
Definition
Type confusion is a vulnerability in which a program interprets a value or object as a different type than it actually is—often via unsafe casts—so field offsets and method tables are wrong, enabling out-of-bounds access, corrupted state, or code execution.
Why type confusion matters
Objects are layouts plus meaning. When code treats a buffer as a different layout, every field offset becomes a wrong guess—reads and writes land on unintended bytes.
Type Confusion is especially powerful in C++ engines and language runtimes because confused objects often carry vtables and length fields. One bad cast can become an arbitrary read/write primitive used in sandbox escapes.
How type confusion leads to compromise
Object exists with a real type
Memory holds a specific structure—say a small string or array object.
Code assumes a different type
An unsafe cast, missing tag check, or stale pointer treats it as another class.
Wrong offsets are applied
Field reads/writes and virtual calls use the incorrect layout.
Attacker shapes the real object
Controlled data is placed where the confused type expects pointers or lengths.
Primitive emerges
Out-of-bounds access or hijacked virtual calls yield memory corruption control.
Frequent type confusion sources
Unsafe downcasts
static_cast/reinterpret_cast without verifying dynamic type or tags.
Tagged union mistakes
Reading the wrong union member after a tag is corrupted or ignored.
UAF refill
A freed object of type A is replaced by type B; stale code still uses A’s API.
Deserializer lies
Serialized type IDs are trusted without matching the actual payload shape.
Defenses that work
| Control | Notes |
|---|---|
| Checked casts | Prefer dynamic_cast/RTTI or explicit tag checks before use |
| Sum types | Use variants/enums that force exhaustive handling of alternatives |
| Hardened runtimes | Enable type and bounds checks in VM/engine debug and fuzz builds |
| Lifetime safety | Eliminate UAF paths that swap object types under stale pointers |
| Fuzzing | Stress cast-heavy APIs and DOM/VM operations with weird inputs |
| Memory-safe languages | Remove most confusion classes outside unsafe FFI |
- Inventory reinterpret_cast and C-style casts on object pointers.
- Require tag or RTTI checks before every downcast on untrusted paths.
- Replace bare unions with tagged variants where possible.
- Fuzz engines and parsers that perform polymorphic dispatch.
- Enable ASan/UBSan on native components in CI.
- Review deserialization type ID handling for spoofable claims.
- Treat type-confusion crashes in browsers/VMs as high severity.
- Isolate risky native components behind sandboxes.
The practical takeaway
Type confusion interprets memory using the wrong type layout, turning casts into memory corruption. Verify types before you trust offsets and vtables.
If a cast is “just to make the compiler happy,” it is probably a security review item.
Related security terms
Use-After-Free
Freed slots refilled with different types often create type confusion primitives.
Out-of-Bounds Read
Wrong-type field access frequently reads past the real object.
Out-of-Bounds Write
Confused writes can corrupt neighboring memory or object headers.
Memory Corruption
Type confusion is a major memory corruption root cause in native runtimes.
Frequently asked questions
What is type confusion in simple terms?
The program believes an object is one kind of thing, but in memory it is another. When it reads “fields” using the wrong layout, it touches the wrong bytes—sometimes with attacker-controlled results.
Where does type confusion appear most?
C++ code with complex inheritance, browser engines, language VMs, deserializers, and any code that casts void* or tagged unions without checking tags.
How do attackers create type confusion?
By winning races, abusing bugs in cast checks, triggering use-after-free so a new object type occupies an old pointer, or supplying serialized data that claims the wrong type.
Is this the same as a bad cast in Java?
Managed runtimes usually check casts and throw exceptions. Type confusion as a memory corruption class is primarily about unchecked reinterpretation in unsafe languages or VM bugs that skip checks.
Why are vtables involved?
If code calls a virtual method on a confused object, it may use the wrong method table, jumping to attacker-influenced function pointers.
How do you prevent type confusion?
Avoid unsafe casts, validate type tags, prefer safe sum types, enable runtime checks in debug builds, and use memory-safe languages where practical.
How do you detect it?
ASan/UBSan, fuzzing, type sanitizers in some toolchains, and careful review of downcasts and union usage.
References
Explore authoritative guidance and frameworks related to type confusion.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.