You laugh, but this is the kind of data that allows you to train models that actually catch a lot of corner cases, as well as generalizing to other 3D applications.
I'm not gonna comment on the morality of mass acquisition of all of this data, but as someone who deals in 3d in the medical/dental space everyday..
there's absolutely no doubt that all of that data is as valuable as gold in research.
On a tangential but related note..
I mean, people in possession of troves of data, especially in the medical or 3D industries, really ought to start understanding the value of the data they're sitting on. You can give it away if you like, but don't be upset when someone turns it into a couple hundred billion dollars and doesn't compensate you.
If you won't like it if tech companies rip you off, then take the legally required steps to protect your data. (That includes making sure you licensed your data properly. And protecting your data with explicit use licenses and, potentially, even access controls.)
Yes, but it also has many conditionals, for example:
- The faster package may have been available for a shorter amount of time and so downloads have not had the time to catch up yet.
- Many people may not be aware of the faster package, but they would switch if they knew.
- Maybe people are aware of the faster package, but there are switching costs that prevent them from adopting it right now that are greater than the costs incurred from the slower package.
I might be in Cornwall in a bit, so I might take you up on that :)
But yeah, it happens. I could share some stories of me (being responsible for) bricking multiple ~200k circuit boards in a row, if that makes it better. In the end nobody really cared and the world kept on turning. Good decisions might come from experience, but experience comes from bad decisions. It's how it is.
So how does the exploit actually work? The best I can find is that they manage to use the corrupted generic decoder state to write a single pointer and associated PHP type information anywhere in memory, then immediately claim "this is RCE". Is that enough? From my (admittedly limited) understanding of such things, after writing code to the target memory you also need to be able to start actually running it. Or do they overwrite the PHP code (which is somewhere in memory) and then let the interpreter do its thing?
But it was withdrawn; now it says that it (CVE-2026-109618) is not an RCE and not even a CVE, apparently an addref call prevents the use-after-free. CVE-2026-109619 is still a memory safe bug, but they have no RCE for that one
> We therefore control where PHP places a pointer and its associated type information. This is application-dependent RCE under both Apache mod_php and PHP-FPM.
Both articles describe how you can end up with freed memory that still has pointers into it. I can understand that this should never be possible, but it seems to me that both articles skip the very important step of how to actually turn this into RCE?
From my (admittedly limited) understanding of these things you would not only need to write arbitrary memory, but also need to be able to jump to the relevant address to execute such things. Or do they overwrite the PHP (byte)code with their own and then just let the interpreter do its thing?
It's generally safe for a defender to assume that if an attacker can corrupt the heap they can achieve RCE, because there are usually so many ways to do it. They're all very specific ways that are hard to find because of all the complexity and mitigations, but there are a practically unlimited supply if someone puts in the effort to find one. But as a defender you don't need to, you should just say game over as soon as you get heap corruption, and go fix it.
Generally the attacker has to cause a sequence of heap allocations so that a certain kind of object gets allocated into the freed space that's still being pointed to, then use the old pointer to corrupt that object, then use the object. A good target is any C++ object with a vtable pointer - not sure if PHP is written in C++. If you can rewrite a vtable pointer and make it point to attacker-controlled data, you can get execution to jump to an attacker-controlled address.
I don't know. Still, at a time like this I would expect a 99% static public website to be up, running and serving all comers. This is a complete mission fail, both in terms of using PHP and in terms of not having a fall-back plan in place.
Due respect, neither of those make sense. PHP is boring software, and this website routinely suggests (1) use it if it is fit for purpose and (2) don't rewrite for the sake of it. For most sites, the engineering effort to have a static backup of their dynamic website (say, generated by Wordpress or Drupal) just isn't possible. They just need to power down and patch.
[EDIT: I see I may have erroneously extended your criticism to sites other than NCSC, for which it does make sense. I would still defend using PHP.]
Because websites with news, continuously updated advice, job openings, etc aren't all that static? This type of site hugely benefits from having a easily understandable CMS that you can teach to more or less everyone in 2 days or less. I suffered through a few of those back in my time in the military, where an instructor would teach a class of 20-30 how to build new pages in the CMS
Now are there more powerful tools out there that result in more scalable websites? Sure. My personal sites are built around static site generators for that exact reason. But none of better tools are as easy to understand for non-programmers as wordpress or one of the other click-and-drag CMS tools.
Not all hacks are used to steal data. It's an authoritative website. If this hack is used to host a fake PHP fix stuffed with credential stealers then you have a problem.
Sometimes, they just want to send spam. Ages ago, someone got a hold of our company's webserver and all they used it for was sending a ridiculous volume of emails. Our ISP spotted the traffic spike and pulled our server off the network.
Oh I absolutely agree they should take it offline until the fix is ready, I just mean that the NCSC itself is very much still operational even if their public website is temporarily offline. Like a computer with the monitor switched off.
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
In an XML document a "processing instruction" can trigger the XSLT processor to transform the document in another format.
So an XML document would be parsed and processed by the XML engine, trigger XSLT processor, which would then trigger again the XML processor again and the HTML processor.
So XSLT processing for XML/XHTML is deeply embedded. Dropping it removes a lot of corner cases that AI is good at exploiting.
The cool thing with a wasm-based xslt implementation is there is no need for the browser vendors to gate-keep it. Just use the implementation you prefer.
Except XSLT dates back to the late 90s. WASM was not even a glint in the eyes of its creators. Mozilla even used XSLT internally to drive the GUI for their browser iirc. I think based on that there is a good reason it was incorporated into browsers.
If they were going to implement it themselves it would be unnecessary to faff around with webassembly. They could just keep the native code implementation that they already have.
The problem is that XSLT has so few users that the browser writers don't want to waste any more time on it. Those few people who wrote their site around it will have to either rewrite it to use something else or add some third party webassembly implementation themselves.
No it really isn't. People have transmuted a few hundred milligrams of mercury into gold in the lab with multi-million dollar machines, but that doesn't make it economically viable in the slightest.
reply