xx_ns

Thanks for clarifying!

I assumed they meant "also" as in "besides Cursor marketplace", which seems to be the highlight of the article. Although you raise a valid point and I've edited the parent comment.

While I don't disagree with you in principle, the context for JS JIT vulns and potential Python JIT vulns is pretty different and worth taking into consideration.

For JS, your machine running untrusted JS code is the intended use case. In this scenario the JS is sandboxed in whatever JS engine (V8 etc) and does not have access to "dangerous" methods, and the main use case for a JIT vuln is to escape this sandbox to execute code on the host. This applies to regular internet browsing (and visiting potentially malicious sites) and also, e.g., using the built-in browser in a locked down device (such as game consoles) to gain arbitrary code execution.

For Python, this security boundary doesn't exist. I can't really think of a scenario where you would be running potentially malicious Python code in CPython that would need a JIT vuln to escape whatever sandbox it is in instead of, say, calling the functions in Python directly (or using the C FFI to do whatever). I'm sure that in some niche use cases, this scenario might exist, but to me, it seems like the potential attack surface is fairly minimal.

EDIT: Also, I'm pretty sure that Python's copy-and-patch JIT writes code to a writable mapping and then mprotects it to W^X? I don't think it leaves RWX pages lying around at all.

It's unfortunate that a technically exciting new feature is being killed partly because of what is essentially bureaucracy (and the lack of the developer's personal bandwidth). On the other hand, it's pretty safe to say that the strict adherence to the PEP policy and all of the bureaucracy that comes with it is what makes Python a great language, for better or worse.

Not to say that the technical objections were without merit, they likely very much weren't, and the debugger and instrumentation support and maintenance work sounds fairly painful on its own.

> given it's vibecoded

Why is this a given? This service has been around for longer than LLMs have been a thing.

Interestingly, they added the `preinstall` key (that is supposed to run the malicious script when installed) under the package.json root, and not under `scripts`, so from what I can tell this wouldn't run on install.

Otherwise, yeah, this seems like a stage-1 loader for fetching and running a payload off the Ethereum mainnet.

Very good write up! Kudos.

I recently wrote about an RCE exploit in the game Project Zomboid (which uses Lua for mods), which also used loadstring as an initial entry point for the exploit chain, but since the Lua interpreter was fully Java, byte-code memory manipulation shenanigans were out of the question for me and I had to pivot in a more traditional way.

The fact that loadstring can also load straight up bytecode was news to me though, that's interesting to know.

This is a really cool project! A mini cyberdeck that doesn't seem too impractical to use. Repurposing the Clicks keyboard is a genius idea.

I find a lot of LLM articles to be hard to read, but since this one was pretty "straight to the point", I found it to be okay and got the important information across.

The title "The Linux reality check" made me groan, though. LLMs (Claude?) seem to love this phrase.

It makes sense. The chess piece is the first profile picture in the list.