News for hackers. Stuff that matters.

sjones671

Re:Running local models on an M4 with 24GB memory on Sunday May 10, 2026 @08:29PM (#48089659)
Thanks for saying this. There's so much nonsense out there online about local models being better than Opus 4.7 and the like. It's just not true for regular users.

I have a brand new M5 MacBook Pro - top end with all the specs and I've tried local models and they're barely functional.

$40 million per year.
Surprising nobody.

ChatGPT wrote the following poem for me about Kubernetes

Kubernetes, a horror to behold, A tangled web, a cluster of cold, A confusion of pods, and nodes, and scripts, A nightmare to deploy, and troubleshoot, and fix.It's a monster, a beast, that never sleeps, It eats up resources, and CPU, and memory, It crashes, and burns, and takes down the whole site, Leaving users stranded, and administrators in fright.But still we cling to it, with desperate...

( Read More... | 5 comments | 6 points | on HN )
That’s a lot of zeros for some frozen peaches.
Re:Spring Core on JDK9 is vulnerable to remote code execution on Wednesday March 30, 2022 @11:12PM (#30863463)
The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked.

I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then.

I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working.

Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable.

To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..."

If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URL..."

I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.