VU#238194: R Programming Language implementations are vulnerable to arbitrary code execution during deserialization of .rds and .rdx files

CERT Security Advisory

A vulnerability in the R language that allows for arbitrary code to be executed directly after the deserialization of untrusted data has been discovered. This vulnerability can be exploited through RDS (R Data Serialization) format files and .rdx files. An attacker can create malicious RDS or .rdx formatted files to execute arbitrary commands on the victim’s target device.
R supports data serialization, which is the process of turning R objects and data into a format that can then be deserialized in another R session. This will provide a copy of the R objects from the original session.
The RDS format, which mainly comprises .rds files, is used to save and load serialized R objects. These objects are utilized to share states and transfer data sets across programs. They are not expected to run code when they are loaded by an R implementation unless prompted by the user. R Packages use .rdx files, which contain a list of offsets, lengths, and names, and are accompanied by a .rdb file, which is used to extract more information about those offsets. .rdx and .rdb files contain RDS formatted data within themselves. A .rds file functions similarly to a .rdx file but only allows for storing a single R object. When loading a .rds or .rdx file, the readRDS function is utilized. An R implementation using the readRDS function given that information will then read the offsets and load the data.
R supports lazy evaluation. This can be implemented through a type called Promise, which can be represented in the RDS format as PROMSXP. This type is used to manage expressions that are called and completed in a asynchronous manner when their associated values are needed to be used by the program. When constructing an unserialized object in this context from the RDS format, the Promise object will require three pieces of data. These are the value of the Promise, the expression, and the environment. This information is loaded by the eval function. The eval function in R takes an expression, in this case the Promise, and evaluates it within the environment specified.
The vulnerability occurs when the eval function evaluates a promise type that has an unevaluated value. The Promise expression will not be properly evaluated and will execute the expression when it is referenced in the program that contains it. A threat actor can include malicious code within a .rds or .rdx file that is referenced by an unevaluated value. When an R implemention loads a package that contains an .rds or .rdx file and the promise value is reached, it will execute the referenced code. This code is arbitrary and and will be executed prior to any opportunity for the victim to explore and see what functions or objects are within the file loaded.
An attacker can create malicious .rds and .rdx files and use social engineering to distribute those files to execute arbitrary code on the victim’s device. Projects that use readRDS on untrusted files are also vulnerable to the attack. Attackers can also leverage system commands to access resources available to the application and exfiltrate data from any environment available to the application on the target device. The code in the malicious files can also be used to access adjacent resources such other computers/devices, devices in a cluster and shared documents/folders available to the application.
Apply Updates
R project has provided R Core Version 4.4.0, which addresses the vulnerability. R Core version 4.4.0 now restricts promises in the serialization stream so that they are now used for implementing lazy evaluation. Apply the update at your earliest convenience.
Secure or Sandbox RDS file usage
Protect and use untrusted/third-party .rds, rdb, and .rdx files either in Containers or in a Sandbox environment to prevent unexpected access to resources.
Thanks to the reporter, Kasimir Schulz and Kieran Evans of HiddenLayer for reporting this vulnerability. This document was written by Christopher Cullen.

Vendor Information

One or more vendors are listed for this advisory. Please reference the full report for more information.


Other Information



Date Public:


Date First Published:

Date Last Updated:
2024-04-29 20:07 UTC

Document Revision:

About vulnerability notes
Contact us about this vulnerability
Provide a vendor statement


Leave a Reply

Your email address will not be published. Required fields are marked *