From f2ea3b98d884a376a3b2c4e6f5a7c975a84b5bfb Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan <62447351+owen-mc@users.noreply.github.com> Date: Thu, 7 May 2026 10:58:35 +0100 Subject: [PATCH] Do not make such a strong security claim Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .../src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/java/ql/src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp b/java/ql/src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp index 65848104ae3..ff235670496 100644 --- a/java/ql/src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp +++ b/java/ql/src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp @@ -21,10 +21,11 @@ Jackson, Jabsorb, Jodd JSON, Flexjson, Gson, JMS, and Java IO serialization thro

Note that a deserialization method is only dangerous if it can instantiate arbitrary classes. Serialization frameworks that use a schema to instantiate -only expected, predefined types are generally safe and are not tracked by this -query. For example, Apache Avro's deserialization methods follow a schema and -therefore cannot instantiate arbitrary classes, making them safe to use even -with untrusted data. +only expected, predefined types are generally not tracked by this query. For +example, Apache Avro's deserialization methods follow a schema and are +therefore generally safe with respect to arbitrary-class-instantiation and +gadget-chain attacks when the schema is trusted and does not permit +user-controlled type resolution.