Summary
On macOS, JupyterLab Desktop versions up to and including v4.2.5-1 declared the com.apple.security.cs.allow-dyld-environment-variables entitlement, which permits the macOS dynamic linker to respect the DYLD_INSERT_LIBRARIES environment variable even when the application is signed with the hardened runtime. This allows a local attacker who is already able to execute code as the current user to load an arbitrary dynamic library (.dylib) into JupyterLab Desktop's process, inheriting any TCC (Transparency, Consent, and Control) permissions previously granted to the application, such as access to the user's Documents, Desktop, or Downloads folders, without triggering additional macOS permission prompts.
This issue affects macOS only and all versions prior to v4.6.2-1. Windows and Linux users are not affected.
Impact
This vulnerability does not allow remote code execution and does not provide an attacker with initial access to a system.
To exploit this issue, an attacker must already be able to execute code locally as the affected user. If JupyterLab Desktop has previously been granted access to TCC-protected resources, the attacker may load a malicious .dylib into JupyterLab Desktop's process and access those protected resources without triggering additional macOS permission prompts.
Users are primarily affected if all of the following conditions are true:
- they are using JupyterLab Desktop on macOS;
- JupyterLab Desktop has been granted access to TCC-protected resources (for example Documents, Desktop, or Downloads); and
- an attacker is already able to execute code as that user.
This vulnerability is most relevant in post-compromise scenarios, where an attacker attempts to expand access to data protected by macOS privacy controls.
Workarounds
There are no complete workarounds.
Users who cannot immediately upgrade may reduce exposure by revoking JupyterLab Desktop's access to protected resources in System Settings → Privacy & Security, removing the TCC permissions that an attacker would otherwise inherit. Upgrading remains the recommended mitigation.
References
SwayZGl1tZyyy Reporter
notluquis Remediation developer
krassowski Remediation reviewer
Summary
On macOS, JupyterLab Desktop versions up to and including v4.2.5-1 declared the
com.apple.security.cs.allow-dyld-environment-variablesentitlement, which permits the macOS dynamic linker to respect theDYLD_INSERT_LIBRARIESenvironment variable even when the application is signed with the hardened runtime. This allows a local attacker who is already able to execute code as the current user to load an arbitrary dynamic library (.dylib) into JupyterLab Desktop's process, inheriting any TCC (Transparency, Consent, and Control) permissions previously granted to the application, such as access to the user's Documents, Desktop, or Downloads folders, without triggering additional macOS permission prompts.This issue affects macOS only and all versions prior to v4.6.2-1. Windows and Linux users are not affected.
Impact
This vulnerability does not allow remote code execution and does not provide an attacker with initial access to a system.
To exploit this issue, an attacker must already be able to execute code locally as the affected user. If JupyterLab Desktop has previously been granted access to TCC-protected resources, the attacker may load a malicious
.dylibinto JupyterLab Desktop's process and access those protected resources without triggering additional macOS permission prompts.Users are primarily affected if all of the following conditions are true:
This vulnerability is most relevant in post-compromise scenarios, where an attacker attempts to expand access to data protected by macOS privacy controls.
Workarounds
There are no complete workarounds.
Users who cannot immediately upgrade may reduce exposure by revoking JupyterLab Desktop's access to protected resources in System Settings → Privacy & Security, removing the TCC permissions that an attacker would otherwise inherit. Upgrading remains the recommended mitigation.
References