CAPEC-237
Escaping a Sandbox by Calling Code in Another Language
The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-237: Escaping a Sandbox by Calling Code in Another Language: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/237.html and https://cve.bz/cve/capec/237?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Probing] The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.
1 technique
- The attacker probes the target application to see whether calling code of another language is allowed within a sandbox.
[Analysis] The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.
1 technique
- The attacker analyzes the target application to get a list of cross code weaknesses in the standard libraries of the sandbox.
Experiment
They probe what they found.
[Verify the exploitable security weaknesses] The attacker tries to craft malicious code of another language allowed by the sandbox to verify the security weaknesses of the standard libraries found in the Explore phase.
1 technique
- The attacker tries to explore the security weaknesses by calling malicious code of another language allowed by the sandbox.
Exploit
They carry out the attack.
[Exploit the security weaknesses in the standard libraries] The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries verified in the Experiment phase. The attacker will be able to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox.
1 technique
- The attacker calls malicious code of another language to exploit the security weaknesses in the standard libraries.
Skills required
- High skill
The attacker must have a good knowledge of the platform specific mechanisms of signing and verifying code. Most code signing and verification schemes are based on use of cryptography, the attacker needs to have an understand of these cryptographic operations in good detail.
Resources required
None: No specialized resources are required to execute this type of attack.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Bypass Protection Mechanism | Access Control, Authorization | |
| Execute Unauthorized Commands | Authorization | Run Arbitrary Code |
| Gain Privileges | Accountability, Authentication, Authorization, Non-Repudiation |
Mitigations
Assurance: Sanitize the code of the standard libraries to make sure there is no security weaknesses in them.
Design: Use obfuscation and other techniques to prevent reverse engineering the standard libraries.
Assurance: Use static analysis tool to do code review and dynamic tool to do penetration test on the standard library.
Configuration: Get latest updates for the computer.
Weaknesses it exploits
- CWE-693 Protection Mechanism Failure
Recent CVEs with these weaknesses
- 6.5CVE-2026-18668
IBM Sterling File Gateway 6.2.1.0 through 6.2.1.2_1 and 6.2.2.0 - 6.2.2.1_1 could allow a remote attacker to perform protocol downgrade attacks due to a security misconfiguration.
- 3.6CVE-2026-102618
IBM i 7.6, 7.5, 7.4, and 7.3 could allow an authenticated user to indirectly disable system auditing, which they otherwise don't have authority to disable.
- 6.9CVE-2026-123556
ZcashFoundation Zebra from 4.5.0 before 7.0.0 contains a protection mechanism failure that bans honest peers by scoring mempool lock-time rejections at the ban threshold. Attackers can broadcast transactions locked until the current height…
- 5.5CVE-2025-55002
JupyterLab Desktop is the cross-platform desktop application for JupyterLab. Prior to 4.6.2-1, JupyterLab Desktop for macOS shipped with Electron's RunAsNode fuse enabled, allowing ELECTRON_RUN_AS_NODE to execute arbitrary Node.js code in …
- 5.5CVE-2025-54991
JupyterLab Desktop is the cross-platform desktop application for JupyterLab. Prior to 4.6.2-1, JupyterLab Desktop for macOS declared the com.apple.security.cs.allow-dyld-environment-variables entitlement, allowing the dynamic linker to hon…
- 8.2CVE-2026-119170
There was a regression in how FIPS algorithms were enforced for the hashlib module. Only users that are using OpenSSL in FIPS mode are affected. Only Python 3.14.10 is affected, all other Python versions are unaffected.
- –CVE-2026-83494
A flaw was found in the training-operator. An incorrect object casting in the PyTorchJob ValidateUpdate webhook allows users to bypass an immutability check. This vulnerability could enable users to detach a queued job from its quota manag…
- –CVE-2026-103863
Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache Sling Engine. Content-Type, charset, and redirect changes from an included component evade the protectheaders / checkcontenttype …
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-480 Escaping Virtualization
Examples
Exploit: Java/ByteVerify.C is a detection of malicious code that attempts to exploit a vulnerability in the M…
Exploit: Java/ByteVerify.C is a detection of malicious code that attempts to exploit a vulnerability in the Microsoft Virtual Machine (VM). The VM enables Java programs to run on Windows platforms. The Microsoft Java VM is included in most versions of Windows and Internet Explorer. In some versions of the Microsoft VM, a vulnerability exists because of a flaw in the way the ByteCode Verifier checks code when it is initially being loaded by the Microsoft VM. The ByteCode Verifier is a low level process in the Microsoft VM that is responsible for checking the validity of code - or byte code - as it is initially being loaded into the Microsoft VM. Java/ByteVerify.C attempts to download a file named "msits.exe", located in the same virtual directory as the Java applet, into the Windows system folder, and with a random file name. It then tries to execute this specific file. This flaw enables attackers to execute arbitrary code on a user's machine such as writing, downloading and executing additional malware. This vulnerability is addressed by update MS03-011, released in 2003.
MITRE's words, unchanged: CAPEC-237 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.