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.

[vy]

@SunWeb3Sec, could you please fix the test failures? Make sure ./mvnw verify passes.

[SunWeb3Sec]

Updated — routed the affected readObject tests through SerialUtil / FilteredObjectInputStream so they pass the new assertFiltered check on Java 8.

[vy]

@SunWeb3Sec, see the failing CI results. Have you made sure ./mvnw verify?

[SunWeb3Sec]

Fixed — the Java 8 surefire run uses FilteredObjectInputStream, whose default allow-list covers org.apache.logging.log4j. but not the org.apache.log4j. 1.2 namespace, so LevelTest#testDeserializeINFO and #testCustomLevelSerialization failed with InvalidObjectException. Passed org.apache.log4j.Level and LevelTest$CustomLevel as allowedExtraClasses in SerializationTestHelper.

[vy]

Could you inline this to newObjectInputStream as a local variable, please? You can do if (ver == 8) { your-var-and-code-goes-here; } else { ... }. Keep the comments above the local var.

[vy]

@SunWeb3Sec, tests are still failing. Would you mind updating the PR and ensuring that ./mvnw verify passes locally before pushing your changes, please?