simplemessageconverter 默认不安全,因依赖 jdk 原生序列化,存在反序列化任意类风险(如 cve-2023-34050),且无法跨语言/版本兼容;它仅适用于 amqp 基础类型,传 pojo 会触发危险序列化,生产环境必须替换为 jackson2jsonmessageconverter 或显式加固。

SimpleMessageConverter 默认不安全,生产环境必须替换或显式加固。它依赖 JDK 原生序列化,既无法跨语言/跨版本兼容,又会在反序列化时无条件加载任意类——CVE-2023-34050 就源于此。Spring Boot 2.2+ 已默认禁用未白名单类的反序列化,但只要没配 allowed-classes 或换掉转换器,SimpleMessageConverter 仍会尝试反序列化,直接抛 ClassNotFoundException 或触发安全拦截。
为什么 SimpleMessageConverter 在 Spring Boot 中默认“危险”
它不是设计来传业务对象的,而是为 AMQP 协议层基础类型(byte[]、String)服务的。一旦你往 RabbitTemplate.convertAndSend() 里传一个自定义 POJO,它就会调用 SerializationUtils.serialize(),把类名、字段值、甚至类字节码一起打成二进制塞进 Message.body。消费者端一收到,就按 MessageProperties.contentType = "application/x-java-serialized-object" 去反序列化——前提是本地 classpath 里得有那个类;否则报 ClassNotFoundException;更糟的是,如果攻击者能控制消息内容,还能注入恶意类执行任意代码。
常见错误现象:
- 消费者启动时报
java.lang.ClassNotFoundException: com.example.order.OrderDTO,即使你确认 jar 包里有这个类 - 测试环境正常,上线后突然消费失败,日志只显示
Failed to convert message没有堆栈 - 启用
spring.rabbitmq.listener.simple.default-requeue-rejected=false后消息直接进死信队列,查不到具体原因
用 Jackson2JsonMessageConverter 替换的实操要点
这是最常用、最稳妥的替换方案,本质是把对象转成 JSON 字符串再发,彻底绕开 Java 序列化链路。但要注意几个关键点:
- 必须在 Spring 容器中声明一个
Jackson2JsonMessageConverter类型的@Bean,Spring Boot 的自动配置(RabbitAutoConfiguration)才会把它同时注入到RabbitTemplate和SimpleRabbitListenerContainerFactory - 发送端和消费端必须用同一个
MessageConverter,否则消费端用SimpleMessageConverter去解 JSON body,会直接报Cannot construct instance of java.util.LinkedHashMap类型错误 - 如果 DTO 里有
LocalDateTime等非标准类型,需提前注册JavaTimeModule,否则序列化失败
示例配置:
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本,重点修复了 Khepri 元数据存储相关问题,并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说,该版本兼容性和稳定性表现较好。
@Bean
public MessageConverter jackson2JsonMessageConverter() {
Jackson2JsonMessageConverter converter = new Jackson2JsonMessageConverter();
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.registerModule(new JavaTimeModule());
converter.setJsonObjectMapper(objectMapper);
return converter;
}
不换转换器,只加固 SimpleMessageConverter 的风险与限制
理论上可以保留 SimpleMessageConverter,仅通过配置白名单收紧反序列化范围,比如:
- 设置
spring.rabbitmq.listener.simple.allowed-classes=com.example.**—— 但该配置只对Jackson2JsonMessageConverter+@type多态反序列化生效,对SimpleMessageConverter无效 - 想让
SimpleMessageConverter安全,只能自己继承它并重写fromMessage(),在反序列化前校验ObjectInputStream的类名,但这已脱离 Spring AMQP 标准路径,维护成本高且容易漏掉边界 case - Spring 团队已在文档中明确建议:“Avoid using
SimpleMessageConverterfor custom domain objects”
换句话说:加固 SimpleMessageConverter 是条死胡同,不是配置问题,是机制缺陷。
最容易被忽略的兼容性陷阱
团队协作中,有人用 Jackson2JsonMessageConverter 发消息,有人还用默认 SimpleMessageConverter 消费,结果消息体是 JSON 字符串,却被当成二进制流去反序列化,报错信息极其隐晦,比如:
InvalidClassException: invalid descriptor for field-
StreamCorruptedException: invalid type code: 7B(0x7B 是{的 ASCII,说明 body 实际是 JSON)
这类问题不会在编译期暴露,只有运行时发消息才触发,且上下游日志对不上。真正要落地,必须统一团队的转换器声明方式,并在 CI 阶段检查 MessageConverter Bean 是否唯一存在。










