You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
This CVE has been marked Rejected in the CVE List. These CVEs are stored in the NVD, but do not show up in search results by default.
Description
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Initially assigned to document an issues that allows guest VM to modify the host’s Vagrantfile via default synced folder, leading to host-side code execution. Rejected as CVE due to documented, intended behavior that does not violate a claimed security boundary. https://developer.hashicorp.com/vagrant/docs/synced-folders
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Initially assigned to document an issues that allows guest VM to modify the host’s Vagrantfile via default synced folder, leading to host-side code execution. Rejected as CVE due to documented, intended behavior that does not violate a claimed security boundary. https://developer.hashicorp.com/vagrant/docs/synced-folders
CVE Modified by VulnCheck7/09/2025 9:15:27 PM
Action
Type
Old Value
New Value
Changed
Description
An authenticated virtual machine escape vulnerability exists in HashiCorp Vagrant when using the default synced folder configuration. By design, Vagrant automatically mounts the host system’s project directory into the guest VM under /vagrant (or C:\vagrant on Windows). This includes the Vagrantfile configuration file, which is a Ruby script evaluated by the host every time a vagrant command is executed in the project directory. If a low-privileged attacker obtains shell access to the guest VM, they can append arbitrary Ruby code to the mounted Vagrantfile. When a user on the host later runs any vagrant command, the injected code is executed on the host with that user’s privileges.
While this shared-folder behavior is well-documented by Vagrant, the security implications of Vagrantfile execution from guest-writable storage are not explicitly addressed. This effectively enables guest-to-host code execution in multi-tenant or adversarial VM scenarios.
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
New CVE Received from VulnCheck7/02/2025 4:15:29 PM
Action
Type
Old Value
New Value
Added
Description
An authenticated virtual machine escape vulnerability exists in HashiCorp Vagrant when using the default synced folder configuration. By design, Vagrant automatically mounts the host system’s project directory into the guest VM under /vagrant (or C:\vagrant on Windows). This includes the Vagrantfile configuration file, which is a Ruby script evaluated by the host every time a vagrant command is executed in the project directory. If a low-privileged attacker obtains shell access to the guest VM, they can append arbitrary Ruby code to the mounted Vagrantfile. When a user on the host later runs any vagrant command, the injected code is executed on the host with that user’s privileges.
While this shared-folder behavior is well-documented by Vagrant, the security implications of Vagrantfile execution from guest-writable storage are not explicitly addressed. This effectively enables guest-to-host code execution in multi-tenant or adversarial VM scenarios.