Monkepatching

How monkey patching works

Monkey patching changes behaviour at runtime by replacing or wrapping code that is already loaded, rather than editing the original source. Because the change happens in memory, it can alter how a function, method, or object behaves for the entire process, which makes it powerful for instrumentation, compatibility shims, and rapid experimentation.

The technique depends on the runtime model of the language or framework. In dynamic environments, names and references can often be reassigned, intercepted, or decorated after import or load time. That flexibility is the reason monkey patching exists, but it also means the resulting behaviour may differ from what the original code author expected.

Why monkey patching is used

Developers use monkey patching when they need to change behaviour without forking a dependency, waiting for an upstream fix, or modifying code that is generated, vendored, or externally managed. It is often seen in tests, temporary compatibility layers, hotfixes, debugging, and observability tooling where the goal is to alter execution just enough to solve a specific problem.

It is usually a tactical choice, not a design ideal. The convenience of a runtime override comes with reduced clarity about where behaviour originates, which can make later maintenance harder. In well-disciplined codebases, monkey patching is typically kept narrow, documented, and time-bounded so that it does not become an invisible dependency.

Security and reliability implications

Monkey patching can change control flow in ways that are difficult to reason about, especially when several libraries depend on the same object or function. A patched method may bypass validation, alter logging, weaken error handling, or subtly change trust boundaries if the override is broader than intended. The same flexibility that makes it useful for adaptation can also make it risky in production.

It is especially important to treat patched code as part of the attack surface when the runtime loads untrusted extensions, plugins, or third-party packages. A malicious or compromised dependency that patches core behaviour can manipulate security checks, capture sensitive data, or redirect execution. The risk is not the technique itself, but the fact that runtime mutation can hide material changes from ordinary code review and static analysis.

How to recognise appropriate use

Monkey patching is most defensible when the change is narrowly scoped, easy to trace, and reversible. A patch that supports testing, logging, or a short-lived compatibility bridge is easier to justify than one that silently rewrites foundational behaviour in a live service. The more central the patched function is to security, data handling, or access decisions, the less comfortable the pattern should be.

Teams should also distinguish between a deliberate patch and an accidental override. In dynamic runtimes, import order, shared global state, and naming collisions can create behaviour changes that look like patches even when nobody intended them. That makes configuration discipline and change visibility important, not just code correctness.

Practitioner guidance

Governance implication: Treat monkey patching as an exception path that needs ownership, review, and expiry. If a patch affects authentication, authorisation, logging, or data handling, it should be reviewed with the same care as any other code that changes security behaviour.

What to watch for: Prefer explicit wrappers, dependency injection, or versioned upstream fixes when those options exist. If monkey patching is unavoidable, keep the patch local, document the reason, and make the override easy to find and remove.