Passing mutable objects to an untrusted method

Revision as of 15:36, 4 November 2008 by KirstenS (Talk | contribs)

Jump to: navigation, search

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

ASDR Table of Contents

Last revision (mm/dd/yy): 11/4/2008


Sending non-cloned mutable data as an argument may result in that data being altered or deleted by the called function, thereby putting the calling function into an undefined state.


  • Integrity: Potentially data could be tampered with by another function which should not have been tampered with.

Exposure period

  • Implementation: This flaw is a simple logic issue, introduced entirely at implementation time.


  • Languages: C/C++ or Java
  • Operating platforms: Any

Required resources




Likelihood of exploit


In situations where unknown code is called with references to mutable data, this external code may possibly make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of execution.

Risk Factors



In C\C++:

  int foo.
  complexType bar;
  String baz;
  otherClass externalClass; 

  void doStuff() {
    externalClass.doOtherStuff(foo, bar, baz)

In this example, bar and baz will be passed by reference to doOtherStuff() which may change them.

Related Attacks

Related Vulnerabilities

Related Controls

  • Implementation: Pass in data which should not be alerted as constant or immutable.
  • Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way - regardless of what changes are made to the data - a valid copy is retained for use by the class.

Related Technical Impacts


Note: A reference to related CWE or CAPEC article should be added when exists. Eg: