That's the thing though, setting bg color opens up a lot of options, and constraining to invert is not sufficient in my opinion.

Not necessarily. I have successfully exploited stack buffer overflows in major products despite stack canaries, ASLR, and DEP. It largely depends on context; if the vector is something that can be hit repeatedly, such a webform that that takes a cert or whatever, that simplifies things a lot versus something like a file format exploit, where you probably only get one chance. While I haven't analyzed this vulnerability, I would absolutely assume exploitability even if I couldn't see a way myself.

The same stuff happens when summarizing documentation. In that regard, I would say that, at best, modern LLMs are only good for finding an entrypoint into the docs.

a) Has the knowledge to run tcpdump or similar from the command line

b) Has the ambition to document and publish their effort on the internet

c) Has the ability identify and patch the target behaviors in code

I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently, and would have learned more along the way. Forgive me for being so critical, but the LLM use here simply comes off as lazy. And not lazy in a good efficiency amplifying way, but lazy in a sloppy way. Ultimately this person achieved their goal, but this is a pattern I am seeing on a daily basis at this point, and I worry that heavy LLM users will see their skill sets stagnate and likely atrophy.

Well, not quite. I think it's more that nobody has taken the time to implement it. That's not to say such an implementation would automatically decrypt the traffic from a capture with no extra leg work, of course. Wireshark dissectors have user configurable preferences, and presumably this would be where captured secrets could be set for use. This is how it handles TLS decryption [1], which works beautifully.

[1] https://wiki.wireshark.org/TLS#tls-decryption