<div dir="auto">Now it seems like a log4j formatting problem with versions prior to 2.15.0.   There are other unpatched vulnerabilities in log4j v1</div><div dir="auto"><br></div><div dir="auto">Next time, I’ll do more research, but continue to monitor your parsers and validators for stack overflow conditions due to deeply nested nodes.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 11, 2021 at 3:37 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Apparently there is a denial of service attack happening on log4j/struts/soap.   Imagine your X3D xml/json/VRML having millions of nested Groups and transforms.   How can we defend ourselves, and what limits can we set in place?  I do know tail recursion can help, but I’m not sure what happens when there are too many stack frames to open.<br>
<br>
I know the standard talks about limits on these things, but is there a limit of depth of nested nodes in the standard?  I will do some googling.<br>
<br>
Sent from my iPad</blockquote></div></div>