update

4ra1n · 4ra1n · commit 6e8c8b72fda8 · 2022-02-14T15:12:18.000+08:00
diff --git a/README.md b/README.md
@@ -276,7 +276,7 @@ Shiro注内存马时候由于反序列化Payload过大会导致请求头过大
 
 - 谈谈Log4j2漏洞（★★）
 
-漏洞原理其实不难，简单来说就是对于`${jndi:}`格式的日志默认执行`JndiLoop.loojup`导致的RCE。有几处关键问题，首先日志的任何一部分插入`${}`都会进行递归处理，也就是说`log.info/error/warn`等方法如果日志内容可控，就会导致这个问题。这个漏洞本身不复杂，后续的一个绕过比较有趣
+漏洞原理其实不难，简单来说就是对于`${jndi:}`格式的日志默认执行`JndiLoop.lookup`导致的RCE。日志的任何一部分插入`${}`都会进行递归处理，也就是说`log.info/error/warn`等方法如果日志内容可控，就会导致这个问题。这个漏洞本身不复杂，后续的绕过比较有趣
 
 
 

Original file line number	Diff line number	Diff line change
`@@ -276,7 +276,7 @@ Shiro注内存马时候由于反序列化Payload过大会导致请求头过大`
`276`	`276`
`277`	`277`	`- 谈谈Log4j2漏洞（★★）`
`278`	`278`
`279`		-漏洞原理其实不难，简单来说就是对于`${jndi:}`格式的日志默认执行`JndiLoop.loojup`导致的RCE。有几处关键问题，首先日志的任何一部分插入`${}`都会进行递归处理，也就是说`log.info/error/warn`等方法如果日志内容可控，就会导致这个问题。这个漏洞本身不复杂，后续的一个绕过比较有趣
	`279`	+漏洞原理其实不难，简单来说就是对于`${jndi:}`格式的日志默认执行`JndiLoop.lookup`导致的RCE。日志的任何一部分插入`${}`都会进行递归处理，也就是说`log.info/error/warn`等方法如果日志内容可控，就会导致这个问题。这个漏洞本身不复杂，后续的绕过比较有趣
`280`	`280`
`281`	`281`
`282`	`282`