When XStream deserializes collection types such as PersistedList and CopyOnWriteList, it does not validate the types of the elements of those collections. This means that even if the serialized data is invalid or corrupted (for example there is a String in a list of Integer), the collection is able to be deserialized with no errors. However, any usage of the collection after it has been deserialized that causes it to reference to invalid element will throw a ClassCastException.
Errors of this sort can be very problematic (for example, an invalid element in Job.properties breaks all permission checks on that Job, which in turn breaks Folders and Views which contain that job) and normally require a Jenkins restart to fix.
This kind of issue can occur in a few ways, here are the ones that come to mind:
- Endpoints like AbstractItem.doConfigDotXml
- Complex callers of AbstractItem.updateByXml that give users a high level of control over the input (e.g. the proprietary CloudBees Templates plugin)
- Manual edits to XML files in JENKINS_HOME
Ideally, in these scenarios, either the deserialization process itself would fail, or it would capture some kind of warning with regard to the invalid element (Maybe OldDataMonitor is relevant?), and would remove the element from the collection.
A possible fix mentioned by jglick would be to update collection classes that have custom Converter implementations like PersistedList and CopyOnWriteList with a new transient field of type Class that holds the type that all elements of the collection must be an instance of, so that their converters can validate each element during deserialization.
Originally reported by 
dnusbaum, imported from: Collections loaded via XStream do not validate the runtime type of their elements
- assignee: dnusbaum
- status: Resolved
- priority: Minor
- component(s): core
- label(s): 2.492.1-fixed, robustness, xstream
- resolution: Fixed
- resolved: 2024-10-11T18:44:03+00:00
- votes: 0
- watchers: 3
- imported: 2025-11-24
Raw content of original issue
When XStream deserializes collection types such as PersistedList and CopyOnWriteList, it does not validate the types of the elements of those collections. This means that even if the serialized data is invalid or corrupted (for example there is a String in a list of Integer), the collection is able to be deserialized with no errors. However, any usage of the collection after it has been deserialized that causes it to reference to invalid element will throw a ClassCastException.
Errors of this sort can be very problematic (for example, an invalid element in Job.properties breaks all permission checks on that Job, which in turn breaks Folders and Views which contain that job) and normally require a Jenkins restart to fix.
This kind of issue can occur in a few ways, here are the ones that come to mind:
- Endpoints like AbstractItem.doConfigDotXml
- Complex callers of AbstractItem.updateByXml that give users a high level of control over the input (e.g. the proprietary CloudBees Templates plugin)
- Manual edits to XML files in JENKINS_HOME
Ideally, in these scenarios, either the deserialization process itself would fail, or it would capture some kind of warning with regard to the invalid element (Maybe OldDataMonitor is relevant?), and would remove the element from the collection.
A possible fix mentioned by jglick would be to update collection classes that have custom Converter implementations like PersistedList and CopyOnWriteList with a new transient field of type Class<T> that holds the type that all elements of the collection must be an instance of, so that their converters can validate each element during deserialization.
When XStream deserializes collection types such as PersistedList and CopyOnWriteList, it does not validate the types of the elements of those collections. This means that even if the serialized data is invalid or corrupted (for example there is a String in a list of Integer), the collection is able to be deserialized with no errors. However, any usage of the collection after it has been deserialized that causes it to reference to invalid element will throw a ClassCastException.
Errors of this sort can be very problematic (for example, an invalid element in Job.properties breaks all permission checks on that Job, which in turn breaks Folders and Views which contain that job) and normally require a Jenkins restart to fix.
This kind of issue can occur in a few ways, here are the ones that come to mind:
Ideally, in these scenarios, either the deserialization process itself would fail, or it would capture some kind of warning with regard to the invalid element (Maybe OldDataMonitor is relevant?), and would remove the element from the collection.
A possible fix mentioned by jglick would be to update collection classes that have custom Converter implementations like PersistedList and CopyOnWriteList with a new transient field of type Class that holds the type that all elements of the collection must be an instance of, so that their converters can validate each element during deserialization.
Originally reported by
dnusbaum, imported from: Collections loaded via XStream do not validate the runtime type of their elements
Raw content of original issue
Ideally, in these scenarios, either the deserialization process itself would fail, or it would capture some kind of warning with regard to the invalid element (Maybe OldDataMonitor is relevant?), and would remove the element from the collection.
A possible fix mentioned by jglick would be to update collection classes that have custom Converter implementations like PersistedList and CopyOnWriteList with a new transient field of type Class<T> that holds the type that all elements of the collection must be an instance of, so that their converters can validate each element during deserialization.