To be fair, this is literally the only thing AI is being sold as useful for that actually works.

Well, they're called "zero days" for a reason.

An important point yes and I do understand that, but the major players like Steam were updated and done before I knew it. I have no doubt this could come back to bite companies/people lagging behind over the next few years, but the impact to me from websites being taken down was 0, which was my point.

How's Rust holding these days I wonder? Always wished I had learned it when it first came out ha.

That would be the best result if everyone just went back to static sites.

but what about vulnerabilities in the web server? 😱

I think there's been one or two image decompression exploits over the years, so a site with a malicious file could end up running code on your system. I remember this being an issue with Minecraft clients and player skins at one point, but I can't remember any specific times this happened in browsers tho.

Yeah but if it's just pure HTML you got an ugly-ass website that's annoying to use. There's been many JavaScript and css vulnerabilities over the years of course. But yes there was and still is plain HTML issues

Client side:

• I vaguely remember some base64 embedded encoding malware.
• I do believe there was some issues with early HTML, if you had malformed tags, that could bypass checks and balances.
• Svg, Images, audio, fonts, and video can definitely contain malware. Before you say fonts are a css thing, was a real tag
• IFrames were the worst:
  • They had too much power in the past and could hijack the page and browser.
  • There was no content security policy back then so they could inject JavaScript into the main page as well.
  • Also they can cover the whole screen and present a normal login screen, and hijack all inputs going through it. Think of it like you're on dodgey-site.com and it has a full page IFrame to bank.com. This was a common hack back in the day which inspired an entire http header to help prevent this.
• Anchor tags can link to something dodgey of course.
• Embedded PDFs were a huge issue.
• ActiveX and other web applets was just fucked. They were so bad they caused malware constantly. This is where unsolicited toolbars came from.
• Adobe Flash had many many vulnerabilities over the years.
• Canvas bugs are still a thing today.

Server side, you could execute SQL injection and path traversal just via URL before the page even loads. Malware and other issues can be embedded in text inputs. HTML can be uploaded to the server and in some cases replayed on the page affecting other users (comment sections were infamous for this).

So yeah; a plain HTML page with no JavaScript or css isn't necessarily safe

My man

I build custom websites that run primarily on css and html. Light JS for applications, and some simple PHP to tie everything together. I am unaware of any flaw or exploit that would disable my sites. I don't recall any html vulnerabilities. Unless there's e-commerce involved, that's nothing I can think of that would be exploitable on either side for html or css. These are both hard coded into the browser so I'm not even sure what an exploit would accomplish other than changing values on the client side. But it's been a long week...

Edit Looks like zarobi below remembered some exploits. Totally forgot about iframes and the weird image data exploits.

I never noticed how long the sales guy's hand is

I'm with you on the first part but I believe that 2/4 PHP exploits have been observed in the wild.

That's exactly the thing. They call themselves PoCs, but most of the time the exploit chain that they "prove" relies on some extremely unrealistic condition, like the intruder already having elevated privileges. Or it's just completely made up and the PoC only "works" because the AI changed the source code. It's incredibly unreliable.

If only it were that easy, if you do that, the managers will be grateful certainly, but they will also endlessly demand more proof and validation that the system is now completely safe from certain doom until they feel comfortable, which is never. In a lot of cases it's simply easier to convince them that the system was never vulnerable to certain doom in the first place, because you were of course already 5 steps ahead of this even in the planning stages, and for some reason they have an easier time accepting that, as long as they still have every reason to believe you are a brilliant tech god who would never personally fall victim to such a common vulnerability. I suppose it's really less about the reality of the situation and more about what kind of corporate image you are cultivating and maintaining for yourself.

the technique of repetitions there didn't do the expected subject emphasis for me.

now that you mention it, influence of llms could be what it is.

In lua you will typically lua_pcall() the entry function written in Lua, but it will often call back into your C functions to do various tasks. Now if your C functions do anything with the lua stack, that might cause OOM, but now your lua_pcall() will catch that - or any sort of error catching inside Lua itself - and you'll be looking at an accidental recovery situation.

At least that was how things looked like when I last poked around Lua a few months ago.

So as far as I know, it's actually not trivial to make Lua safely abort on OOM, and it's not the default behavior. I also don't think there are lua_push* function alternatives available using the default C API that don't longjmp in a likely often unsafe manner out of your C code if you use them and you hit OOM.

Summed up, I would expect many Lua integrations to have the same problem.

cgi-bin