CWE-1123 is the use of too much self-modifying code, meaning programs that change their own instructions while running. MITRE places it under excessive code complexity (CWE-1120) and marks it as allowed for mapping, with the usual advice to read the name and description before choosing it.
How it happens
Self-modification shows up in performance tricks, in obfuscation, in plugin and patching systems, and in dynamic code generation. Each use has a reason. The weakness is the accumulation: a codebase where what runs is not what was written.
What an attacker gains
MITRE lists reduced maintainability and increased analytical complexity. The issue makes the product harder to understand and maintain, which indirectly affects security by making vulnerabilities more difficult or time-consuming to find and fix, and might make them easier to introduce.
Reviewers and scanners read the source. If behaviour at runtime differs from the source, they are reviewing something other than what executes.
How to find it
The record lists no detection methods. Search for runtime code generation and modification: eval, exec, dynamic loading, writable and executable memory, and patching of function tables. Review each one and ask whether a static alternative exists.
How to fix it
The record has no formal mitigations. Prefer data-driven design, where configuration changes behaviour rather than code. Where dynamic code is needed, confine it to one reviewed module, avoid building code from external input, and keep the generated output loggable and testable.
Quick check
Why is self-modifying code hard to audit?
Because the code a reviewer reads is not necessarily the code that runs.
