--- title: "Block DYLD Environment Variable Injection | Security Cookbook" description: "Block DYLD_INSERT_LIBRARIES and other dyld environment variables to prevent code injection into third-party macOS applications." doc_version: "1" last_updated: "2026-05-22" canonical: "https://northpole.security/cookbook/block-dyld-injection" --- [Back](https://northpole.security/cookbook) ### Idea macOS uses the dynamic linker (dyld) to load libraries at runtime. Several environment variables can be used to inject malicious code into running processes without modifying the binary itself. This is a powerful attack technique that bypasses many security controls. The most dangerous environment variables are: - DYLD\_INSERT\_LIBRARIES: Forces dyld to load additional libraries into every process - DYLD\_LIBRARY\_PATH: Hijacks library search paths to load malicious versions - DYLD\_FORCE\_FLAT\_NAMESPACE: Disables two-level namespace lookup, enabling symbol interposition As documented by Csaba Fitzl at VirusBulletin 2021, these environment variables allow attackers to inject code into any process, including privileged system services. The injected code runs with the same privileges as the target process. dyld strips these variables from any binary protected by System Integrity Protection (SIP) or launched with the hardened runtime, which covers Apple platform binaries and most modern signed third-party apps. Binaries without the hardened runtime remain vulnerable. Some apps explicitly opt back into DYLD env var handling by adding hardened-runtime exception entitlements to their code signature: - `com.apple.security.cs.allow-dyld-environment-variables`: tells dyld to honor DYLD\_\* variables despite the hardened runtime - `com.apple.security.cs.disable-library-validation`: lets the process load libraries not signed by Apple or the same Team ID, which is what an injected `DYLD_INSERT_LIBRARIES` payload typically needs These exceptions are common in apps that ship plugins, JIT compilers, or scripting hosts — Electron apps, IDEs, and debugging tools often request them. Apps with either entitlement are the prime targets for the rules below; author one rule per app you want to protect, using its specific signing ID. A CEL rule can then detect when the process is launched with a dangerous DYLD environment variable set and block execution. ### Solutions ExecutionBlock DYLD\_INSERT\_LIBRARIES Prevent execution when DYLD\_INSERT\_LIBRARIES is set Signing ID TEAMID:com.your-org.your-app CEL Expression has(env.DYLD\_INSERT\_LIBRARIES) ? BLOCKLIST : ALLOWLIST Copy Custom Message Execution with DYLD\_INSERT\_LIBRARIES is not allowed ExecutionBlock DYLD\_LIBRARY\_PATH Prevent execution when DYLD\_LIBRARY\_PATH is set Signing ID TEAMID:com.your-org.your-app CEL Expression has(env.DYLD\_LIBRARY\_PATH) ? BLOCKLIST : ALLOWLIST Copy Custom Message Execution with DYLD\_LIBRARY\_PATH is not allowed ExecutionBlock DYLD\_FORCE\_FLAT\_NAMESPACE Prevent execution when DYLD\_FORCE\_FLAT\_NAMESPACE is set Signing ID TEAMID:com.your-org.your-app CEL Expression has(env.DYLD\_FORCE\_FLAT\_NAMESPACE) ? BLOCKLIST : ALLOWLIST Copy Custom Message Execution with DYLD\_FORCE\_FLAT\_NAMESPACE is not allowed ExecutionBlock All Dangerous DYLD Variables (Combined) Block all dangerous DYLD environment variables in one rule Signing ID TEAMID:com.your-org.your-app CEL Expression has(env.DYLD\_INSERT\_LIBRARIES) || has(env.DYLD\_LIBRARY\_PATH) || has(env.DYLD\_FORCE\_FLAT\_NAMESPACE) || has(env.DYLD\_FRAMEWORK\_PATH) || has(env.DYLD\_VERSIONED\_FRAMEWORK\_PATH) || has(env.DYLD\_VERSIONED\_LIBRARY\_PATH) ? BLOCKLIST : ALLOWLIST Copy Custom Message Execution with dangerous DYLD environment variables is not allowed ### Mitre Attack Tactics [Privilege Escalation](https://attack.mitre.org/tactics/TA0004/)[Stealth](https://attack.mitre.org/tactics/TA0005/)[Execution](https://attack.mitre.org/tactics/TA0002/) Techniques [T1055: Process Injection](https://attack.mitre.org/techniques/T1055/)[T1574.006: Dynamic Linker Hijacking](https://attack.mitre.org/techniques/T1574/006/) ### Tags dyldcode-injectionenvironment-variableslibrary-injection ### Deployment Notes These rules prevent any process from launching with dangerous DYLD environment variables set. You can deploy individual rules or use the combined rule that catches all dangerous DYLD variables. Important considerations: - Platform binaries are already protected by SIP and won't be affected - Legitimate development use cases may need these variables (debugging, profiling) - Consider using Workshop tags to exempt developer machines - The combined rule is recommended for simplicity Note: This does NOT protect against: - Direct modification of libraries on disk - Code injection via other mechanisms (thread injection, etc.) - Attacks that set these variables before Santa loads ### False Positive Guidance Legitimate uses of these environment variables: - Software developers debugging applications with custom libraries - Performance profiling tools using instrumentation libraries - Development frameworks that inject debugging helpers - Testing environments that need to override system libraries Consider: - Exempting developer machines using Workshop tags - Creating approval workflows for development use - Allowing specific development tools by their signing ID ### Testing Instructions 1. Try to run a command with DYLD\_INSERT\_LIBRARIES: `DYLD_INSERT_LIBRARIES=/path/to/lib.dylib /bin/ls` (should be blocked) 2. Verify normal execution works: `/bin/ls` (should work) 3. Test with DYLD\_LIBRARY\_PATH: `DYLD_LIBRARY_PATH=/tmp /bin/ls` (should be blocked) 4. Check that legitimate apps run normally without these variables ### Detection Methods Monitor CEL execution events for blocked DYLD variable usage. Any attempt to use these variables outside of approved development contexts is highly suspicious. Investigation steps: - Check which binary was attempting to launch - Identify the parent process that set the environment variable - Review the library path being injected - Determine if this is legitimate development activity ### Resources [Csaba Fitzl: Mitigating Exploits Using Apple ESTake a look](https://theevilbit.github.io/talks_workshops/2021/VirusBulletin2021-Fitzl-mitigating-exploits-using-Apple-es-WP.pdf)[MITRE ATT&CK - Dynamic Linker HijackingTake a look](https://attack.mitre.org/techniques/T1574/006/)[Apple Developer - Dynamic Library Programming TopicsTake a look](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/) ### Related Rules [ Execution ControlExecution #### Prevent Code Injection in Electron Apps Block Chrome remote debugging ports and Electron inspect flags to stop attackers from injecting malicious code into already-approved applications. ](https://northpole.security/cookbook/prevent-electron-code-injection)[ Execution ControlFile Access #### Prevent In-Memory Code Execution Block dyld from loading code via NSCreateObjectFileImageFromMemory temp files, raising the bar for in-memory execution and reflective loaders. ](https://northpole.security/cookbook/prevent-in-memory-execution) ## Sitemap - [Home](https://northpole.security/index.md) - [Workshop](https://northpole.security/workshop.md) - [Santa](https://northpole.security/santa.md) - [Features](https://northpole.security/features.md) - [Cookbook](https://northpole.security/cookbook.md) - [Docs](https://northpole.security/docs.md) - [Blog](https://northpole.security/blog.md) - [Glossary](https://northpole.security/glossary.md) - [About](https://northpole.security/about.md) - [Contact](https://northpole.security/contact.md)