[Rd] unsafe parsing of DESCRIPTION Authors maybe from R

[Levi Waldron]

Thanks, Simon. Just to clarify:

> there are numerous ways that R code can be evaluated (Authors using R is just
one of several examples), this is well known and not unexpected. After all,
you can simply call source() or eval() at any point, so it is not clear
what threat model you have in mind. (BTW: your GitHub page requires 3rd
party package so I fail to see the point as you can always install a
package that does anything).

A scenario I had in mind was that the CRAN incoming package server sends an
immediate email containing a confirmation link and an interpreted version
of DESCRIPTION, prior to any build/check. If that server is using
desc::description or utils:::.read_authors_at_R_field, then this might
provide an attacker an efficient way to modify trusted packages in the
queue before they're sent to build servers.

BTW the example demonstrated arbitrary code execution when 1) installing a
package with no dependencies and no R/, src/, tests/, or other code outside
of its DESCRIPTION, and 2) parsing its DESCRIPTION file using
desc::description without installing it, but it would apply to anything
else that results in utils:::.read_authors_at_R_field(). I was surprised
that arbitrary code execution can happen when installing but before loading
a package, or when parsing its DESCRIPTION without ever installing it, but
if that introduces no new risks, I'm glad to hear it.

Sincerely,
Levi

On Tue, Apr 7, 2026 at 1:06 AM Simon Urbanek <simon.urbanek using r-project.org>
wrote:

> Levi,
>
> there are numerous ways that R code can be evaluated (Authors using R is just
> one of several examples), this is well known and not unexpected. After all,
> you can simply call source() or eval() at any point, so it is not clear
> what threat model you have in mind. (BTW: your GitHub page requires 3rd
> party package so I fail to see the point as you can always install a
> package that does anything). By definition, installing a package or running
> R code gives the user full access to R and the system - so adding a
> system() doesn't do anything new - if you can run R code then you could
> have simply written system() yourself instead.
>
> I understand where you are coming from, but it should be expected that
> anything that deals with packages is by design executing code from the
> package, so you can always create a malicious package - by design. That
> doesn't mean that we shouldn't strive to limit eval()s or to perform
> validity checks, but this is not practical in all instances, because R
> relies heavily on the ability to run R code in those instances - by design.
> For example, some use a canonical document in the package that is parsed
> when creating the authors list instead of embedding it directly in the
> DESCRIPTION. We could disallow that and limit the language (funnily, we
> discussed exactly this case last year in Vienna), but this is just one of
> many use-cases of this approach, there are several others in the packages
> toolbox. You can always find internal R functions that do various tasks
> using eval(), so I think the starting premise that this shouldn't happen is
> simply wrong. The only way you can get something "safe" is to disallow R
> code and only enable very specific API (like REST or OCAP), anything else
> is free for all by design.
>
> Cheers,
> Simon
>
>
> > On 7 Apr 2026, at 15:32, Levi Waldron <lwaldron.research using gmail.com>
> wrote:
> >
> > This issue arose during an AI-assisted security review of core
> Bioconductor
> > packages, that an attacker could execute arbitrary code on any system
> that
> > calls `utils:::.read_authors_at_R_field()` or other tools for parsing a
> > DESCRIPTION file,  regardless of whether it installs, builds, or checks
> the
> > package. I put some details and a reprex at
> > https://github.com/lwaldron/nothing/tree/check-vulnerability. Let me
> know
> > if you'd prefer I take the github page down.
> >
> > This seems worse than the inherent .onLoad(), tests/, etc
> vulnerabilities,
> > because it can be exploited in environments not intended to install or
> > check packages or run their code, like the CRAN incoming package queue
> > which does seem to parse the DESCRIPTION file.
> >
> > -Levi
> >
> > --
> >
> > Levi Waldron
> >
> > Professor and Chair
> >
> > Department of Epidemiology and Biostatistics
> >
> > CUNY Graduate School of Public Health and Health Policy
> >
> > Institute for Implementation Science in Population Health
> >
> > 55 W 125th St, New York NY 10035
> >
> > https://waldronlab.io
> >
> > Join the microbiome Virtual International Forum:
> https://microbiome-vif.org
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>

-- 

Levi Waldron

Professor and Chair

Department of Epidemiology and Biostatistics

CUNY Graduate School of Public Health and Health Policy

Institute for Implementation Science in Population Health

55 W 125th St, New York NY 10035

https://waldronlab.io

Book a meeting with me <https://bit.ly/meetlw>

Join the microbiome Virtual International Forum: https://microbiome-vif.org

	[[alternative HTML version deleted]]