NitpickLawyer

It's not 19hours. The server was originally configured with no running php. Once they added a php file, the server got pwned in 2 hours.

The e-zines can make a comeback, there's probably enough content now. phreak2030s: "put the local load in the bearing firmwares". Or something :)

Sorry, I thought you were asking about the tech applications. I have no idea about the other stuff, can't comment.

> what even are these experiences? whom are they for?

One possible use for these is to facilitate lab -> this -> real world for robot models. Basically better than lab / algorithmically designed environments and cheaper / easier to train on than real life. Something that "looks" like real life and can scale, to apply RL for robotics to.

IIUC, the first setup couldn't be exploited because the site didn't run any php. You kinda need the server to run some php if you're gonna use a php vuln. It got solved ~2h after they added a php-version.php ...

> (so you might not ever see a direct refusal)

A note that the only inference providers that hide thinking are the closed labs. Most (all, afaik) inference providers serving open models will send the clear thinking tokens always.

Sorry, I'm not following. Constrained generation is something that helps you, the caller, to get back a message that looks a particular way. I'm having trouble seeing how this would work in an adversarial way. Perhaps you can elaborate?

A malicious inference engine can already return anything it wants, it doesn't need constrained decoding on the LLM side. If your client blindly runs commands in an unprotected environment, you're already pwned. They don't even need to run an LLM, they could just randomly add "tool_response:{'execute':'rm -fR *'} and that'd be it...

> but massaging the sampler(?) also sounds like that might give a lot of control over outputs with the weights staying technically the same?

Yes, this is what constrained decoding means. You constrain the model to only output from a set of "allowed" tokens (a.k.a. grammars).

So, if you use tool use with constrained decoding, you can be certain that the model will always choose from a list of approved tools (i.e. if tools=['read','write'], it cannot output 'execute', even if in other sessions it could, if execute was in the approved tools).

The tricky problem is that certain models work / have been trained in certain ways. And constraining them can lead to "invisible" problems. Constrained decoding only guarantees perfect syntax, not perfect semantics (i.e. it could write nonsense in the correct file).

> Could something like that also be used in other contexts?

Sure. You can build pretty cool grammars and constrain the model to do cool stuff, akin to "tool use" but more free hand. You could, for example, make it always emit a 10 point plan. For any prompt, it will give you a fixed syntax 10 point plan, always. And the plan will be constant with a plan_title and 10{plan_item, item_text}. But, as above, there's no guarantee that the individual items in the plan would make any sense... (i.e. step7 in a pasta making recipe would be "add glue").

> So they admit that they could do more, but they won't?

Yeah, there's another paragraph:

> Identifying and removing cyber-related data. During development, we observed vulnerability research performance improving steadily as post-training scaled. Tracing the source of this trend, we found that cyber-related content was embedded within the general mid-training corpus, and cyber-related tasks were present in the RL environment mix — a natural byproduct of training on broad data. In preliminary experiments on internal models, we found that without data removal at either the mid-training or the RL stage, downstream cyber capability would increase substantially. These findings gave us a concrete lever for control. For the open-weight release of K3.1 Pro, we identified and removed cyber-related data from both training stages, while retaining the general-purpose coding tasks needed for model usefulness. We will continue to apply appropriate controls at every training stage, of which cyber-related data identification and restriction is one example.

(emphasis mine)

It's clear that cyber is a touchy subject right now. But it's also clear that RL works on it, because it's highly verifiable. So smaller models are going to become very interesting, because they can be fine-tuned later to cover this field.

I think the golden "catch 22" error will forever be the classic "No keyboard detected, press F1 to continue".

> so you say they only sat on it for a week?

This is absurd, and it shows that you have absolutely 0 idea of how any of this works. Finding a bug and delivering a working RCE 11 days later is absolutely not "sitting on it". This is how this works. You need time to test, exploit, confirm, and so on. Sorry, but just stop being so negative. This can't be healthy for you.

No idea what your comment is even about. The researchers that found and reported this did not sit on this for 2 months.

> 1 August 2026 [...] Ryan Austin finds the RCE paths, tweets a cryptographic hash on 5 August, and submits the bug and working RCE proof-of-concept to PHP between 11 August and 14 August.

> 19–24 August 2026: Wiz Research independently collides with the same bug family using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol, reporting its variants on 24 August.

I get some skepticism about marketing copy, but your comment is blatantly wrong and needlessly rude.

The difference is that meta is providing that service world wide. Depending on where the user is located, there are a ton of considerations to be made when deleting a user. The flow should go through all these things before being deleted.

- some countries require saving "the last known address"

- others require keeping logs about "the last known connection point" (IP)

- in some countries, if the user was a paying user, you need to retain payment details / invoices / etc for years

- some countries you can receive subpoenas that mandate what data should be retained

All these things need to be checked before deleting an account. Having a "manual" deletion endpoint would be more troubling.

As an aside, early in the GDPA implementation phase, there was coverage of many companies implementing it poorly at best. There are articles detailing how you could delete a user's account by sending the "required info" (e-mail, ssn) from another e-mail and they'd delete the account / send over data. Would you be comfortable with someone being able to delete your account like that?

> This is just telling the chatbot to lie.

Why do you think that? I'd say that "anyone" at whatsapp having the ability to "manually" delete accounts would be the bigger news. In large corps, no one should have that capability. Anything dealing with user deletion should go through a well established, legal approved process.

> The biggest LLM sellouts in open source

I'm pretty sure someone will soon call Linus a sell-out. The hate / denial / radicalisation is just sad at this point... Do, or don't, but at least don't hate the others. Be and let be. No need to call other people names just because you don't like their sand castle. There's plenty of sand on the beach.