And as usual, this is padded out with ill-fitting AI-generated stuff following textbook AI patterns. The only insight here is to add an explicit recursion depth guard - which follows automatically from an understanding of the issue. But the identified problem is crashing the process, which would be equally well dealt with by just handling the exception. (There's also a weird reference to the C++ API documentation despite that everything else shown is about Java.)
The overall structure is rigid, and yet the plot wanders. The introduction promises: "Read on to learn about how we discovered these issues and how to prevent them" - but nothing else in the article is actually about the discovery process (how did they develop and run the CodeQL query? How did they obtain data for it?); it just shows the general form of the vulernability, a single detailed case study and then one of the standard mitigations.
Oh, and of course: why on Earth would it be necessary to use a bullet-point list - consisting of two bullet points, where one of them is "audit your code" - to explain the fix?
The reason it's so short is because it's just a summarization of a larger paper[1] and talk[2]. This is mentioned explicitly in the second paragraph of the post as well as at the end.
(You're right that there's nothing so special about adding a depth guard -- it's CS 101. It's not intended to be communicated as profound; the thing that's supposed to be interesting is that actual vulnerabilities still fall out of this, as the post is meant to tease.)
[1]: https://resources.trailofbits.com/input-driven-recursion-whi...
[2]: https://www.districtcon.org/bios-and-talks-2025/low-effort-d...
It does not take many stack frames to overflow the stack. Java only handles ~10k frames by default. Most applications will have no problem with 10k loop iterations, and it might take millions to cause a notable slowdown. It is usually trivial to craft input causing ~10k recursive calls. An input causing millions of iterations is probably much harder. One example input from the whitepaper that crashed a real application is a string repeated 20k times taking up ~200KB. To get to one million iterations the request would be ~20MB.
The failure modes also differ significantly. Recursion crashes the application with a stack overflow. Iteration just ties up a thread. Web frameworks often auto kill busy threads after timeout anyway.
You could argue that catching StackOverflow exceptions is a built in defense as well, but the numerous DoS CVEs for stack overflow crashes show this is not a reliable defense.