Python Class Pollution is the corruption of a Python class’s attributes through unsafe object deserialisation or attribute assignment, causing unintended behaviour in all instances of that class. Attackers may alter control flow, disable checks or redirect sensitive actions. Defenders should avoid unsafe deserialisation, constrain dynamic attribute writes and validate object graphs before use.
How Python Class Pollution Works
Python class pollution happens when unsafe deserialisation or unchecked attribute assignment corrupts a class rather than just one object. Because class attributes are shared, the poisoned value can change behaviour across every instance that later reads it.
This is dangerous because the modified class can alter control flow, bypass validation, suppress security checks or send sensitive operations down an attacker-chosen path. The problem is not limited to a single malformed payload, it becomes a shared-state integrity issue.
Why Shared Class State Makes It Dangerous
Class pollution is especially damaging when code assumes class-level defaults are trustworthy. A single write to a class attribute can ripple through object creation, request handling or business logic that reuses that class anywhere in the process.
The practical impact is broader than ordinary object corruption. If a class stores permission flags, callback targets, feature gates or policy references, poisoning that class can silently change how every future instance behaves without breaking the program in an obvious way.
Where Unsafe Deserialisation and Dynamic Writes Create Exposure
The usual exposure points are deserialisation paths that rebuild Python objects from untrusted input and helper functions that assign attributes from attacker-controlled data. Problems often appear when frameworks allow nested object graphs, automatic field binding or generic update logic that never checks whether the target is a class attribute.
Secure Coding Guide is the right baseline for this class of flaw because the defence starts with rejecting unsafe object reconstruction and constraining reflective writes. Good secure coding practice treats object graphs as untrusted until they are validated.
Defenders should also verify that sensitive classes cannot be reached through unexpected input paths. Even when the original payload seems harmless, a polluted class can become the hidden state change that makes later code misbehave.
Detection, Containment and Recovery After Pollution
Detection usually depends on noticing behaviour changes rather than a visible error, because the application may keep running with subtly altered logic. Review deserialisation entry points, trace unexpected attribute changes and compare runtime class state against the expected schema or object model.
After remediation, restart affected processes if class state may have persisted in memory, then review whether any security decision, outbound action or access check relied on the modified class. Where the class influences authentication, authorisation or privileged actions, treat the incident as a possible integrity compromise rather than a simple coding defect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V5 — File Handling | Class pollution often begins with unsafe object deserialisation and object graph handling. |
| Recommendation — Avoid unsafe deserialisation and validate reconstructed object graphs before use. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The term concerns secure coding defects in application logic and object handling. |
| Recommendation — Review deserialisation and dynamic attribute assignment for unsafe mutation paths. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw is triggered when untrusted input is accepted into object attributes or graphs. |
| Recommendation — Validate external data before it can change object or class state. | ||
| OWASP SAMM | Implementation — Implementation | Secure coding practices must prevent unsafe object mutation and deserialisation patterns. |
| Recommendation — Build secure coding checks that reject reflective writes to shared class state. | ||
| OWASP API Security Top 10 | API8 Security Misconfiguration — Security Misconfiguration | APIs and serializers can expose mutation surfaces that let attackers alter shared runtime state. |
| Recommendation — Harden API binding and serializer behaviour to prevent attacker-controlled attribute writes. | ||
Practitioner Guidance
Why practitioners should care: Python class pollution is a code integrity problem with cross-instance blast radius, so a single unsafe write can affect many requests, users or transactions. The key judgement is to treat class attributes as shared mutable state and to review any code path that mutates them from external input.
What to watch for: Pay close attention to generic deserialisers, ORM-style mass assignment, recursive object binding and helper utilities that copy arbitrary keys onto objects. These are the places where attacker-controlled data most often crosses the boundary from instance data into class-wide behaviour.
Related resources from NHI Mgmt Group
- What breaks when machine identities are not governed like first-class identities?
- What breaks when a prototype pollution bug combines with a request-building library?
- What breaks when enterprise agents are not treated as first-class identities?
- How should security teams choose between JWT, Redis, and database sessions for Python apps?