You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
StreamMessage should use the same "white list" mechanism as ObjectMessage to avoid some arbitrary code execution on deserialization.
Even though StreamMessage is supposed to handle only primitive types, it is still to possible to send a message that contains an arbitrary serializable instance. The consuming application application may then execute code from this class on deserialization.
The fix consists in using the list of trusted packages that can be set at the connection factory level.
The text was updated successfully, but these errors were encountered:
StreamMessage now uses the same "white list" mechanism as
ObjectMessage to avoid some arbitrary code execution on deserialization.
Even though StreamMessage is supposed to handle only primitive types,
it is still to possible to send a message that contains an arbitrary
serializable instance. The consuming application application may
then execute code from this class on deserialization.
The fix consists in using the list of trusted packages that can be
set at the connection factory level.
Fixes#135
StreamMessage now uses the same "white list" mechanism as
ObjectMessage to avoid some arbitrary code execution on deserialization.
Even though StreamMessage is supposed to handle only primitive types,
it is still to possible to send a message that contains an arbitrary
serializable instance. The consuming application application may
then execute code from this class on deserialization.
The fix consists in using the list of trusted packages that can be
set at the connection factory level.
Fixes#135
(cherry picked from commit f647e5d)
StreamMessage
should use the same "white list" mechanism asObjectMessage
to avoid some arbitrary code execution on deserialization.Even though
StreamMessage
is supposed to handle only primitive types, it is still to possible to send a message that contains an arbitrary serializable instance. The consuming application application may then execute code from this class on deserialization.The fix consists in using the list of trusted packages that can be set at the connection factory level.
The text was updated successfully, but these errors were encountered: