weibo.com/1705822647/Lm0FY1WyS＃comment
imgur.com/KSkhaQO

不好意思，订正一下，据说是影响 jdk9 以上

imgur.com/tqghBeI

weibo.com/1865990891/Lm1i1b52c

啥漏洞能不能说清楚

这个时间点说清楚违法

不影响 JDK8 安心了

😂那能不能提供一个解决办法或者复现办法。。。

非长期支持版，有人在生产用？

这下有理由把那些老古董升个级了😂

是 JDK9 还是 JDK9+? JDK9 应该没什么人用了。

就问一句 jdk17 受不受影响，不影响就没事！

是这个吗 xz.aliyun.com/t/11114

不好意思，订正一下，据说是影响 jdk9 以上

还好 我们 gateway 我已经迁移到 nodejs 了，年初把 authserver 也迁移了，现在我们都是在 node.js 上面运行了！暂时不怕了

希望可以加速淘汰 spring ，这么多动态反射操作，又臭又长的各种配置
一个框架还搞个字符串形式的嵌入 dsl ，当时看到就觉得有病

twitter.com/Herdwolfman/status/1508683029811658754

是 spring mvc 的吧，还好不用

都在等一个英雄

啥漏洞啊 好慌啊

github.com/spring-projects/spring-framework/commit/3811cd4c0a0be3aac6e842cf1890610ce986449d
github.com/spring-projects/spring-framework/pull/28075

Spring Cloud Function SPEL 注入远程命令执行漏洞
排查参考： cn-sec.com/archives/853272.html
官方修复： github.com/spring-projects/spring-framework/commit/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529

没发现能直接利用的

说的不是 Spring Cloud 的呀

有人复现了 但是打码了

mmbiz.qpic.cn/mmbiz_png/sGfPWsuKAfdSdviblWkNAwlHD2UQ3yH0ibwOfu3IFbc83XIschNlkpV3SibxEcznXz19SUO3h09YOJMZbbbfoxz1A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

影响太小了，现在 80%以上的项目都在 jdk8 上

几天之前就有公开的 poc 了
github.com/cckuailong/spring-cloud-function-SpEL-RCE

不是同一个东西啊？

如果是这个 RCE 的话，感觉是搞了个大新闻。
Spring 的 SerializationUtils 我看只有开启了 才有可能用到。
大部分项目应该也都不用 Spring 的 cacahe 。

今天出的是 spring RCE ，不是前几天的 Spring cloud function RCE ，楼上几个别搞混了

现在公司百分之 90 之上都是 1.7 和 1.8 吧， 最起码应该是个 11.

然而真的比其他好用得多，也是一家独大

只要 1.8 没大的安全问题，万事大吉

上来一张微博截图 剩下全靠编

强烈围观一下！

github 有

问题是淘汰了 spring 了用啥呢
注解配置也没多少东西，想要配置基本跑不掉反射（除非做 mircronuat 那种 apt 代码生成

了解的越多越会发出我艹真妙，我怎么想不到的感叹，你这寥寥几句就要淘汰 Spring

Spring Cloud Function 没几个项目用吧？

能展开说一下嘛？

是个技术都有利弊，不去衡量优缺点，反正就要喷彰显自己的优越感。

能展开说一下嘛？

要组件互相依赖，还要解藕，要么扫包反射、要么编译期做文章。
所谓的又臭又长的配置，就是默认配置不是自己想要的。

扫包的根本目的是不是自动装配而不是依赖解耦？
为了自动装配各种三方包，涂一层封装，然后外化到配置文件，这真的有很大意义吗？
我对 spring 了解不深，所以对它的流行相当茫然。

quarkus 牵着 micronaut 的小手表示看戏.

抛开 Java 很多时候过度设计不说。一开始必用 Spring 的原因是依赖注入带来的事务管理器，之后就是 Spring Boot 简化了一堆配置。
现在直接用原生 Servlet 搭个项目是真的要愁死人。

我的理解 依赖解藕 基于 自动装配（控制反转 + 依赖注入）。

没理解外化到配置文件是什么意思。

这下万年 Java8 的又有不升级的理由了😅

这个漏洞是说的 SpringBoot 2.6.5 刚刚修复的 “CVE-2022-22950: Spring Expression DoS Vulnerability” 么

这个漏洞应该是类似任意文件写入，据说是老漏洞补丁的绕过

Quarkus:😁😁😁😁😁😁😁

你是还在用 struts 么？开开眼吧，还又臭又长，笑死

原来还有这样的历史，涨知识了，是不是说依赖注入导致事务管理变得复杂了？给我的感觉是现在基于注解的事务管理方式比编程式更加复杂不可控。不是抬杠，“简化”与黑箱伴生而存，可能这是社区思考后决定承受的代价吧。

就是说 spring 选择了以自动装配的方式达成依赖解耦？那确实没啥说的，因为我觉得 springboot 的各种问题缘由就在自动装配。个人更倾向于显式的编程式的配置。
外化到配置是说，用配置代替编程接口，这中间增加的复杂度我个人认为不值得。

凭什么觉得比 log4j 危害更大呢

2010-1622 相关

这下，坚守 jdk8 更有理由了

（绝不是因为懒）

建议客户使用 PHP

说了新版本不稳定不可靠吧（幸灾乐祸），jdk8 可以再用十年。

怎么又是 java 的

扫包的根本目的，ioc 和 di 怎么不是为了解耦

并没有，大部分情况下一个注解搞定，单理解手写大部分都需要理解很久

如果在 a 类用 b 类的非静态方法你要 new 然而用 spring 后不需要 new 交由 speingioc 管理，而且面向接口直接声明接口即可

外化到配置不理解

还是 jdk8 的多

你没看明白或者我没说明白，我上面说的自动装配不是类的自动装配（ di ），而是库。另外 ioc 为什么就得扫包？如果必须扫，那其它的 di 框架都是假的，如果不必须，那目的就不完全是 di 。

spring-framework 是不扫包的，但是你要声明每一个你要用的 bean ，SpringBoot 简化配置，通过扫描的方式，省略繁琐的配置。 一个项目你要用的 100 个类，你要配置 100 个甚至更多的 bean 标签，折磨啊

外化到配置确实不是通用语吧，这么说吧，程序员面向接口 /类 /对象编程，在 spring 里面向配置 /注解编程，虽说过于极端，但也是它很突出的一个现象。用 spring 做项目给我感受最大的是离不开搜索引擎（说我菜我肯定认），因为注解和配置打断了我通过 IDE 调试的过程（还是菜），而不用的时候我都可以通过 IDE 和库文档进行下去，几乎不用去搜索。

DI 肯定是要知道使用的对象和需要注入的对象全类名，构造函数和 setter 方法，如果 IOC 不扫包，这些都是手动配置， 库有自动装配吗。 你是指 SpringBoot 的 starter 吗

1. 既然对 spring 了解不深，那其实很多道理也没法讲清楚。只能说 spring 做得够早够好，抢占了先机，后来的框架虽然有各种优势但是都做不到颠覆，于是大家就还用 spring
2. 事物控制是可以独立使用的，和依赖注入没关系，各种东西自己 new 自己组装也行。事务切面就不用说了是依赖切面的。编程式的事务 api 貌似也有，但是应用场景太少了
3. 编程组装可以，但是东西多了之后编程组装太墨迹了不是么

4. bean 声明之类的外化配置现在没人用了，现在只是把真正的“配置”外化

   这个我知道，但是拿 guice 来对比呢？

   我可以通过规范了解到 spring 的都是 springl 开头，然后都有代码提示，然后也可以点击跳转对应的 Properties 例如 RocketMQProperties
   /**

   • The name server for rocketMQ, formats: host:port;host:port.
     */
     private String nameServer;

   /**

   • Enum type for accessChannel, values: LOCAL, CLOUD
     */
     private String accessChannel;

   private Producer producer;
   对应名字和注释挺简单的，如果是需要 new 就强耦合了，多数据源多种数据库也会麻烦。
   去注解大部分是为了自定义，SpringBoot 的 starter 默认是可用的(三方做的不一定)，为了项目的需求进行一定的替换定制化，如果该类用户代码写了注入容器，Spring 就会取消自己的装配

   显然不是

   显然不是这个洞

现在 Spring Boot 也是滚动更新，J9 以上也是滚动更新。凡是滚动更新，不出漏洞才不正常。当然，对于 Spring Boot ，以及所有库，的滚动更新，如果你写好写全了单元测试代码（相比于只编码，工作量最少加两倍），那你只要一直用最新稳定版本就没事了，漏洞顺手就改，连手动测试都不需要。以上仅限于上层应用框架，JKD 这种底层基础设施，能不升级就别升级，尤其是 J9 以后那狗日的不考虑向后兼容性的滚动升级。

因为这个洞可以导致任意代码执行，并且条件只需要 spring+Java9 及以上

例如 redis
官方默认是可用，但是用户想用 json 可视化
(proxyBeanMethods = false)
(RedisOperations.class)
(RedisProperties.class)
({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })
public class RedisAutoConfiguration {

(name = "redisTemplate")
(RedisConnectionFactory.class)
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<Object, Object> template = new RedisTemplate<>();
template.setConnectionFactory(redisConnectionFactory);
return template;
}

(RedisConnectionFactory.class)
public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
return new StringRedisTemplate(redisConnectionFactory);
}

}

然后用户配置

public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
redisTemplate.setConnectionFactory(redisConnectionFactory);
StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
RedisSerializer