Harden ObjectArrayMessage deserialization with SerializationUtil.assertFiltered

[SunWeb3Sec]

Harden ObjectArrayMessage.readObject() with SerializationUtil.assertFiltered()

Summary

Adds a single SerializationUtil.assertFiltered(in) call at the top of ObjectArrayMessage.readObject(), bringing it in line with the defensive pattern already used by ObjectMessage and ParameterizedMessage.

Change

log4j-api/.../message/ObjectArrayMessage.java

Before

private void readObject(final ObjectInputStream in) throws IOException, ClassNotFoundException {
    in.defaultReadObject();
    array = (Object[]) in.readObject();
}

After

private void readObject(final ObjectInputStream in) throws IOException, ClassNotFoundException {
    SerializationUtil.assertFiltered(in);
    in.defaultReadObject();
    array = (Object[]) in.readObject();
}

Plus the corresponding import org.apache.logging.log4j.util.internal.SerializationUtil;.

What this PR deliberately does not do

• Does not change the serialized wire format — ObjectArrayMessage instances produced by older versions still deserialize into a patched version, and vice versa.
• Does not touch LocalizedMessage or FormattedMessage. They have similar gaps, but the Log4j security team scoped this request to ObjectArrayMessage only. Happy to submit follow-up PRs for those if desired.
• Does not modify existing tests (LocalizedMessageTest#testSerialization*, FormattedMessageTest#testSerialization) that use plain ObjectInputStream, because those classes are untouched.

Tests

Added a minimal round-trip test (ObjectArrayMessageTest#testSerializableRoundTripThroughFilteredStream) that serializes and deserializes through SerialUtil, which uses FilteredObjectInputStream on Java 8 — verifying the new assertFiltered() call accepts filtered streams.

Behavioral note

On Java 8, deserializing an ObjectArrayMessage through a plain ObjectInputStream (no JEP 290 filter) now throws IllegalArgumentException instead of silently proceeding. This matches the existing behavior of ObjectMessage and ParameterizedMessage. Callers that relied on unfiltered deserialization of ObjectArrayMessage should wrap their streams in FilteredObjectInputStream, matching the project's guidance for the sibling message types.

On Java 9+, the behavior is unchanged — assertFiltered() is a no-op when a JVM-level ObjectInputFilter is active, and a warning otherwise.

Checklist

• Single class changed (ObjectArrayMessage)
• No wire format change
• No new public API
• No new dependencies
• Unit test added
• Changelog entry: src/changelog/.2.x.x/harden_message_deserialization.xml (type changed)

References

• Private discussion with the Apache security team (closed as Informative — not a vulnerability; code-quality improvement welcomed).
• Hardened siblings for reference:
  • ObjectMessage#readObject
  • ParameterizedMessage#readObject

Thanks to the Apache security team for the clear triage.

[vy]

@SunWeb3Sec, would you mind applying this DiD in all private void readObject\((final )?ObjectInputStream hits, please? You can skip tests, just do the necessary changes along with a very brief change log entry.

[SunWeb3Sec]

@vy Done, broadened to all private void readObject(ObjectInputStream) hits across the listed modules. Please review. thanks

[vy]

@SunWeb3Sec, thanks so much for the contribution and prompt reaction. Changes LGTM.